3 Golden Rules for giving Code Reviews.

You’ve finished your piece of work, you sit back, let out a deep breath and your shoulders relax. You did it! It was hard, there was a time where you had to manoeuvre around a tricky problem, and there’s a small piece of code that could be better but it was the best you could come with up with. You’re looking forward to getting your teams feedback and hoping they may have a more elegant solution or have questions you can share ideas on!

But what happens if the feedback you receive makes you angry? Or upsets you? How do you deal with that? What have they said/done that’s provoked that reaction?

Or perhaps you’re the reviewer and your colleague has reacted in a way that you weren’t expecting. How do you feel? Do you feel like they’ve overreacted? Or worse, did they *deserve* it?

Rule #1    Ask questions rather than make statements

Be kind! Sounds obvious right? But it can be all too easy to get more concerned with the code and forget about the author and their intentions. How many times have you looked at a piece of code and thought “What the hell were they doing!?!?!?”. Take a step back and remember those were decisions that were made… on purpose. Try asking why the author chose a certain method over another, and not in an accusery way either. Come at it from the angle of trying to learn about the code, and from that make your suggestion in how it could be better. If your suggestion isn’t necessary, or more of a style choice you think should be favoured, or a more efficient implementation, then do just that – suggestit. No one likes smug people and it can embarrass the author as these reviews are usually public. Be humble and help.

Rule #2    Limit personal preference

As touched upon above, personal preference is your personal preference. Unless agreed upon beforehand, picking up on issues such as formatting or layout can distract from real bugs and errors in the code. I realise that the control-freak inside most of us gets frustrated at what we feel are silly design choices, but one single person alone is not in control of the code base. If two people have different views about these issues, there is no winning in an argument – so don’t waste your time.

Rule #3    Thoroughly check its purpose

Let’s use Scala as the language we’re using. So you’ve skimmed the code, there’s no Option.get, there are no var’s to be seen and all the names being used are informative and clear. Ship it!

But wait… What if the method does not solve the task at hand. Maybe it sends the wrong (but valid) message to the wrong place. Maybe it uses the wrong data to add records to a database. Even if all of the method names match their contents, unless you go back to the original task and look at the acceptance criteria, there is no way to know if this code review deserves the OK. I would suggest taking a look at the tests and see how these compare to the aim or goal of the task. Once you know that, you can ensure all of the tests test the right things. Easy peasy.

One year in.

I have just logged in to my mostly forgotten wordpress account and the following was sitting in the ‘drafts’ section.

This is it.

My big transition.

This week I signed up to Github, registered for access to the Instagram API, tweeted my first tweet and joined reddit.

I was full of ideas…

I can honestly say my enthusiasm hasn’t waned, I just focused it on other areas of my career.

Something that has captured my attention in the last year is how fun it can be to get involved with the community – especially helping others into the scary world of technology. This year I have taken part in both Scala Exchange 2015 and Scala Days 2016 talking about what it is like to learn Scala and what to expect from the experience, hopefully encouraging and relating to others going through the same transition.

Going further with this interest was getting involved with an initiative called codebar.io, who’s “goal is to enable underrepresented groups to learn programming in a safe and collaborative environment and expand their career opportunities.” I found it incredibly rewarding and interesting to provide help and advice to people with their own projects in mind. It served as an important reminder to me of how cool technology can be as a tool for creativity when you’re inspired.

So after quickly reflecting on the past year, noticing how different it has been from my expectations, I have decided to set some goals for the following year.

  1. Deliver a talk at at least one more conference. Even though there have rarely been other times when I have been as nervous as I am before public speaking, it is one of the most fulfilling things I have done in my career so far.
  2. Help organise a community event (codebar?).
  3. Finish Coursera’s Functional Programming Principles in Scala (finally!).
  4. Start a home project and see it through to the end.

But who knows, things haven’t gone to plan as of yet – they’ve been even better.