Comment by Edman274
6 years ago
Here's the suggestion: don't ask! What are you going to do with the information? If you ask and the answers are reasonable, then ... so what? What have you meaningfully learned? You've learned that an existing solution does not completely solve a problem.
Now you understand the problem a little better, and you understand the shortcomings or deficiencies of a pre-existing solution a little better, but you're signalling to the person you're asking that you're looking to second-guess their judgment or wisdom before you even understand the problem that was trying to be solved. Why didn't you wait until you understand the problem well enough such that you'd be able to see (along with them) why an off-the-shelf solution wouldn't work? Asking why a specific off-the-shelf solution wasn't chosen is a way of signalling to someone else "hey, I don't understand the problem very well but I'm sure that I have a better solution". So don't ask why a technology wasn't chosen; ask questions about the problem domain until you understand why - WITHOUT asking.
Here's the other scenario: you know for a fact that an off-the-shelf solution would've been a better choice than what someone else did. In that case - guess what? Don't ask: tell. Don't patronize someone by saying "why didn't <software> work here in a case where it obviously was a smarter choice"; instead, have the courage to say "I think that a better use of time would've been doing research and seeing if <software> was usable." Because if you're trying to tell someone that they made a mistake by reinventing the wheel, asking them why they reinvented the wheel rather than telling them they did so will probably be seen as patronizing or dishonest.
Either understand why the first thing that popped into your head doesn't work without having them tell you why that's the case, OR be so certain that the first thing that popped in your head does work that you're willing to declare that. Anything else is inviting people to believe that you're trying to "stump-the-chump", so to speak.
Here's the suggestion: don't ask!
This is bad advice and I hope nobody takes it. We learn from each other. I've very glad I didn't have to learn everything I know first-hand.
Personally I am honored when people think highly enough of me to feel like they can learn from my experience. I also like learning new things, so if there was some obvious answer that I just missed of course I want to know about it!
The correct answer is first form a relationship, then ask. The author worries:
I have realized I honestly don't know how to express my question to make clear that I mean #2, without including a ridiculously long and pleading disclaimer before what should be a short question.
It's perfectly ok to have that long preface the first time you ask this kind of question. "Sorry to be long-winded, but since we don't know each other that well yet I just want to be clear: I don't understand why you didn't choose XYZ? I'm interested in learning about this but I haven't spent as much time on it as you have. I would have tried XYZ but I'm assuming there was some issue. What was the issue?"
In general over time people will learn your character and your intention. If you are truly humble and trying to learn they will come to expect that attitude of humility from you and the long preamble won't be necessary.
In situations where you don't have the opportunity to build a continuing relationship just accept that the verbosity of your question is the price of clear communication without the context of an existing relationship.
But please, please keep asking questions, even if they seem obvious. That's how we grow.
I'm not saying "don't ask questions." I'm saying "Don't ask that specific question that specific way. Get the same information by asking about the problem that's trying to be solved for long enough that you come to the same conclusion that they did that an off the shelf solution doesn't work. And if that never happens and you're never led to believe that an off the shelf solution was inadequate, then just say so."
That sounds like a colossal waste of time when you could learn just as much by asking that specific question.
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.
> Here's the suggestion: don't ask!
In addition to my learning (and other reviewers too embarrassed to ask a question they might be wrong about), I can't count the times I've asked a simple probing question about X and gotten a short response that includes "thinking about it more I realized that X is correct but I completely screwed up Y!"
"Don't patronize someone by saying..." I'm sorry but a company where people confuse genuine curiosity into your work and chosen solutions with patronizing would feel so toxic to me that I would leave very soon. Don't be a snowflake, just answer the question honestly. Maybe you should have used sshd and you should stop wasting time doing what your are doing right now. Or maybe sshd doesn't cut it and the person asking you why you didn't use it is going to learn something new. Fear of patronizing is inhibiting honest open communication.
> Either understand why the first thing that popped into your head doesn't work without having them tell you why that's the case
I actually like that phrasing. Some thing simple and open-ended, like
"Well, the first thing that comes to my mind is sshd."
And let them talk.
It's generally a true statement, in that it is the first thing that comes to mind, with all the naivete that this implies. And IMHO doesn't unduly pressure the person who has worked with the problem longer.