On a rainy Tuesday in Utrecht, a six-person platform team at an invented logistics company, which we will call Brouwer Freight, deployed a change that rerouted all of its test traffic into the live customer database. The change had been written by Daan, the team’s most careful engineer. He had read it three times. It still went out wrong. What follows is a made-up story, and the names are made up too, but anybody who has shipped software in a team will recognise the shape of it.
The change that looked perfect
Daan had spent two days refactoring the environment settings so that each service read its database address from one place. It was tidy work. He ran the unit tests, which passed, and he reread the diff while eating lunch at his desk. Everything read as intended, because Daan knew what he intended.
What he could not see was that a default value, left over from an experiment the week before, pointed at production when a particular variable was missing. In staging the variable was present. In the new preview environment it was not. Nobody was careless. The error sat exactly where Daan’s attention never rested: in the line he had written first and trusted ever since.
Forty minutes of confusion
The first sign was a customer-support message about duplicate shipment entries. Then the on-call engineer, Sanne, noticed that the load tests she was running appeared in a dashboard of real parcels. The team gathered around one screen, tracing the problem backwards. Within forty minutes they had rolled back the change and begun to clean up the strays.
No parcel was lost, but a lot of goodwill was. The retrospective, held two days later, had the sombre tone of a team that knew the mistake had been small and the consequences larger than they should have been.
The question that changed the retrospective
Midway through the meeting, the newest member, Fatima, who had joined only a month earlier and still felt unsure about speaking, asked a gentle question: “Who else read the change before it went out?” The room fell quiet. The honest answer was nobody. The pull request had been approved with a quick thumbs-up from a colleague who trusted Daan’s reputation and skimmed the summary.
That was the hinge of the story. The team had a review step, but it had become a formality. What they lacked was an actual second reader: someone who sat with the change, asked what happens if a variable is missing, and read the file from top to bottom instead of the diff alone.
Trying pairing, with a few rules
Brouwer Freight did not buy a tool or write a thick policy. They agreed on five simple rules, taped to the wall by the coffee machine:
- Anything that touches shared configuration gets a named reader before merge.
- The reader reads the whole file, not only the changed lines.
- The author states, in two sentences, what could go wrong.
- Readers ask at least one “what if it is missing or empty?” question.
- Everyone reviews, and everyone is reviewed, including the team lead.
The fifth rule mattered most. When the lead, Joost, handed over his own change to be read by Fatima, the room’s attitude shifted. Being reviewed was no longer something that happened to people who made mistakes. It was simply how the team worked.
What the first month brought
In the first month, the team caught seven problems in review that would otherwise have reached staging or beyond. Most were small: a hard-coded timeout, a copy-pasted hostname, a log line that printed a token. One was nearly a repeat of the original incident, a default that pointed the wrong way. Sanne found that one, and she said later that she only noticed because she had not written the code and so did not know what it was supposed to say.
The team also found that reviews improved their own reading skills. Engineers began to ask themselves, before sending a change, what a reader would ask. Daan said he now rereads his work imagining Sanne looking over his shoulder.
The awkward second week
Not everything went smoothly. In the second week, two reviews sat unread for three days because everyone was busy with a customer deadline, and Joost nearly waived the rule to get a change out. Sanne objected, politely. She proposed a compromise: a fifteen-minute slot after the morning stand-up, reserved for reading each other’s changes, nothing else. It felt artificial for a few days and then became the part of the morning people liked best. Reviews that waited a day or more disappeared, and the slot gave the team a quiet routine at the start of each day when questions could be asked without an audience.
There were also moments of friction. Daan, used to being the one others trusted, found it uncomfortable to have a junior colleague question his naming choices. He said so in a retrospective, and the team treated it as a useful admission rather than a complaint. Talking about the discomfort openly made it shrink.
Growing through review
Fatima’s career benefited from the new routine. Reading other people’s changes taught her the codebase quickly, and her questions, fresh and unburdened by assumptions, turned out to be exactly what the team needed. Stories like hers are common in engineering careers; the overview of how people move from a first DevOps role towards a senior one notes how shared review is one of the quickest ways to build judgement. Another walkthrough, a roadmap listing abilities, side projects and qualifications for engineers in this field, lists collaboration alongside technical skills for the same reason.
A visit from outside the story
A few months later, Fatima was helping her uncle in Rotterdam look at options for treatment abroad, which is a private matter and not one this story will touch. She did, however, notice how many forms he had to complete. One site they browsed was KneeHospitals, a portal for overseas patients with hospitals and doctors grouped under each country and forms for quotes and appointments. Fatima made no medical comment; she knew nothing about that. She simply sat with him and read each entry back before he sent it, catching a transposed digit in his phone number. It was the same habit as at work, applied to an ordinary form.
What Brouwer Freight learned
Twelve months on, the incident log looked thinner, though they were careful not to claim the review habit alone was responsible. They had also changed other things. But the engineers agreed on a few lessons:
- A review that is only a thumbs-up is not a review.
- Readers find different things from authors, especially when they read whole files.
- Reciprocity keeps the practice friendly.
- Newcomers are valuable readers precisely because they assume nothing.
As the team grew, new hires were asked to review something in their first week, partly as training and partly because a first-week reader sees things nobody else can. For those wondering where to build credentials alongside such habits, the comparison of certificates that help a DevOps career move forward is a sensible place to start.
Epilogue
Daan still writes careful code. He still reads it three times. But when he finishes, he sends it to someone else, and he enjoys reading theirs in return. On the day of the incident he thought he needed to be more careful. He now thinks he needed to be less alone with his work.