The more projects I work on with people who I hold in high-esteem, especially as it relates to programming, the more I find myself wanting to pre-justify the reasons I’ve made a decision about how I’ve solved a problem.
This isn’t to say that I try to be defensive about what I’ve done from the start. Instead, it’s more of an attempt to try to justify or rationalize the reason I did something so the person reviewing my code understands it and doesn’t think ill of it. The thing is, I’ve never really had an experience – at least not in the last, say, half a decade or more – completely obliterate my confidence.
Instead, they’ve done one of three things:
- The person reviewing the code has made a recommendation as to how the code can be improved,
- The person reviewing the code has asked why I did what I did (either to better their understanding or to see if there’s not a better way the problem could be solved),
- The person has provided insight on how to rearchitect the solution simply.
And regardless of which of the above is used, I’m generally grateful.
Thus, one of the things I’ve been trying to get better at doing is merely deciding on how to implement a solution, commit the code, and let the code review process do its thing.
The Code Review Process
That is, I want to get better treat the code review process as an actual thing (which, I’d argue, it is) versus a debate, argument, or discussion with someone else that has yet to take place (because it hasn’t, right?). Because I’ve found that when I opt to do this, I end up being able to:
- provide a justification for why I chose to implement the solution that I did and educate the reviewer (it sounds arrogant, but I don’t mean it that way),
- understand why the reviewer proposed the solution they did (and learn in the process!),
- gain a broader thought process around the solution as it fits in the entirety of the application.
For many of us, we’re writing code that contributes to part of a larger whole, right? Thus, the way we’ve implemented something may be the best way given our constraints, or it may be a way that needs to be improved. After all, we don’t have the knowledge of the system in its entirety.
We don’t know how or why our peers have implemented their solution in the way that they have, and we don’t know how things will scale in the short-term (because I think it’s hard to know in the long term really).
Is This Personal? 🤔
Anyway, I share this because I’ve said I’m a fan of code reviews multiple times before and it’s one of the most significant values that you can gain in your career. But you have to tear down whatever predispositions you may have really, or you may want to impose before the process does its work.
So maybe I’m writing this more for myself, or maybe you’ll get some value out of it, as well. Whatever the case, commit your code and step back and let the process of review do its thing. Don’t offer justifications before they are needed, don’t provide the rationale behind your decisions until needed, and be open-minded to what you may receive.
Any of the above could interfere with the benefits you may receive if you just commit your code and let the review work on your commits.