7 ms·

Are 10-11 hour programming days feasible?

52 points by dholowiski 16y ago

Skywing 16y ago
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. =/
- mironathetin 16y ago
  So, life is a lot of fun for you?
  - ams6110 16y ago
    How "fun" one's life is is not really for anyone else to judge, is it?
    - mironathetin 16y ago
      That's not a judgement, it's a question. I'd be interested how this feels and how he does it. I manage to work on my projects for 3-4 hours a night, but not for extended times. If someone here claims he has a way, let's ask him how.
pan69 16y ago
The Laws of Productivity: http://lunar.lostgarden.com/Rules%20of%20Productivity.pdf http://lunar.lostgarden.com/Rules%20of%20Productivity.pdf
- snitko 16y ago
  I was gonna post the same link. tl;dr you gain occasional productivity boosts by extending the work day, but that is inevitably followed by a decrease in productivity to make up for it.
sophacles 16y ago
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.
- kahawe 16y ago
  Also, the fact that the bossman can obviously NOT think of any (better) way of getting new customers but asking his people to implement features and then hope to lure someone in sounds pretty bad. Depending on country and social insurance and on your readiness for a "unique" company death-march experience, it might be something you want to do... but if you have any responsibilities in life then make sure you have some money on the side and get out as soon as you can. If you can afford it, just for the hell of it, then keep your eyes and mind open as much as you can and observe what is going on around you. What does your boss say, what things does he avoid or not say etc. All this might give you some interesting thoughts and views on "management" and people but most likely will leave you rather disillusioned and maybe even bitter. Getting screwed over and/or taken advantage of is like losing your virginity: it will be hard or downright impossible to go back to "before it happened".
BigZaphod 16y ago
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.
gsivil 16y ago
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
fleitz 16y ago
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.
- InclinedPlane 16y ago
  Good tools combine powerful underlying systems with abstractions that bring the necessary complexity of the system into a realm that is manageable by users. When done well it can make a tool that took a tremendous amount of effort and which encompasses a great deal of complexity look effortless and simple. And more importantly be intuitive to use. If you look at a tool like a hammer both Spolsky and DHH would likely say that it was a simple tool. But that simplicity underlies a lot of complexity. The simplest hammer, the sort that a parody of DHH's ideals would lead you to believe he would advocate building, would be a simple suitably sized and shaped rock. Modern hammers are built using centuries of experience and a great deal of research. A great deal of metallurgy has gone into refining the exact variety of materials used in the hammer head as well as in the manufacture of it (drop forging). And not just in ensuring it is of a certain quality, but in ensuring that it is precisely suitable for its intended tasks. A great deal of research and experience has gone into shaping the head and the handle, and in their construction. Ergonomics, durability, efficiency, cost, etc, all of these factors are carefully balanced in the end product. When you hold a hammer you don't need a manual, it's operation is obvious and intuitive. The best tools work that way. It takes a lot of effort to learn how to drive an automobile properly because it is a complex task, yet the fundamental interface is nevertheless (today) very straightforward and intuitive. Take a moment to think about all of the various tools you use routinely, from silverware and pocket knives to automobiles and cameras. Are these tools simple or merely deceptively simple? How do these tools take control of the inevitable complexity underlying their operation? How do they bridge the complexity gap between the "user interface" abstraction and their fundamental operation? What characterizes better tools of each sort from lesser tools? The same applies to software as well. The language we use in describing software and its use is today incredibly crude and barely suitable for the task, which leads to many debates where neither side is capable of fully articulating their meaning and people are left with half-ideas of what either is trying to get at. I don't think Spolsky or DHH are necessarily arguing in opposite directions, I think they are trying to articulate the complex nature of something that is difficult to convey. Elegance is perhaps one aspect of it, but there is no single word that fully describes the concept that either is trying to get across, I think. Edit: Another perfect example: I occasionally use an infrared thermometer in the kichen. It is supremely intuitive to use. It is vaguely gun shaped, fitting easily in the hand. It has a single button, a trigger, and an lcd screen that displays temperatue and units. Pressing the trigger once generates an instantaneous reading which is displayed on the screen for several seconds. Holding down the trigger generates a continuous reading, updating the display perhaps a few times every second or so. Releasing the trigger leaves the last reading displayed as above. When taking a reading a red laser marks the targetted spot. The battery compartment can be opened without tools but is designed such that the act of using it will prevent the compartment from being opened. When you consider the complexity of such a device, how many various pieces have to be put to use (such as optics, sensors, processors and software to analyze the IR spectrum within a narrow beam and determine a temperature to high accuracy, not to mention all the supporting components like the laser pointer, display, body, power system etc.) it gives a greater appreciation for the incredible elegance of the tool.
