This is unfortunately going to be one of my least entertaining postings. In my time at University I wasn't really taught what Code Reviews were. So I spent a lot of time trying to learn it myself and will be attempting to relay something from my Monkey-Lizard Brain to yours.
What is a Code Review?
Code reviews are a moment typically used before lines of code are merged into a code base. This is primarily done on larger scale companies that have the time for this. For smaller companies and projects what we get from them is similar but sometimes less affordable. Which is sanity checking, time to verify if there is a better way to do things from someone potentially more experienced, and time to get to know your fellow engineers. Please do not take all of this at face value as thee way to do Code Reviews. Your ideals will be altered and further founded in their own path as you do these.
Some Standard Best Practices
Review fewer than 400 lines of code(LOC) at a time.
The reason for this is our brains can only realistically run for so long with so much into it. In practice in some of these firms 200-400 lines of code is the upper limit for the efficiency of processing. Furthermore on the previous point made, this practice in a 60-90 minute period should yield a 70-90% defect discovery. So if 10 defects exist we should be finding 7-9 of them in theory.
Take your time. This should be under 500 LOC per hour.
Our Monkey Lizard Brains have limited processing power. It's extremely powerful, however it is overloadable. 500 LOC is a fairly strict line but use your better judgement. Signs things are too much to process potentially is increased irritability as things are added into the mix. When you identify this I strongly advise getting a step away from it.
Sixty minutes at a time maximum
Sixty minutes is around the maximum ability to be properly and fully engaged in these types of activities. Take the time to really sit and stew with it.
Think of how this author going to react to the presented list of defects?
If you bomb someone with 50 different mistakes, it’s highly unlikely we will learn through the process. As it’s quite hard to get past all the defects.
Settle style arguments with a style guide.
This is a bit dated for our purposes though I would like to attempt a discussion with how we feel about present styling. In both C++ and Blueprints.
Be cordial about code examples…
Some of us are putting immense effort into just having a deliverable. It won’t always be elegant or even sometimes the most efficient. Relax with it and try to show whenever possible what you’re looking for when making these conversations. Don’t just say “why not do it this way” since we might not always have the visualization in our head for it.
Avoid saying “you”
This word becomes very directed to the author regardless of how jaded we may think we are. It can make us accidentally defensive and hits prides. Stay objective and try to generalize into saying something like “Can we do xyz” instead of “Could you do zyx.” While we have individualized code this game is OUR project. Maintain the sense of camaraderie in saying we it keeps the idea to the collective effort we have. If you prefer not saying we “What about doing xyz” is another good alternative.
Frame your feedback as requests. Avoid being demanding.
This gives the author more autonomy and keeps things cordial. As well as you can have a more polite back and forth discussion. Sometimes you will be right which makes it hard to avoid being “demanding” however you won’t always and the rationale discussion is more easily had in the polite headspaces.
Offer sincere praise
The code reviews don’t have to just hammer mistakes. Please look for some things to reinforce good habits and make the review a calmer environment. Actively seek the improvements other people make as they grow alongside you. This is more applicable later in life but for now it is good to think about in general as we practice these.
Try to bring the code up a letter grade or two
In learning about code reviews I found this strategy. With corresponding rubric:
I believe the above Rubric will further our conversations about the code and improve objectivity. If the author requests the grade we can use it. If the author didn’t request it, do NOT mention the letter you went with. We can’t always bring quality up rapidly but can bring it up a little bit over time. Not every iteration will need perfection.
Stalemates:
In our future lives as developers some of us may end up in issues where one end will not approve without changes while the other doesn’t intend to change it. How do we avoid this proactively? Well watch some of the signs.
Shift in tonality for the negative
Notes per round are going higher
Suggests we aren’t clearly communicating
Talk these things out, keep the reviews in person as much as possible to prevent this issue. Go over the designer view. Sometimes in our professional career what we are working with isn’t entirely up to us. This could be for a variety of reasons if that potentially becomes an issue I will be requesting a mediator in the form of either one of our producers or Connor as the product owner. As that may be the strongest way to break such a moment in our case. Recovering from these moments I believe we can mend our own paths however if there is an issue. Please, bring that third party mediation to have the extra set of eyes in the conversation. Know, we care as a team about each other and understand passion burns bright in many of us in this art of creation.
More than just finding bugs
At the end of the day this is to aid us as developers. However, we can take this time and learn quite a bit about each other. Looking through our individual bases and hearing the thought process behind these things teaches us quite a bit about each other. Thus I believe that this process will bring us a bit closer if we approach it openly and reminding ourselves we are humans. Not machines. I know as time dredges on in our projects we will all be experiencing varying degrees of burnout. Remember you are always going to be learning. Go into these with grace and understanding you'll be astonished what you learn and discover with it.
Finally. Know your worth as a person. As a generalist engineer I have found myself on many teams that abused my ability to put many hats on. With this I burnt out quite hard and struggled to bring myself back to a strong performer. So take care of yourself out there as well.
Comments