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.
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.
"Embracing their creativity and productivity" is hell for the rest of the team who now has to do 5k line code reviews or the feature is forever siloed to that one dev. Most work is not inspiring; when it is it's usually because someone else is spending their time eating shit to give you room to get inspired.
> The vast majority of “deadlines” are completely artificial
IDK, to me it sounds like you have worked in a half dozen B2C startups in a US urban region, all with plenty of money to burn and still seeking "product-market fit". Most development work doesn't go that way. If we don't have A, B, and C ready by the end of the year contracts get breached and people get laid off.
> "Embracing their creativity and productivity" is hell for the rest of the team who now has to do 5k line code reviews or the feature is forever siloed to that one dev. Most work is not inspiring; when it is it's usually because someone else is spending their time eating shit to give you room to get inspired.
I actually think it's ok to silo projects to a single dev if you design your architecture correctly so that their zone has well defined APIs. I've definitely seen this work better than design/dev by committee.
> IDK, to me it sounds like you have worked in a half dozen B2C startups in a US urban region, all with plenty of money to burn and still seeking "product-market fit".
It's true! (except for the seeking product market fit part, they have had it). I definitely enjoy this type of development better, I also think it leads to the best results and the highest quality software if done right (alongside open source).
> Most development work doesn't go that way. If we don't have A, B, and C ready by the end of the year contracts get breached and people get laid off.
I'm 100% sure you're correct, but I don't think this is developer friendly or a good thing. Part of making great software is having the proper business infrastructure around it. That includes sales, which definitely shouldn't have contract deadlines for unshipped features imho.
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.