Sticking to a Task vs Varying It

Question

When you have several programming tasks to do at once, do you prefer to go through them one at a time, or to vary them, perhaps based on subtasks or on time? Why?

For myself, I find that:

Pros for sticking:

• If I lose my concentration or train of thought, it takes a while to get back into it. If I chug through one task, I'll probably get more done.
• Getting to cross things off a todo list feels good and looks good to my employer.

Pros for varying:

• Sometimes my most productive work is in the first hour or so that I'm working on a task. If I vary, I get several first hours in a day.
• Getting stuck on a task when you're not making any progress is not much fun. Giving it some time often allows you to come up with solutions in a more relaxed manner.

What do you do? Is there a particular time frame between varying tasks that works best?

Answer 1

Working on several tasks at the same times means permanently having several tasks half done (so... not done). I hate that. This is waste and often means that I almost never have a "clean" version of my software.

So I work on one task at once.

Answer 2

I tend to agree with Lean and Agile thinking, that reducing Work In Progress will improve efficiency, so I try to keep at one task. It puts an emphasis on breaking tasks down into manageable, short chunks. However, there are times its good to break away from it, which I do. But my goal is to finish each task before going to the next.

Answer 3

Work on one until it's done. I find it very disheartening when I done a bunch of work and nothing is done.

Answer 4

My strategy is to do the most urgent tasks first. If there are no urgent tasks (and that's pretty rare - I usually get to kickstart my day with urgencies) I try to tackle the hardest problem I'm currently capable thinking about. Rarely, I get to choose the task that is most fun.

Regarding being stuck, that depends... some problems I tend to solve by biting into them and not letting go until I've solved them, and some I solve when I get away from the computer. Somehow there's always a need to change tactics and play catch with my mind to get the maximum out of it.

Answer 5

I try weigh in urgency in the task as well. If I have a task which is urgent I prefer to complete it before moving on. If I have tasks that are not urgent I sometimes have a few tasks(2-4 maybe, not more than 4) which I'm working on concurrently.

Pros for sticking:

Easier to focus on the task and block out other tasks

A complex task could require you to go through old code to understand the task and this will take up time before you actually get to work.

Cons for sticking:

Solving one task at a time means you waste idle time in compiling, copying files etc before you can move forward.

Answer 6

If it can help :

I start in the morning and go through my mails, sort emergencies, respond, clear the stack completely before I start my day. Try to keep it under 30 minutes. If an answer deserve more attention I make a task of it and put it on the pile. Anything unanswered becomes a task to be tackled after lunch (see below). I must say I have the benefit to work in a radically different timezone than most of my correspondents. This allows me some leeway as they do not expect an answer until the next day. Also once I get through the daily mails I rarely receive any past 9am so I do not have to worry about interruptions from mails. However, I did find that this made me much more efficient so much that when get back in normal 9-5 rumble I will say that I only answer mails between 08:30 and 09:30 and between 13:00 and 13:30. I get some heat for this sometimes but they adapt, I even got a thanks once from someone that adopted this practice and nearly tripled his productivity !

Then I pick a task and work on it until it is finished. I tend to make my tasks such that they represent work units of 4 to 8 hours each, anything more deserved to be broken down further.

Lunch interruptions, log book brain dump, belly filling. Reading through blogs and keeping questions up to date on the few SE sites I keep close.

Then go through the task piles and fix low hanging fruits. Sometimes a task only requires a few minutes, analyse bug trace from support, help QA with questions etc. I find it harder to concentrate right after lunch so this time is perfect for such small tasks. Usually 1 to 2 hours devoted to this. Here it's not priority so much as the desire to get as many done as possible.

Then pick a new task on the pile and work at it until finished. Very often the same task spans the whole day with the extended lunch interruption (for the smaller tasks). possible also that I have to continue the next morning.

Any time I interrupt a task for longer than 1 hour I pickup the log book and make a brain dump of it there so that the time to get back in the zone gets shorter the next time I tackle it.

I find this routine suits me well and provides a healthy mix of allowed interruptions and long stretch to get in the zone.

Your Mileage May Vary