The art of giving and receiving code reviews

Community
1

Hi All,

I just finished participating in the “Reseach Software Engineers” conference in Germany, deRSE19 . From the conference I took home 2 important messages, the first one I will share in this post (and the second to come soon!).

Alexandra Hill gave a talk about “The art of giving and receiving code reviews” which I found both interesting as well as useful! I will share with you here the summary, and then the slides of the talk.

TL;DR:

  • Code reviews increase code quality, reduce bugs and lead to better design decisions.
  • A pull request is in principle a creation of the author. Like a musician writing a song, they have feelings of ownership over the PR and thus can be hurt when someone is too critical.
  • As an author, try to lower your defensiveness.
  • As a reviewer, try to raise the confidence of the author.
  • When commenting on a code review (regardless of your role), be mindful of where your comment will fall in the “conflict vs. reward” scale.

This is the summary, but if you are interested for more you may find her slides here: Alex Hill | Talks or even a youtube recording of the same talk I heard here: The Art of Giving and Receiving Code Reviews Gracefully - Alexandra Hill | #LeadDevLondon 2018 - YouTube

This brings me to a request I have! Some of you know that I have been developing the package DrWatson which is a scientific project assistant. Besides contributions from my student @JonasIsensee I’ve written most of the code myself. The problem with this is that pretty much noone reviews my code.

Therefore, if you use DrWatson, or you are at least interested in it, please get in touch with me in order to review my pull requests. I am not asking you to contribute code (which if you want that would be amazing), I am only asking for someone to review my Pull Requests. This will help the code become more readable, and the API design decisions to be more sensible.

12 Likes
2

I understand that proper code review has a lot of advantages, but do you really expect users of software to do code review? They are users and not developers.

3

So is the original code (of the original author) :wink:

When the PR is not urgent (eg a critical bugfix), I find it best if at least a week has passed since the both original code and the PR was written. This helps me to be detached about my own code (since if I do something weird, I usually forget why I did it, so I am more willing to let it go).

Finally, it is totally fine to have very specific expectations about coding style, just make them explicit beforehand, simply by linking one of the excellent style guides. Personally I like

7 Likes
4

Sorry if this wasn’t clear @thofma , the request in the end of my post was targeting people that also write Julia code and are not “only users”. You will be surprised by how many people are regular Julia users but also publish packages.

In fact, I am one of them.

4 Likes
5

I review PRs for packages I didn’t write some times. It’s good train reading material. Very interactive. Sometimes more drama than a Facebook comment stream on a CNN article, sometimes as much drama as the review section of an esoteric physics text. Highly recommended for all occasions.

13 Likes