One of the most enjoyable, and at times scary, things about working on my team is doing code reviews. They are mandatory no matter how “senior” you think you are or how long you’ve been on the team. I sometimes catch myself thinking “better not add Mr. SoAndSo because he’s going to point out all the ugly things in this pile of hacks I’ve been constructing here”. It’s those times where I just go back and try to make things less hacky. And then add that guy who would have the most objectively critical eye to look at the code change.

Do code reviews. You’ll occasionally butt heads, as there’s rarely a single “best” way to make even the simplest bug fix. But no matter how “senior” or “junior” your reviewers may be, you’ll always be better off at the end. I lost count of the number of times that I said to myself “Huh, I didn’t know that” after seeing a reviewer leaving his comments. Not to mention that you’ll have somebody else having at least some level of familiarity with your code if you ever get too swamped. Don’t count too much on that though, as people weave in and out of projects.

Every once in a while you’ll get out of your comfort zone working on a new feature or fixing a bug. At some point you know your reviewers, their style and their strengths. Don’t be tempted to add reviewers that will be inclined to rubber stamp such code. Seek out people who are deeply familiar and well versed in the specific area. You will be afraid that they’ll pick your code apart like a poorly constructed house of cards it is. Better now than after it ships. Such a reviewer knows how to do this better than you, and the result will be better for both you and your code base. It will just take longer. Don’t let your ego take a hit. It’s just code.

When you’re asked to do a review, do it quickly. Don’t drop everything and do it immediately, but do it the same day. The quicker you provide good and actionable feedback, the fresher it is on the side of the code author. Don’t let your reviewers rot. This also helps preventing unnecessary rebases. Not to mention spreading your strengths around, and learning from the strengths of others.

Don’t do gigantic code drops. If it’s a big feature, map out smaller steps towards the final goal. Mark unfinished places with TODOs so that the reviewer knows this is not the final thing. Build trust in each other to understand that sometimes the road to the final feature takes multiple steps. But always keep an eye on those first couple of steps to make sure that the road is taking the right overall direction.

Stay focused on criticizing code. If you feel strongly about something, be direct and concise. But never ever ever get personal. See the arguments for what they are and for what they should be. You are not your code. A critique of your code is not a critique of you as a person. Sometimes it’s hard to tell the difference especially if you’ve been working on something for a long time. Code reviews are a negotiation. It’s not a zero sum game. In the end, it is all about clarity and complexity.

There’s no better opportunity than doing code reviews to grow and become just that much better. Every single day, if you can. Even after all these years. There simply is no such a thing as those mythical 10,000 hours in our field.