Code Reviews Are About The Future

One of my favorite podcast (about management of all things), is Manager Tools. Feedback is one of MT’s core practices, as you would assume, and feedback according to MT is always about the future.

Think about it – You want to give someone feedback over the awful, or awesome thing they did. Whatever happens, they can’t change what they did. You can only affect the future – either encourage them to not do it again, or do more of it. I’ll let you decide which is which.

And now for something completely different.

There was a question about code reviews in a Facebook group, and someone posted that refactoring and reviewing is probably a waste of time since you’re probably not going to get back into that code again.

And he may be right.
He may also be wrong, I can’t see the future so well.

We invest in refactoring and clean code, because we believe this investment will be valuable in cutting development costs in the future, because our goal is: Working code, over and over again.

But code reviews, they are not about hedging bets. They are really about the future.

See, code and test reviews are our opportunities to ensure our goal (especially the “over and over again”) is met. In code reviews we build our foundation of “this is how we write code here”. This is where we signal what is (and what is not) important for our teams in terms of code.

If we talk about names in reviews, for example, people will understand that names are important, and will put emphasis on naming the next time they code, because people are smart and get the message.

Now, notice that I called them opportunities, because if code reviews are done, let’s say, not effectively, we’ll miss our target. If we comment on everything we see, people will understand that everything is important, which means, nothing is important. You may be able to improve as a team, but not a lot.

That’s why it’s important to decide what to focus on in the code, prior to the reviews. It is even more important to stick to those decisions in the reviews themselves. Don’t comment on names if you’re focusing on complexity. You want to communicate the importance, over and over again.

Code reviews are about the future, and this is one of the cases where you can actually impact the future. Why bet, when you can change the odds?

If you want to learn more about code reviews and clean code, check out my Clean Code workshop. It’s future-liciuos.