Although this topic is something that should be obvious to everyone by now, as it seems to be beaten to death on a regular basis (in a good way), I am still amazed at how many hiring companies still place stuff in their hiring ads like:

• Must be able to juggle multiple projects simultaneously
• Excellent multi-tasker
• Ability to productively work on several projects concurrently

As a matter of fact, this jibberish nonsense used to be something that I put on my resume – until I realized that, well, it’s simply not true.

The latest tidbit I’ve read about this comes from a link to Coding Horrors that I noticed on Joel’s reddit site. The long and the short of it is that you effectively lose 20% of your time (due to context switching) by adding a a single project to your current workload. It only goes downhill from there (as additional projects are added). That 20% isn’t “lost” because that’s how much of your time you are now spending on the second project. That 20% is time that is flushed down the toilet, never to be recovered.

Let’s use a good concrete example. If you spent 4 hours in the morning working on Project A, and after that 4 hours your boss tells you that it’s time for you to start working on Project B, you can expect to flush the next 1 hour and 36 minutes (20% of an 8 hour day) down the toilet as your brain tries to forget the 600 things that you were remembering as you worked on Project A, and tries to lookup the 600 things you need to be remembering to work on Project B. This effectively leaves 2 hours and 24 minutes of productive time for Project B before you (hopefully) go home to watch Start Trek: The Next Generation re-runs (and/or an episode of 24).

He cites other great sources, more from Joel on programmers and quiet working conditions (see point 8). Not to mention this article and some great stuff from Kathy Sierra (who’s Creating Passionate User’s blog is nothing short of absolutely fantastic) stating that multi-tasking makes us stupid.

So, in summary:

• Get quiet working conditions for your developers
• Put them on one project
• Give them a spec, and leave them alone. If they’re any good, they’ll come and ask you questions when they need to clarify something.