Optimizing your workflow does matter in the long run

There always seemed to be a group of programmers arguing that things like typing speed or a workflow tailored specifically to you and the way you work don’t matter because these are not the bottleneck. They say it’s the thinking process that takes most of the time and energy, and optimizing the part that comes after doesn’t make much sense.

Let’s leave the discussion about whether that’s true aside for a moment. However, it’s worth noting that the “typing speed doesn’t matter” argument is often brought up by people who can’t type quickly. Have you ever met a fast typer who wished they hadn’t learned to type quickly because the speed was getting in their way? Similarly, it’s usually people who are happily clicking around with their mouse, repeating the same actions over and over again, day after day, who claim that learning and configuring keyboard shortcuts of the editor you’re using is a waste of time.

Not long ago, I was one of those people. Only after learning how to touch type have I noticed how effortless typing could be when you don’t have to look at the keyboard all the time and can leverage all 10 of your fingers during the process. Likewise, I started to strongly appreciate the value of having keyboard shortcuts ingrained in my muscle memory and not needing to reach for my mouse as frequently as I used to.

Two weeks ago, I finished my second marathon. At first glance, running and programming don’t have much in common. However, it was this race that has reinforced my conviction that optimizing your workflow does matter in the long run.

The race

Even though my fitness level was similar and my training plan almost identical, I managed to finish the race 10 minutes faster than my first marathon last year. It was focusing on the seemingly irrelevant details and having a much smarter strategy for the race that allowed me to arrive at the finish line earlier, feeling much better than last time.

During most officially organized races, you will encounter several aid stations. These are designated areas for runners to hydrate and refuel, usually positioned every few kilometers. At these stations, volunteers hold out cups of water to the runners so that they can grab them while still running.

Have you ever tried running and drinking from a cup simultaneously? When I first did that, I spilled almost all of it onto my face and nearly choked with little of what remained. There is always an option to stop for a moment and drink, but stopping is always risky because it might be challenging to force yourself to start running again.

It turns out that such a seemingly insignificant thing as the right technique for grabbing a cup of water can have a considerable impact on the final time. It’s enough to squeeze the top of the cup, leaving a small hole to drink from, which allows you to take frequent, small sips like this:

You might think it doesn’t make a huge difference, but remember that a marathon is a long distance. You are likely to pass at least 8-12 of those stations throughout the race. Without a proper technique for drinking, you’ll interrupt your breathing rhythm and lose much-needed focus, leaving the station frustrated and discouraged every time, all of which can contribute to a couple of additional minutes to your final time or a lack of satisfaction after finishing the race.

Back to programming

This experience made me realize how beneficial it might be for us programmers to make our tools as efficient as possible, especially when we think about programming as a lifelong career or hobby.

That keyboard shortcut for a frequently used action we’ve been diligently refining over the last weeks might seem silly to other people. Still, this very shortcut, which is now ingrained in our muscle memory, saves us from costly context switching, losing focus, reaching for our mouse, or simply wasting time. Having a bespoke workflow allows us to think purely in terms of “what” we want to do, not “what and how”.

Everyday tasks like switching between apps, running tests for our project, jumping to a specific file in the editor, or renaming a variable are performed by us dozens of times per day, so why would anyone argue that making sure these things are easily and quickly accessible is a waste of time?

Part of the reason might be that the gains are not clearly noticeable, as they are in running, for instance. When you introduce some changes, like the technique mentioned above for grabbing a cup of water or a carbon-plated pair of shoes, you can quickly tell whether it worked by simply checking your finish time. It’s more complex with programming because there is no obvious metric we can compare - it’s mostly subjective.

Therefore, drawing an analogy from other disciplines where the results are more tangible can help us visualize the importance of removing the minor pain points we encounter multiple times per day, specifically when we think about programming as a marathon, not a short park run.

The joy aspect

Another benefit of having a personal, customized environment that makes repetitive tasks easy and fun is that you will derive satisfaction from using it.

For example, when you have a keyboard that gives you joy with every keystroke, you’re more likely to come back to programming repeatedly and consistently because just the idea of being able to type on that keyboard again might be enough to motivate you to keep working on your side projects.

Similarly, having a script that puts a smile on your face every time it’s executed, potentially saving you seconds or even minutes of manual labor, is well worth it. All of this contributes to an overall joyful experience.

In contrast, having tools that work against you rather than with you might cause resentfulness to the mere idea of having to program again. A keyboard that causes pain in your wrists will make you come up with excuses to avoid typing as much as possible, and you might find yourself writing less helpful code review comments, shorter and ambiguous documentation, or confusing messages to your colleagues.

After all, wouldn’t it be a good idea to allow the mind to focus on abstract and complex problems, which supposedly are the bottleneck, instead of thinking about the distracting little details that can get in the way?

I hope you found this post useful. If you have some questions or thoughts, leave a comment here or reach out to me on X.