Code reviewing: why it is so important?
Recently I had a discussion with a colleague of mine about procedures and code reviewing and i realised 2 really important things. The first is that code reviewing is priceless and extremely beneficial but only if we follow some principles and we keep everything transparent. On the contrary, code reviewing can become a really painful process and ruin teams collaboration and relationships, if we do it wrong.
In this post I ‘ll share why reviewing is important and in a follow-up i will analyse how we can make it work as a team.
So why code reviewing is so important?
Codebase’s integrity
Following some guidelines and some best practices is really important while developing an application. This will give you the flexibility to make changes fast when needed, maintain the codebase or adapt to technologies upgrades easily. Especially now that agile methodology is getting followed by even more and more software companies and fast-paced development is a thing, codebase’s integrity seems to be more important than ever.
So what mechanism is going to ensure that these guidelines are getting followed without having to micro-manage each engineer? Code reviewing is the answer!!
Spot severe issues faster
Sometimes throughout reviewing we can understand that there are bigger issues under the hood so we need to change direction. This might also affect business decisions not only tech ones. No matter how we all hate it, we cannot predict 100% of cases if something will go wrong early enough. As much as we plan we still can fail but there is a good chance to catch this while reviewing a new feature.
How many times have you realised while reviewing a merge request that this is causing more issues compared with the ones you wanted to solve or that you definitely need to do this and that first, before releasing it?
Of course this will be a huge alarm and will indicate that there are some big holes in our procedures. These might be sloppy planning, missing architecture, lack of specifications, advanced complexity and many more. So we know what we need to improve as a team now right?
Team’s collaboration
Believe it or not but team’s collaboration improves a lot through code reviewing. This process will bring the engineers closer and will make them share knowledge and ideas. It will also help them realise that they are in this together. Software development is a team sport so the earlier we realise this, the better results we shall accomplish as a team.
Engineers self-improvement
A mechanism that enforces knowledge and experiences sharing among engineers, obviously helps them to grow individually. Stronger and happier engineers, means stronger teams and this will result into faster delivery times and more stable and well-structured software.
It is costless for firms
Code reviewing is a really cheap way to accelerate teams members and improve them individually. Teams should learn how to function in a way that is beneficial for all participants so they keep on sharing knowledge and improving constantly due to this internal procedure.
Workshops, seminars etc are definitely the best way to train and educate engineers but if you haven’t established a highly collaborative environment first, then definitely you are not taking the most out of these, because sharing isn’t there yet.
Faster on-boarding for new teams members
I am sure we all have some ugly memories about 1 project at least where we started working and spent days or even weeks till we figure out how things work. Do you remember how things were when you submitted the very first merge request back then? Anyone else here who wanted to share his / her solution with other developers in the firm and felt totally lost? Don’t let this happen to new team members. It is really stressful.
Code reviewing will help new members to accelerate smoothly and start adding value to the team faster. They will probably understand tricky parts in the codebase easier after receiving some feedback or reading some proposals and snippets in review comments. Also this will help them to interact with other team members early enough in order to realise fast how things work and how team collaborates.
No more coding loneliness
Many engineers tend to isolate in order to deliver their tasks on time. So when they struggle they face some really depressing and stressful moments. Why this happens? Because they don’t feel that they are part of a collaborative environment, so they think that finding the optimal solution is 100% their problem and they are totally responsible to figure things out on their own. This is wrong and trust me, sooner or later burn-out will knock the door.
As we know, engineering is a teams sport so through code reviewing we enforce collaboration. Teams members, by doing so, grasp that the team as a whole pushes the application forward. How? By proposing alternatives, different approaches and ideas while reviewing their colleagues work. That way each engineer knows that he / she will get some valuable feedback down the road and this definitely takes some weight of his / her shoulders.
Sloppy engineers
Code reviewing makes good engineers happy and sloppy engineers miserable. Lazy and arrogant ones hate the whole process. This is a huge disadvantage that no hiring interview can highlight. Good news right? You don’t need lazy and arrogant engineers in your teams. You will spot them really fast because of their lack of discipline to follow teams guidelines and their continuous complaints. Why do they complain? Because they hate it.
They hate reviewing, because it really takes time to read other people’s code so unless they want to improve the codebase and share their knowledge with colleagues then they probably cannot find such an importance in doing so. Also they mostly hate getting reviewed by other guys. Sometimes this might be even personal like a judgement or so. No matter what, this means that they cannot really work in a collaborative environment and they will ruin team’s spirit sooner or later because of their personalities. Trust me, you don’t need such guys in your company and your teams of course.
Happy engineers
We discussed about sloppy engineers but what happens with the rest? These realise that this is a place they can shine. I remember a colleague saying that he really enjoys reviewing because he adores reading other engineers ideas and proposals. So after doing so he keeps notes in order to search for all these things he learns. How cool right?
Developers who understand that all this takes place for their own good will blossom. There is nothing personal or whatsoever. It is just an exchange of opinions, experiences and knowledge and all of us can learn tons of stuff out of it on a daily basis.
Conclusion
We tend to believe that fast paced development is the holy grail but we forget how harmful can be an awful codebase for the company itself. Fast and sloppy development is like shooting your leg. I am not talking about over-optimising and over-engineering but every company who cannot maintain its software then probably will be in deep shit really soon. Code reviewing will help a lot in avoiding this from happening.
Engineers also benefit hugely out of it. At first it may seem time-consuming but sooner or later the teams will learn to work that way so it will become a vital part of their workflow. Reviewing will help developers to self-improve and collaborate so the teams will become stronger and more competent. Also they will create stronger bonds as a team after realising that they are in this together for each merge request that gets submitted. Who doesn’t want to be part of a healthy team right? Cheers!!
If you found this interesting, you can follow me on Twitter at @fakiolinho. Check out some of my other articles below:
