---

Over the last few years, I started noticing a pattern in the things I buy, the technologies I learn, and the projects I choose to work on. I don't always choose the cheapest option, and I don't always choose the best option either.

What I seem to optimize for, more than anything else, is momentum.

When I want to make something, I want the distance between the idea and the result to be as short as possible. Sometimes that means buying a better computer. Sometimes it means improving my workspace. Sometimes it means spending several days struggling with a technology I've never used before.

Those decisions may look unrelated, but for me they come from the same place: I don't like unnecessary friction between wanting to do something and actually doing it.

I Pay to Remove Repeated Friction

I've never found it particularly useful to be cheap about things I use every single day. If I use a monitor for eight hours a day, paying more for a better one doesn't bother me much. The same applies to my computer, keyboard, mouse, desk, chair, or the software I depend on.

The cost of a bad tool isn't something you pay once. You keep paying for it every day.

A slow computer costs a few seconds every time you build something. An uncomfortable desk annoys you every time you sit down. A bad display makes hours of work slightly less pleasant.

None of these problems are dramatic on their own. That's exactly why they're easy to ignore. But small problems have one important property: they repeat.

So when I buy something, price alone doesn't tell me very much. I prefer asking:

How often will I use this, and how much will it affect my everyday life?

I may refuse to spend a lot of money on something I'll use twice a year, but I'll happily spend the same amount on something I use every day. For me, value is closely connected to frequency.

Not All Friction Is Bad

There is a contradiction in the way I work. I try to remove friction from my tools, but I don't necessarily want to remove it from learning.

I enjoy entering areas where I don't fully know what I'm doing. It might be Three.js, WebGPU, Unity, Blender, AI, robotics, or something completely different.

I open a project, read the documentation, try something, break it, and try again. Eventually, something appears on the screen that wasn't there before.

From the outside, this can look inefficient. I could probably watch a tutorial from someone who already understands the subject and reach the answer much faster. But reaching the answer isn't always the point.

I don't only want to understand something. I want to do something with it.

Seeing why the code fails, choosing the wrong architecture, hitting a performance problem, or realizing that my mental model was wrong is part of the learning process.

Some friction slows you down for no reason. Other friction teaches you something. I've become much more interested in knowing the difference.

I Prefer Learning by Building

I've stopped believing that I need to understand an entire subject before I'm allowed to use it. Most of the time, I do the opposite.

I decide what I want to build, then I learn whatever is necessary to build it.

I don't need to finish a complete Three.js course before making something with Three.js. I start making the thing. I don't need to understand every part of Unity before making a game. I learn the parts my game needs.

This approach has an obvious weakness: my knowledge can become uneven. Sometimes I know something fairly advanced in one area while missing something surprisingly basic right next to it.

I'm fine with that.

The information I learn has somewhere to go. It isn't floating around waiting for a hypothetical future use case. It's attached to a problem I actually had.

When I look back a few weeks later, I usually have more than completed videos or notes. I have something that works: maybe an application, a small game, a developer tool, or just a GitHub repository that solves one specific problem.

For me, those are better proofs of learning.

Good Tools Should Give Me Leverage

The reason I like good tools isn't simply that they make work faster. What interests me more is that they expand what one person can realistically do.

The amount of work a single developer can take on today is very different from what it was only a few years ago. I can write software, experiment with 3D, prototype a game, design and ship an application, work with infrastructure, or enter a field I barely understand and start exploring it almost immediately.

AI has accelerated this even further.

That's exciting to me, not because I want a machine to do everything for me, but because good tools increase the surface area of what I can attempt.

That's what I mean by leverage.

The best tools don't just save me ten minutes. They allow me to attempt projects I might otherwise never start.

But this comes with another problem: there is always another tool, another framework, another editor, another AI model, another productivity system.

So I've developed a simple rule for myself:

A tool should eventually give me back more than it asks from me.

If learning and maintaining the tool takes more time than the problem it solves, it has stopped being a tool. It has become another hobby.

Optimization Can Become Procrastination

This is the part I have to remind myself of most often.

Improving the way you work can sometimes be more enjoyable than actually working. Building a new PC, trying a new editor, researching frameworks, rearranging the desk, refactoring the project structure, or creating the perfect productivity system can all feel productive.

And sometimes they really are.

But they can also create a very convincing feeling of progress without producing much actual progress.

Those aren't always the same thing.

Sometimes I tell myself I'm removing friction when I'm actually avoiding the difficult part of the work. I don't need a perfect setup to start a project. I don't need to find the perfect course before learning something. I don't need to choose the perfect framework before writing the first version.

A slightly bad setup that produces something real is often more valuable than a perfect setup that never gets used.

I still don't think I've completely figured out where that line is. Maybe I never will.

But there is one question I try to ask myself more often:

Is this actually removing an obstacle, or is it just making me feel productive?

That question has saved me from a surprising amount of unnecessary optimization.

I Value Time More Than I Used To

Underneath all of this is a much simpler idea: my time is limited.

Money is limited too, obviously. But money can be earned again. Time is a little harder to replace.

That has changed the way I think about spending.

Instead of only asking, “Is this expensive?”, I increasingly ask, “How much time, attention, or energy will this give back to me?”

If a tool saves me twenty minutes every day, its price starts to look different. If something annoys me repeatedly and I can permanently remove that annoyance, that has value too.

This doesn't mean every inconvenience should be solved by buying something. Far from it.

But I think one of the best uses of money is removing problems you otherwise have to experience over and over again.

In that sense, sometimes I'm not really buying hardware or software.

I'm buying back attention.

Attention Is Probably the Scarcer Resource

For a long time, I thought productivity was mostly about time: doing things faster, automating things, saving minutes, and finishing more work.

I'm less convinced of that now.

You can technically have enough time to work and still accomplish almost nothing if your attention keeps getting fragmented.

A slow computer isn't annoying only because it wastes thirty seconds. It interrupts the thought you were holding. A complicated workflow isn't expensive only because it has five extra steps. It creates another opportunity to stop.

A bad tool doesn't always consume much measurable time. Sometimes it simply makes starting slightly less attractive.

Those tiny effects are difficult to measure, but I think they matter.

Momentum is fragile.

Anything that allows me to stay inside the problem for longer is valuable to me.

What I Actually Optimize For

If I had to turn all of this into a few principles, they would probably look something like this:

Remove unnecessary friction from everyday work. Don't remove the useful friction from learning. Spend more carefully on things you rarely use, and care more about the things you touch every day. Use tools to expand what you can do, not just to make the same work slightly faster. Learn by building whenever possible. And don't let optimizing the system become a substitute for using the system.

I never deliberately created these as a philosophy. I noticed them after seeing myself make similar decisions again and again: in what I buy, in what I learn, in which projects I start, in how I set up my workspace, and in what I'm willing to spend time on.

So maybe productivity isn't really what I'm trying to optimize.

Maybe it's something simpler.

When I want to make something, I want to be able to keep going.

Momentum.