Why Working On Tasks In Parallel is A Pipe Dream | Hacker News Reader

Why Working On Tasks In Parallel is A Pipe Dream

calebelston.com

37 pointsdkasper12 comments

This is an attack on multi-tasking, not on multi-projecting (sorry for the mangling of the English language).

Working on multiple tasks (or even large, meta-tasks) at the same time sucks. However, working on multiple, completely separate and independent projects at the same time is great.

Look at the most successful people out there and you'll find that one common property is the seemingly endless number of projects they are involved in at any one time. Having your fingers in a lot of pies is definitely a way towards success - far from the "pipe dream" this article declares.

Progress in your work-life can be measured in the number of balls you can juggle without dropping them. Of course, one of the key skills to acquire in order to do this is to learn how to delegate parts of those tasks - but the central ability is still that of handling more than one project at a time.

That's a good point, updated the title. I added projects to the title (which was not in the original) to make it clear it is not a blog post about pipelined CPUs :)

Thanks, that makes more sense now.

Speaking personally, the biggest challenge with multiple projects is the ease with which you can switch from one to the other and still feel productive. Encounter something unpleasant that needs to get done? Switch and work on the other project. I've done this in the past and the results are (a) everything moves slower, (b) I have less motivation to tackle the stuff I want to put off, and (c) there is a very high switching cost (in terms of time) that I pay.

Multiple projects are good (and critical for me personally) but they definitely come at a cost. I think I'd prefer a plate spinning analogy to juggling. Focus on keeping one plate spinning and only divert your attention when another plate is about to fall. If you try and touch every ball frequently (with the juggling analogy) its hard to make substantail progress.

Sometimes you have to force yourself to be parallel. Software projects are often exploratory and you can quickly find yourself falling down rabbit holes so one project can easily consume all the time available. Parallelizing can at least allow you step out of the warren for a while at which point you find a more direct or better implementation.

Being parallel on a task is a little silly.

Being on parallel projects is very possible, and is also a great way to happen when there are "waiting fors" on projects, either from lack of specification, lack of data, lack of knowledge, etc. It also is a great way to combat some burnout or dealing with a very hard project (which you can only do for so many hours a day directly).

I do agree most businesses are unwilling to properly prioritize. But the idea each person should work on one and only one thing till complete is a little out there.

not to mention that some people just do better when they have more than one project running concurrently.

A contrary approach to working non-parallel is the little and often philosophy (Mark Forster talks about this in his time management books). Working on big projects in small chunks, but with great regularity.

Personally I only switch to a strictly 'serial' approach when I'm faced with a deadline, I'm in a zone or when I'm feeling stubborn about getting something solved. The problem with serial mode is that it tends to reduce quality and drains energy to an extent.

Wait...

At a certain point, you have to ask, "What is two tasks and what is one?"

Currently I'm working on a GUI. In the testing phase, I notice a number of bugs. I can usually get an idea what's needed to fix each bugs and then do all the fixes before I have to go back to another testing phase. Am I "multitasking" since I don't necessarily tackle each bug separately?

This certainly seems much faster than shops where I had to always be working on bug X at any given moment.

I sort of agree: hitting the highest priority tasks first is a generally good idea. However, there are often small 10 to 30 minute tasks of lower priority that still make sense to clear for many reasons: cut down on synchronization effort with co-workers, free up even your subconscious mind from thinking of them, etc.

Also, sometimes we may have to wait for an hour for a very large build to run. Sometimes you can stay on the same task by editing code, designing, etc. but often these delays are great opportunity to clear small tasks.

Whether switching back and forth between two tasks makes sense really depends on the kind of tasks you're doing. Sometimes you're doing something with unavoidable delays, and you either work on something else or you don't do anything.

I agree with the general thrust of what he's saying - if you're not blocked it makes more sense to do one task at a time to completion instead of having a bunch of them going at once. But it's really rare to have a job where you can always do that.

Some good points, but consider:

- alternate tasks to switch to when dealing with unavoidable delays (e.g. waiting for other people, information, etc)

- alternate tasks to switch to during periods of weak concentration or limited time or high interruption

For example, you might build that big scary new algorithm in the morning in an uninterrupted block, but towards the end of the day, you might be good for nothing but a bit of code gardening or tools work.

Our brains are always multi-tasking and sometimes you have to let your fingers switch tasks to keep up with its progress.

Reply on news.ycombinator.com