[MattGaiser]

A lot of organizations would benefit from being more clear of what needs to be developed, even on this side of the world.

I probably lose 1/4 of my time to unclear specs and things that PMs assume I would know. Why they think I know anything about the industry is another question.

[Person5478]

I have an analogy I like to use.

No one in their right mind would put an engineer on a factory line because said engineer built the machine. Yet people are completely ok handing off tasks to developers and asking them to do the mechanical part of the job.

In both cases you're only extracting half the value from that person that you could be.

That back and forth with your PM isn't wasted time, it's you digging in to better understand, and in doing so are given the opportunity to identify and make suggestions due to the expertise you have that the PM doesn't. I'll go one further. Your company should endeavor to put you face to face with the "customer" making the request if it's practically possible for exactly the same reason, and your PM shouldn't be involved at all outside of setting the priority for the work itself. This is of course ideal circumstances and there are always reasons why the reality can't match exactly, but in general this is what you should be endeavoring to do.

[MattGaiser]

> Your company should endeavor to put you face to face with the "customer" making the request

Strongly prefer the current system over that :)

[Person5478]

That's so foreign to me I just have to ask why.

[MattGaiser]

Maybe it is different if the customer is technical, but non-technical people are often painfully imprecise.

A "bunch" is not a valid item count.

They are going to be dissatisfied by whatever colour "red" is chosen. Or with the sequence of steps to get to a goal in a paginated step flow if not ironed out first.

If something is going to expire, they need to specify the time along with the date and whether it is attached to the user's timezone or UTC.

They are going to say Firebase when they mean Mixpanel because they might have Googled something and badly misunderstood it.

You are trying to do a structured activity based on the thoughts of someone who often isn't.

Given the choice between writing code that gets tossed or a tedious and repetitive conversation where I am endlessly asking "can you be more specific?", I choose writing code. Someone else can have that conversation.

[Person5478]

From my perspective, that back and forth is a natural part of software development. If they wanted red and once they see it they decide they want a different shade, to me that's good software development (as long as it doesn't turn into bikeshedding).

Often people aren't sure themselves what they want until they see it, or they get new/better ideas after seeing it in motion (or decide they don't like it). Good software dev is like boiling water. It's tumultuous with a smattering of chaos, but in general drives towards the goal.

It also allows you, as a developer, to take more ownership of the software as a solution. At the end of the day you're helping solve someone's problems. For me that's satisfying, even if it's a small problem.

And it's been my experience when you do that well, people love you for it.

And to be clear, I put customer in quotes for a reason. Sometimes the problem you're solving is that batch job needs to be realtime, or that one query is slow as the data got too large, ad nauseum. It's not always non-technical people.

What I never want is a PM to just tell me to make a query faster without being able to discuss with the people it affects what their use case is so I can start optimizing for the specifics rather than just in general (although sometimes that's the right approach).