Avoiding "the stupid hour"

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.