The github code review problem / Product before code

The remote / GitHub code review problem:

A part of any developer’s workflow is the code review, the main tool these days to do that in a team is the great feature of the code review with GitHub. (Usually, with the pull request).
The feature is amazing. Code comparison view, line by line comments, tagging, mentioning – it’s like fucking developer’s social media. It’s great, but we have lost an important part in this new workflow tool – we lost the product.

We have three well-known methods to review a code:

  1. Not to review a code.

Next:

2.   The pair programming:
Our code is great, and we know how it can be even better, when having a second eye on it in a pair programming session. It is really the best way. Some love it, some hate it (I personally, know that it will achieve the best results, but most of the time still prefer to fire keyboard signals with my headphones, in my “zone”).
It is also known that it’s something that not all companies or developers will accept. Most of them won’t. It’s costing more money on dev-time and does not save the same 50% of fewer bugs.
It is also not comfortable. You need to sync time. Sometimes somebody is sick. Sometimes you’re better alone. It’s perfectly fine. I am sure that most of the beautiful pieces of code in the world were written first by a lonely developer. (I hope that he/she was sitting in an airplane, avoiding screaming children, noises with earphones full with Volbeat music, which is exactly what I am doing now).

3.  The code review:
The middle way, between the pair programming and the no review, is the good old code review.
In this way, you don’t waste money on double dev-time. You get your “zone”, but you still get a second eye on your code.
You both look at the branch / PR, but also look at the feature, as it is already open in the developer’s browser. You try it, and play with it to understand what the code should do. You have immediate communication with the developer so you can ask/react to the feature and get a reaction back immediately.
Reviewing a code without seeing the feature/bugfix at work, is just testing a car only by its blueprint. No practical test before passing it to QA or even – pushing toward an acceptance test.

Now we got lazy. We check the pull request, we don’t sit together and explain. It is rare for people to actually pull the branch to their computer. They don’t need to anymore, so they won’t try the feature. This is how we lose the best power of the review – deploying a great, working feature. A beautiful code is great, but worth nothing without a working product.
I see this change and how it hurt us. Open source projects and private projects, getting more and more bugs that would never happen with a real feature review. It costs money, and it’s a downgrade to a dev-process that advanced so well in the last years. We have such great tools – don’t let them lead the human brain. They are just tools.

I say – review, with your locale tool. Try the feature, or a feature that uses this piece of code.
We should not become just coders, masters of beautiful abstractions and a code that looks like a poem. We should also never forget the reason we write it – the product is paying our salary – the final result of our masterpiece.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.