Debugging productivity

In 1997, NASA’s Pathfinder spacecraft made history as it touched down on Mars. Sending back stunning images, it captivated the world. Scientists and engineers eagerly awaited more data when, without warning, Pathfinder fell silent. The transmissions stopped. Back on Earth, engineers scrambled to find out why. Pathfinder wasn’t broken. It was stuck. Overloaded with minor tasks, it failed to complete its most important work. In effect, it was procrastinating.

The root cause was a flaw in its scheduler, the software managing task priorities. Instead of efficiently switching between processes, the system became trapped in an endless loop of low priority tasks. Like a worker drowning in emails while neglecting major projects, Pathfinder was busy but unproductive. After debugging, NASA’s engineers fixed the issue and Pathfinder resumed its mission. The episode serves as a reminder. Even the most advanced systems can get overwhelmed when they fail to prioritise effectively.

Productivity lessons from computer science

If debugging is the process of removing bugs then programming must be the process of putting them in. - Edsger Dijkstra

Pathfinder’s struggle is not unique to machines. People, too, suffer from a kind of scheduling bug. We fill our days with tasks, meetings, emails and notifications, being busily unproductive. The way computers manage time offer insights into how we can optimise our own.

Prioritisation problem

If you spend too much time thinking about a thing, you’ll never get it done. - Bruce Lee

One of the first challenges is the time cost of prioritisation itself. Consider an email inbox. We might skim through messages, deciding which is most important before responding. Once a message is answered, we repeat the process. It seems efficient, but follows a quadratic time algorithm (from computer science). As the inbox grows, the time required to process it increases exponentially. Double the emails, quadruple the effort.

Programmers faced a similar issue in 2003 when Linux, one of the world’s most widely used operating systems, began spending more time ranking tasks than executing them. The counterintuitive solution? Instead of ranking every task, they introduced a priority bucket system, grouping tasks into broad categories. The result: less precision, but more progress.

For humans, insisting on always doing the most important task first might be counterproductive. An over optimised system can collapse under its own weight. Instead, answering emails in chronological order, or even at random, leads to better results.

Costly context switches

The highest performers structure their time to reduce switching costs, not maximise busyness. - Tim Ferriss

When a computer switches from one task to another, it undergoes a context switch: saving its current state, loading new data and reorienting itself. Each switch takes time and computing power. The same applies to people. Checking emails, responding to messages and shifting between projects come with a hidden cognitive cost.

Recognising this tradeoff between productivity and responsiveness is key. In computer science, the solution is called interrupt coalescing: grouping interruptions together instead of handling them one by one. In 2013, this approach led to a massive increase in laptop battery life by reducing the frequency of system wake-ups. Similarly, we can apply this principle by batching our own interruptions: checking emails only once per hour instead of reacting instantly, scheduling meetings back-to-back rather than sporadically throughout the day.

Strategic inaction

By not acting in haste, you preserve optionality. - Rory Sutherland

Pathfinder’s failure wasn’t due to inactivity. It was due to misguided activity. The same is true for us. We’re conditioned to believe that busyness equals productivity. In reality, the best systems and the most effective people know when to pause, consolidate and move forward with clarity.

Other resources

Algorithms to Live By talk by Brian Christian

Deep Work in 5 Steps post by Phil Martin

Balancing Maker v Manger Needs post by Phil Martin

Instead of trying to do everything at once, we should embrace a more structured approach. Prioritise broadly, minimise context switching and recognise that sometimes, less precision leads to more progress.

Have fun.

Phil…