Why we invest in code review and you should too

What is “good” code?

What is writing good code? When you are new to coding, you are probably happy when your code works. So would “good code” mean “working code”?

Suppose you have a project and you get it to work. You do the obligated happy dance and then leave your code alone. Six months later, you’ve had an awesome idea for a new feature. You open up your code and… it looks like Chinese. Sadly our minds cannot remember complex things in much detail for a long time (at least my mind cannot; if yours can: give me your secret!)

“If your code looks like Chinese after six months. Would you still consider it “good code”?”

Good code should probably be “readable” as well as “working”. In fact, there’s a whole list of adjectives we need to put in front of “code” before it becomes “good”. Good code = working, readable, extensible, documented, scalable, efficient, robust, smart, according to the styling, consistent, doesn’t repeat itself,…

How to write “good” code?

Well, at Skryv we do it this way:

• First of all, we realise that we don’t know everything and we are open to learning new things.
• Secondly, we are respectful towards each other and strive to help others grow where possible.
• Thirdly, we review each others code.

What’s in it for the code reviewer?

All developers at Skryv review code. As reviewers, we give thumbs-ups when we see something that we like. We ask questions to understand better. We give suggestions for improvements. We find bugs that can still be fixed before something actually gets broken and sometimes we nit-pick a bit about code style and typos so the author knows we reviewed the code thoroughly.

It is interesting to see how other people tackle problems. As reviewers, we might learn new things and grow as a developer ourselves. Also, we are up to date with changes to our shared codebase. That will make it easier when it is our turn to change something to it later.

"We are up to date with changes to our shared codebase"

What’s in it for the author?

All of our code gets reviewed. As authors, we know that we are not perfect and we see the comments from the reviewer as learning experiences. We want to give the reviewer the best reviewing experience and so we make our code review-ready (so: readable) before passing it to him. When the reviewer asks us questions, we know that the code is not self-explanatory yet and we can think about a different design, a better variable name or a comment with an explanation. This improves the global readability of our code and makes it easier for future new developers to understand what’s going on when they see the code for the first time (and for ourselves, when we get back to it in six months).

“When the reviewer asks us questions, we know that the code is not self-explanatory yet”

The reviewer can give very good suggestions that we did not come up with ourselves. This also improves our codebase, as well as our personal developer skills. It happens often enough that a comment from a reviewer leads to a co-creation process where author and reviewer combine their skills. When 1+1>2, it leads to better ideas, better developers and better code.

Recently we stressed more this concept introducing Pair Programming in our team. This should allow us to move the review from a downstream process to a more real-time activity. We are still experimenting with it and we will let you know the result in a future blog post.

At Skryv, we know that a combination of an open attitude and a respectful feedback culture helps grow our developers and our code. That makes it more than worth to invest in code reviews.