There’s an argument to be made for ease of use in software. The epiphany with Apple software in the early part of the 21st century was that most users had tasks they wanted done. They did not want to use a computer to do them, per se. But if a computer could do them, that was okay.

The problem with this perspective is that it assumes a certain amount of laziness—or perhaps lack of discrimination‒on the part of the user. There are some excellent times to be lazy, but choice of tools is not one of them. Ask any accomplished carpenter if the Home Depot plane and the Lee Nielson plane is the same tool. They are not. But let us explore this analogy a bit more. It’s actually damned appropriate.

If a computer and the software running on it are tools, then, like a carpenter, an experienced computer user should be discriminating in their tools. This perspective took me a long time to arrive at. I enjoy learning about my tools. And yet, I have watched a number of highly productive software developers not give a second thought to their tools. Perhaps it’s more fair to say they do not give a thought to how their tools work.

This lack of curiosity in the things that enable their work means they will always suffer when their tool breaks. At some fundamental level they do not know how they are doing what they’re doing. Any furniture maker knows at a basic level how a table planer works. Do you understand your linter works? How about the request and response cycle in your browser? The algorithm that kicks out the most appropriate answer on StackOverflow? I hope you’ve answered yes to at least one of those. But what about how a compiler works? A JIT scripting language compiler? These are all the tools of our trade.

In the case of software there’s an even worse fate. What happens when your tool doesn’t even allow you to be curious about it? Closed source software, or even just limited access to the source means you are working with a black box. You couldn’t learn how it worked even if you wanted to. I can think of a worse fate for someone who does something professionally.

All this is a round about way to explain why I am drawn to Emacs and tools like it. Popular open source tools that have survived, at this point literally, for generations of builders. There will always be a new and shiny thing. But I have made an intentional effort to lean into the open source tools that have served the curious among us for a long time now.

I encourage you to find some part of the software stack that allows you to do work and lean into it. Learn why it exists, how it is built, the people who built it, and maybe even how you can help build it in the future.