On the fungibility of time

Now, unless you have a strict timetable - you still have a choice of when to place things in your schedule. As in a choice on what todo next. This makes this first tool useful: you’d want to fetch things that need done anyway in the future (especially if small/short) - today. Now, if possible (if you have room for them now). This clears your future schedule for big blocks - lowering the entropy of future schedules. Less tasks switching, or, who knows, even a few vacation days. Even a little bit of collecting together all needed information (links, emails, documents, addresses, maps) for the upcoming big push, ahead of time - will yield a feeling of being in control - and a warm start for the upcoming work block.

So, for the most part, schedule is mostly fungible - at least with respect to small tasks. They can be fetched to near-future and done, emptying the long-term calendar for more important blocks.

On asynchronous work

A dishwasher started will ensure clean dishes in the evening.

  • it does require checking regularly (preventively) for good working condition: be it cleaning, lubricating.

An email asking clarifications earlier during a project work - might ensure you have all the answers you require well ahead of its delivery deadline.

  • it does require collecting all questions and composing the message that sounds sensible

A long-running computation started - will help you having plots to add to your report during writing it later, today. Or tomorrow.

  • that is - given that recent input still works with the current model, the software doesn’t need recompilation (or even porting to the newest libraries versions)

While asynchronous work is a smart optimization, it will require preventive maintenance for worry-free runs. Corrective maintenance is when everything breaks down - just when you needed it most to run fine.

There will be a limit on the harvesting volume - when collecting a few tasks could feel like a chore in itself - and an even higher threshold that makes sorting out all the details of the harvest barely manageable.

Queueing towards the output port

When all input gets stored in the entry hall - pretty quickly the house becomes unusable.

If instead, every input gets dispatched quickly to its “work-context” destination, the entry keeps neat and still usable.

This is very much how fast network switches process packets: instead of buffering all information at the entry port - they will queue it at the exit port in the first step. In switches, same as houses, one port tends to handle a lot of traffic - while all the others tend to stay free of queued info.

So, a labelling system - and a fast dispatching one are good strategies to prevent clutter.

Rest is a project to attend too

Nobody writes down that we all need rest. But we do. Sometimes long, sometimes just often.

Learning is strongly enhanced by a lot of small naps during the day - for long-term memory storage and connections building.

Undisturbed blocks can host top priorities

If you have a 5am-8am block of time (it can sit at different hours) - you can definitely host your most important projects there. The ones that push your agenda forward - your best moonshot projects, the book you always wanted to read (and try it’s ideas out), the code you always wanted to write.

Having that part first thing in the morning - before everyone wakes up with their questions, requests, chatter - will guarantee that by the time all these come up - you’re all set and ready to go. Especially since it (should) involve projects that span weeks, months, years - and rely on compounding 1% over years.

This is a place where setting the right priorities - and working them in that particular importance order can bring a decisive win.

Every day.

Batching

During tasklist walkthrough you might notice some are quite similar - and most importantly - can be run in the same context. At the same desk, during a single drive around, using a small set of devices. It is a good idea to group them together.

Same caveat as for asynchronous work applies: you might get overwhelmed by the sheer amount of things to collect/batch.

Inclusion-Exclusion Principle

The union of all tasks that comprise a project is decomposable as follows:

The Union of all. Minus the union of all-but-one. Plus the intersection of all-but-two. Minus the intersection of all-but-three. And so on, until the intersection of all.

This suggests a possible strategy: start examining intersections. Start work (if it is not too hard a problem to solve) with the intersection of all: the exact work that needs done in any scenario, whatever the path taken to arrive at succesfully delivering the project.

Then examine All-But-One intersection. Whatever got left out - and is particular to almost all - but didn’t get done in the first pass.

However, if the project is too hard - one can sort the work the other way around: start with common parts in 2-3 tasks. Do all their combinations. Chances are by the time you finish them - you are well on your way to solving the 4-intersections covered partially.

Comments

Questions or suggestions?