Out of the abyss: Why you need to start peer reviewing

Developers are introverts. It's just part of the gig. The iconic image of a developer is clamped with headphones, gazing down at a tottering laptop screen, drenched by its blue light in an otherwise dark room. Face it, we thrive in isolation. We're fuelled by music and stymied by meetings. We build things the way we want them to be, and we're our own harshest critics. Code is art. We're artists. Like all artists, we thrive on a steady diet of the liberty to create beautiful things. Alone.

So wouldn't it be great if life really afforded for us to act like that? We all know the sad realities of billable time, sprint goals, planning sessions, client needs, and that pesky bug in the universe that won't let a day exceed 24 hours. All of that amounts to a huge infringement on our desire to work in a vacuum. It's maddening.

It shouldn't be, though. It's not such a bad thing that we're forced to come up for air once in a while and join the rest of the functioning world. Getting other people involved in what you do may feel intrusive, and it may disrupt the delicate ebb and flow in that code laboratory between your ears, but I can promise you -- it will make you a better developer.

Having your code peer reviewed, and becoming a peer reviewer yourself is a great way to get out of your head a bit and remind yourself that what you're creating is about much more than you. The people who surround you aren't just fixtures on rotating chairs. They can help you, and, in turn, you can help them.

Your job as a developer is not just to write code. The end game is to produce a great product, and helping out your team members is one way to increase your chances of getting there.

At SilverStripe, we have a team who wanted to encourage this type of proactive peer reviewing, and decided to gameify it. Team members earn points every time they voluntarily walk over to another team member's workstation and offer their help. At the end of the sprint, the team member with the most points wins a small prize. So far, it's working very well.

It's important to remember what a peer review is not a failsafe. When things go catastrophically wrong, you may be tempted to blame the peer reviewer for failing to surface the critical bug. The logic is that the peer reviewer is the last link in the chain, and ultimately the decision to merge the bad code is what brought the site down. Stop thinking that way. That's not what peer reviewing is about. Peer reviewing is just a safety net. Ideally, it should catch everything, but sometimes it won't. If you're constantly relying on the peer review to surface critical bugs, you should take that as a queue to look further down the food chain for problems.

Instead, think of peer reviewing as a security system on your house. In most cases, just having it in place is enough to improve outcomes. Sometimes, it will be defeated, and bad things will happen, but that is not a reason to remove it all together.

So take off those headphones every now and then. Turn on the lights. Look around. Learn your co-workers' names. You might learn something.

But once you do, don't forget to jump back into that dark coding abyss. It’s nice in there.

Want to know more?

Whether you already have a peer review process established, or are new to the idea, these ten tips, for both reviewers and reviewees, can help you become a more aware developer and position you for growth.