DEV Community

Cover image for My day is being planned by an algorithm
Morten Olsen
Morten Olsen

Posted on


My day is being planned by an algorithm

Allow me to introduce Bob. Bob is an algorithm, and he has just accepted a role as my assistant.

I am not very good when it comes to planning my day, and the many apps out there that promise to help haven't solved the problem for me, usually due to three significant shortcomings:

  1. Most day planner apps do what their paper counterparts would do: record the plan you create. I don't want to make the plan; someone should do that for me.
  2. They help you create a plan at the start of the day that you have to follow throughout the day. My days aren't that static, so my schedule needs to change throughout the day.
  3. They can't handle transits between locations very well.

So to solve those issues, I decided that the piece of silicon in my pocket, capable of doing a million calculations a second, should be able to help me do something other than waste time doom scrolling. It should let me get more done throughout the day and help me get more time for stuff I want to do. That is why I created Bob.

Also, I wanted a planning algorithm that was not only for productivity. I did not want to get into the same situation as poor Kiki in the book "The circle", who gets driven insane by a planning algorithm that tries to hyper-optimize her day. Bob also needs to plan downtime.

Bob is still pretty young and still learning new things, but he has gotten to the point where I believe he is good enough to start to use on a day to day basis.


How does Bob work? Bob gets a list of tasks, some from my calendar (both my work and my personal calendar), some from "routines" (which are daily tasks that I want to do most days, such as eating breakfast or picking up the kid), and some tasks come from "goals" which are a list of completable items. These tasks go into Bob, and he tries to create a plan for the next couple of days where I get everything done that I set out to do.

Tasks have a bit more data than your standard calendar events to allow for good scheduling

  • An "earliest start time" and a "latest start time". These define when the task can add it to the schedule.
  • A list of locations where the task can be completed.
  • A duration.
  • If the task is required.
  • A priority

A task

Bob uses a graph walk to create the optimal plan, where each node contains a few different things

  • A list of remaining tasks
  • A list of tasks that are impossible to complete in the current plan
  • A score
  • The current location
  • The present time

Bob starts by figuring out which locations I can go to complete the remaining tasks and then create new leaf notes for all of those transits. Next, he figures out if some of the remaining tasks become impossible to complete and when I will arrive at the location and calculate a score for that node.

He then gets a list of all the remaining tasks for the current node which can be completed at the current location, again figuring out when I would be done with the task, updating the list of impossible tasks and scoring the node.
If any node adds a required task to the impossible list, that node is considered dead, and Bob will not analyze it further.

Graph example

Now we have a list of active leaves, and from that list, we find the node with the highest score and redo the process from above.

Graph example

Bob has four different strategies for finding a plan.

  • First valid: this finds the first plan that satisfies all restrains but may lead to non-required tasks getting removed, even though it would be possible to find a plan that included all tasks. This strategy is the fastest and least precise strategy.
  • First complete: this does the same as "First valid" but only exits early if it finds a plan that includes all tasks. This strategy will generally create pretty good plans but can contain excess transits. If it does not find any plans that contain all tasks, it will switch to the "All valid" strategy.
  • All valid: this explores all paths until the path is either dead or completed. Then it finds the plan with the highest score. If there are no valid plans, it will switch to the "All" strategy.
  • All: This explores all paths, even dead ones, and at the end returns the one with the highest score. This strategy allows a plan to be created even if it needs to remove some required tasks.

Scoring is quite simple at the moment, but something I plan to expand on a lot. Currently, the score gets increased when a task gets completed, and it gets decreased when a task becomes impossible. How much it is increased or decreased is influenced by the task's priority and if the task is required. It also decreases based on minutes spent transiting.

The leaf picked for analysis is the one with the highest score. This approach allows the two first strategies to create decent results, though they aren't guaranteed to be the best. It all comes down to how well tuned the scoring variables are tweaked. Currently, they aren't, but at some point, I plan to create a training algorithm for Bob, which will create plans, score them through "All", and then try to tweak the variables to arrive at the correct one with as few nodes analyzed as possible when running the same plan through "First valid"/"First complete".

This approach also allows me to calculate a plan with any start time, so I can re-plan it later in the day if I can't follow the original plan or if stuff gets added or removed. So this becomes a tool that helps me get the most out of my day without dictating it.

Bob can also do multi-day planning. Here, he gets a list of tasks for the different days as he usually would and a "shared" list of goals. So he runs the same calculation, adding in the tasks for that day, along with the shared goal list, and everything remaining from the shared list then gets carried over to the next day. This process repeats for all the remaining days.

I have created a proof of concept app that houses Bob. I can manage tasks, generate plans, and update my calendar with those plans in this app.

There are also a few features that I want to add later. The most important one is an "asset" system. For instance, when calculating transits, it needs to know if I have brought the bike along because if I took public transit to work, it doesn't make sense to calculate a bike transit later in the day. This system would work by "assets" being tied to a task and location, and then when Bob creates plans, he knows to consider if the asset is there or not. Assets could also be tied to tasks, so one task may be to pick up something, another to drop it off. In those cases, assets would act as dependencies, so I have to have picked up the asset before being able to drop it off. The system is pretty simple to implement but causes the graph to grow a lot, so I need to do some optimizations before it makes sense to put it in.

Wrapping up; I have only been using Bob for a few days, but so far, he seems to create good plans and has helped me achieve more both productive tasks, also scheduling downtime such as reading, meditation, playing console etc. and ensuring that I had time for that in the plan.

Top comments (6)

andrewbaisden profile image
Andrew Baisden

Now this is a really cool, fresh interesting idea.

joelbonetr profile image
JoelBonetR 🥇

Hahaha! That's DOPE, will you publish the code? I've a couple of friends in mind to recommend it to 😁

mortenolsen profile image
Morten Olsen

Source id here and an initial web version is here

I have just begun a rewrite an a major UX change to bring it out of PoC state, so be aware that at the moment it isn't really initiative

snikhill profile image
Nikkhiel Seath

This is interesting.

I shall like to try this out.

anwar_nairi profile image

That sounds like something very useful right there congratulations!

Will you plan another article to explain the tech behind it?

Is Bob available for discuss (web app, mobile app) right now?

mortenolsen profile image
Morten Olsen


Well originally I only build it with iOS in mind, and since iOS does not give a good way to distribute apps other than a full App Store release, I didn't do much in terms of releasing. Also because the initial version was very tied to the phones calendar I didn't think a web version made sense.

...But ask and you shall receive

I have now done a quick web "optimization" of the app at but I had to limit the functionality a bit, so now only the "routines" task source are there. Will fix "goals" later today when I have the time.

Keep in mind that this is still in the PoC phase, so the UX is horrible and user hostile. Again something I plan to fix once I have the time.

If you want the app experience and know how to run an expo app the full source is available at

I don't plan to do a follow up about the actual app as it is just pretty standard React Native/Expo stuff, and people have written better articles about that then I could

Need a better mental model for async/await?

Check out this classic DEV post on the subject.

⭐️🎀 JavaScript Visualized: Promises & Async/Await

async await