4 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. Maybe schedule in s

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

GiorgioG 3y ago
I don’t live in an alternate universe where “Maybe schedule in some rework time to try again” ever actually happens.
- boxed 3y ago
  Maybe look for a new job?
- cqqxo4zV46cp 3y ago
  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.
deleted 3y ago
[deleted]
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.
    - 3y ago
antupis 3y ago
Yup pretty much this but you need to grind that $0/day work that you see right problems.
atoav 3y ago
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.
mmcnl 3y ago
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 3y ago
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 3y ago
  > 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.

by roenxi 3y ago

GiorgioG 3y ago

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

boxed 3y ago
Maybe look for a new job?
cqqxo4zV46cp 3y ago
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.

deleted 3y ago

[deleted]

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

antupis 3y ago

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

atoav 3y ago

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.

mmcnl 3y ago

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

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