Are 10-11 hour programming days feasible?

This is the best quote from the comments:

Unfortunately, I see way too much of two kinds of people in startups. There are way too many dishonest owners and bosses who will take advantage of trusting geeks. After all, our skills are all engineering and software, not negotiation and conflict. On the other hand, there are way too many gullible geeks, and geeks who like so many beaten house wives are simply unable to grow a pair and stand up for themselves. Assuming you care about your employees, it's probably up to you to stand up for them.

That right there is the reason you see this question come up over and over in software companies. The plainly obvious answer, when asked to work 60 hour weeks as a matter of policy, is "Not just no, but hell no. It simply doesn't work. We'll do it (to your detriment) but you're going to have to pay us hourly while it's happening." But because of this unique combination of uninformed (or manipulative) management and meek developers, that answer never gets presented and the policy gets put in place.

If you see this start to happen at your office, stand up for yourself and your co-workers immediately. They won't put the policy in place if they know for a fact that the whole team will walk.

Short answer in this situation: No.

Expanding a bit: The employees only gain in the most abstract sense by working longer to implement a bunch of features that are vaguely defined as to when and why. They get no extra money, no sense of worth attached to their shares, no bonus for doing the work.

This isn't about some "incentives don't work" crap either. It is pretty simple people dynamics: these guys work at a startup for a salary, they are not really in it for the big payout, they are in it for the job. Having to work absurd hours when there is no obvious benefit or need is a good way to create resentment. If it was a 2 or 3 week push to "finish this stuff and knock out a release" fine, but give them some relaxing days/paid time off at the end. That is what they respond to.

Further, the fact that the bossman thinks this unpaid indefinite death march is a decent idea suggests it is time for resume freshening.

Yes, 10 or 11 hour programming days are feasible. They can even be productive, and not lead to burnout. HOWEVER for that to happen, it has to be programming that the programmers want to do, and they need to be given a lot of freedom in how they accomplish it.

Think of it this way--if a programmer won the lottery and retired, what would he do? Many would spend 12 hours a day programming on personal projects. If you can make work line up with those interests, then they might spend that kind of time on work.

This is hard to accomplish. All of the times I've seen it happen were spontaneous. That is, the programmers worked 10 or 12 hours a day without having been asked to do so.

The best thing about 11 hour days at a startup is that you have absolutely no time be distracted by applying for other jobs! The worst part is that, by Thursday afternoon, you are afraid to touch your good early-week code with your wrecked head and retarded fingers.

I worked those, with a twenty minute lunch break, for 7 months, for not shitty pay but not good pay. At the end, we were asked to work for no salary, after everybody got super shitty performance reviews. We asked for stock and the CEO flipped. I quit, and asked him for my back wages, and he threatened to sue me for libel if I said they were owed. I lodged a court case and he back paid me.

Like almost everyone else I'd say no, especially in the context of employees being asked to do so. I do think it's possible for short bursts, where someone is internally motivated. That's usually the "implementing my idea frenzy" sort of thing: you've worked out an idea in your head, and then have a big coding binge turning it into the first prototype. But it's really hard to call that up on command as an employee assigned programming tasks, or keep it up long term (at least in terms of being productive for those long-hour weeks... it's quite possible to "work" 80-hour weeks while getting 20 hours of work done in them).

The Laws of Productivity: http://lunar.lostgarden.com/Rules%20of%20Productivity.pdf

In answer to the headline: Of course - just not every day. :)

In answer to the actual situation behind the headline: No. It's time to find a new boss.

I'd estimate that 4 hour programming days are feasible as an average.

10-11 hour days means that the guys will be just doing nothing (or worse) more than half of the time.

I think Linus Trovalds in an interview was saying something of the sort:

I do not believe in crazy schedules. It does not worth it to work one day for 16 hours because the next day you will be like a ghost. Work as much that you will be able to work equally much and a lot the next day.

