Hacker News Reader

Comment by SomeCallMeTim | Hacker News Reader

That was the same gist I got.

"We needed people who would be with us at 2 a.m. committing code so that we could have it in front of AT&T the next day."

That's not about good employees, that's about employees with no lives outside of work. Of course the ones whose job becomes their life will stay longer. It's far more traumatic to leave if you don't know anyone outside of work.

I'll take the four-day workweek start-ups any time over the death march start-ups. And I'll put my own short-week productivity up against anyone's 80-hour week.

View on HN

I worry that justifying the desire for a life outside of work in terms of "productivity" already concedes too much.

Even if my short-week productivity doesn't match my 80-hour week productivity, I'll still prefer the short week, with no guilt over having those preferences. My goal in life is not to optimize everything I do for maximum benefit of my employer; I have my own priorities and trade-offs to worry about.

Granted. I'm sticking with the short week for as long as someone will pay me for it. That really is the argument you need to make: Can you get enough done in a week to be worth your salary and benefits?

If so, then an employer should be willing to pay you appropriately for that amount of time.

It's true that someone experienced and focused could work 35 hours and produce as much as (or more than) another person who is less experienced and more randomized putting in 80 hours. Start up workloads (for good or bad) is more suited the latter type of workers though. The main reason is most of the time, no one knows exactly what needs to be done in a start up. Yes, product road map changes monthly (or even weekly) and blockers come up every day. As a result, someone sticks around more will be able to respond faster to the changes.

I will never do more than 60 hours work week, and that will only be for a couple of weeks max to get something out of the door. So as a result, I'll never work for a start up that doesn't have a concrete product road map that I could understand and believe in.

I disagree with your premise (that 80 hours a week is appropriate for a start-up).

As an experienced developer (25+ years now), I'd put money on my code being more capable of pivoting quickly to a new product road map than the code of a less experienced developer.

I've had clients/employers be amazed by how fast I could change fundamental behaviors of software I've worked on, and not because I put in 80 hours, but because the design starts out flexible, and I can adapt the work to the new requirements with minimal effort.

Sure if you're ask your dev to make changes on a Saturday, the 80-hour employee will be there, but if he/she is still working on that major pivot by Monday, and I can make the changes in a few hours, and my code is more stable, then I still win. ;)

Sorry, but I just don't buy this wishful thinking of low hour high productivity. Personally, I probably hit peak productivity around 60 hours although I rarely work for longer than 4 hours without taking a break to eat lunch/dinner or play with my daughter. People who hit peak productivity at 30 hours probably just don't like what they're working on as much and so of course founders select for the former. That said this only relevant if you're trying to be highly productive. I have nothing against people who choose to spend their energy on other things.

That's interesting, how do you define 'productive'? What can you do after 60 hours you can't do after 30?

I can get more things done in 60 hours. I'm looking at productivity over the long term. If I work 60 hours/week for a whole year I will accomplish a whole lot more than if I worked 30. But if I work 80 hours per week, I will only accomplish marginally more than 60 hours and maybe even less if I burn out. Everyone has different priorities and different breaking points, but I find it disingenuous when people claim more hours doesn't allow for more productivity. I'm certain there are people that can sustain much longer periods of productivity than myself and as a result accomplish more things.

Of course spending time alone does not mean you'll be productive, but assuming equal intelligence, someone who is able to sustain concentration over a longer period of time will accomplish more than someone who concentrates for a lesser amount of time.

Well, I can't say that it's true for EVERYONE, but my typical work-week includes about 30 hours of work, and I work on teams with others who work 40+ hours, and I consistently get more done per week than many other team members.

Maybe I'm just faster; my own experience is that I can push to 50 hours in a week, maybe 60, but then the following week I get about 20 hours of productivity in before burning out, so 60 isn't sustainable, at least for me. And those last 20 hours in a 60 hour week are really only good for brainless tasks.

God forbid I do any truly complex code in that time, or my net productivity will actually go negative, as I'll need to spend more time later fixing what I did as a zombie.

I don't think he was implying that every week should be 80 week death march.

I think instead he was saying that when something is due the next day. He doesn't want someone who just clocks out because 5 pm came around. He wants someone who cares enough to stick around till they have something working for the demo they have tomorrow

I challenge you to spend 80 hours finishing something due "the next day." Days are only 24 hours, after all.

80 hours means they've been death marching for at least five days (assuming the devs still sleep) and more likely a full week (if you allow for commute time and eating not at your desk).

And I do stick around until late when something is due the next day. But that typically means I put in less time later, so my net time spent is still about 30 hours/week. Putting in extra time means I need more free time to balance things out, and I think anyone who doesn't do that isn't acting in their own interests -- or their employer's.

Reply on news.ycombinator.com