

Why Working On Tasks In Parallel is A Pipe Dream - dkasper
http://calebelston.com/why-is-parallel-a-pipe-dream

======
swombat
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.

~~~
dkasper
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 :)

~~~
swombat
Thanks, that makes more sense now.

------
smackay
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.

------
gte910h
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.

~~~
prknight
+1

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.

------
mark_l_watson
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.

------
tsotha
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.

------
onan_barbarian
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.

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

