In the past several years, I’ve moved from jobs with solo developers to jobs with teams. The jobs with solo developers, obviously, lacked a culture of peer review – when there’s only one developer on the team, having a co-worker review code before it’s shipped is a bit difficult.
Unfortunately, most of the larger teams of which I’ve been a part have also lacked a culture of peer review. More often than not, these teams were comprised of formerly-solo developers who didn’t understand the value of the review. Sometimes, they contained very senior engineers who felt they no longer needed peer review.
No matter your position, your tenure, or your experience, you should always have someone else double check your code.
#WorksForMe
Most often, the issue at hand is that code will run on one machine or in one environment, but not others. I’ve seen this happen when a piece of code requires a library or other dependency and the developer writing that code has a copy of the library or dependency that’s out of date, modified, or comes from an unreliable third party.
The code will run on their system and pass any and all tests it needs to; when moved to production, or just a peer’s machine, it fails in a ball of fiery glory and everyone wonders, “what happened?”
Asking a coworker to not just review your code but make sure it actually works on their machine helps avoid this frustrating situation. If you’re working on one operating system (i.e. Windows) and your customers might be using another (i.e. Mac), it’s also useful to have a coworker test in the environment your customers will be using.
The number of development tools that claim cross-platform compatibility but which are unusable on either Windows or Mac is astounding. The number of developers using them anyway demonstrates just how infrequently we actually test on the rival platform in the first place.
Hubris
I’ve worked on teams with entrenched senior developers who demonstrated a remarkable level of arrogance when it came to code review. In one position, where I’d just learned and was still using Visual Basic, I was told by a lead engineer explicitly to never touch his code.
“Maybe after you’ve graduated to a real language you’ll have the chops to understand how this works. Right now, I don’t want you wasting your, my, or the company’s time looking at this. You wouldn’t understand it anyway, so don’t even bother. By the way, you’ve got bugs here and here, so obviously you have a few years to go before you’re experienced enough for a review.”
The irony: he was also using Visual Basic. And had far more bugs in his code when I finally ignored him and checked out his repository anyway.
It doesn’t matter how much experience you have, how many years of bug-free code you’ve written, or the “senior” nature of your job title: you’re human. Humans make mistakes, and that means even you can make a mistake.
I’m presently a senior engineer. I have a large team of engineers working on projects with me and often only need to work on the more sophisticated coding problems in our projects. I still ask other engineers to give me a “sanity check” before I ship code because I recognize the value of having a second (or third) set of eyes on the code.
The more perspectives you have on a problem, the more diverse the solutions you can find – one of them might be better than others. The more perspectives you have on a proposed problem (i.e. ready-to-ship code). the stronger your confidence will be that it’s the right solution and the best solution.
There is never a substitute for quality peer review.
