3 ms·
Talking to the users, allowing them to show you what they are trying to do with your software, almost feels like cheating, because of how easy things suddenly a
by bombela 23d ago
Talking to the users, allowing them to show you what they are trying to do with your software, almost feels like cheating, because of how easy things suddenly appear to be when uncertainty fades away.
Obviously, the number of uniquely different users has an influence, and users most often do not truly know what they need, but that's our job to tease appart.
Turns out the users most often benefits from small changes that reduces friction toward achieving their goal. Any time saving will be appreciated, but only if it can be trusted to work. Nothing worse than the dread of knowing an action might or might not work randomly.
I use most software today with a constant sense of fear that the next action will break something and waste my time. Undo probably doesn't work properly anyways
- devmor 23d ago"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.
- robertlagrant 23d agoIt 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.
- some_furry 23d agoTrying 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.
- computomatic 23d agoThis 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 23d ago> 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.
- devmor 23d agoI 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.
- hathawsh 23d agoI 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. :-)
- win311fwg 23d agoReverse 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 23d agoI 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.
- win311fwg 22d agoThat’s the job we all want to have, but it doesn’t exist. It’d be nice to say you are the lone outlier here but unless the previous comment was completely made up we know that’s not the case.
- devmor 22d agoYour job doesn't have to be that way. You can't always change your circumstances, but if you work to make little changes to improve your environment, the people that work with you probably will too. My current team is like that - we all see the roadblocks that make our job harder, and we know we can't solve them all, but we talk about and work on making our own solutions to get around those things - like making a habit of asking those questions to better understand what's really desired by the stakeholder.
- win311fwg 22d agoI has only been approximately 11 hours since your job was expressed to be quite different. I am glad that you recognized the source of your frustration and managed to turn your situation around — and so quickly at that! — but be aware that it is still early days. Temporary aberrations are common in the workplace.
- devmor 22d ago
- natdavidson 23d agoI wouldn’t ask that if you want to keep your job.
- reaperducer 23d agoI 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 23d agoReally? I’ve asked that question all the time throughout my career. Lots of promotions. No firings or layoffs. Why would you lose your job?
- devmor 23d agoThat’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.
- boogieknite 23d agoi consider a sign of maturity in myself that i always defer to adapting my software to fit how the user is trying to interact with it. the sign of immaturity is that my deference masks internally screaming, "why would you want that!? why would ANYONE want that!?" my "customers always right" approach has produced much more successful and useful software compared to my perfect little hobby projects which will never be complete and noone would ever use anyway