This is likely the start to a useful approach. I suspect the crux of the challenge is that engineers who need to write code get very pedantic in their questions and picking the answers apart (because we need to be! code leaves no room for ambiguity or intuition). And you can imagine how that feels from the other side. I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate. A natural response will be to try to dictate what to build (often micromanaging) and avoid the discussion about why at all costs. Writing offers a bit of a neutralizing buffer, at least.
> I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate.
Wow, that's describing it really well. I work for a guy who basically started a company by trying to vibe code his ideas into existence (late 2023 LLMs) and realized he would need actual developers to get anywhere.
It was excruciating trying to make him answer questions to get proper domain modelling going since LLM use had made him think of software as being wished into existence in a "declarative" way.
Not to mention the heavy contrast my persistent questioning had to a background of sycophantic yes-man claudespeak.
I was really wondering what these replies were talking about until this one - when I remembered a guy I used to work for that was just like this.
I think I have been pretty lucky the last 5-6 years of my career at least, where someone asking those questions is treated as trying to drive the team to a better result, rather than a pedant.
