[roenxi]

Culturally it is best to train developers to just do something, then provide non-judgemental feedback when what they do isn't what you want. Maybe schedule in some rework time to try again. That way, developers move quickly and sooner or later start building useful things.

"Just tell me what to build" is a dangerous attitude to foster. It pushes more work into the management layer which is already a bottleneck for making decisions. That is bad strategy. A couple of devs thinking that way is OK, but it is going to accentuate the inevitable management dysfunction.

The best approach is a culture where PMs understand customer problems and give quick, effective feedback to developers about whether what they just did affected a customer in a good way. Then management lets developers do what they do as quickly as possible. Alternatives can work, but that is the sweet spot.

The ultimate goal of any software company is to have that one lucky dev who just gets it, builds something amazing quickly and then the company comes in to maintain and milk the product until management miscalculates, destroys it and the cycle starts again. Failing that, the next best option is a product guy who just gets it and organises the engineers to build something that makes customers happy. Neither of those states depends on debate or, curiously, on what the median developer is doing. Software developer productivity is one of the spikiest, most disjointed and chaotic metrics I've ever dealt with and most of the time it appears to be $0/day value add or slightly negative. Then sometimes it spikes to a few million dollars an hour. The culture should all be about working around the spikes, not the day to day.

[nomel]

> Culturally it is best to train developers to just do something, then provide non-judgemental feedback when what they do isn't what you want.

My preferred method of development is tell me what you think you want, then be available for the stream of questions I'll be asking you to make sure what you need is accomplished.

I've found that it's almost always a bad idea, for everyone involved, to implement what someone says they want, unless they're assholes or competent developers.

[danparsonson]

Very much this - I regularly find that asking "what problem are we solving?" allows me to work with the stakeholder in question to find a better solution than what I was initially asked to build. It's fine to take a stab at a solution but it's also a good idea to remember that you hire experts for a reason.

[fallous]

Very much this. I have a long-standing saying that I share with those that want to bypass the "explain your goals to me" portion of the conversation and want to skip to "just do what I asked."

"Be very careful what you ask for because if I really dislike you I'll give you EXACTLY what you ask for and you'll find out quickly how much you didn't want that."

[cqqxo4zV46cp]

This comment got me excited for something that’d actually be useful to say to people, instead it’s needlessly hostile.

[rpmisms]

It's easy to say with a smile an a laugh, but definitely depends on your organization. I do tell people almost exactly this in my solo dev role, but more win the context of "I literally don't have the time to redo this, so let's get it right the first time".

[mmcnl]

I think it's an engineer's responsibility to present likely outcomes with their likelihood without judgment. Opinions are usually not needed unless asked.

[kevan]

> III. Professional Obligations

> 1. Engineers shall be guided in all their relations by the highest standards of honesty and integrity.

> ...

> b. Engineers shall advise their clients or employers when they believe a project will not be successful.

There's nuance around how hard you should push back on bad requests and where ownership/accountability and decision-making responsibility ultimately lie but providing professional judgement/advise/opinions is definitely in bounds for engineers.

[1] https://www.nspe.org/resources/ethics/code-ethics

[rpmisms]

No, I'm not a machine. I'm the only one who can do the work, so maybe listen to me when I tell you it's a bad idea.

[chiefalchemist]

Exactly. Wants (as initially stated) are rarely the actual business' needs. There also has to be some level of depth and breadth understanding, the implementated needs with be fragile and break easy.

That said, interpretating what's and crafting them into needs is more enginner than developer.

[swader999]

A lot of the replies to this are dancing around just ask them "Why" they want what they want. Then the "what is built" can be creatively explored and even negotiated as long as it solves the why.

[atoav]

As a former freelancer in the webdesign, webprogramming, graphics design etc field, what astounded me the most when I first got to work with a software developement company was that there was no design session.

For me it was normal to assume that neither my customers nor I know what they need automatically. This requires a creative process and the finding of a common language at least in the beginning of the project.

The worst thing is when developers you work with are "Ok go!" without discussing and you know they got a hammer and now everything to them looks like a nail. Sure they get things done, but if so do builders that start building a house without a plan.

That strategy works if the requirements are foolproof and straightforward, but as soon as the project reaches a certain complexity. Sure requirements can change, customers can fuck up and misjudge what they want, but a good craftsperson thinks about the future of a project as well. And while you might think you sell software, you are also selling a relationship with the customer. If they feel like you tackled that problem openly together with them, that is worth something as well.

[GiorgioG]

I don’t live in an alternate universe where “Maybe schedule in some rework time to try again” ever actually happens.

[cqqxo4zV46cp]

I’m in management and routinely allow for this. Not as much as my team would ideally like, as is and should be expected, but much more than zero. Sorry about your crappy job.

[boxed]

Maybe look for a new job?

[antupis]

Yup pretty much this but you need to grind that $0/day work that you see right problems.

[mmcnl]

I'd argue that your best approach is only the "best" approach in specific environments you have encountered and that it is not a universal truth. I think it totally depends on the environment and what is expected from that environment what works best.

[n0w]

This sounds a lot like letting the monkeys bang away on typewriters while you sit back waiting for Shakespeare...

TFA seems to present reasonable advice. Yet lots of comments here don't seem to agree that "give experts necessary context and trust to build good products" is a decent strategy.

[roenxi]

> This sounds a lot like letting the monkeys bang away on typewriters while you sit back waiting for Shakespeare...

Well, humans are primates and I suppose we could draw a parallel between keyboards and typewriters. Although if a dev is trying to write Shakespeare they will get gentle feedback that this is an inappropriate use of their time.

> Yet lots of comments here don't seem to agree that "give experts necessary context and trust to build good products" is a decent strategy.

I expect all the opinions agree that the plan is to give experts necessary context and trust to build good products. There aren't actually that many options here. You have to talk to devs, and then you have to let them dev. The question is how much context can/should be front-loaded and how to deliver feedback.

And those are relatively simple to answer; much as possible and frequently. Beyond that we're relying on monkey-typewriter dynamics.