3 ms·

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

by nomel 3y ago

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

chiefalchemist 3y ago
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.
danparsonson 3y ago
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 3y ago
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 3y ago
  This comment got me excited for something that’d actually be useful to say to people, instead it’s needlessly hostile.
  - rpmisms 3y ago
    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 3y ago
      I think it's an engineer's responsibility to present likely outcomes with their likelihood without judgment. Opinions are usually not needed unless asked.
      - rpmisms 3y ago
        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.
      - kevan 3y ago
        > 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 https://www.nspe.org/resources/ethics/code-ethics
        rpmisms 3y ago
        I am not an accredited engineer, but I should probably read those guidelines. Thanks!
swader999 3y ago
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.

by nomel 3y ago

chiefalchemist 3y ago

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.

danparsonson 3y ago

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 3y ago

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 3y ago
This comment got me excited for something that’d actually be useful to say to people, instead it’s needlessly hostile.
- rpmisms 3y ago
  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 3y ago
    I think it's an engineer's responsibility to present likely outcomes with their likelihood without judgment. Opinions are usually not needed unless asked.
    - rpmisms 3y ago
      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.
    - kevan 3y ago
      > 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 https://www.nspe.org/resources/ethics/code-ethics
      - rpmisms 3y ago
        I am not an accredited engineer, but I should probably read those guidelines. Thanks!

swader999 3y ago

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.