Skip to main content
Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.

Task Switching, Sensory Specific Satiety, And Staying Productive At Work

By Ben Nadel on
Tags: Work

As a software engineer, one thing that I've never connected with is the idea that engineers only have "N" number of hours per day in which they can be productive. I believe this concept stems from a lack of strategy, not a lack of capacity. I am not going to argue that every hour of every day has equal potential; but, I do think that we can employ strategies to maximize every hour if we learn to lean into the constraints of our day instead of fighting them.

GIF from Hackers movie, Dade in the zone.

If you're like me, you can eat a massive dinner and still have room for a dessert (or two). This isn't just gluttony, it's a phenomenon known as sensory specific satiety. It means that part of the sensation of being full (sated) is directly tied to the food being eaten. Which means that when you switch the food you are currently eating, your sensory perceptions reset, you no longer feel full, and you can continue to eat.

I apply this same concept at work. But instead of switching foods, I'm switching tasks. Once my brain feels "full" on a given task, and I know that I can no longer remain productive on said task, I switch it up. This usually means changing from a high-thinking, longer-term task over to a low(er)-thinking, shorter-term task. My brain resets, the feelings of task satiety dissipate, and I'm ready to rock once again.

On top of the mechanics of "task satiety", I also lean into the fact that I am more creative in the early part of the day. As such, I do more creative work - like architectural and user interface (UI) design - in the morning. And then, in the afternoon, I skew more heavily towards implementation details and bug-fixes.

By embracing the idea that my brain can only be productive on a single task for "N" hours, I can force my brain to remain productive for the entire work day. In fact, on days where I do this most effectively, I can even end the day feeling energized, not depleted. But, again, the trick is to lean into the constraints of your day, not to fight them.

Task Satiety, Task Estimation, and Why I Have to Double My Estimates

Most engineers are terrible at estimating how long it will take to complete a large project. I'm no different; but, understanding "task satiety" helps me estimate work more accurately. Because I know that "one day of work" isn't 8 straight hours of work.

For the sake of discussion, let's say that I can remain productive on a single task for 4-hours before my brain feels "full" and I have to switch tasks. This means that if a task looks like it will take "a day" - or, 8-hours - that's really 4-hours spread-out over two days of effective coding.

What this means is that I have to double my estimates. Because when I think about how long a task will take, I think in terms of contiguous time. But, when I go to implement said task, I can only operate in discontinuous bursts of focused effort.

Having a Backlog of Bugs Can Super-Charge Your Productivity

It's one thing to embrace task satiety and task switching; it's another thing to know what task to switch to. My biggest productivity killer is not having a backlog of things that I'm interested in working on. If I don't know what to work on next, it means that my brain has to work hardest (task selection) at the point it is most "full". This can easily lead me into a pit of despair where I end up checking Twitter instead of solving customer pain-points.

Because of this, I try to always have several tasks standing by in my mental queue. This way, when my brain fills up on one task, I can immediately switch over to another task, reset, and keep on jamming-out in my code editor!

Reader Comments

What has two thumbs and hopes you leave a comment? This Guy! (Ben Nadel).

Post A Comment

You — Get Out Of My Dreams, Get Into My Blog
Live in the Now
NEW: Some basic markdown formatting is now supported: bold, italic, blockquotes, lists, fenced code-blocks. Read more about markdown syntax »
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.