Type A and Type B Productivity

In the month of December 2024, I started messing around on the piano a bit. I started practicing every day, and the habit actually started to stick a little. I did it for about 10 days, practicing on single scales exercise in C major for about 10 minutes per day, and it was small enough that it was actually sustainable. Plus, it was just spaced out just enough that I could see improvement in about a week.

Also in the month of December 2024, I started learning Rust, a programming language which I hadn’t touched since 2018, when I read a book on the syntax that I’d now forgotten nearly completely. The first few days were painful, even trying to do simple problems, with the assistance of LLMs for the syntax. But after about 7-10 days once again, I was able to set up the initial scaffolding for the project much much faster than I could at the start of the week. I found myself recalling syntax and patterns that I’d used 3 or 4 days ago – I was thinking something like “wow, I just used this language feature in day [n-3], how did it go again?” and then I would reinforce that neural pathway by re-implementing that same pattern.

Let’s call this pattern of working on something a little bit every day, type B productivity.

I don’t believe that working consistently on a project every single day is the key to productivity. I actually think that in terms of absolute productivity, working on something a little bit at a time every single day is more of a morale booster than a productivity booster. Working on something for, say, 15 minutes a day necessarily means that you’re switching contexts more. Plus, there’s the added fact that working on a project is essentially a time-sink / cost, and you don’t yield the benefit from a project until it is actually completed. Real productivity comes when you’re neck deep in something, with all of the context loaded into your brain, and you can make changes lightning fast because you know where everything is. That’s just not possible with 15 minutes a day.

This latter pattern, of getting neck deep into something and really pushing on it, and allowing it to take over your life – let’s call that type A productivity. It’s what you use when you’re first building out a project, and it’s how I’ve worked on so many of my side projects this past year, from ssdb (link), to canvas-datatable, to spock-lang (link), to novadyne (link). The best example of type B productivity is probably the initial prototype I built out for the order processing software for the company I work at. I was able to get that into production in about 3 months as a solo dev, when previously I had never deployed anything on my own.

If you can get out of the trap of running after the new shiny thing for a couple weeks, and really commit to something, then type BA productivity is really how you get shit done.

Let’s compare and contrast type A and B productivity[1].

The Forgetting Curve. The amount of information we remember after initial exposure to it follows a pattern for exponential decay; however, this can be staved off by reviewing the information at intervals spaced exponentially further apart. Every time the information is reinforced, the rate at which it is forgotten decreases. The time between reinforcement is critical to long term retention of a concept.

Firstly, on a time crunch, it’s obvious that type A prevails. You simply can’t go anywhere fast on 15 minutes a day. Conversely anyone who’s crammed for a college assignment (which is pretty much everyone who’s been to college) knows what monumental feats can be achieved if you have a large project due in a few days. So, type A has the advantage of being better under the constraint of a deadline. Furthermore, with the added penalty of context switching, you’re not really getting anything done at all until you violate your time constraint because you actually want to get something done.[2]

In what situations do you want type B productivity? Well, the most obvious case is one where you get paid for the number of hours you work. In this case, you’re bound to have time left over, because 8 hours doesn’t take up your whole day – you may, however, after factoring in your daily routine, have only about an hour or less of actual free time per day. Obviously, in this scenario, it makes sense to use that time on whichever project you deem most important. What if you don’t get paid hourly, and instead need to optimize for actual output such as the number of features delivered?

In this case, it isn’t so clear that type B productivity makes sense. Like I mentioned previously, the more projects you work on simultaneously, the longer it takes for you to reap the benefit of any one of them, since they hold no value while incomplete. The primary use case for it, in my opinion, is when the primary goal is learning or maintaining skill.

When you’re learning a new skill, especially a complex one, it’s essential to reinforce that skill over time, instead of trying to cram learning it into a short window. This is how I was able to be so time efficient in learning the piano and Rust. By reinforcing the activity every single day, and allowing my brain to work in the background in between the different tasks, I was able to be much more time efficient, and much better at the end of a week than I would have been had I simply did all the practice on a single day. Essentially, you’re getting spacing for free.

The synergy goes further than just that, though. Unless you’re a student, you don’t really have time to just learn all day, but spending 15 minutes a day on something is well within most people’s schedule. Add to that the fact that it’s pretty convenient to work on something for 15 minutes without getting distracted or interrupted, and it’s clear to see why strategy makes a lot of sense, at least for learning new skills.

[1] I recognize that I’m overloading the word productivity here, as it’s almost paradoxical to say, as I do later in the essay, that type B productivity isn’t actually that productive. I thought about using a less specific word, such as “work”, but I want to avoid association “work”’s association with employment, and all the rituals surrounding it that aren’t necessarily core to getting the job done. Productivity, on the other hand, has to do with completing the task that achieves the desired result, the thing that directly impacts the bottom line.

[2] I don’t know if I should be saying this with as much conviction as I am. I’m certainly not an expert in type B productivity. Maybe it’s the case that after numerous days of genuinely trying to get productive work done in 15 minutes, it starts working, just as a married person with children is more efficient with their time than someone who is unattached, just out of necessity.