
Avoiding "the stupid hour" - greenyoda
http://rachelbythebay.com/w/2012/11/22/stupidhour
======
cstross
Some folks can pull all-nighters; not only can I not stay awake for more than
24 hours (I literally keel over sideways and faceplant on the floor, snoring)
but if I try working more than 10 hours, I run into stupid hour syndrome. And
in my later post-programmer life as a writer, if I write past a certain point
(roughly 4500 words of fiction or 6000 words of non-fiction) in a day, then
for every 1000 words past that point, I end up having to bin and re-write
about 1500 words the next day. Because it's unmitigated crap.

Limits, folks: we have them. Learn and respect them and don't try to be macho
about it, because it doesn't help.

~~~
epochwolf
I can second this. I'm a 26 year old programmer and I've done one all nighter
in my life. I don't remember what happened after hour 26. I know I attended
class until 2pm but I can't remember any of it.

I can get anywhere from 3 to 6 hours of useful programming in a day and a
couple times a year I might do 10 hours. I am far more productive at an
average of 4 hours of work per day than trying to do 8 or 9 hours. I've worked
with people I considered far smarter than myself and I can match or beat them
by putting in a third of their hours working on similar problems.

Just this week, I did an estimated 2 weeks of work in about 14 hours over 3
days, most of it staring at a whiteboard. All of the code was written in 2
three hour sessions on the final day. I frequently do things an order or two
of magnitude faster and smarter when I'm well rested and relaxed.

I don't mean to brag. It really bothers me I come in to the office just before
the daily standup, work for 6 hours and leave before anyone else. (I usually
spend an hour or two doing non-programming tasks each day)

I can definitely say "work smarter, not harder" is really effective for me. I
don't know if it's true for everyone but I suspect it is.

~~~
cstross
The notional eight hour work-day wasn't invented for occupations with high
cognitive/reasoning workloads; it was invented for factories that needed
workers to operate three shifts per day consistently.

It became culturally ingrained because, back at the peak of labour-intensive
industrialization, about 50% of the work force were employed in factories. But
it doesn't actually bear any relation to how much time we can spend working
effectively in tasks that require high-level reasoning skills. Nor does it
bear any relationship to the earlier pre-industrial paradigm (agricultural
labour from dawn 'til near-dusk, which could vary from 6 to 18 hours per day
depending on the length of the day -- indoor lighting consisting of
[expensive] candles).

Unfortunately it's also easy to see whether a body is physically present or
absent from an office -- easier than measuring the quality of its mental
outputs -- and it's still relevant to service occupations, which is why we're
mostly stuck with it.

------
chrisacky
It's really hard to emphasise how important identifying those moments when
you're productivity starts to wane actually is....

I'm sure so many of us have this mindset where we all think we are
indestructible, mentally and physically, and burning through the nights to be
that guy who "gets shit done" is as important as shipping your first line of
code.

When I was a lot younger, I couldn't identify poor code even during my best
hours, so I could happily burn through an all nighter, but after years of
experience you get that wisdom to be able to notice when you aren't switched
on. For me, this is usually at about 8pm at night (after working for a full 12
hours with minimal breaks). You start to notice that your concentrate flickers
and something that should have taken 15 minutes has actually taken you 2 hours
and it's now 10pm (and you have fifteen tabs of HackerNews open).

Do yourself a favour and just stop. Come back refreshed. Whether that is in an
hour, or even a full night. Unless you have some insane deadline that doesn't
depend on code quality, it's inadvisable to ever burn through it... because
ultimately you are wasting time that could be better used on recuperating your
faculties!

~~~
cstross
"should have taken 15 minutes and has actually taken 2 hours" is a _really_
good sign that it's time to give up and go get some sleep.

This is also a good sign that you should sign off sick if you've got a cold or
flu or some other ailment, even if it's only 11am. It indicates that your
productivity is about to go negative and you may actively _damage_ your
project if you keep flailing around.

~~~
malnourish
I find that if I step back from the project when I'm sick, not only do I
recover faster, but I often think of novel ways to solve a problem (or realize
the solution was under my nose) by nature of taking some time away from the
screen.

~~~
hox
You'll find that stepping back from a problem, even when not sick, generally
can help your overall perspective. I personally like to take walks and focus
on things other than the problem at hand; this almost always results in
clarity for me.

------
chaz
There's also the "hero night." It's pulling off an all nighter to accomplish a
seemingly impossible task with a hard deadline. This happens about once a
year, and it was in April for me this year. The company had 24 hours for an
opportunity to be on national TV, but we needed a landing page built, with a
contest, and a Facebook integration. Small company means you gotta take the
chance.

Grabbed my earbuds, fired up my Spotify, and got to work. Got it done and
deployed a couple of hours before airtime in the morning. It worked great.
Unfortunately, the TV spot didn't pan out quite the way we were told, and it
didn't provide much value after all, but everything I built worked. I would
have felt terrible if the opportunity was in fact huge, but what I had built
was subpar.

It's a nice feeling to be the hero, even for yourself. But it's also easy to
overvalue a success like that and assume that it will always be that way, and
always be the hero. Unfortunately, it turns into "stupid hour" most of the
time.

------
jackcviers3
There's a lot of talk about this subject as if the practicioners of coding
long past the point of optimal productivity have a choice not to code when you
are at that point. I don't think most of us actually have a choice - it is
often a case of ship or lose customer x. Promises are made that can't be kept
by humane working hours. Things break days before a huge demo. Someone gets
sick. You are in an arms race with a well-funded competitor.

