5 ms·

Open source is just one example. In general I would say engineers work well in a quite place with no distractions and minimal bureaucracy. It is creative work a

Open source is just one example. In general I would say engineers work well in a quite place with no distractions and minimal bureaucracy. It is creative work after all. > Your idea of a managerial role doesn't seem to leave much room for technical or team leads, only "product management". Sometimes your role is to hire/motivate/unblock - and sometimes the motivational role is make sure someone spends those three hours writing unit tests everyone agreed were important even though no one wants to. I did include mentorship in my list of things needed to help engineers grow. I'd also add "everyone agreed" in a traditional management setting is pretty much identical to "the person who decides how much people get paid, said so". Good devs will typically write the appropriate amount of testing unprodded.

morelisp 5y ago
Engineers (and everybody else) like working in places with no distractions and minimal bureaucracy. But that doesn't mean they all work well them. > I'd also add "everyone agreed" in a traditional management setting is pretty much identical to "the person who decides how much people get paid, said so". Absolutely no one on our team deciding what people get paid has any say in how many tests we write. The engineering manager has some say (mostly as a tie-breaker) in technical decisions but does not "decide" how much anyone gets paid (outside of salary range for new job postings), but can choose to advocate (or not) for a particular person's salary with higher management. The senior developers have the most say, and they determine no one's salary. > Good devs will typically write the appropriate amount of testing unprodded. Qualifying this with "good devs" somewhat begs the question. I would rather avoid judging the developers and just say, no, most developers will not typically write the appropriate amounts of tests by without some friendly reminders.
- solosoyokaze 5y ago
  > Engineers (and everybody else) like working in places with no distractions and minimal bureaucracy. But that doesn't mean they all work well them. I don't think evidence exists to suggest they don't. From a burnout perspective alone, making people work in an environment they don't like will cause attrition. Especially now that there are plenty of WFH options. That's not even touching on how stress impacts creativity. > Qualifying this with "good devs" somewhat begs the question. I would rather avoid judging the developers and just say, no, most developers will not typically write the appropriate amounts of tests by without some friendly reminders. Our personal experiences are diametrically opposed to each other then. I've never seen lack of tests be an issue on any team I've worked with. I have however seen unproductive teams create tests in place of being productive.
  - morelisp 5y ago
    There's a wide range between "burn out" and "had to do something I didn't want to at work today", just like there's a wide range between "my manager's bugging me every 30 seconds on slack" and "why can't I just write the whole feature from my one-sentence description heads-down for 3 weeks and then put up 5k lines at once for code review?" A lot of otherwise-competent developers will do the latter if you don't force them otherwise. (Way more common even among developers skilled at time management: Getting caught up in a bug for X days and not asking for help.) One view is of course that these are not "good developers" and you should not hire them or work with them. Two better views are that these are developers that need to learn a new skill to be even more effective and this will take time and someone pushing to actively learn it; or that even if they don't ever learn it, they can still be effective at their job when supported by a more active manager. (And a critical piece of advice for managers - that doesn't mean you need to be more active for everyone else on the team at the same time.) I have worked on teams closer to as you have described, but I would say that's on a separate axis from functional/dysfunctional - it's very easy to get a team of insular divas - or even sustainable/non-sustainable - developers can build the perfect thing on schedule which no one will want to pay for, which a heavier-handed product-focused manager might have prevented. I do think people who can self-organize are also very good at self-selecting into similar groups. This can result in the illusion that developers are much more effective at this than they believe. Two decades of free money and easy job-hopping resulting in no consequences for bad decisions also helps maintain that illusion - for bad managers also.
    - solosoyokaze 5y ago
      I respect your opinion but have a different philosophy. > why can't I just write the whole feature from my one-sentence description heads-down for 3 weeks and then put up 5k lines at once for code review?" A lot of otherwise-competent developers will do the latter if you don't force them otherwise. (Way more common even among developers skilled at time management: Getting caught up in a bug for X days and not asking for help.) I’d argue that both of those are ok, and the former is even desirable. If you have a dev who wants to do that, they are usually quite good and you should embrace their creativity and productivity. The vast majority of “deadlines” are completely artificial and don’t match the way great software is written (by inspired devs). So much value creation is the search for black swans. Great developers have the ability to make those if you optimize for it. I could see an ad agency or something having deadlines, but personally I would never work in that environment as I prefer product work and maximizing creativity and individual contribution.

