Avoiding "the stupid hour"

http://rachelbythebay.com/w/2012/11/22/stupidhour

by greenyoda • 14 years ago

185 47 14 years ago

kiba• 14 years ago

I thought it's "Pulling all nighters"

saraid216• 14 years ago

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

chrisacky• 14 years ago

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!

cstross3• 14 years ago

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

malnourish2• 14 years ago

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.

malnourish2• 14 years ago

Exactly! Many of us who have pulled all nighters (or very late nights) know that not only does the quality of our product decrease, but the quality of our lives.

I enjoy what I'm doing less, my body and mind begin to feel strange. What's worse, is that I'll likely spend more time sleeping than I would have had I gone to bed, and I'll wake up at a non-optimal time to boot.

In almost all cases, I find it far better to hand in something a day late than on time and full of errors.

cstross3• 14 years ago

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.

seanmcdirmid2• 14 years ago

As for writing (scientific papers), I find it best to use my most productive hours for editing and the stupid hours for writing new material, under the assumption that I would have to edit new material anyways.

Programming is much the same way. Use your best hours to refine/polish work that is furthest down the line, use your worst hours to write crap that gets you started thinking about what the real solution will look like. Even in your best hours, you probably aren't going to come up with the right solution immediately (unless the problem is easy).

tankbot• 14 years ago

This is a very interesting philosophy I would like to hear more about. I suspect it is different for coding? It seems like tracking down all of the connected logic bits would be difficult after writing deliriously.

jackpirate• 14 years ago

Interesting. I find editing much less mentally straining, so I use my stupid hours (or better yet, unmotivated hours) for editing/refactoring and my good hours for generating the new content. I've noticed that my prose style tends to be very hierarchical and not very free-flowing, so I wonder if there's a correlation there.

epochwolf4• 14 years ago

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.

adrianhoward6• 14 years ago

I don't think you should be bothered... I've seen the 'about six hours' of productive coding figure come up multiple times when teams actually experiment with their hours worked and their productivity. I suspect that your co-workers would be more productive if they had the same work pattern you do.

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.

I'm pretty darn sure of it myself. Every team I've worked on that's been doing more than 45 hours a week has got more productive by cutting hours worked.

Rather than staying up until 1am in an awe inspiring hacking session to get the latest release running, I'd much rather people went home at 5pm so they were on the ball enough not to write the damn bugs in the first place.

cstross3• 14 years ago

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.

coroxout• 14 years ago

When I first started at my current job it was 20 hours a week. I'd work 9-2pm 4 days a week. When I was made full-time (37.5 hours) I remember noticing that I wasn't really getting any more done - more replying to emails, sure, but the actual useful output per week remained much the same.

I realise this post will be ridiculous to many people reading this, for whom 37.5 hours is still half-time.

(If it's any consolation, I was also not getting noticeably more done in my free time when I had more of it.)

adrianhoward6• 14 years ago

And those who can and do pull all nighters often don't have much insight into how productive they are actually being. I know I've been surprised in the past when getting folk to work fewer hours results in more getting done (see this previous comment for the story http://news.ycombinator.com/item?id=4781103 ).

I can and have pulled all nighters. I probably still can. It's just that I've learned that doing so, or spending more than about 30-35 hours a week coding, makes me slower - not faster - overall. Even, and I can't emphasise this point enough, if I feel completely fine doing those extra hours. People are really bad at introspecting on their own productivity.

Figure out some metrics for productivity. Try cutting the time spent in front of the keyboard for a few weeks. Measure. You may be surprised.

EwanG• 14 years ago

Unfortunately the problem isn't whether you know and respect them, but whether your boss does. I've worked for folks where they want to be able to point and show that you were doing "something" when a release is delayed, and the fact that you will be making more mistakes is less important than the fact they can show you were there.

pcl2• 14 years ago

> 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• 14 years ago

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.

pcl2• 14 years ago

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.

adrianhoward6• 14 years ago

That's simple to get around - you just schedule in a regular cadence for stepping back.

For example we do a little regroup after lunch, and have a weekly short 20m retrospective on Friday afternoons before stopping for the weekend.

thirdtruck• 14 years ago

Agreed. I have to make a point of doing this with my fiction, such a leaving sentences half-finished, and I found that it does wonders for maintaining productivity. It keeps my mind from "closing the loop" and treating a project as "finished" prematurely.

discreteevent• 14 years ago

Hemingway said that you should stop writing for the day when you know what the next thing is.

mcmatterson• 14 years ago

'Park facing downhill'. I love it. I've read before that Hemingway used to leave his writing for the day in mid sentence, so when he sat down the next morning, he had somewhere concrete to start. I'm not sure how true the legend is, but it's a technique I use often with good results.

epochwolf4• 14 years ago

I did this Monday. I had meetings all morning so I spent three hours hogging the team whiteboard before I left for the day. It really works. I went and worked on some hobby writing I do and my brain worked on the problem in the background. The next day I had a new approach to try when I woke up.

adrianhoward6• 14 years ago

I have this pattern.

It's one of the (many) reasons I love TDD. Leave terminal with a failing test case. Come back the next day and I've got something obvious and trivial to code next. Bam. Straight back into that intermittent reward driven flow.

derwiki• 14 years ago

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

chaz• 14 years ago

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.

bitteralmond• 14 years ago

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.

naner• 14 years ago

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.

jackcviers32• 14 years ago

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• 14 years ago

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.

adrianhoward6• 14 years ago

1) The first product to market often doesn't win. In fact I'm hard pushed to think of many examples of that being true ;-)

