This is one of my favourite analogies because it captures the fractal nature of todo lists and the relationship between big and small tasks.

In the classic game Asteroids, you maneuver a spaceship and shoot asteroids. Big asteroids break up into smaller ones few times until they completely disappear.

In todo list, you start with a few big problems. When you tackle one of those big problems, it breaks up into few smaller problems.

This can happen in a few ways. Either you decompose the problem into multiple smaller ones before you start, or you encounter more problems as you work on it, or after it's done.

Starting with big tasks 🔗

Big asteroids are easier to hit, because they are bigger. They break up into smaller pieces that are more difficult to hit, because they are smaller.

Similarly, after you do the main work on a task, you uncover a long tail of improvements, edge cases, and little cleanups with diminishing returns.

When you've tackled the big asteroid and most of its remains, at some point it becomes pointless to chase around a few tiny asteroids when there's still two giant ones floating around.

When small tasks are important 🔗

If you break too many big asteroids at once, though, your game field gets flooded with smaller asteroids that you have to maneuver around. You get the "death by thousand cuts" situation in your project.

This is why it's good to avoid tackling too many big problems at once and why it's important to work on smaller problems and papercuts, even when you still have bigger problems to solve. Completing small tasks will clear space for the next big task.

Optimal strategy 🔗

If you've played asteroids for a bit, you probably found out that there's a certain optimal way to break apart big asteroids such that there's always some manageable number of asteroids in the game. I find this to be true in project management, too. The exact formula is often not obvious in my experience.