3 Wishes for My Future Code-Reviewers
When I first started working as a software developer in a dev team, I sat down and tried to figure out — how am I going to be the best at what I do? I thought my way to being a super-awesome-kick-ass-coder was to just work on the hardest tasks, with the smartest people. That turned out to be only partially true.
I have a confession to make — my tendency as a person is to just go down the rabbit hole and do it all on my own. I have a hard time asking questions because I’m eager to prove myself. I enjoy the adrenaline rush of learning something new, and like many of my colleagues — I was professionally educated to think that in order to solve a very hard problem, you have to squeeze your brain until the solution is formed.
This is how I rolled, and it seemed about right for a while — until I was lucky enough to have a conversation with a good friend who is also a dev team leader. “I can’t see myself work without peers who give me a good-enough code review”. This caught me by surprise. I could see why another pair of eyes is important, but work-critical? Seemed pretty radical to me. I started being more observant of the code-reviews I was given and giving to others, and finally ended up with a list of three main points, that for me — made code-review a good and effective process.
Going With the Flow
The first thing you do when code-reviewing is obviously trying to understand the flow. The question you should be asking the most in this part, is WHY.
Why did you choose this flow? Why did you split your code to these particular functions? Why do you need all of this code (in other words — are you implementing an already-existing logic)? What is the right architecture for this feature?
This is also the time to think how to avoid common pit-holes — Did you over-design? Did you unintentionally change a correct existing behavior?
If you haven’t received a decent answer to all of these questions — you’re not doing a good enough job. Most code reviews I got (or gave) only focused on some of these questions to begin with, or stopped asking once they spotted one or two issues.
Don’t Speak; I Know Just What You’re Saying
The second part of your code review is making sure the next time someone has to read this code — it will be easy. It doesn’t mean the logic is simple, but it does mean it should be self-explanatory. Variables and functions’ names should indicate their role in the show, loops should be easy to follow and core-logic functions should be maintained simple and neat. My personal worst nightmare is endless wrappers. When I dive into the third or forth layer of code wrappings, I get miserable and my good intentions tend to fade.
Another aspect of code readability is code conventions. It’s not only a matter of aesthetics — it’s the code equivalent of proper English. It enables us better communications with our colleagues, which leads me to my last wish.
Be Kind
Although getting good feedback is important to me, it’s very hard to listen and learn when delivered aggressively or disrespectfully. I expect my code reviewer to assume I put thought into what I’ve done, and am willing to learn and get better. Even if you’re a senior level developer reviewing a junior developer, it doesn’t justify being condescending — it makes your feedback difficult to accept and understand, and inevitably just makes you a bad code-reviewer.
Bottom Line
Code-reviews are important. They’re every developer’s best ways to evolve, learn from other developers and maintain stable systems. It’s not easy — it takes a lot of time and effort, but if done right and patiently — totally worth it.
