I was once in a -casual- tech interview in Sausalito. The VP of Engineering asked me: “how do you do code reviews?”
I was taken by surprise by the question. I took code reviews for granted like it was something natural, you don’t need to think much about it.
After that experience, I’ve started to pay more attention to how other colleagues were doing code reviews. I’ve found they were all ego-driven:
1) I can teach you: some engineers browse through the code and look for areas where they can shine and teach. A piece of code that can be optimized, revealing a gem of knowledge for them to share.
2) I don’t have time: “I’ve looked to all the code. I didn’t see anything horrible, so I will approve your changes, and we both can move on with our lives.”
3) Let’s talk about business: especially managers, they will ignore the code and go for the logic. Is it pulling the correct data? Is it outputting the right information?
4) Let’s achieve Nirvana-level perfection: 100% code coverage, the perfect variables name, the most optimized block of code. Let’s waste our all budget and time on this because it needs to be perfect.
Code reviews it is an overlooked area these days, although you can trace back documents since the ’70s.
One step in the right direction is to have a process. Your engineers are already doing code reviews. Ask them how they do it. Remove the ego factor, and come up with an egoless process they can follow.
