Jesse Storimer has great thoughts on code review and pairing. You Should be Doing Formal Code Review:
Let’s face it, developers are often overly confident in their work, and telling them that something is done wrong can be taken as a personal attack. If you get used to letting other people look at, and critque, your code then disidentification becomes a necessity. This also goes vice versa, you need to be able to talk about the code of your peers without worrying about them taking your critiques as a personal attack. The goal here is to ensure that the best code possible makes it into your final release.
I struggle with this so much, on both the giving and receiving side. When I’m reviewing code, I find myself holding back so as not to come off as saying the other person’s code is awful and offensive. On the receiving side, I often get frustrated and feel like a huge impediment has been put in front of my ability to ship code. In reality, neither is the case. Whether I’m the reviewer or the reviewee, the other party is simply trying to get the best code possible into production.
Jesse has further great points: review helps you avoid shortcuts, encourages one to review their own code (my favorite), and it makes for better code.
More recently, Jesse’s pointed out that pairing isn’t necessarily a substitute for code review: “…pairing is heavyweight and rare. Code review is lightweight and always.”
In my experience, pairing is great for cornering a problem and figuring out what the path to the solution is. Pairing is great for bringing people into the fold of a new team or project. Review is great for enforcing team standards and identifying wholly missing functionality. Review is sometimes great for finding little bugs, as is pairing.
Neither pairing or code review is a silver bullet for better software, but when a team applies them well, really awesome things can happen.
2 thoughts on “Whither code review and pairing”
As time goes on I realize more and more that getting better at programming has more to do with my personal development than with code itself. A certain proficiency with code is required, but beyond that…
Thanks for the follow up, I’m always glad to know that I’m not the only one struggling with this :)
One thing that has hit me in the past is the tendency for developers working in a team to develop individual ideas of code ownership. Someone has coded a particular piece, hence it is theirs and if you touch it they take offence. I’ve always been of the opinion that the code becomes the team’s code as soon as you check it in, and therefore everyone is free to improve it immediately. This avoids the overhead of articulating the critique and hoping the reviewee will actually follow through on it.
Comments are closed.