Multitasking your “Plane” into the Ground

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…

A perverted pursuit of style

Write because you have something important to say.

If you don’t have something important to say, find something that upsets you, engages you, or otherwise feels important to you. Read about it and talk about it with people that know about it until it feels like something important you must say something about.

If you do this you’ll feel a need to write even on days when you’re not inspired. If your message is important enough, you might be able to not just finish the first draft, but also edit it into something publishable.

If, on the other hand, you write because you love language and you feel sexy whenever you use complicated words and craft impressive, long sentences, if you want to show people, especially the opposite sex how smart and irresistable you are by using language, the risk is high that you only end up showing your reader…

…that you have fallen victim to a perverted pursuit of style…

If you write because you have something important to say you’ll feel a need to write even on days when you’re not inspired.

Header image: By Patrick Denker, Flickr, Link (Edited)

Introducing the “Getting Started Writing” page

I’ve created a “Getting Started Writing” page (you can find it under the “Writing” entry in the site menu). This page lists some of the resources I’ve used to learn how to write. The list is semi-ordered in the order I think would benefit a beginning writer best, but you should of course create your own order just as you should create your own process of how to write.