5 Reasons for Having Your Code Reviewed
Why Code Reviews Are Important
Getting on the soap box
Have you ever written some code, or an entire application, that you came back to a month later and thought
What the heck was I doing?
Maybe you hope for the opportunity to refactor, rebuild or otherwise destroy your troubled code before anyone else comes across it. But if only someone was there to talk you off of the ledge none of this would have ever happened.
Code reviews give you that month in advance.
Code reviews, along with other great practices for building software, reveal things about what we write. There are times when we can go off on tangents of coding that we initially thought were great but later turned out to be something we, or our team, wished never existed.
Imagine becoming your future self in an afternoon. How would knowing those craft altering adjustments benefit the products you write? How much time could you save? And how would your team, your customers and your company benefit from approaching the authoring of code collaboratively?
How much code have you read wishing it was done differently? Think back on what problems could have been avoided. If those developers are still with you, what steps are being taken to improve the patterns they create in other parts of your company?
Great authoring comes from the collaborative efforts of common professionals.
Many Professions Need Reviews to be Successful
If publishers never proofread and provided feedback on submitted materials from authors the general quality of published literature would diminish greatly. When you go in for a major surgery how important is it to you that your doctor has the correct and most accurate paperwork? Would you feel better or worse that various engineers looked over the blueprints of a new passenger carrying plane prior to it taking real customers?
Checking and reviewing each others work happens everywhere and in every profession that takes what they do seriously. Without reviews there is neglect and with neglect comes issues. If we do not fix issues they fester and become worse.
5 Reasons to Encourage Code Reviews
Break habits in our coding
Authoring code is the practice of solving problems through written instruction. As we continue to author code to solve problems sometimes we get comfortable in our authoring patterns and techniques. While we are writing code for a company for a long period of time, we tend to adapt the practices we find in the code bases we work on and carry those with us in our personal work and into the work of other companies. We build habits in how we author code because they are safe, they work and we understand them.
We ( ourselves ) understand what we are doing...
That does not mean that our team and our colleagues understand what we are writing. Or that our work makes sense for the long term health of our software. Code reviews affords our colleagues the opportunity to help us break habits and even try new patterns.
Most of what I author is Javascript, and I have yet to try and adapt every Javascript design pattern. I have not because either I have not explored it myself or my colleagues have not encouraged it. I can say that code reviews have helped me discover and practice new patterns and techniques that have equipped me with new strategies to solve problems more effectively.
Sometimes, while I am reviewing code, I will notice that someone wrote themselves a small utility function, or series of utility functions, that were already available in the framework or library they had been using. This happens especially in the Node.js code I review, where the developer has not thought to look at the Node.js documentation for help with something. I would provide a simple comment and a link to the utility natively built into Node.js and away they go. The long term benefit of that transaction is that that developer is now more likely to leverage the code around them rather than rolling their own. That developer is also likely to encourage the same practice in the code they review so on and so on.
The best code is the code we did not write at all.
Learn from your colleagues and teach others
Code reviews give us the opportunity to learn from one another. We learn through knowledge sharing. Whenever another developer has some feedback for me on the code I had written I take that feedback for my personal development and growth.
To be honest, I have learned the most from reading the code of my colleagues. Reviewing another developers code gives you the chance to study how someone else has solved a particular problem. This eventually had lead me into studying my favorite libraries and frameworks to get a sense for how they tackle various issues.
Improve the general quality of your product
I couldn't even imagine how many lines of code are shipped around the world each day. And everyday bugs and poor experiences are put in front of users. Defects in our software costs our business and our customers. In my opinion, the most damage is done to the trust of our software. If users cannot trust that our products will perform as expected, how can we expect people to use them?
Code reviews, along with good TDD, BDD etc..., give us an opportunity to find and correct blemishes in our work. To help protect our users from our errors and continue with delivering great experiences.
Reduce technical debt
Technical debt is a very real cost associated with building software. Some product and marketing folks have a hard time relating to this issue. Sometimes they think that once something has been written it will always work the same way as before and developers can bend and shape the thing ( rant.. rant. rant... )...
I try to use metaphors around these conversations like:
Imagine our software is carved out of wood. With each change we are subtracting from it. Unless we take care of what we have we may run out of options to make change.
Or you could just find another piece of wood and build it all over again... the right way... right?
As developers it is up to us to explain technical debt and share the challenges we face so we are allotted the time we need to come back and apply the necessary polish.
A few things that stand out that contribute to technical debt:
- A poorly organized set of programatic statements, perhaps a closure that is doing way too much
- Outdated, deprecated or insecure dependency is in use
- Poor naming conventions
- Anti-patterns ( typically associated with extending existing functionality where the patterns were not so clear to begin with )
- Taking shortcuts
- Your framework is starting to take a turn
This is just a short list, but you get the idea that whenever we do something, or neglect to do anything, to our software we incur some debt for that work. A great team will keep their technical debt in mind when new projects are scheduled. Great teams will also set aside appropriate time for refactoring code in their software.
Code reviews allow us to discover issues with technical debt early on. Code reviews help us document issues we may come back to later, or tackle issues on the spot with a bit of refactoring. Over the long term your technical debt becomes more manageable keeping your software easier to extend and change as needed by your users.
It is more manageable to pay on credit cards month to month instead of paying the entire debt all at once.
Get feedback on new ideas
I probably throw out more code than I keep. But during that time I am scratch padding various designs, or providing crude examples for my teammates. Every now and then I will do something that I think is a little unique, and before I commit the thing for a life in our software I ask for feedback on what have I done.
Usually I will send my thoughts around to my colleagues and teammates to get their opinions on what I am working on. This has really helped me make sure that what I am thinking makes sense to the rest of my team. There are times I hear
Oh, I wouldn't have thought to do it that way...
others may say
Why... oh why...
If I get the latter I know I have gone in the wrong direction. This exercise has helped me make decisions that make more sense for my team rather than solely myself. There are times we read something online that we would like to try in code, which should be encouraged, but these new ideas and optimizations should not happen in a vacuum. Without checking in with our teammates we risk separating our work from them.
When a developer does not understand something, they simply rewrite it until they do.
What is Stopping You?
It is too selfish of us to refuse code reviews. For a few years of my career I had worked in a bubble, writing anything I wanted. I was a bit intimidated by the thought of having someone looking over my work. "Code complete" does not always translate into "Dev complete". I am sure there is a wide range of reasons why we would avoid having someone else review our code, but try not to let them stop you. Code reviews will only make you better at what you do. There is nothing wrong with having our ideas challenged. By being challenged we are forced to justify ourselves in meaningful ways. It really makes us have to think about our decisions.
I challenge you to ask yourself, what is it that stops you from asking someone for their feedback on something you authored? What would it be like if your team performed code reviews on the regular?
Try it!