2) Even taking that as true - I'm not sure I follow the argument. Working longer hours != shipping earlier. If you are working past the point of optimal productivity then, in anything but the very short term, you are slowing yourself down.

I've seen multiple teams ship faster by working fewer hours. I know others have too. I find it freakishly bizarre that folk don't measure their productivity and optimise for going faster rather than working longer.

brazzy• 14 years ago

Yes, sometimes there are emergencies where working long hours isn necessary, and if you're well rested before, you can still be productive, if not optimally so. But these are rare exceptions. If they occur regularly, it's a sign of shitty management and a shitty company you need to get out of ASAP. Especilally if you're told it's normal and something to be proud of

As for your examples

>ship or lose customer x.

shitty customer, will probably use low quality resulting from it as an excuse to withhold payment. Get a better customer.

>Promises are made that can't be kept by humane working hours.

Shitty management, no excuses

>Things break days before a huge demo.

Probaby because of bad code written by someone working late.

>Someone gets sick.

Nobody else can do their job? Shitty management

> You are in an arms race with a well-funded competitor.

You probably won't win it with code that breaks all the time.

dasil003• 14 years ago

> Something I would like the programming world to discuss is that it isn't the best coded product that wins - technical quality rarely matters

That depends. If by code quality you mean living up to every aesthetic whim and being fiddly over inconsequential details, then no, it doesn't matter. On the other hand, for any code base that lives through a few pivots the conceptual integrity of the architecture starts to break down. At every juncture you can just power through with a quick hack to ship the feature, but over time you are weaving yourself a rat's nest of unmaintainable code. If you have to do this to win the customer, so be it, but at some point this does catch up to you, and you will fail oh so very hard.

jackcviers32• 14 years ago

All great points. As for shipping first, see Netscape and Dos. For heroic hours being the norm, see Facebook and Google.

As for shitty management and someone getting sick and breakage before a big demo, not necessarily. I've been a part of small teams most of my professional career. So many times the only way to get big fish to bite be was to both overpromise and over-achieve, and with small teams this usually meant grinding through tough situations like those above. You don't always know with enough time to spare when you have a chance to demo new functionality for a really big fish. With sickness, it is the redundancy of skills and codebase knowledge that have led me to take one on the chin.

epochwolf4• 14 years ago

As I said in a previous comment, I average a 6 hour workday with a third of it being administrative stuff like email and working wih QA. This is he norm for me. That doesn't mean I don't do crunch time.

If my team needs someone to work the weekend to ship in an emergency, I will do it. But, that blows away the next week of productivity. It's fine to do this once in a while and I don't complain about doing it. But, if this the norm, you don't have priorities right. Not everything is really an emergency.

gurkendoktor• 14 years ago

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• 14 years ago

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.

adrianhoward6• 14 years ago

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?

I will normally feel better and more awake after doing something like this.

That, of course, may well have no effect on how productive I am.

Optimising for 'feeling good while working longer hours' should not be the aim. Optimising for 'producing the most useful stuff in time period X' should be what we're after.

Earlier in my life I could happily sit in front of the keyboard for fifty hours a week and feel fine. However, when I started measuring what I produced I found that I was more productive if I spent about 30 hours in front the keyboard.

If I had a time machine that's what I'd tell my 20 year old self. You can do more by spending less time in front the keyboard, which has the happy side effect of giving you more time to do more away from the keyboard.

lnanek2• 14 years ago

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

jneen• 14 years ago

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

Yoni1• 14 years ago

+1. Good night :)

jasonjackson• 14 years ago

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.

epochwolf4• 14 years ago

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.

lostnet• 14 years ago

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.

Avoiding "the stupid hour"

Related Stories