I write a lot of Awk code. I think it’s fun. Awk has been around since 1977. Almost every time I tell someone that I program in Awk, the response is some variation on: “What? Why would you do that?”

I get a similar reaction when I mention that I’ve written a contact manager almost entirely in bash. I’ve seen this reaction online, too, when people ask for help using bash or Awk or Perl or sed. “You should just use Python,” someone often says.

They’re probably right. I haven’t used Python, but I’m sure it’s more modern and less esoteric than the other tools I’ve mentioned. Lots of programmers write Python professionally, so it’s probably safe to assume that a fair number of large companies use Python. We can also, then, infer that it is performant and scales well. I’m sure this is also true of other languages, such as C# and Java. These are serious languages that enable professional developers to deliver scalable, high-performance solutions that enterprises can rely on.

But that’s not my idea of fun. I’m not interested in the strictures of industrial software development. I write programs that help me publish this blog, manage relationships with recruiters, and track my cat’s health. There’s definitely less pressure in this scenario than in any corporate IT department, but that doesn’t mean that I don’t care about quality. My code has to be effective, but I have a lot of control over how that happens.

Why, then, do I choose the tools that I do? Why not be sensible and use a real programming language?

I use these tools because I find it fulfilling. Conceptually, some tools in the GNU suite have a history going back over 50 years. Text formatting and macro processing predate Unix. When I use these tools, I feel a connection to the past, to the people that have created and maintained these tools, and to a coherent philosophy about how to solve problems.

I admit, some of these tools are deeply idiosyncratic and can be a pain in the ass to use. But, when I actually manage to make them work, I feel that I’ve learned something about the past, something that I can’t really put into words. To me, it is comparable to standing on a sailboat and looking out on the ocean, feeling the rocking of the waves, hearing the wind beat against the sails, and knowing that, for centuries, sailors have shared that experience.

What am I doing, then? Am I just playing around in a dusty old sandbox? Are my creations just laughable oddities? I’m sure many will say so. To me, though, creating these programs is a method of self-expression. Text-manipulation utilities are my tools and text, sometimes code, sometimes prose, is my medium.

Words like “self-expression,” “tools,” and “medium” for me evoke images of an artisan pulling and shaping clay into pottery, a carpenter carving wood into furniture, or a jeweler working and finishing metal and stone. The act of making something through the application of skill and care is craft.

In Programming as Craft, Danny Crichton also mentions this application of skill and a connection with the past, but ultimately concludes that programming is not a craft because skill cannot accumulate when tools and methods are constantly changing. He tells a story about how much fun he had learning about computer science. After “modernizing” his toolchain, he went to create something,

And I stopped, burdened by the sheer amount of effort it takes just to get the most basic of apps running. Maybe I have changed as well, but programming just didn’t inspire the same level of awe as it did before. It didn’t feel so much as a craft as a never-ending trial of stamina. It just wasn’t fun, in the sense that I walked away after an afternoon with a sense of joy at the creation that I had unearthed.

Why did he take on so much complexity – so much that he no longer enjoyed it? To me, Crichton sounds like one of the many people who assume that the needs of industry are the only ones that matter. It’s an easy trap to fall into when the industrial perspective is dominant in literature and online fora. That perspective is relevant to people who want to gain and use these skills to get into the industry, stay in the industry, drive innovation for the industry, and make a bunch of money. Many people want to do those things, more than want to engage in some personal archaeology of computer science, so I understand why that mindset is so pervasive. But I think it can give people the impression that computing is just about business and not, to steal a phrase from Steve Jobs, a bicycle for the mind that amplifies human ability.

If I wanted to make my own clothes, I wouldn’t try to mimic those that produce clothing at an industrial scale. There’s a long history of people making their own clothes resulting in a rich body of tradition and literature. There is no long history of domestic computer science that focuses on application of the skill by the individual for their own benefit.

Crichton identifies a need for a “slow code movement.” If you step off the hedonic treadmill of languages and frameworks fueled by corporate money and unchecked, self-serving cleverness, you will find that programming-as-craft lives. I think this is especially evident in the maker community where the act of creation, often for one’s own benefit, is of the highest value.

Many GNU tools are conceptual descendants of tools developed for Unix. Unix, compared with its predecessors and even “user-friendly” systems that followed, feels as though it was made with human users in mind. The command-line interface rewards effort, and skill can be built and honed. The C programming language, slightly younger than Unix, has heavily influenced every major language in use today. If you learn C, learning anything else requires only incremental effort.

I’m going to keep programming in Awk. It’s effective, but also fun to use. There are many things it doesn’t do well or at all, but those are things that I, myself, just don’t need. It connects me to a tradition and a lineage that, one could argue, goes all the way back to the abacus. Whatever your tools, medium, or purpose, happy hacking.

Postscript

If the needs of most programmers are relevant to industry, then I expect that most fora will, and should, address those needs. Crafters simply need to be aware of this so that they can evaluate the information they receive. It also means that crafters are responsible for putting in the work. Read the documentation. Run experiments. Learn by doing.

Learn how to ask questions. When you ask for help from strangers online, understand that many (if not most) of them have an industrial mindset and they may not share your values. If you are trying to build a website using a macro processor from the 1960s, they are probably going to tell you to use WordPress like a normal person. To them, it’s a solved problem. They may not understand that you are doing this because you find it interesting and enjoy the challenge, or that you want to know what it feels like to use those tools. Feeling, expression, and personal fulfillment are irrelevant to industry.

So, if someone cuts you down for making irrational decisions, just understand that they don’t share your values. If you get stuck, consider stepping back and revisiting the fundamentals before asking for help. When you do ask for help, ask good questions.