I’ve been thinking a lot recently about how to improve my programming efficiency. I’m also trying to improve my productivity, but I don’t have much to add there. (I’m using “efficiency” to mean “output per unit time” and “productivity” to mean “amount of time spent working”, though I haven’t seen a consistent way of naming these two concepts.)

I’m currently summing up my thinking in the form of a simple formula. And I mean “simple” as in “simple to understand”, even if it’s difficult to execute:

Improving yourself 2% a month will 10x you in ten years.

I think many people would find this so simple as to be unhelpful, but the point of this blog post is to argue that it is thought provoking, if not necessarily a plan to be followed explicitly.

Personally I find the formula helpful: it takes something very large (being 10x more efficient) and breaks it down into things that I suspect most people think as small (a 2% improvement). Ten years is a long time, but is still shorter than a career.

The rest of this blog post is about how we might find these 2% improvements to start stacking. I believe this is a lot more interesting than trying to find the perfect insight that will lead to a single 900% improvement.

Quick note — I’ve framed it as a “constant-relative-improvement” schedule, but more realistically it’d be a “constant-effort” schedule. Something like “Spending N hours a month will 10x you in ten years”, but for the sake of concreteness I listed the percentage increase because we can know the specific number.

Improving performance

As a field, software engineering seems fairly concerned with measuring individual performance, but relatively unconcerned with improving performance. Sure we tend to read blog posts and maybe learn a new language every now and then. But there are other fields that put an extreme emphasis on self-improvement and we can look to them to see what it would mean to truly care about this.

The two fields that come to mind are music and athletics, and there are probably more that I’m not thinking of (perhaps “performance arts” more broadly). These are fields where one’s level of performance is absolutely critical, and I’m not an expert on either of these fields but my understanding is that a large part of one’s efforts is focused on improving one’s abilities. As engineers we spend the bulk of our day operating and a small fraction of the day on improvement, but in these fields I believe the split is the opposite.

Beyond simply making the tradeoff to invest more time in improvement, there are also several techniques that are standard in these fields that I’ve realized are lacking in engineering:

• Having a coach, someone whose job is to help you improve
• Spending time doing practice, particularly drills or “deliberate practice”
• Frequently recording one’s own work and reviewing it, often with someone else

These are things that are so standard that it would be highly questionable to try to excel in music or athletics without them, but yet they are completely foreign to the field of engineering. Personally I think this absence in engineering is a bug, not a feature.

Side note: I think providing any of these is a great startup idea

What we can do

One of my intentions for this year is to to try to invest in my efficiency. I’ve already started recording some of my work sessions, and have thought of several ideas through this process:

• Learning and customizing all of the tools I use: window manager, shell, text editor
• Learning VSCode+Copilot and seeing if I am more efficient with it
• Recording myself working and reviewing it
• Writing down my problem-solving process and reviewing it

These are all things that will improve my personal efficiency.

The last one has been surprisingly profound: I will periodically write down my entire thought process for solving a tricky issue, and then review it after the fact. The main insight I’ve drawn from this so far is that the mere act of writing down my thoughts helps solve difficult problems, perhaps similar to the “rubber duck” method.

But what gets me excited is that observing my work process has suggested some things that we can improve about the art of programming that could make us all faster.

For example, I’ve noticed that I spend a great deal of time communicating my intentions to the computer. I will often have a natural-language description of something I would like to do, something that any developer would be able to understand, but it takes some time to translate this to something the computer can understand, such as by finding the exact API function to use. We humans are slowly getting better at instructing computers, but why can’t computers get dramatically better at understanding humans?

Codex/Copilot is a great improvement on this front, but isn’t quite what I mean. For example, consider the fact that when we humans write code for consumption by other humans we do it differently than when we write it for computers: we call the first “pseudocode” and the second “code”. But what exactly makes pseudocode a better language for communicating between humans but worse for communicating to a computer? If humans can understand pseudocode, why can’t computers?

I have several ideas in this direction, and I’m excited to write some more blog posts about them, stay tuned!