5 ms·

I think we've built companies and cultures that are incompatible with long-term employment and happiness. Anyone who joins a company can crank full 8+ hours a

I think we've built companies and cultures that are incompatible with long-term employment and happiness. Anyone who joins a company can crank full 8+ hours a day for a while to establish themselves (and a reputation). The "problem" is, as people establish themselves, the problem domain becomes less exciting. There's less urgency to crank indefinitely. They settle into a pattern that involves fewer hours, though those hours are more productive because they know the ropes. There is a sweet spot where someone knows enough to be productive but isn't yet complacent. This is the spot that every employer dreams of: employees cranking, full speed, productively, for 8 hours. It's just not sustainable. You can fire people and try and keep turning over staff such that everyone stays in that sweet spot, but you'll eventually end up with a different sort of headache when your staff has no organizational memory for why decisions were made. The people who built things and have the long-term visions have left, and those who pick up the torch try will never have the same big-picture in their head. The challenging bit is how do you separate someone who works 3h a day because that's all they can sustain (and they're just being realistic), and those who work 3h a day, could work more, but chooses not to? I'm not sure you want to force either out, but can you incentivize the latter to produce more?

BlargMcLarg 4y ago
Here's the real challenge: stop thinking in hours, limit upper bounds so employees don't inevitably fall into a race to the bottom (like what is happening now). If your 3-hour-could-be-8 made adequate contribution, whatever that is, that's enough. If it takes them 8 to get to where the other is, incentives will push them to do so.
- csa 4y ago
  > If your 3-hour-could-be-8 made adequate contribution, whatever that is, that's enough. If it takes them 8 to get to where the other is, incentives will push them to do so. This works great until you PIP an underperforming female, minority, or person over 40. The discrimination lawsuits will make the company regret their progressive stances. You wouldn’t believe how many times I have seen this happen. The median outcome is a settlement with no admission of guilt (usually because it’s cheaper than the alternatives), and the person now has a job for life or is given severance until they get a comparable position elsewhere (and they won’t be rushing).
treis 4y ago
I think there's plenty of people that would crank out code* given a sane supporting organization. The issue is that most organizations aren't sane and there's little incentive to crank out code. Incentives are generally (1) finish 5 points of stories per week and (2) build a resume/promotion package. Both of those sound okay but tend to be wrought with perverse incentives. (1) leads you down the path of padding estimates so you don't miss. It also means if you finish early you don't really want to pull in more stories. That tells people you're padding estimates and they'll push you to lower estimates or take on more stories. Then when you need that padding it's not there. So if you finish your work on Wednesday it's better to chill and look busy instead of doing more. (2) is just obviously bad. Delivering complicated projects and supervising other employees makes you look better. So projects get complicated and teams get bloated. *Crank out code should probably be "build functionality according to good practices" but doesn't really change the point.
zmgsabst 4y ago
I think software is just an immature profession — so we don’t have a good idea of what a day looks like. Looking at my day as a carpenter, then: - 30 minutes break - 30 minutes startup/cleanup - 1 hour moving stuff/between jobs - 6 hours ostensibly working; 4-5 hours focused And what I expect of SDEs, now: - 1 hour breaks - 1-2 hours communicate (email, CRs, meetings, etc) - 1 hour continuing education/corporate overhead - 4-5 hours writing code/tasks I’m always skeptical when I hear people are doing more than around 4 hours of coding a day — and start to wonder what’s being skipped.

BlargMcLarg 4y ago

Here's the real challenge: stop thinking in hours, limit upper bounds so employees don't inevitably fall into a race to the bottom (like what is happening now). If your 3-hour-could-be-8 made adequate contribution, whatever that is, that's enough. If it takes them 8 to get to where the other is, incentives will push them to do so.

csa 4y ago
> If your 3-hour-could-be-8 made adequate contribution, whatever that is, that's enough. If it takes them 8 to get to where the other is, incentives will push them to do so. This works great until you PIP an underperforming female, minority, or person over 40. The discrimination lawsuits will make the company regret their progressive stances. You wouldn’t believe how many times I have seen this happen. The median outcome is a settlement with no admission of guilt (usually because it’s cheaper than the alternatives), and the person now has a job for life or is given severance until they get a comparable position elsewhere (and they won’t be rushing).

treis 4y ago

I think there's plenty of people that would crank out code* given a sane supporting organization. The issue is that most organizations aren't sane and there's little incentive to crank out code. Incentives are generally (1) finish 5 points of stories per week and (2) build a resume/promotion package. Both of those sound okay but tend to be wrought with perverse incentives. (1) leads you down the path of padding estimates so you don't miss. It also means if you finish early you don't really want to pull in more stories. That tells people you're padding estimates and they'll push you to lower estimates or take on more stories. Then when you need that padding it's not there. So if you finish your work on Wednesday it's better to chill and look busy instead of doing more. (2) is just obviously bad. Delivering complicated projects and supervising other employees makes you look better. So projects get complicated and teams get bloated. *Crank out code should probably be "build functionality according to good practices" but doesn't really change the point.

zmgsabst 4y ago

I think software is just an immature profession — so we don’t have a good idea of what a day looks like. Looking at my day as a carpenter, then: - 30 minutes break - 30 minutes startup/cleanup - 1 hour moving stuff/between jobs - 6 hours ostensibly working; 4-5 hours focused And what I expect of SDEs, now: - 1 hour breaks - 1-2 hours communicate (email, CRs, meetings, etc) - 1 hour continuing education/corporate overhead - 4-5 hours writing code/tasks I’m always skeptical when I hear people are doing more than around 4 hours of coding a day — and start to wonder what’s being skipped.