Big task or small task first?

Alexandru Trandafir May 27, 2017

For sure many of us have read or listened to a lot of productivity advice from the tons of resources, such as posts, books and so on that are available out there and sometimes we find ourselves with the following kind of advice:

You should first deal with the biggest and most important task on your list and leave for later the less important smaller ones.

Do you agree with that?

We should really consider if that works for us.

Let’s see some reasons why we would rather choose to think and act differently.

BIG TASKS CAN GET REALLY BIG

Let’s put the example where this one developer has a lot of work to take care of:

1 big project
3 medium projects
3 small tasks

Yeah.. sounds like this developer is not going to sleep very much this week. But let’s analyze.

With the above mindset the developer should choose to work on the big project because is the most important, most difficult and most appealing from an economic point of view.

The problem with doing the bigger thing first is that it will require that much dedication and focus for a long time that most probably the other 3 medium projects and 3 smaller tasks will be abandoned for a long while until enough progress will be done with the big project.

SMALL TASKS CAN FUEL YOUR MOTIVATION

Now I'm not saying that you should focus only on the smaller tasks and leave the big one for the end, because this way you’ll also end up in trouble because you never deliver the big project.

What needs to be considered is the momentum and motivation that having something completed will provide to your mental health every time you finish a smaller task.

It all boils down to breaking big projects into smaller tasks.

Probably the best way to think is that we should always try our best at breaking the big projects into smaller more doable in a short time tasks.

Indeed breaking projects into smaller pieces and prioritizing them could be one of the most valued skills of a person.

What do you think? Would love to hear your feedback! Specially regarding working on multiple big, medium and small projects at the same time and progressing in parallel with all of them.

This article was originally posted at HeavyDots Blog

Alexandru Trandafir

Web developer and founder of HeavyDots, full service development and digital design agency, headquarters in Barcelona, remote and international approach.

Timur Batyrshin

Link e52c429ee7fe82bfec2d6542cc7b4a04b7d9f886827998833080ac23fcd2f169

I believe there could be several explanations to this:

That's about goals, not tasks.
That's about importance of tasks (linked to your goals), not to their size.
You talk about projects, not tasks, while the saying is about tasks.
The very essence of the saying is about dropping smaller, less important tasks to the floor and not doing them at all. How to choose these? Just do 3 larges things and abandon everything else for the day. They'll probably take most of your day anyway.

I can totally understand both points, it's just context that matters very much.

Stein B. Johansen

True, so true.
In my experience, it is better to divide into small tasks. It increases motivation, development speed and is easier to roll back changes. Also you will divide it into smaller tasks in your head anyways - aka what Dan North likes to say: "Fits in my head".

Motivation gets up, because you get done with tasks faster.

Productivity gets up because you are motivated, and it is easier for peers to do code review/check your work.

Less error since tasks are isolated. It is much faster to do something wrong on larger tasks that spread throughout the code.

If you have implemented changes you want to postpone, or don't want them, removal is much more isolated.

Also; keep to ONE task. Do not do refactoring or implement or change anything just because it is a one-liner or very simple. Keep to the task and write a new task on that refactoring or one-liner. Especially refactoring is perfect for cluttering up reviews...

Lovis

"Do not do refactoring or implement or change anything just because it is a one-liner or very simple. Keep to the task and write a new task on that refactoring or one-liner."

I don't think this is possible. Just like a surgeon needs to cut you open in order to get the actual surgery done, you almost always need to refactor/change something before you can do the actual task (well).
Fowler calls this "preparatory refactoring".
Also, refactoring, not on the backlog. So I wouldn't really waste time writing a new task for each change I think is valuable (also, Boy Scout Rule).
However if you're simply suggesting putting all those things into a different commit, then we're thinking the same 🙂

Chris Shepherd

The example sounds like my typical working day, in the example you have 7 tasks. What people forget is that usually those 7 tasks probably represent 7 different customers. Which means 7 people requesting updates on how things are going.

Get rid of the 3 easy tasks first = 3 less things to worry about, 3 less people to keep updated.

Walker Harrison

I feel like there's a good parallel to be drawn here to the actual algorithmic challenge of scheduling in computer science -- using earliest due date or shortest processing time, etc. Obviously there are "human" measures to consider, like small tasks being motivating as you mention, but I do think a hybrid of "proven" methods and personal preferences might be the best choice.

Kim Kulling

I do agree: a really big task is a good indicator for a couple of smaller tasks, which can be extracted. Big tasks which will take more than 2 weeks to solve are hard to implement, hard to test and hard to understand for other developers.