I remember a release night years ago when a colleague, bleary-eyed at one in the morning, leaned over and said, “Can you just look at this before I push?” It was a single line of configuration. I spotted that a staging address had been pasted into the production setting. We both laughed, a little too loudly, and neither of us forgot it. Stories like that are why a second pair of eyes has graduated from optional extra to default expectation in engineering teams. This piece traces how that shift happened and where it seems to be heading.
How we got here: from heroics to habits
Early software shops often relied on individual brilliance. One engineer owned a subsystem, changed it when needed and was the only person who understood it. That worked until the engineer went on holiday, changed jobs or simply made a mistake at the wrong moment. Gradually, the industry noticed that quality depended less on the best individual than on the process surrounding them.
Several developments pushed in the same direction. Pair programming, popularised through Extreme Programming in the 1990s, put two people at one keyboard. Formal inspection meetings tried to catch defects through group reading. Later, distributed version control and the pull request made it natural to propose a change and invite comments before merging. Each step lowered the cost of asking someone else to look.
The current state of play
Today the pattern is mainstream. Most teams that ship regularly expect at least one other person to read a change before it joins the main line. What differs is the quality of the practice. In some teams, review is a living conversation that spreads knowledge. In others it is a ritual approval, with a quick click from someone who has not really read the change.
The healthiest teams share a few traits. They keep changes small. They treat comments as collaboration. They rotate reviewers so that expertise is shared. And, crucially, they review the things that are not code: infrastructure definitions, runbooks, data pipelines and release plans.
Trend one: review is moving beyond application code
Infrastructure described as code, pipeline definitions and dashboard configuration all change production behaviour, yet were once edited casually. The trend is toward giving them the same scrutiny as application logic. A mistyped variable in a deployment file can do as much damage as a bug in a function, and a reviewer who reads it cold is more likely to see the typo.
Machine learning operations is a clear example. Models, features, thresholds and training data all change outcomes. Our roadmap for data scientists and engineers moving models into production and our look at why operating discipline decides whether machine learning succeeds both point toward the same conclusion: when many hands touch a pipeline, having another person read each change is part of operating responsibly.
Trend two: pairing for debugging and learning
More teams now schedule pairing not to produce code faster but to unstick people and share understanding. Two engineers looking at a failing job together find the cause sooner than one engineer circling alone, and the newer person learns how the senior approaches the system. Remote tools have made this easier, since a shared screen and a voice call recreate most of what a shared desk offered.
Trend three: reviews that look at the human side
The conversation is shifting from “did you find defects?” to “did the exchange leave both people better informed?” Teams are paying attention to the tone of comments, the speed of replies and whether quieter members feel able to challenge senior authors. A review culture that intimidates people produces approvals without scrutiny, a result that is arguably worse than skipping review, since it manufactures false confidence.
Trend four: the same instinct outside work
One of the more interesting developments is how engineers carry the habit into daily life. Many now ask a friend to read a rental agreement or a travel booking before paying, exactly as they would ask a colleague to read a change. The same applies to arrangements made for family. A medical tourism website like KneeHospitals, a site that arranges hospitals and doctors under their destination countries and offers enquiry and appointment forms, is a typical setting where the form-filling is simple but the details matter, and a second reader before sending is common sense. Again, that concerns the paperwork and nothing else.
Trend five: smaller teams, more shared ownership
As organisations flatten, fewer engineers sit in narrow specialist lanes. Platform duties, deployment and on-call responsibilities are spread across more people, and that makes it more likely that the person changing a system is not its original author. In that setting a second reader is not a luxury but the means by which context travels. A reviewer who knows the old behaviour can say “this used to be handled upstream,” which no amount of reading the new code alone would reveal.
Teams adapting well tend to pair each newcomer with a rotating reviewer during their first months. The newcomer benefits from guided exposure, while the reviewer is forced to explain assumptions that had become automatic. Both sides come away with a clearer picture of how the system really behaves, rather than how its documentation claims it does.
What gets in the way
- Time pressure. When deadlines tighten, review is the first thing cut, which is precisely when errors are most likely.
- Large changes. A reviewer facing thousands of lines can only skim.
- Ownership silos. Teams that guard their area jealously resist outside readers.
- Uneven reciprocity. If only juniors get reviewed, the practice feels like surveillance rather than partnership.
Where it seems to be heading
Expect review to become more continuous and more tool-assisted. Automated checks already handle formatting, known vulnerabilities and obvious mistakes, freeing humans to concentrate on design and intent. That is a good division of labour, provided people remember that tools check what they were told to check. The question “does this make sense?” still needs a person who did not write it.
Expect, too, a greater emphasis on teaching through review. Teams that want to grow people quickly are turning review comments into a learning channel: explaining why, linking to examples and recording recurring patterns in shared notes.
A closing thought from that night shift
The colleague who caught my pasted address did not outrank me, did not know the system better and was not even on the same project. They just had not been staring at the file for six hours. That is the secret ingredient, and it is available to any team that decides to ask. Make the request easy, reply promptly when somebody asks you, and say thank you out loud. Gratitude is what keeps the whole arrangement running, and it costs nothing to offer after even the smallest catch. The trend is real, and joining it takes one message to a colleague, whenever you are ready to send it.