March 7, 2014 by Roman Ožana

8 Lessons I’ve Learned as a Code Reviewer

This is a guest post by Lloyd Waldo, featuring tips from Salsita Software Founder & CEO Mathew Gertner and Wikidi‘s very own senior developer, Martin Čechura. It originally appeared on the blog of Czech seed accelerator StartupYard


While you’ve probably made a few New Year’s resolutions this year, if you’re anything like me, you’ve intentionally put too much on your plate, just to have a good excuse not to have completed any of them by the end of the year- when you can conveniently forget you made them before, and make them all over again.

Will I lose 20 Kilos this year? It’s possible I guess. There are parasites I could be exposed to. Will I call my mother every week this year? 5 fruits and vegetables a day? Now we’re just being silly.

So let’s not make this a resolution. Let’s just make this a kind of reminder. If you write code, and you aren’t a total cowboy about it, you do some version of code review. So why not do it right? We surveyed a few of our mentors and friends on good Code Review practices, and here are some resulting tips from a Startupyard Mentor Mathew Gertner, Founder and CEO of Salsita Software and Martin Čechura, Senior Developer at Wikidi.


Why is Code Review such an important process?

LESSON:  “I’ll Fix it Later”

The most obvious benefit is to get an extra pair of eyes on the code to find (potentially subtle) errors and suggest better ways of doing things. This is particularly useful when a senior developer reviews code from a less experienced colleague, but we’ve found the inverse to be true as well.

A junior developer or one who is unfamiliar with a specific language or technology can learn a lot by reading and understanding the code of someone with more experience.A particularly valuable consequence of our policy of manual code reviews is that developers write their code more carefully in the first place.

Knowing that it is going to be reviewed, they are less likely to write a quick hack while telling themselves “I’ll fix this later.” 

Mathew Gertner

Do you like a more formal, or less formal approach to Code Review, and why?

LESSON: Save your time, do it over coffee.

In my opinion, the correct way is a combination of formal and informal approaches. A purely formal look feels more forced, while an informal approach does not impose such an emphasis on good habits.

Martin Čechura

Formal code review is very time -and resource- intensive. In my opinion it doesn’t make sense unless defect-free code is critical (e.g. aircraft control software). In other cases, good code review software and practices provide much of the benefit at much lower cost.

Mathew Gertner

What are a few things developers are consistently under-prepared for in Code Review, and how can they be helped to prepare better?

LESSON: Take your time, and use your noggin.

Imagine a problem in the real world, think abstractly (to some degree), split bigger problems into smaller parts, and don’t not be afraid to ask someone else. Use your head.

Martin Čechura

Developers are generally unprepared to spend the necessary time to do effective code reviews. They claim they don’t have time due to their other workload, and they rush through reviews just checking the high-level structure and cosmetic details like code formatting. It’s not possible to do a proper review unless you understand the other person’s code at a deep level. The best remedy for this is to provide explicit time for code reviews. Another technique might be to do meta-code reviews (reviewing the reviews) to make sure that people are taking the necessary time, although we haven’t tried this yet.

Mathew Gertner

What are some mistakes you’ve made in your approach to reviewing other people’s code? How did you recognize and correct those mistakes?

LESSON: Trust the process.

Code review is not a way to criticize other developers, or to prove that one is better. It is a tool for checking and preventing errors, and getting perspective on the problem, which is written in code.
Martin Čechura

What are some things you do to stop Code Review from becoming stressful for a coder?

LESSON: Take it easy. Give praise.

Making it too large a formality is a problem. Penalties for errors (if still not reproduced) instead of using that to generate new knowldge. It’s also stressful if a coder isn’t praised for a job well done.
Martin Čechura
I solicit feedback frequently from our developers, and I’ve never heard the comment that someone felt stressed out by code reviews. Maybe this is because our reviews are done by peers, not bosses.
Mathew Gertner

What are the worst habits for a person in charge of Code Review?

LESSON: Be consistent, be open.

Thinking only one view is the correct one, an inability to adopt a different way of solving the problem than the one already verified, and an inability to appreciate a good idea, or solution.

Martin Čechura

The biggest danger is inconsistency. It’s tempting to forego reviews when work is urgent, which sends the message that they are a luxury we indulge in when we have time, rather than an important and integral part of the development process.Mathew Gertner

How about some better habits for a person leading Code Review?

LESSON: Don’t be a teacher or a cop, just do your homework.


An ability to explain what is wrong and why and to show a better solution, and patience. I have to be a co-worker, not a teacher or a cop. 🙂

Martin Čechura

This involves going through their code before they post it and, essentially, reviewing it themselves. This is particularly important when the reviewer is not intimately familiar with the relevant code base. Not only does it make the review faster and more valuable, it often leads to developers finding errors in their own code before it even gets to the reviewer. 

It is also vital to avoid having code reviews become a bottleneck. A development process where code reviews block the developer leads constantly to situations where a developer is hectoring the reviewer to unblock them. The result is generally a fast and sloppy review. Of course, the review has to happen eventually, but we have structured our process so that the developer can continue to more forward, with the review required only in order to release the next version of the software to the client. 

What I’ve found to help reviewers most is to urge developers to heavily annotate their reviews.

Mathew Gertner

Can you list 3 to 5 bad coding habits for developers that come up often in Code Review?

LESSON: Don’t be a cowboy, leave comments.

Unused or incorrect use of design patterns, algorithms that are too long and complex, retaining bigger problems in smaller parts, repeating of code,  and absence of basic documentation.
Martin Čechura 
Inconsistent naming and code formatting, code duplication, insufficient code comments. 
Mathew Gertner 

What lessons have you learned as a code reviewer? 

Let us know here or on Facebook. You can also find us @testomatocom

Is your website available? Testomato can check your website availability every 15 seconds from 10 different locations around the world and will send you an alert if the site is unavailable.

Keep track of the important parts of your website with simple checks that can run every minute. They can check plain words, HTML code, HTTP headers, redirects … and much more. Never miss anything.

Websites break, it happens all time. You'll be the first to know. Testomato has an extensive database of and will let you know if it finds any error on monitored url.