DEV Community

Simuletic
Simuletic

Posted on

My weeks got easier when I stopped using GIANT to-do lists

My weeks got easier when I stopped using GIANT to-do lists

I'm a developer, which means I have a strange talent for turning very simple problems into systems.

A task needs doing?

Easy.

Create a project.

Add a label.

Set a priority.

Put it in a sprint.

Maybe create a recurring rule.

Perhaps we need a dashboard.

Before long, managing the tasks becomes another task.

I eventually realized that my biggest productivity problem wasn't that I needed a better to-do list.

It was that one giant to-do list has no concept of capacity.

A list doesn't tell you when anything will happen

Imagine this list:

  • Fix authentication bug
  • Answer customer emails
  • Finish App Store screenshots
  • Go to the gym
  • Review a pull request
  • Book hotel
  • Write release notes
  • Fix landing page
  • Call dentist
  • Test Android build
  • Research new feature
  • Buy groceries


It's technically organized.

Everything is captured.

Nothing is forgotten.

But there's a problem.

When am I actually going to do any of it?

A normal to-do list treats all twelve tasks as if they're competing for attention right now.

So every time I look at it, I have to make the same decision again:

What should I do next?

That decision gets surprisingly expensive when you make it twenty times per day.

I started treating the week like a capacity constraint

Instead of maintaining one backlog, I started forcing tasks into actual days.

Monday:

  • Answer customer emails
  • Review PR
  • Gym

Tuesday:

  • Fix authentication bug
  • Test Android build

Wednesday:

  • Finish App Store screenshots
  • Buy groceries

Thursday:

  • Fix landing page
  • Research feature

Friday:

  • Write release notes
  • Book hotel
  • Call dentist

Nothing revolutionary happened.

But something important did.

I could immediately see when I'd created an impossible day.

Five large tasks on Tuesday?

Move two.

Friday already full?

Stop pretending that another task will somehow fit there.

The week became a very crude—but surprisingly effective—capacity planning system.

It's basically WIP limits for your personal life

Software teams figured this out a long time ago.

If you have twenty things "in progress", you don't actually have twenty things in progress.

You have twenty unfinished things.

Yet our personal task managers often encourage exactly that behaviour.

Everything sits in one enormous queue.

Everything remains visible.

Everything feels active.

Putting a task on Thursday gives it permission not to matter on Monday.

That's the part I've found most useful.

It's less about scheduling and more about removing things from today's attention.

My current planning rule: one anchor task per day

I've also started picking one task for each day that matters more than everything else.

Not five "P1" tasks.

One.

For example:

Tuesday: Ship Android build.

There might be four smaller things underneath it, but if the Android build ships, Tuesday was successful.

This stops another developer habit I have: completing six tiny tasks because checking boxes feels better than starting the difficult one.

Leave empty space

This was harder for me.

When planning a week, my instinct is to use all available capacity.

Monday through Friday: filled.

Perfect.

Until Tuesday's bug takes three hours longer than expected.

Or someone schedules a meeting.

Or a child gets sick.

Or an API decides today is the day it will return an undocumented error.

Now the entire plan slides one day to the right.

So I deliberately under-plan.

If I think I can handle five things, I schedule three or four.

It feels inefficient when planning.

It feels extremely efficient on Thursday.

The five-minute version

My weekly planning process has eventually become:

  1. Dump everything out of my head.
  2. Pick the 3–5 things that actually matter this week.
  3. Assign those tasks to specific days.
  4. Pick one anchor task for each day.
  5. Leave some capacity unused.
  6. At the end of the week, move, delete or finish the leftovers.

That's basically it.

I've written a more structured version of the five-minute weekly planning routine if you want to try the method yourself or try Weeklane App.

The interesting part is that you don't need a particular app to do this.

Paper works.

A Markdown file works.

Apple Reminders works.

A whiteboard works.

The important change is going from:

“Here are all the things I need to do.”

to:

“Here is what I realistically intend to do on each day.”

Why I ended up building around this idea

I now work on a small app called Weeklane that's based almost entirely around this concept.

The whole product is basically seven short lists—Monday through Sunday.

And one of the hardest product decisions has been resisting the temptation to keep adding things.

Projects?

Could be useful.

Nested subtasks?

Definitely useful sometimes.

Complex prioritization?

Useful.

Team collaboration?

Also useful.

But eventually you have built Jira again.

So I've been trying to apply the same principle to the software that I apply to the week:

Just because there's room to add something doesn't mean you should.

I'm curious how other developers handle this.

Do you keep one backlog for everything, plan tasks into individual days, use your calendar, or have some completely different system?

Top comments (0)