Rubber Stamp
Noun · Hacker Culture
Definitions
Rubber Stamp in software development describes a code review practice where a reviewer approves changes without carefully examining them. The reviewer may glance at the diff, leave a quick approval, and move on, providing no meaningful feedback on code quality, correctness, or design. This defeats the purpose of code review, which exists to catch bugs, improve code quality, share knowledge across the team, and ensure consistency with coding standards. Rubber stamping often occurs when teams enforce review requirements without fostering a genuine review culture: approvals become a gate to pass rather than a quality checkpoint. Contributing factors include time pressure, large pull requests that are overwhelming to review, uneven technical knowledge between reviewer and author, and social dynamics where junior developers hesitate to critique senior colleagues. Combating rubber stamping involves keeping pull requests small, rotating reviewers, establishing clear review checklists, and building a culture where constructive feedback is expected and welcomed.
In plain English: Approving someone's code changes without really reading them, just to move things along.
Example: "Don't rubber-stamp that 2,000-line PR — break it into smaller changes so reviewers can actually give meaningful feedback."
Etymology
- 1860s
- Charles Goodyear's vulcanized rubber enabled the first commercial rubber stamps, used for approving documents with a quick impression.
- 1990s
- In software engineering, 'rubber stamp review' emerged as slang for code reviews where the reviewer approves without meaningful examination.
- 2000s
- Agile and open-source communities formalized concerns about rubber-stamping. Projects began requiring substantive review comments before merge approval.
- 2020s
- Automated CI/CD pipelines and AI-assisted code review tools raised new questions about whether algorithmic approvals constitute rubber-stamping.
Origin Story
The Review That Barely Glances Before Approving
A 'rubber stamp review' in software development refers to a code review where the reviewer approves changes with little or no meaningful scrutiny, much like a bureaucrat stamping documents without reading them. The metaphor dates back to at least the early 20th century, when rubber stamps became common office tools for marking official approval. In the physical world, the phrase took on a pejorative tone by the 1930s, describing legislative bodies that automatically ratified whatever was put before them. The term migrated naturally into software engineering as code review became standard practice in the 1990s and 2000s. With the rise of GitHub pull requests and mandatory review gates, rubber stamping became a recognized anti-pattern. Teams that required approvals before merging sometimes found reviewers clicking 'Approve' with a cursory glance just to unblock a colleague. The practice undermines the entire purpose of peer review: catching bugs, sharing knowledge, and maintaining code quality. Modern engineering organizations combat rubber stamping with metrics like review depth, comment rates, and tools that flag suspiciously fast approvals.
Context: Borrowed from early 20th-century bureaucratic language and applied to superficial code review practices.
Fun fact: A 2018 study by Microsoft Research found that code reviews taking less than 15 minutes were significantly more likely to miss critical bugs, suggesting a strong correlation between review time and defect detection.