Multitasking is incredibly alluring. Why go slowly, doing one thing at a time, if you could get a second thing done? Why not fill those five seconds while your code compiles with reading an article about the latest web frameworks?

In fact, multitasking is hiding everywhere in your daily work. Any time you switch from one task to another with the intention of going right back, that counts as multitasking. You might do it without realizing, because...

• while your code is compiling, you switch to your browser to check Twitter.
• while you are coding, you check Slack briefly to see if anything is going on.
• during a meeting, you check Hacker News for anything interesting.

The siren song of multitasking is strong, but the costs are high. Computers are designed for multitasking and parallelism, but humans are not. For us, context switching is very expensive: every time you switch, you lose track of where you were in the previous task, and it can take you 15 minutes to get the state of your codebase back into your head when you switch back. Is it worth spending minutes getting back to where you were just to save the mere seconds you wait for something else to happen? It certainly is not.

This constant context switching also drives down your quality. Every time you context switch, you drop ideas and you drop your focus and this means you cannot engage in very deep thought. You might be able to produce simple CRUD apps this way, but even then, you will miss subtleties in your data model or the domain you are solving for or in how your users will engage with the application. The quality of what you ship decreases when you work in short bursts.

Instead of working in bursts, the way our phones have trained us to do, it is better to spend that time simply idle or bored (in shame, I admit that I looked at Twitter three times while writing this post). Boredom is critical to getting good work done, because the downtime lets your brain explore the non-obvious paths that you may not go down otherwise. This is how you find major bugs, deficiencies in your architecture, or unexpected user experience issues before you ship it.

Multitasking will also make you ship your code late. When you provide estimates, those estimates are usually given optimistically. They are written with the assumption that the requirements are complete, no unexpected complexity is hiding in the problem, and most importantly, that your time will be allocated in sufficiently large chunks to the task. To see this is true, think of a programming task that would take you two hours to complete. How long would it take you if you can do it all in one shot? What about if you can only work in 30 minute chunks? What if you can only work in one minute chunks? If you are limited to one minute chunks and the task has any reasonable complexity, you might never finish it.

It is very rare that you truly need to multitask or switch between tasks rapidly. (If your job is one where you are expected to respond to instant messages instantly, I am truly sorry, and you need to know that there are better opportunities out there. I'm always happy to help point people toward better jobs.) In almost all of your daily work, you can afford to let things go. Those posts on Twitter will still be there when you are at a good stopping point. Those Slack messages will still be there when you are at a good stopping point with your code. That HackerNews post will still be there when your meeting is over. The task you are working on, or the peers you are working with, deserve your full attention, and giving it will let you ship higher quality software on a more reliable schedule.