morelisp 5y ago

Engineers (and everybody else) like working in places with no distractions and minimal bureaucracy. But that doesn't mean they all work well them. > I'd also add "everyone agreed" in a traditional management setting is pretty much identical to "the person who decides how much people get paid, said so". Absolutely no one on our team deciding what people get paid has any say in how many tests we write. The engineering manager has some say (mostly as a tie-breaker) in technical decisions but does not "decide" how much anyone gets paid (outside of salary range for new job postings), but can choose to advocate (or not) for a particular person's salary with higher management. The senior developers have the most say, and they determine no one's salary. > Good devs will typically write the appropriate amount of testing unprodded. Qualifying this with "good devs" somewhat begs the question. I would rather avoid judging the developers and just say, no, most developers will not typically write the appropriate amounts of tests by without some friendly reminders.

solosoyokaze 5y ago
> Engineers (and everybody else) like working in places with no distractions and minimal bureaucracy. But that doesn't mean they all work well them. I don't think evidence exists to suggest they don't. From a burnout perspective alone, making people work in an environment they don't like will cause attrition. Especially now that there are plenty of WFH options. That's not even touching on how stress impacts creativity. > Qualifying this with "good devs" somewhat begs the question. I would rather avoid judging the developers and just say, no, most developers will not typically write the appropriate amounts of tests by without some friendly reminders. Our personal experiences are diametrically opposed to each other then. I've never seen lack of tests be an issue on any team I've worked with. I have however seen unproductive teams create tests in place of being productive.
- morelisp 5y ago
  There's a wide range between "burn out" and "had to do something I didn't want to at work today", just like there's a wide range between "my manager's bugging me every 30 seconds on slack" and "why can't I just write the whole feature from my one-sentence description heads-down for 3 weeks and then put up 5k lines at once for code review?" A lot of otherwise-competent developers will do the latter if you don't force them otherwise. (Way more common even among developers skilled at time management: Getting caught up in a bug for X days and not asking for help.) One view is of course that these are not "good developers" and you should not hire them or work with them. Two better views are that these are developers that need to learn a new skill to be even more effective and this will take time and someone pushing to actively learn it; or that even if they don't ever learn it, they can still be effective at their job when supported by a more active manager. (And a critical piece of advice for managers - that doesn't mean you need to be more active for everyone else on the team at the same time.) I have worked on teams closer to as you have described, but I would say that's on a separate axis from functional/dysfunctional - it's very easy to get a team of insular divas - or even sustainable/non-sustainable - developers can build the perfect thing on schedule which no one will want to pay for, which a heavier-handed product-focused manager might have prevented. I do think people who can self-organize are also very good at self-selecting into similar groups. This can result in the illusion that developers are much more effective at this than they believe. Two decades of free money and easy job-hopping resulting in no consequences for bad decisions also helps maintain that illusion - for bad managers also.
  - solosoyokaze 5y ago
    I respect your opinion but have a different philosophy. > why can't I just write the whole feature from my one-sentence description heads-down for 3 weeks and then put up 5k lines at once for code review?" A lot of otherwise-competent developers will do the latter if you don't force them otherwise. (Way more common even among developers skilled at time management: Getting caught up in a bug for X days and not asking for help.) I’d argue that both of those are ok, and the former is even desirable. If you have a dev who wants to do that, they are usually quite good and you should embrace their creativity and productivity. The vast majority of “deadlines” are completely artificial and don’t match the way great software is written (by inspired devs). So much value creation is the search for black swans. Great developers have the ability to make those if you optimize for it. I could see an ad agency or something having deadlines, but personally I would never work in that environment as I prefer product work and maximizing creativity and individual contribution.