What's your productivity cycle?

Question

I was recently listening to one of the old Stack Overflow podcasts where Joel mentioned, almost in passing, that many great developers are actually not that productive most of the time.

I'm paraphrashing here, but the gist is that a lot of developers go into a hyper-productive flow state a few times a week, and that's when 80% of the work gets done. After that we go into a recovery period where we charge back up and get ready for the next burst.

In my personal experience this is absolutely and profoundly true, and at times I've felt really bad about it.

Let me explain.

Overall my output is very high, but it comes in bursts. There will be an amazingly productive day sandwiched between two or sometimes more days where I definitely worked but it wasn't the same. For awhile I tried to force it all the time, thinking that it was my responsibility to always function at my highest level. Needless to say, this lead to great suffering, and occasional caffeine rage.

(Note to future prospective employers: That last part was a joke. Probably.)

Eventually I came to terms with the fact that my overall output is actually high, although my pattern is bursty and a bit unpredictable. And I realized the the lulls are part of the process and well worth the price of the absurdly productive periods.

Also, learning to take better care of myself (diet, exercise, etc) definitely continues to improve my productivity across the board.

I wonder what other developers think about this, and what your own experiences have been. It seems to me that understanding, admitting, and harnessing this could be a big deal to a lot of people!

Note: I know that there are a lot of productivity gurus who advocate discreet phases of work (gather, work, recover, etc), and that seems to be the same idea. Personally I'm a big fan of GTD, although I'm not sure it directly addresses this subject. I'm interested in whether any of those guys actually had anything useful to say that made an impact for you.

Answer 1

I find myself in much the same situation as you. The rough part for me is that I find it extremely difficult to enter and maintain flow during the work day, and when I really get things done is in all-nighters, when there's nobody to bug me. Unfortunately, I'm coming to realize that I'm not as young as I used to be, and have noticed that I'm brutally depressed for a week after an all-nighter. I just can't keep doing that. So I'm in a position of trying to break out of a pattern that works for me in terms of productivity but really doesn't on a personal level.

As Mr. Horse said, "no sir, I don't like it".

Answer 2

I work two days a week: Wednesday and Friday. Oh, I'm in the office M-F; but you only see me getting things done on those two days. Thursday lets me cool off from my huge Wednesday and prepares me for Friday. Saturday thru Tuesday prepare me for the huge Wednesday ahead. Wednesday is probably my biggest day.

Those other workdays are wasted on company overhead: Meetings, Action Items, E-mail, phone tag, low-priority test issues, etc.

Sometimes I have nothing to do on a Wednesday. I leave early and go home to work on my own projects.

Answer 3

I guess, for me, it comes down to how one measures "productivity". There are days that I don't write a line of code but spend the whole day researching something or designing a solution to a problem. Am I "productive" on those days? Not if someone were to do a daily LOC check on me but am I moving toward the goal? Sure.

Ultimately I'd say that I don't dilly-dally at work. I get paid to provide a solution to a problem and not to "sling code" alone. There are periods where I'll take time for myself - I read for an hour just about every day, typically on some technology I'm trying to grok, and I check the e-mail from time to time, but I try to keep my mind on the goal otherwise. Once in a bit the whole shop will do an extended lunch or have a chat session, but nothing excessive.

I like have a checklist of tasks to accomplish and think GTD is one way to accomplish things, but certainly not the only or best way. Not sure how I'd measure 'best' anyhow.

Anyway, that's my two cents.

Answer 4

For myself, I tend to have a few different states where I'm getting things done as generally, my real work breaks down into a few categories:

1) Planning - Determining which steps should be taken to resolve an issue and which of many possible solutions should be used. This can be fun for me to think about "How would I do this and what steps should I use to explain the sequence I see in my mind for this?" Breaking down stories for a sprint can be a meeting that falls into this category.

2) Investigating - Tracking down the root cause of a problem or fixing a bug through trial and error. Figuring out what is causing a problem can have its moments of "Aha! I got the bugger now..."

3) Developing software - This is like executing on the first categorty where some combination of documentation, code, and tests are made to complete a given story or task.

While I do like all 3, there are times where I'm shifting between them as in developing something, I'll need to investigate a bug it finds in what I think is a good solution to the given problem, or plan out why what I thought would be simple isn't quite that simple and this should be reflected in the cards for a sprint.

I did leave out the administrative aspect of my job which would include things like timesheets, updating the codebase on my machine, and meetings generally.