I do not think that it would be possible biologically to keep that pace of work(10-11 hours programming days) for long periods.

The exception: of course sometime when an emergency shows you should work and 10 and 15 and 18 hours straight

Burn out will start after 2 weeks, error rate will raise accordingly. Very soon, you will be occupied a lot fixing errors that only occur, because programmers are not well concentrated.

Trivial. The company will lose instead of win. New features require programmers that are inventive. Ever seen someone inventive who is overworked?

And then: require 15 hours work without any more salary? Find new jobs.

After 30 years in programming business I must say: the way to win is to stay creative, think well what features your product needs to stay on top and satisfy customers. Implement and test this as good as you can. The rate buggy software loses customers is high. And a lost customer will not come back for a long time.

Sure they are. I do it every day. I work at my actual job for 8 hours, and then come home and work on my own stuff for another 8 hours. I've been doing this for quite awhile. =/

Consider this a gift. It's a thinly veiled advanced-warning pink slip.

If an employer ever asked you to do that, get out. Even if he takes "no" for an answer, your boss doesn't understand programming and how to allow programmers to function at maximum productivity, and hasn't bothered to figure that out before he started hiring programmers.

That is the wrong person to work for if you're a programmer, and it will be a reoccurring them.

"For some reason our job listing that says 'engineers needed, 10-11 hour days for 8-hour pay' isn't getting the response we'd hoped for."

The problem is it's hard to be creative or insightful if you are working that hard * , which means that you won't see the simpler way that saves a lot of time. So you can do it, but only for mindless repetitive mechanical work, that doesn't require creativity - but then again, that's exactly the kind of work that is ripe for automating, though doing so usually takes some insight and creativity.

This is not what you're talking about, but an exception is someone I knew who would code 30 hours straight, because it enabled him to keep all the code in mind, instead of having to reload it each day. I think it took a few days break after each such session.

* irrelevant to the question, but if "programming" includes thinking about it in the back of your mind, while day dreaming, asleep, having a shower etc, then you can "program" 24/7.

Apart from the (admittedly pretty pivotal for this case) unpaid overtime request part, I feel a 10 hour average is not unreasonable as long as it's not rigidly mandated. Requiring physically being in the office for 10 hours straight five days a week is idiotic in software. Allow going home or stepping out of the office for a couple of hours for a walk in the park when the code isn't flowing or you're stuck on a dumb bug, but make it clear there's a lot of work to be done (and compensate accordingly!). If programmers like what they're doing they won't count the hours.

Of course that's not going to fly with those who don't wish to work outside standard 9 to 5 -- and there's a lot of people who don't for very valid reasons -- but they're less likely to be found in a start-up anyway.

Absolutely feasible, you'll just produce the same as of working 6 hours per day after the first couple of days of working so long. So absolutely useless too, if done for long time. Only useful for sprints, two or three days every month at max.

Not really.

It would probably be better for the health of the company to direct all dev efforts towards marketing the current software (at a sane pace).

  For example:
  setting up mailing lists
  ad words
  ads on craigslist
  SEO
  A/B testing
  heck, even getting the devs to pick up the phone
  and do some old fashion cold calling.

The closer devs are to the customer the more they will know about what customers want.

Working 11 hours is counter productive, as a coder you should focus on mental state. It's far better to be highly productive for 3-4 hours a day than unproductive for 11 hours. Being unproductive for 11 hours just leads to working 12 hours the next day as you fix the bugs you put in yesterday. All you're adding to the code base at that rate is bugs. Being tired and in a poor mental state will lead to having two eyes on the goal instead of two eyes on the path. Time in seat does not equal working (or profitable) code.

How does working longer lead to more profit?

How does working longer lead to working code?

Have customers asked for those new features?

Are the customers paying for the dev effort?