jarek 16y ago
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.
- lsc 16y ago
  the number of people who can effectively code for 10 hours a day for a period of months is... small. Nearly everyone I know who claims this ability spends a lot of time doing things like reading hacker news rather than coding. This, I think, is one of the tests of a manager. A bad manager loves to see people looking busy. A bad manager will hire people who claim to work 10 hours (or more!) a day. This manager will quite often stay at work with everyone else (it doesn't matter how early you show up, as long as you show up before the boss. It doesn't matter how late you leave, as long as you leave after the boss.) but he usually slips into dealing with personal business. And so does nearly everyone else. I think a much better approach is to let people figure out what their optimum productivity is. I know one guy who says "i have four good hours a day" - and he is very, very good during those four hours. But after those four hours, really, you might as well send him home to play video games or something. He's done. Expecting 10 hours a day of work on average encourages a culture of deception; a culture of "look busy" which really, isn't any good for anyone. Yeah, I want you to work as much for me as you can. But really, if you are going to work for five hours a day and screw off on facebook the other five? I'd prefer you just go home and do something fulfilling. You aren't making me any money on facebook, and destroying your home lives doesn't make me any richer. Now, there are some people who can code, consistently, for 10 hours a day. But they are dwarfed by the numbers of people who act busy for 10 hours a day to meet the expectations of management.
vegai 16y ago
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.
_delirium 16y ago
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).
dstein 16y ago
Consider this a gift. It's a thinly veiled advanced-warning pink slip.
jordanbrown 16y ago
Terrible idea Just to do it for the sheer fact of thinking more features will being in more money.
jasonkester 16y ago
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.
mariusmg 16y ago
Yes. But only for a short period of time.
mironathetin 16y ago
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.
beej71 16y ago
"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."
- jarek 16y ago
  Maybe you should have had it say "software developers."
antirez 16y ago
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.
6ren 16y ago
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.
rickmb 16y ago
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.
hessenwolf 16y ago
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.
mfukar 16y ago
Not consistently.
- htsh 16y ago
  Exactly -- feasible, yes. Sustainable, no.
tzs 16y ago
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.
- Roboprog 16y ago
  Exactly. I find it useful to work one, maybe two long days during the week to clean something up or catch up. But otherwise, I need to rest, and see my family, the rest of the time, or things are just going to go downhill. I believe Ed Yourdon had a title that applies: Deathmarch.
DanielBMarkham 16y ago
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.
alexobenauer 16y ago
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.
sambeau 16y ago
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).
mnml_ 16y ago
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.
leed25d 16y ago
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.
chrisbennet 16y ago
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).

52 points by dholowiski 16y ago

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. =/

mironathetin 16y ago
So, life is a lot of fun for you?
- ams6110 16y ago
  How "fun" one's life is is not really for anyone else to judge, is it?
  - mironathetin 16y ago
    That's not a judgement, it's a question. I'd be interested how this feels and how he does it. I manage to work on my projects for 3-4 hours a night, but not for extended times. If someone here claims he has a way, let's ask him how.

pan69 16y ago

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

snitko 16y ago
I was gonna post the same link. tl;dr you gain occasional productivity boosts by extending the work day, but that is inevitably followed by a decrease in productivity to make up for it.

sophacles 16y ago

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.

kahawe 16y ago
Also, the fact that the bossman can obviously NOT think of any (better) way of getting new customers but asking his people to implement features and then hope to lure someone in sounds pretty bad. Depending on country and social insurance and on your readiness for a "unique" company death-march experience, it might be something you want to do... but if you have any responsibilities in life then make sure you have some money on the side and get out as soon as you can. If you can afford it, just for the hell of it, then keep your eyes and mind open as much as you can and observe what is going on around you. What does your boss say, what things does he avoid or not say etc. All this might give you some interesting thoughts and views on "management" and people but most likely will leave you rather disillusioned and maybe even bitter. Getting screwed over and/or taken advantage of is like losing your virginity: it will be hard or downright impossible to go back to "before it happened".

BigZaphod 16y ago

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.

gsivil 16y ago

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

fleitz 16y ago

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.

