Comment by kaelig
6 years ago
On large projects, it becomes impossible for anyone to understand how each line of code works and what the best solution should look like. In such a complex area, assertive code review comments could be counter-productive.
In most cases, showing curiosity and asking questions in code reviews goes beyond educating yourself: it's also about providing "self serve" context for future developers who need to understand why a specific decision was made.
This context can also, for example, prevent future developers from trying to refactor or rewrite entire pieces of a program to follow "what first comes to mind".
I'm curious to know about the kind of projects you work on and how you've seen the approach of asking fail there.
In the linked article, the quote that starts it is the following:
"Whenever you look at a problem somebody’s been working on for a week or a month or maybe years and propose a simple, obvious solution that just happens to be the first thing that comes into your head, then you’re also making it crystal clear to people what you think of them and their work."
So let me ask this - do you believe I'm responding to the case of tiny code reviews that happen daily with pull-requests, or do you think I'm responding to the scenario the article proposes - which is when someone asks why an off-the-shelf solution wasn't used after the implementors worked on their new solution for "weeks or months or years"?
I am responding to the question in the article (or at least what I understood it to be) and not to the more-common instance where this probably comes up which is in daily code reviews. There is a difference in asking why someone didn't choose X option when the amount of time they spent on a problem is one day versus one month. I am responding to the one month scenario. I believe code reviews happen more than once a month.
Is my response an understandable one?
Thanks for answering, I see other folks had concerns similar to mine regarding your comment.
I understand better where you’re coming from.
(Where I work) I find there is something to be gained by showing interest and asking about the parts of the code I don't understand or would have approached differently.
(my favorite thing is when folks preemptively comment in their own pull requests to explain tradeoffs and design decisions before being asked about them, or write comment blocks in the code to add useful context)
You're right to mention context. In my own experience, when stating something that can be interpreted in multiple ways, whether it is interpreted good or bad by someone depends on what they believe the context of the statement is. It's my job to provide the correct context. Adding a disclaimer is one way to try to fix this, but I think for many people you need to provide context in your typical interactions with that person. The disclaimer is probably a good idea if who you are speaking with is unfamiliar with you, as there's not much context built up yet.