Paraphrased from “Mayday Air Crash Investigation:”

“Oh no, he’s multitasking… no wonder his plane went into the ground…”

Contrary to popular belief, multitasking is not at all guaranteed to make you better or faster. Rather the opposite…

When it comes to airplanes and pilots multitasking is at best prohibited and possible grounds for termination.

Not even computers do much multitasking, as in preforming several things at the same time. For instance the computer I’m writing this on has 6 cores (i.e. the ability to do 6 things at the same time) but looking at the number of threads (think of it as simultaneous tasks) it’s obvious that the computer only seem to be doing several things at the same time. (My computer currently have 3 804 threads going!)

Instead the operating system uses priorities and scheduling to give each thread a certain number of processor seconds per hour during which it can perform its tasks. It also uses interrupts (which pretty much is exactly what the name implies) when something that need immediate attention happens (for instance, the user presses a key on the keyboard, and whatever else is going on, that user will be unhappy if that doesn’t immediately produce a letter on the screen…)

Since a computer memory is widely superior to a human memory, it takes very little time for the CPU to reorient itself to the new task.

Use a priority list

As a human, your best bet is to keep a priority list of tasks to do, and only switch task before task completion if the new task is of a much higher priority.

For instance, in my line of business you might be working on an improvement to a system when the production environment has a critical problem… you drop the improvement and switch over to the critical problem… but if there’s a new improvement order (which usually doesn’t even have an SLA—agreement that stipulate that handling the issue must start within a given time limit) you keep working the current problem until you need some variation to keep your brain alert…

Give extra focus to the critical tasks

Another strategy is to designate certain tasks so important you either finish them or abort them. You never do anything but this task and if something of a higher priority comes in, you abort.

Again, in my business this would be deployments to production… in some cases even to test environments.

You don’t want to miss any critical steps when deploying to production so you make space for the event in your calendar letting everyone know you’re deploying at that time and are otherwise to be considered “out of office.”

Make room for the critical tasks

A third strategy is to finish everything on your list that is dependent on these critical tasks before you perform them.

In my business, we’d never go into production if we haven’t performed acceptance testing first. And we never go into acceptance testing if we haven’t finished the work. Or at least, when the situation is not dire and we’re not in a panic, that’s what we’re supposed to do. (I’d probably quit a project or company where panic deployment of untested functions was a norm… that or go on sick leave due to stress…)

Personally, I create checklists and prepare the deployment by packaging files, even copying them to a staging folder in production well ahead of the actual deployment. In most cases this makes a deployment into me having to stop a few processes (on a checklist) then copy some files, starting/restarting the processes and verifying what has already been thoroughly tested.

That’s it.

Complexity and challenges should never come from performing the critical tasks (e.g. deployment to production) they should come long before that (e.g. programming and testing the function, figuring out how to deploy it as easily as possible).

That way you should hopefully be able to prevent your “plane” from crashing…