InclinedPlane 16y ago
Good tools combine powerful underlying systems with abstractions that bring the necessary complexity of the system into a realm that is manageable by users. When done well it can make a tool that took a tremendous amount of effort and which encompasses a great deal of complexity look effortless and simple. And more importantly be intuitive to use. If you look at a tool like a hammer both Spolsky and DHH would likely say that it was a simple tool. But that simplicity underlies a lot of complexity. The simplest hammer, the sort that a parody of DHH's ideals would lead you to believe he would advocate building, would be a simple suitably sized and shaped rock. Modern hammers are built using centuries of experience and a great deal of research. A great deal of metallurgy has gone into refining the exact variety of materials used in the hammer head as well as in the manufacture of it (drop forging). And not just in ensuring it is of a certain quality, but in ensuring that it is precisely suitable for its intended tasks. A great deal of research and experience has gone into shaping the head and the handle, and in their construction. Ergonomics, durability, efficiency, cost, etc, all of these factors are carefully balanced in the end product. When you hold a hammer you don't need a manual, it's operation is obvious and intuitive. The best tools work that way. It takes a lot of effort to learn how to drive an automobile properly because it is a complex task, yet the fundamental interface is nevertheless (today) very straightforward and intuitive. Take a moment to think about all of the various tools you use routinely, from silverware and pocket knives to automobiles and cameras. Are these tools simple or merely deceptively simple? How do these tools take control of the inevitable complexity underlying their operation? How do they bridge the complexity gap between the "user interface" abstraction and their fundamental operation? What characterizes better tools of each sort from lesser tools? The same applies to software as well. The language we use in describing software and its use is today incredibly crude and barely suitable for the task, which leads to many debates where neither side is capable of fully articulating their meaning and people are left with half-ideas of what either is trying to get at. I don't think Spolsky or DHH are necessarily arguing in opposite directions, I think they are trying to articulate the complex nature of something that is difficult to convey. Elegance is perhaps one aspect of it, but there is no single word that fully describes the concept that either is trying to get across, I think. Edit: Another perfect example: I occasionally use an infrared thermometer in the kichen. It is supremely intuitive to use. It is vaguely gun shaped, fitting easily in the hand. It has a single button, a trigger, and an lcd screen that displays temperatue and units. Pressing the trigger once generates an instantaneous reading which is displayed on the screen for several seconds. Holding down the trigger generates a continuous reading, updating the display perhaps a few times every second or so. Releasing the trigger leaves the last reading displayed as above. When taking a reading a red laser marks the targetted spot. The battery compartment can be opened without tools but is designed such that the act of using it will prevent the compartment from being opened. When you consider the complexity of such a device, how many various pieces have to be put to use (such as optics, sensors, processors and software to analyze the IR spectrum within a narrow beam and determine a temperature to high accuracy, not to mention all the supporting components like the laser pointer, display, body, power system etc.) it gives a greater appreciation for the incredible elegance of the tool.

jarek 16y ago

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.

lsc 16y ago
the number of people who can effectively code for 10 hours a day for a period of months is... small. Nearly everyone I know who claims this ability spends a lot of time doing things like reading hacker news rather than coding. This, I think, is one of the tests of a manager. A bad manager loves to see people looking busy. A bad manager will hire people who claim to work 10 hours (or more!) a day. This manager will quite often stay at work with everyone else (it doesn't matter how early you show up, as long as you show up before the boss. It doesn't matter how late you leave, as long as you leave after the boss.) but he usually slips into dealing with personal business. And so does nearly everyone else. I think a much better approach is to let people figure out what their optimum productivity is. I know one guy who says "i have four good hours a day" - and he is very, very good during those four hours. But after those four hours, really, you might as well send him home to play video games or something. He's done. Expecting 10 hours a day of work on average encourages a culture of deception; a culture of "look busy" which really, isn't any good for anyone. Yeah, I want you to work as much for me as you can. But really, if you are going to work for five hours a day and screw off on facebook the other five? I'd prefer you just go home and do something fulfilling. You aren't making me any money on facebook, and destroying your home lives doesn't make me any richer. Now, there are some people who can code, consistently, for 10 hours a day. But they are dwarfed by the numbers of people who act busy for 10 hours a day to meet the expectations of management.

vegai 16y ago

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.

_delirium 16y ago

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).

dstein 16y ago

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

jordanbrown 16y ago

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

jasonkester 16y ago

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.

mariusmg 16y ago

Yes. But only for a short period of time.

mironathetin 16y ago

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.

beej71 16y ago

"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."

jarek 16y ago
Maybe you should have had it say "software developers."

antirez 16y ago

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.

6ren 16y ago

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.

rickmb 16y ago

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.

hessenwolf 16y ago

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.

mfukar 16y ago

Not consistently.

htsh 16y ago
Exactly -- feasible, yes. Sustainable, no.

tzs 16y ago

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.

Roboprog 16y ago
Exactly. I find it useful to work one, maybe two long days during the week to clean something up or catch up. But otherwise, I need to rest, and see my family, the rest of the time, or things are just going to go downhill. I believe Ed Yourdon had a title that applies: Deathmarch.

DanielBMarkham 16y ago

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.

alexobenauer 16y ago

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.

sambeau 16y ago

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).

mnml_ 16y ago

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.

leed25d 16y ago

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.

chrisbennet 16y ago

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).