Kennis How code reviews work

How code reviews work

Since all the real fuss started about pairing and code reviews I’ve only seen one approach in code reviews work really well and that’s pull requests. Pull requests force a peer review and if you implement them well, they rarely get merged without the opinion of an extra pair of eyes. So, I’m really going to write about code reviews in the form of pull requests. This is what I learned.

Even more specifically I am writing about pull requests within a stable coherent corporate team. Pull requests in open source projects in github or bitbucket have even different dynamics that deserve a separate blog, interesting as well.

 

The first ever pull request you make is awkward. It feels like an infringement on your privacy. You have been working on some code that you feel you own, you are responsible for it. You have worked blood, sweat and motherf’n tears. Then, you publish it, where your team can see it. You are on trial. All you can do is wait for the verdict of the jury.


That is how you feel when you still have to learn how to act as the requester. Because that’s really the hardest role to play in a pull request. There is two parts in that: 1) preparation and 2) deal with the feedback.

 

#1 Preparation is the relatively easy part of it. There are numerous blog posts that write about how hard the reviewer role is, but they most often end up in describing what the requester should do to solve it:

  • Make small pull requests
  • Use a clear title
  • Have on point commit messages (the what, not the how)
  • Use multiple commits (I learned this from @stil4m who practices it in extreme)
  • Add comments to the pull request
  • Add screenshots
  • … much much more to add here

 

#2 Is hard. This is where you need to be psychologically prepared. People will say harsh stuff about code that flourished under your care. Pull request comments are most often direct, blunt and uncensored. That’s good. They are written in a pace that requires directness and speed. People take time to write what they think about your code, but don’t have time for a love letter.


When you, as a requester find yourself able to take the honest feedback, remove all the emotion (that is really coming from you, not the reviewer) and shape this into even better code… you will find yourself in the now more than ever. That is when you truly experience the power of pull requests.

 

Because in the end, it’s less about you and all about good code.