"What problem are we trying to solve?" is a question I have to ask constantly in corporate development environments, and rarely does anyone presenting the task to be done actually know the answer!

It's very frustrating.

▲

hathawsh 3 hours ago | parent | next [-]

I try to remember to say something like this: "This is an interesting solution, but I'm not confident we have a shared understanding of the problem we're solving. I have a few guesses, but I don't want to bias the discussion, so please restate the problem without suggesting a solution. If it's too difficult to explain, I can suggest what problems I think you might be running into." I wish I always remembered to say that. :-)

	▲	0x445442 an hour ago \| parent [-]
		Upper management material right there.

▲

robertlagrant 4 hours ago | parent | prev | next [-]

It can be the case that people don't want to accidentally mis-state the problem, or get into a debate about the problem because they know people will chime in about nonessentials. I would recommend "Have we written down the problem we are trying to solve? I'd like to understand more." And get it written down if it isn't already.

▲

computomatic an hour ago | parent | next [-]

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.

	▲	Alwayshasbeeb a minute ago \| parent [-]
		> 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.

▲

some_furry 3 hours ago | parent | prev [-]

Trying to position the conversation as "we're on the same team, trying to figure the problem out together" also helps a lot of the intensity of these conversations melt away.

▲

natdavidson 2 hours ago | parent | prev | next [-]

I wouldn’t ask that if you want to keep your job.

	▲	devmor 9 minutes ago \| parent \| next [-]
		That’s a very silly statement. I’ve been asking that question for over a decade and it’s the question that makes me a better developer.
	▲	reaperducer an hour ago \| parent \| prev \| next [-]
		I wouldn’t ask that if you want to keep your job. You are correct. You ask that if you want to get promoted to a better job, because you understood the problem and likely saved the company money, time, effort or all three, rather than just pushing the buttons like a good code monkey.
	▲	paulhebert an hour ago \| parent \| prev [-]
		Really? I’ve asked that question all the time throughout my career. Lots of promotions. No firings or layoffs. Why would you lose your job?

▲

win311fwg 2 hours ago | parent | prev [-]

Reverse engineering the problem from someone's solution is the job. If you find it to be frustrating, you might be in the wrong profession.

	▲	devmor 5 minutes ago \| parent [-]
		I don’t know what job you think I have, but my job is to identify and implement solutions to problems, not figure what problems exist from someone else’s contrived answer to the problem.