Milo Land

Efficiency is a false god

Kent Beck said "make it work, make it right, make it fast". There's two steps before making something efficient. In many cases, aligning with the principles here may result in more "efficient" work. But we should be digging further.

What is the point of more efficient work if the work being done isn't actually solving the problem? What if your efficiency is in fact creating more problems that then need to be solved? Particularly if those new problems are going to be problems unwillingly received by someone else, what good is the work being done?

Efficiencies mean externalities

The most obvious target here would be something like AI, which in some cases consumes tanks of gas per given task, and is often trained using low paid workers who have to suffer through grotesque and traumatic training data. This externalizes the cost of your efficiency to the planet at large through climate change and to less fortunate or marginalized people and communities. It's not just a financial decision. We sacrifice these things on it's altar, as it is "necessary" to do what we "need" to do.

OpenAI o3 Consumes Five Tanks of Gas Per Task

OpenAI Used Kenyan Workers Making $2 an Hour to Filter Traumatic Content from ChatGPT

But these externalities also apply to your future self. Creating a new system means a new task of maintenance. Especially in the world of modern web development, this means endlessly upgrading your dependencies, sometimes brutally so when it comes to frameworks, server infrastructure, and the like. But this can also mean, going through and updating documents, third-party billing services, websites, etc. And if you want someone else to do this, this means more money. And when you need more money, this means more work for you to do. More work means you have less time, which means more automations, more systems, etc.

What you learn from the task might be the whole point

I'll digress a bit to talk about learning in particular here, as I think it's easy to conflate concrete tasks from personal endeavors, like art and self development.

Music is "just" notes and chords and words. Paintings are "just" paint on a canvas. A book is just words on a page. You can go read the plot to your favorite movie on Wikipedia, so why bother watching it?

If you are wanting to read a book but instead rely on something like a book-summarization service or AI to do the reading for you, you are likely missing out on the entire purpose of reading: empathy, understanding, and really knowing what is being expressed. Those services are not including the most important part of the experience: you and your experience. What they define as valuable is not what you do. And even if it is, the information is likely worth much less to you.

I think the time spent and the work done to get the information and solutions you need gives it more weight and depth. You are less likely to touch a hot stove after touching it yourself than relying on someone else telling you not to. There is motivation and a deep reason that is more significant than logic and reason. This takes more effort and investment and vulnerability, of course, but in most cases, the journey is the point.

The sacrifice to our false idol of efficiency here is the core of what we sought: meaning.

Spend more time on the problem

Now if you have a concrete solution, we still have to deal with this same efficiency problem.

When solving a problem, you go through a recursive process, a variant of "rubber ducking":

This often manifests as an XY problem, where we try and solve for a proposed solution, instead of solving the issue itself. Automating this process can result in solving for the wrong problem.

Rubber duck debugging

XY Problem

My problem solving framework

This is similar to the problem of proper delegation. Delegating a problem well requires the other party you are delegating to has all the information necessary to fully understand what to do next. By writing all this out, you often catch problems in your solution or your process.

This is not on it's face "efficient". This is not a bug! This is your brain at work!

For a while, when I was a freelancer, I was considering hiring an assistant to handle taking emails and handling my scheduling. Would that have been a net benefit at that time? Probably, possibly. But the issue I was actually trying to solve was not that of not having enough time, as I still had time. The issue I really had was being unaligned with my needs, bending over backwards to do what I "should" be doing instead of working on myself. Had I followed through on this, I would have had slightly more time, less money, and the same underlying problem. Granted, I did not have the emotinoal maturity to notice this at the time, and I think I knew this as I never moved forward on it.

Or just avoid the task entirely

Why use lot word when few word do trick?

In many cases, the struggle to solve a problem is the whole point. Being able to understand the actual problem, going through all the edge cases, understanding all primary cases, and all the rest of the steps could have the most efficient solution of them all: realizing you don't need to solve the problem, or removing that task from your life entirely. The easiest system to maintain is no system.

I see this in jobs all the time, too. A product or codebase is soaked with debt in the form of barely utilized services or difficult to maintain processes or code. It becomes outdated and thus despised by users. The solution then becomes putting in mountains of time to bring it up to a modern standard or something, which just kicks the can further down the road. When the solution could likely just as easily be deprecate and remove the bloat entirely.

I noticed this as a freelancer particularly. The amount of effort to keep the work I was doing financially viable was immense, and I was paying the "passion tax" for it as an artist. If I had found a job outside of that work that could financially support me so I could make art on the side, would I have been happier? I certainly am now, as that's the path I ended up taking.

If you do still have to solve it, use small and sharp tools

The idea of small and sharp tools is from a book "The Art of Unix Programming" by Eric S. Raymond. These small and sharp tools should do only the bare minimum (and less than that if possible), and if it can be broken down into smaller tasks, you probably should.

Eric S. Raymond's "The Art of Unix Programming"

This is particularly easy to visualize in programming, but is just as common elsewhere. It's part of the brain process of "chunking", too. When we wake up and "get ready for work", what this actually entails is an often recursive set of chunks. "Put on clothes" is a chunk, including "Put on underwear", which is a chunk containing "Get new underwear our of drawer", which is a chunk containing "Walk to dresser", which contains "Turn towards dresser", etc.

When we have a problem, chunking it down can reveal problems that have already been solved by other people, or ways that you can avoid it altogether. But this also often results in being able to solve small pieces that aren't the core problem, but are a sizable part of the problem anyway. Solving for 20% of your problem instead of 100% is still a sizable improvement! These small and sharp tools are often able to be reused, as well, meaning downstream improvements for you and your community.

Never stopped to ask if we should

I guess this whole thing is a reaction to the desire to improve things that do nothing or very little, because it is "sexy" or "easy", in comparison to actually building or improving things that are useful or solve real problems, because it is "hard" or "not making money". A big "capitalism bad" post, sure, but a necessary refutation for the work we do, at least I do, every day. That one route is motivationally easy and another hard may have less to do with the relative importance and more with the values given by the system we're in.