I like this point. I think one of the problems is productivity can be measured so many ways, and they seem to be so context sensitive. Just looking at my own life suggests multiple types of measures for productivity...
For instance. I can apply the author's method to my house cleaning. Just wait until it's been scheduled, and knock it out fully in a manic cleaning session every other month for a few hours. Afterwards my house will be dazzling, and it will be great for a few days. Then I can do nothing for a while and it will turn into a mess over time again, and a couple months later I can make it dazzling again.
Unfortunately my goal is not to sometimes have a sparkling house - its to have a clean house because I find it peaceful. Bursty productivity is at odds with this goal. Rather, the overall result of spending 5-10 minutes a day cleaning stuff, with the occasional deep clean meets this goal better. Therefore it's more productive - the average state of the house is much much cleaner.
However, I recently built a patio at the same house. I had started it 3 years ago with the goal of "work on it a bit every weekend til it's done". After a couple weeks, it didn't progress anymore. So I set aside the weekend earl this summer and knocked it all the way out. Done, complete, usable and the goal is met. Basically the author's method. Bam goal met, in 1/150th of the time I spend trying the other way. Unbelievable productivity!
Of course I can come up with code analogies from my work too - but these are simpler but still illustrative examples :)
So it seems there is at least one axis of consideration for productivity - the maintenance vs one-shot axis.
Another thing that comes to mind related to this: personal development. I find that sometimes it feels like I'm not progressing at all - this is my skill set, this is what I'm capable of, thats all. Then one day I find that bam - I'm writing a bit of code that I know would have struck me as impossible a few months prior. Example: I remember about a year ago, I tried to grasp the dragon book. I gave up because it was too over my head on a lot of topics. I set it aside as as something to grapple with later. The other day I had to write a parser to handle an input file format that had the underpinnings of a DSL. I went and found a parsing library, and wrote a working parser using decent technique. In the interim I didn't really even explore that stuff - mostly I was focusing on unrelated goals. But somewhere in there I "leveled up".
In fact "leveling up" is a productivity related analogy I like a lot - it seems sometimes that I'm just grinding out things, and not making any progress, but in the background my brain is doing things - tiny imperceptible things, and then one day suddenly something clicks and they whole of the changes is noticable - I leveled up. Just like in an RPG when you grind out some battles do some boring side quests, and generally don't notice major differences. Then you get the level and have a new power and it's exciting again. This is productive, but in a different way: the end result is being able to accomplish more, but there's not a really good way of discussing it, the language isn't there.
Another under-explored topic is that of a concept I call many-tasking. It isn't multi tasking. It isn't single-tasking. It's more related to priortization and task ordering. Find a task that is blocking a few other tasks, and get it done, freeing up lots of other things to do. Similarly (much related but not exactly like David Allens context notion) there are often many very similar tasks related to bigger projects. Grouping them can be much more productive than not doing so. For example this morning I'll sequentially work on: some tasks for ops - making our services easier to deploy, some tasks for testing that will take advantage of some of those ops improvements, and a few changes to our core algorithm that will make it stabler. They all are related to the same handful of modules, so I group them together rather than put them as the independent tasks they are. There is still some context switching, but it is light-weight as I'll already have loaded the code into my head. I'll accept the overhead of context switching rather than the much bigger overhead of reloading that code 3 times this week. So that's a nuance axis I guess too: it isn't multi tasking or single tasking - there's a continuum there that has various tradeoffs.
Finally though, there's the very real issue that different people are different. Different ideas of what matters, different ideas of how to get into flow state, different ideas of how to group things, etc. It adds a layer of complexity to these discussions, because it seems a lot of people don't realize that the small differences between people can lead to big differences in style of work - they assume they have a lock on the right way.
Comments
I like this point. I think one of the problems is productivity can be measured so many ways, and they seem to be so context sensitive. Just looking at my own life suggests multiple types of measures for productivity...
For instance. I can apply the author's method to my house cleaning. Just wait until it's been scheduled, and knock it out fully in a manic cleaning session every other month for a few hours. Afterwards my house will be dazzling, and it will be great for a few days. Then I can do nothing for a while and it will turn into a mess over time again, and a couple months later I can make it dazzling again.
Unfortunately my goal is not to sometimes have a sparkling house - its to have a clean house because I find it peaceful. Bursty productivity is at odds with this goal. Rather, the overall result of spending 5-10 minutes a day cleaning stuff, with the occasional deep clean meets this goal better. Therefore it's more productive - the average state of the house is much much cleaner.
However, I recently built a patio at the same house. I had started it 3 years ago with the goal of "work on it a bit every weekend til it's done". After a couple weeks, it didn't progress anymore. So I set aside the weekend earl this summer and knocked it all the way out. Done, complete, usable and the goal is met. Basically the author's method. Bam goal met, in 1/150th of the time I spend trying the other way. Unbelievable productivity!
Of course I can come up with code analogies from my work too - but these are simpler but still illustrative examples :)
So it seems there is at least one axis of consideration for productivity - the maintenance vs one-shot axis.
Another thing that comes to mind related to this: personal development. I find that sometimes it feels like I'm not progressing at all - this is my skill set, this is what I'm capable of, thats all. Then one day I find that bam - I'm writing a bit of code that I know would have struck me as impossible a few months prior. Example: I remember about a year ago, I tried to grasp the dragon book. I gave up because it was too over my head on a lot of topics. I set it aside as as something to grapple with later. The other day I had to write a parser to handle an input file format that had the underpinnings of a DSL. I went and found a parsing library, and wrote a working parser using decent technique. In the interim I didn't really even explore that stuff - mostly I was focusing on unrelated goals. But somewhere in there I "leveled up".
In fact "leveling up" is a productivity related analogy I like a lot - it seems sometimes that I'm just grinding out things, and not making any progress, but in the background my brain is doing things - tiny imperceptible things, and then one day suddenly something clicks and they whole of the changes is noticable - I leveled up. Just like in an RPG when you grind out some battles do some boring side quests, and generally don't notice major differences. Then you get the level and have a new power and it's exciting again. This is productive, but in a different way: the end result is being able to accomplish more, but there's not a really good way of discussing it, the language isn't there.
Another under-explored topic is that of a concept I call many-tasking. It isn't multi tasking. It isn't single-tasking. It's more related to priortization and task ordering. Find a task that is blocking a few other tasks, and get it done, freeing up lots of other things to do. Similarly (much related but not exactly like David Allens context notion) there are often many very similar tasks related to bigger projects. Grouping them can be much more productive than not doing so. For example this morning I'll sequentially work on: some tasks for ops - making our services easier to deploy, some tasks for testing that will take advantage of some of those ops improvements, and a few changes to our core algorithm that will make it stabler. They all are related to the same handful of modules, so I group them together rather than put them as the independent tasks they are. There is still some context switching, but it is light-weight as I'll already have loaded the code into my head. I'll accept the overhead of context switching rather than the much bigger overhead of reloading that code 3 times this week. So that's a nuance axis I guess too: it isn't multi tasking or single tasking - there's a continuum there that has various tradeoffs.
Finally though, there's the very real issue that different people are different. Different ideas of what matters, different ideas of how to get into flow state, different ideas of how to group things, etc. It adds a layer of complexity to these discussions, because it seems a lot of people don't realize that the small differences between people can lead to big differences in style of work - they assume they have a lock on the right way.