

Are 10-11 hour programming days feasible? - dholowiski
http://ask.slashdot.org/story/11/01/13/229205/Are-10-11-Hour-Programming-Days-Feasible

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

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

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

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

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

------
pan69
The Laws of Productivity:
<http://lunar.lostgarden.com/Rules%20of%20Productivity.pdf>

~~~
snitko
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.

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

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

------
gsivil
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

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

------
Skywing
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
So, life is a lot of fun for you?

~~~
ams6110
How "fun" one's life is is not really for anyone else to judge, is it?

~~~
mironathetin
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.

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

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

------
beej71
"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
Maybe you should have had it say "software developers."

------
6ren
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.

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

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

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

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

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

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

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

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

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

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

------
mfukar
Not consistently.

~~~
htsh
Exactly -- feasible, yes. Sustainable, no.

------
mariusmg
Yes. But only for a short period of time.