Something I would like the programming world to discuss is that it isn't the
best coded product that wins - technical quality rarely matters. Usually, the
first product to market wins, or the programmer who kicks out the most
features as long as the features works. Shipping isn't just a feature. It is
the only code quality metric that matters to anyone who isn't a coder. It also
is easier to ask forgiveness for refactoring after the ship date than it is to
ask for permission to push the date back. All-nighters are ingrained in the
practice of programming for a living. The code may not always be robust or
elegant, but in most cases what matters is that it works and gets done faster
than the others guys' high quality code job.

~~~
wpietri
I agree that when emergencies happen, we should rise to the occasion. But I
think it's a business mistake to let emergencies become the new normal.

I have seen a number of shops that rely on last-minute rushes and big drama.
Indeed, I've made some spectacular money from pulling their nuts out of the
fire. But the main reason that they had to do something dramatic was the
accumulated weight of all their poor decisions. It's as if their technical
debt was held by a loan shark, showing up smacking them around just for fun.

It isn't the best product that always wins. But shipping a shitty product also
doesn't guarantee winning either. All else equal, wasteful organizations lose
out over time. That doesn't mean I'll never step away from the optimum path,
but it does mean I'll only leave it when I think there's a strong business
case for doing so.

------
naner
The worst part about the self-inflicted "stupid hour" is that your decision-
making faculties are already working poorly by the time you decide whether to
keep going or not.

It reminds me of the tragic comedy of trying to overcome a bad habit. The
stress from abstaining from the vice causes a strong impulse to seek solace in
the very vice you're trying to quit.

Plan ahead for moments of weakness. I actually have a "stop-hacking" alarm on
my computer... gives me a brief warning to finish what I'm doing then it locks
the screen 60 seconds later.

------
pcl
> Have you ever come back to a project and been unsure of where to get
> started? If you had left off just one item sooner the day or week before,
> you'd already have a known starting point.

I can't find a cite for this right now, but I've heard this phrased as "park
facing downhill." Towards the end of the day, I actively try to get myself
into a position where I've put together the beginning of an idea and gotten
some failing test cases written, or at least some non-compiling pseudocode
into a buffer somewhere. This sets me up for success at the beginning of the
next day -- I work right into a state of flow while tying together the loose
ends from the day before.

~~~
Evbn
With this approach, you never have time to stop and clear your mind and look
at the big picture, you are always stuck in the rut of what you were doing
yesterday, which is what you were doing the day before, and on and on.

~~~
pcl
If I had the luxury of coding all day, I could see this as an issue. More
often than not, however, I end up with meetings and whatnot peppered here and
there throughout my day, so finding time to think about the larger picture
isn't hard. What is hard (for me) is to kick-start myself in the morning, and
a little help from my yesterday-self goes a long way.

------
derwiki
I never understood why people treated working through sleep deprivation as a
badge of honor. Glad to see that others agree!

------
jasonjackson
These articles pop up all the time, as if people hadn't had the foresight to
realize their brain function decreases when they don't sleep. Sleep
deprivation is a tool which allows you to sacrifice some degree of brain
functioning (different for each person) to gain in other areas like meeting
hard deadlines, or taking advantage of your programmer flow state, or the
positive feeling you get knowing you grinded away at a task non-stop until
completion.

~~~
epochwolf
Yes, it's a tool but if you're constantly reaching for it, you have a problem.
This tool robs future productivity at a 2 for 1 ratio. The only thing it's
good for is getting a small task done sooner at the expense of getting other
stuff done later.

------
bitteralmond
The last bit about the "subconscious processing" is spot on. I read a study
once that found that people daydream/drift off around 30% of the entire day,
and the people who do not resist doing this and allow themselves to dream are
more creative and productive as a result.

------
lnanek2
A lot of times with a no sleep weekend hackathon or a launch or something I
can work a long time on the tough parts first, clearing up all the technical
risk in a design with little test screens/pages/activities for example, and
then the next day running on no sleep I'm still OK for testing on a dozen
different phones/emulators/browsers and making forms return nice looking error
messages and making all the buttons on the site look consistent, etc..
Basically you just have to delegate to your stupid hour self the lousy slog
work. :)

------
gurkendoktor
I have this, but a 20 minute nap or a walk to 7/11 usually fixes it. What
happens to anyone in this thread when they try that?

~~~
NathanKP
I do the same thing. Whether or not it works depends on the time of day. If it
is just a 4:00 in the afternoon lull in attention span a short walk (or if I
have a deadline an espresso at the desk) will usually get me back on track. If
it is late in the evening though I can only delay the inevitable need for
sleep so much.

I think that inevitable tired point where you aren't going to get anything
more out of yourself effectively, no matter what you do, is what this article
is about.

------
jayferd
Just realized that I'm in "stupid hour" right now. Going to bed.

~~~
Yoni1
+1. Good night :)

------
lostnet
I think a large problem is in our psychology of not wanting to scrap our
previous labor even if it was substandard.

At this point I hope most coders are checking in code regularly enough that
they could identify a point close to where quality declined and could throw
everything after it out.

Personally, I usually start a day with a review of the previous changes but I
rarely back out low quality changes. I often realize a continuation/rework has
taken longer than a full backout and redo (and I have virtually never been
disappointed by a redo,) yet there is a psychological barrier to overcome
before backing out.

------
kiba
I thought it's "Pulling all nighters"

~~~
saraid216
"Pulling all nighters" implies that you code past midnight, which isn't the
case. I used to do stupid hour by staying at work until 8pm; it was
ridiculous, and I've since learned not to do it unless I've actually got some
flow going.