Software is a business with zero cost of reproduction, therefore its essential that a customer base is established on the minimal amount of code. One should not start writing code until there are enough customers to pay for the feature or a customer is willing to front the costs for the dev effort. It's not the dev's fault that management chose a set of features that is unprofitable. Rather than adding more unprofitable features you should focus on adding profitable features. Or focus on selling the features you have until it's profitable. If you can't sell the feature don't code it. Find out first by trying to sell it.

Spolsky says one thing about features, DHH says another, the important thing is not who says something but how relevant it is to the situation at hand. As a user of Fogbugz I can tell you that one of the things I really liked about it was it's simplicity. Fogbugz for me was way better than JIRA which has many more features.

In my experience, the length of the working day is usually a red herring. Over-engineering & over-complexity is usually the problem that slows the launch of a product. (as well as good old-fashioned bad planning, bad management and unrealistic expectations)

* Too little pressure and flexible deadlines lead to over-engineering and feature creep.

* Too much pressure and unrealistic deadlines leads to bug-ridden, throw-away spaghetti code.

* A realistic deadline with a small amount of pressure leads to better design decisions and just-engineered-enough code.

Combining over-complexity with long hours towards the end of a release is normally a recipe for disaster.

Projects that have too little pressure at the beginning are often the ones that end up with too much pressure towards the end as unfinished, superbly flexible, elegant code is shoe-horned into the one imperfect small use case it was built for (while twenty other features, that were pushed aside for it, languish unimplemented).

Coming up to a deadline, sometimes these really help (code marathons) when used sparingly.

After working on a few deadline-centric projects (based around the college school year), We've certainly found this to be the case.

It's feasible but it not productive, what you do in 11hours can be be done in 8. Unless you are very enthousiast about what you are doing there is no way you start don't loosing productivity after 8 hours being focused.

I think the key question here is this guy's relationship to his boss, which can't be determined from the brief amount of data provided. There's also the issue of whether more features make a difference, so this entire thread is a bike-shed-painting exercise.

Everybody is saying "no", and I'm the PM who usually tells his team to take more time off, but I'm also a contrarian, so for purposes of this comment I'll say "yes"

Here's the deal: work is somewhat arbitrary. Yes, there are those of us who are working on curing cancer, building the next space transport system, or curing world hunger. But most of us are doing something a lot more mundane, like getting some random project finished.

Given a situation like that, there are two types of thinking. Type 1 says that since none of it matters, you might as well look out after yourself: make sure you are well-cared for. Have plenty of time off. Do fun stuff to alleviate the boredom. Pick up a video game in the evenings to spend ten thousand hours playing it over the next year.

Type 2 says that since none of it matters, it's up to you to make it matter. Pick a goal, find something to push yourself to. Make it into a game. Do something, anything, to keep making yourself learn. Life is about stress, and if you are not externally stressed you must learn to create your own internal stress if you are to grow and learn and do more cool stuff.

Neither one of these types of thinking is worth a hoot by themselves, but I'll only work with people who have type 2 thinking and have to force themselves back to type 1. I've found there are way too many type 1 folks who have long forgotten how to work as a type 2, and those are folks who are just filling up seats and waiting for the end of the day. Those are also the types of folks who sit around wondering if it's "feasible" to work 11-hour programming days. The rest of us are just doing it.

So yes, you can, but it should be something special, and you need a system where you break off and do cool stuff. This is a long run, not a sprint, but even in a long run you need a kick -- a long sprint at the end. It's actually one of the better parts of a long run. Don't be a sucker for an abusive boss, but learning to push yourself and getting in the habit of applying internal stress is a critical factor in moving your life and career forward.

Ten years ago, I worked at a startup with a fixed 50 hour week without getting burnt out or surfing the web but I don't think I could be as productive as I am now (45 hour week).

In my opinion, not in a sustainable way.

I have worked 60-80 hour weeks for a period of a little over three months, but after that I needed some serious break time.

Terrible idea Just to do it for the sheer fact of thinking more features will being in more money.

Not consistently.

Yes. But only for a short period of time.