Who are you coding for?
I’ve been reflecting on the code review process after receiving feedback on my own pull request yesterday. I though I’d come up with a very succinct and efficient solution to a problem — combining model data and device capabilities to decide whether to hide a button, in just a couple of lines of code — but two other team members recommended a different approach.
Their main feedback was that they did not see the logic as obvious, which I initially completely rejected because I felt the logic was perfectly clear. But after thinking about it I recalled a principle that I firmly believe in.
As a developer, you are writing your code for other developers and your future self. What seems clear now, may not be so clear in future.
If more than one person feels there is a clearer way to express some logic, then it will be far more critical in the future when someone is reading that code to diagnose a bug or because they need to change some behaviour due to new business requirements.
I also realised that when we discussed their comments I spent most of the conversation trying to “win the argument”, and convince them that my code was fine. If I had begun with the mindset that this was not “my” code, but actually code for others, then the conversation would have been quite different. In fact, I probably would have just made the recommended changes immediately.
One of the trickiest parts about code reviews is there is usually more than one way to solve a problem and sometimes all the proposed solutions are “correct”. So falling back on the principle I mentioned above can be a quick way to find a resolution. And this reminds me that every team should have a clear set of principles — a topic for another article.