80hr weeks also mean it takes 120 hours to do something that should take 30.
But hey, on the other hand, a lot of my work is "Hey, so err, we have this mess on our hands and we need somebody to come fix it because we can no longer implement new features because we keep breakign everything"
I'm sure those engineers are totally fine guys, but man the code I've seen ... wow.
80 hr weeks == all the people at your company who have substantial talent and experience go elsewhere because they can make the same money by working fewer hours. Basic economics.
80 hr weeks == vastly diminished possibility of hiring people who have families, other interests, or "lives" outside of work, so your hiring pool is diminished.
80 hr weeks == everyone is overworked and tired, there's no slack in the system to allow for doing things the right way, effective productivity is actually much decreased because the quality of work is low and the opportunity to pay down technical debt is absent. Any amount of extra productivity that could be had by working more hours is eaten up by people needing to "live" at work (pay bills, communicate with friends and relatives, eat, etc.) and by constantly having to pay the interest on technical debt that can't be paid down.
80 hr weeks == no ability to innovate, no agility, so you get stuck plugging away on N-1 ideas while your competitors who have slack have spent their free time spinning up an N+1 prototype that is going to disrupt your entire business.
Problem is that the formula you really want is usually productivity per dollar and long-term productivity over time.
You can try to optimize both, but the problem with labor is that productivity per hour is not a constant. Even manual labor may see diminishing returns when working lots of overtime. In fact with manual labor the diminishing returns are often fairly easy to measure. With programming, it's much harder to predict.
The conundrum is that unlike manual labor, under some circumstances programming can actually see increase in productivity per hour the more time per day you spend at it. (Less mental context switching? I don't know why it is)
But that's usually only if you don't factor in resulting burnout. Experienced developers recognize this and is why they're more reluctant to work for hour-demanders.
There is such a thing as programming trance, with working 16hrs a day and very high productivity. But then, you need an environment fully devoid of distractions (like working from home if you are single or a locked personal office otherwise), no interactions with your boss or co-workers etc. Unlikely to happen in a company where long working hours are a norm.
Also, programming trance can last at most a week and you can't do it more often than once or twice a year. There are physical limits to what your brain can sustain.
I worked with a guy who would go on a big coke binge and was really quite productive for about 72 hours. He would then do almost nothing for the next three weeks but complain about how hard he'd worked.
If you really manage to achieve Flow State and have a really good view of the problem clear in your mind, then pulling long hours can be very helpful. I think most really good programmers know just how this feels, and when to do it.
Problem is, it's not a "superpower" that can be switched on at-will; it's a state of concentration that requires not only work ethic but a real, intense interest in the subject and a lack of competing thoughts and obligations.
A manager who is demanding high hours is not going to be refraining from piling on the distractions and obligations, because pushing out those competing demands are exactly why they demand the hours.
When I pull an all-nighter, I build momentum like a freight train. In one 16- to 20-hour session, I can get a solid week's worth of work done.
...And then I'm so exhausted that I'm useless for a week afterward. So it's not really all that useful unless I'm up against an absolutely immobile deadline.
is it really though if you're creating so many issues with bad code that after fixing it, support issues, et all that you only end up with equivalent 30hr/week?
when you fuck with the formula, 'basic economics' goes out the window.
Except it doesn't, because the manager will shift to a different aspect of Basic Economics and fire the overworked developer for nonperformance and churn through to the next monkey to leap into the meat grinder. Just add H1-B to your recipe for success.
