Live data from Hacker News

"Any time you have worked long hours, it is a sign of a broken process."

programmers.stackexchange.com

81–90 of 172 posts

Re: "Any time you have worked long hours, it is a sign of a broken process."

#81
I am surprised no one has quoted something from Steve Blank http://steveblank.com/2009/06/18/epitaph-for-an-entrepreneur... "Work Smarter Not Harder As I got older I began to realize that how effective you are is not necessarily correlated with how many hours you work. My ideas about Customer Development started evolving around these concepts. Eric Ries’s astute observations about engineering and Lean Startups make the same point. I began to think how to be effective and strategic rather than just present and tactical."

Re: "Any time you have worked long hours, it is a sign of a broken process."

#83
The broken process may not be company-specific. We are in an industry that is driven not just by getting things to market, but by getting things to market faster than the other guy. As we all know, software does not really scale too well to adding people to the problem. Thus, being to market faster is often achieved by coaxing more work out of the same number of people, this results in long hours.

Thought experiment: Imagine some sort of truce declared among startups to skip this part of the arms race. Or, imagine a law passed capping work weeks for software engineers at 50 hours, no exceptions (again, the reason this happening by law would be to eliminate the arms race). What would it do?

Re: "Any time you have worked long hours, it is a sign of a broken process."

#84

How about in a cyclical project start -> project release process? I am not referring to "crunch time" where you realize everything is broken and your schedule was unrealistic; rather, many projects I have participated in have an escalating work load as you near release, because a lot of the work simply cannot be done before previous stages are completed. Unless you are a large entity that can heavily "pipeline" by ru…

Work that can't be done because of dependencies, long release cycles instead of incremental delivery, planned escalating work load...

What part of that do you think is NOT broken?

Re: "Any time you have worked long hours, it is a sign of a broken process."

#86
Any time you have worked long hours it is a sign of a broken process.

--------------------------

I see the point they're trying to make, but this is the problem with speaking in absolutes ...

My personal preference (and I suspect other developers do this too, but I could be very wrong about that) is to work when I'm in the zone ... sometimes I can go for 8 hours, others I can go 24 hours straight without any trouble (other times I don't get anything done for a couple of days) ... during projects when I'm knee deep in building something, its not uncommon for me to do 10 - 14 hour days ... not because its expected of me, but because that's how I work.

As long your employer isn't forcing you to do death marches/ insisting you work on weekends and you're getting good rest, exercise and eating well, I don't see a problem.

Re: "Any time you have worked long hours, it is a sign of a broken process."

#88
post #63

Earlier quoted context omitted.

"If you're working overtime very often on your own business, it's either because you're incompetent, or lazy, or greedy, or failing (see 'incompetent')." Of all of the successful people I've met (measured in cash, influence, etc), I can't think of ANY who weren't pretty seriously married to their work. I guess many of those people fall into the "greedy" camp and are doing it for the money. But I think most of them do…

I think that's a myth of the startup world (a persistent, but mostly incorrect myth). I know successful people with both balanced and unbalanced lives... and the former are definitely happier. I'm not convinced that regular long hours lead to a more competitive business. Particularly when it comes to running a business (as opposed to being a contractor or freelancer, which is a completely different proposition), spen…

I think you're ignoring the group of people who both work smart (as you define) AND work long hours. That combination would probably have the highest correlation with success. It's not either / or.

Re: "Any time you have worked long hours, it is a sign of a broken process."

#89
post #13

What do long hours often represent? Enterprise: Incompetent management, lazy co-workers, and spoiled users. Small Business: Tough competition and limited resources. Startup: Taking advantage of opportunites that may not pass this way again.

I think it's important that these long hours are the exception and not the rule. You do hit a burnout point eventually and this can be devastating for a start-up where you need your best and brightest being exactly that and coming up with new and better solutions to existing problems that will help put you ahead of the current and future competition.

Re: "Any time you have worked long hours, it is a sign of a broken process."

#90
post #63

Earlier quoted context omitted.

"If you're working overtime very often on your own business, it's either because you're incompetent, or lazy, or greedy, or failing (see 'incompetent')." Of all of the successful people I've met (measured in cash, influence, etc), I can't think of ANY who weren't pretty seriously married to their work. I guess many of those people fall into the "greedy" camp and are doing it for the money. But I think most of them do…

I think that's a myth of the startup world (a persistent, but mostly incorrect myth). I know successful people with both balanced and unbalanced lives... and the former are definitely happier. I'm not convinced that regular long hours lead to a more competitive business. Particularly when it comes to running a business (as opposed to being a contractor or freelancer, which is a completely different proposition), spen…

I agree.

   On the more competitive business part, on average a developer only has about 3-4 peak hours of productivity during any given day. The time when your programming in the "zone" and get huge amounts of work done in minimal periods of time. The remaining time tends to be filler time, minor code cleanup, changes, being stuck on problems you would never encounter when still fresh/awake. etc.

  When you increase work hours across the board you increasing this filler time of not especially high productivity work. At the same time you tend to decrease the amount of peak productivity/in the zone hours developers see each day due to the gradual effects of burn out. 

 It's not good for business.
Post reply on HN