Hacker News Reader

Comment by nomel | Hacker News Reader

> 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.

View on HN

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.

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."

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

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".

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

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.

> 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

I am not an accredited engineer, but I should probably read those guidelines. Thanks!

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.

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.

Reply on news.ycombinator.com