Intractable technical problems are a fact of life. Architectures make seemingly easy use cases impossible. Critical code won’t scale, because of meaningless choices made years ago. There are endless tech problems that defy easy and obvious solutions.
Earnest, well meaning, developers who come up with solutions that won’t work are also part of life.
After you’ve been thinking about a problem for months or years it can be tempting to tell a developer why their solutions won’t work. Lead the developer down your chain of reasoning. Show them how much more you’ve thought about the problem. How you’ve considered their solution, and a dozen others. Be superior and dismissive.
Prove that the intractable problem can’t be solved until you get the developer to say “Ok! Ok! You’re right! It won’t work!”
Or, you could be open to being wrong and build an ally.
Agree with the basic idea of the solution. That seemed like a good idea to you too! Then, instead of telling them why they can’t, ask the developer how they got around the intractable problem.
“How did you solve it?” is interested and hopeful. It tells the other person “I have spent time thinking about this problem too. Here’s where I got stuck. I’d love to hear how you think we can solve this problem.”
There’s almost never a solution. Most of the time the other person had no idea that the architecture wouldn’t support it, that the message size is too big, or any of the subtle technical reasons why the solution won’t work.
Asking about the solution, instead of preaching the problem, puts the two of you on the same side. It makes you allies against the problem and sidesteps the teacher/student power dynamic of “That won’t work.”
Sometimes, a fresh perspective does produce a solution to the intractable problem. Since you avoided staking a claim that there was no solution, you won’t feel the sting of being wrong. You won’t end up defensive, and can embrace the developer’s solution.
“How did you solve it” builds allies.
“That won’t work” harms you both.
