2025-02-01 ketchup.el

A few years ago I wrote tomato.el, which I’ve been using ever since on a daily basis. I was not always happy with it, though. The main issue I had with it is that the 25 minute intervals seemed a little bit too rigid. Oftentimes I heard a ding meaning that a tomato has just ended, and I take a short break, which disrupted my flow. Other times the short break became a bit longer and my productivity plunged. Also, it was not rare that I finished some task and saw that only, say, 18 minutes passed, so what do I do for the next 7 so that I don’t “lose” my tomato?

Some time ago, someone pointed me to an absolutely fascinating article about a concept called Third time, which really resonated with me. It also mentioned how the Pomodoro technique is worse than you might think, and even if I didn’t arrive at the exact same points, I fully agree with that criticism. To reiterate my last example, I often worked on some task A for some time – say 40 minutes – and then switched immediately to some task B, spending 10 minutes on it before taking a break. This means that I clocked just one “tomato” even though I worked for 50 minutes and “deserved” two. (I usually solved this by not clocking out of task A, which gave me the two tomatoes, but that corrupted my clock data. This was not as bad as it seems – when many of my tasks take several hours, discrepancy on the order of minutes is not really a problem, but it still bothered me a tiny bit.)

The most intriguing here is the fact that I independently devised a system very close to the “Third time” concept. I have intended to blog about it for a long time (I made an Emacs tool to help me with that about 6 years ago!), but my code still a bit buggy, so it will probably have to wait some time until I resolve its issues.

In the meantime, I decided to stop using tomato.el and introduce a new system. Instead of 25-minute chunks, it uses 5-minute ones, so the most I can “lose” if I clock out early is 4 minutes, not 24. (Since I’m going to use small pieces of a “tomato” instead of the whole ones, I decided that ketchup.el is a great name!) Of course, I still want something to incentivize me to work in longer intervals and not take a 1-minute break after each 5 minutes of work – that would be ridiculous. Here is my idea. Instead of counting “pomodoros” or “tomatoes” in Beeminder, I’m going to count abstract “points” based on these 5-minute chunks. However, the amount of points is not a linear function of the time spent working. Spending N minutes productively translates to floor(N/5)*(1+floor(N/25)) points. In other words, every 5-minute chunk is worth one point plus the number of points equal to the number of full 25-minute chunks. This way, working for a full 25-minute period still gives me a nice bonus, but stopping after 24 minutes is not worthless, either. Also, if I’m in the flow and don’t stop working after 25 minutes, but work for, say, 30 or 35, that is “better” than working for 25, taking a break and then working for the additional 5 or 10 minutes.

Initially, I thought to make this function a bit more complicated and explicitly “punish” (by awarding fewer points) continuous intervals of work of more than, say, 50 minutes. The idea is that I should take breaks and not sit down for prolonged periods of time. However, I hardly ever do that, because every now and again I need to go to the toilet, or make myself some tea, or something like that, so I figured I don’t need additional incentives for that anyway. (Case in point: I downloaded my Beeminder data for the goal I have for my daily job for several years. I had over 28 thousand datapoints – meaning 28k+ stretches of work – and only 22 of them were 90 minutes or longer.)

Interestingly, just changing the code for tomato.el so that another number of points is sent to Beeminder is not enough to achieve what I want. The first change I needed was that I no longer want notifications about some interval passing – the whole point is that I don’t want my flow to be disrupted. From now on, the plan is to work for how long it’s needed, not in rigid, 25-minute stretches. Another change is that I now need to tell Emacs that some tasks should not be awarded points. For example, I have some “tasks” for the few videogames I play, with a “do-less” Beeminder goal attached. They are mostly casual games I spend no more than 10-15 minutes on at a time. When using tomato.el, that was not a problem – in the (very rare) case of playing for 25 minutes or more, I just deleted the Beeminder datapoint manually. Now that would definitely not scale – playing for 5 or 7 or 10 minutes is something I do much more often. I decided to add another Org property, called just ketchup, which must be set to a non-empty string for the respective headline to be eligible for “ketchup points”. (Of course, this property is inherited throughout the Org file structure.)

And that’s if for today. I started a new Beeminder goal for the “ketchup points”, with a conservative slope for now, to see how it goes.

CategoryEnglish, CategoryBlog, CategoryEmacs, CategoryOrgMode