A few months ago I had a brief lapse of sanity that led to a weekend of extreme anxiety, depression, and existential doubt. I read an announcement and watched the related presentation by Chris McCord—a developer I like and respect a lot who has personally assisted me on at least one occasion and whose tools I use on a near daily basis—and in it he linked another article that has received a lot of traction titled My AI Skeptic Friends Are All Nuts.

The timing was bad for me on a personal level. There had been a lot of talk internally where I work about AI in coding, especially because a recent engineering-wide presentation strongly implied it may be mandated in the future. This laser focused my neurosis for a few reasons:

  1. As I said, I really respect Chris McCord. Like many others, when someone I respect takes a position I double check myself and that’s almost never fun.
  2. Many other engineers in the organization are all in on this. Same situation. People I believe to be smart disagree so I have to self evaluate (again).
  3. A friend of mine who seemed to be on the same page with me about AI being Satan—who is the devil and the father of all lies—was suddenly in full vibe mode, going so far as to say something to me—as if ripped right from Thomas Ptacek’s article—along the lines of “all code can’t be a work of art.”

His comment stung and the change in position, or perhaps the public change in position, was especially unnerving. It was like Chris McCord had just given him permission he needed to openly disagree.

My internal death cycle thus began.

Was I just the latest generation of people who resist change because we’re old and set in our ways? Was my resistance because I like things the way they are? (I really don’t. Even writing that made me throw up in my mouth a little bit.) Was I that person who romanticizes “the old ways”? Had I become that old dog who cannot learn new tricks?

Moreover, as I occupy a senior position, were people agreeing with my anger toward AI’s place in software engineering doing so because they agreed with me or because they felt like they had to agree? Was I imposing my ideas on others by being vocal?

It was a bad weekend. I messed with LLM tools again. By Sunday afternoon I felt resignation set in. Whatever, I’ll just do this thing because… wait a minute. Because why? What the fuck was I even thinking? What the fuck was I even doing?

Other excellent and hilarious writers have already dismissed and destroyed My AI Skeptic Friends Are All Nuts. There is, however, one particular part I wanted to address myself that is at the heart of how I approach software and the other trade and hobby skills I engage in.

The “but the craft” section is easily the most personally enraging portion of piece. I have some thoughts. Let’s pluck a bit out of this:

Do you like fine Japanese woodworking? All hand tools and sashimono joinery? Me too. Do it on your own time.

I think this is what really bothered me in context to what my friend had say about how everything couldn’t be a “work of art.” That felt like a very direct and personal attack.

The thing is, I actually sort of agree with what I believe they’re getting at. The problem is, neither Mr. Ptacek nor my friend, seem to understand the difference between art and decoration.

Art is an important element of engineering disciplines. To those who love what they build, it’s more important to our work than those who produce slop to collect a paycheck will ever understand. The latter also fail to understand what art is or even means in this context.

What many of us Bohemians discover as we grow in our skills is that restraint is one of the most critical elements of artistic expression. Revisiting the basics and considering how they affect both the function and aesthetic of the overall piece is incredibly important. Consideration of the piece holistically is another major component. What does it do? Where does it fit? How does it fit?

Art is not flair. Art is not mere decoration. Art is not superfluous nor excess.

Let’s talk about building a bookshelf.

There is considerable variation in what should go into the construction of a bookshelf. It depends on what the commissioner—who may very well be yourself—wants. It depends on time constraints. It depends on budget. It depends on materials. It depends on the available tools.

Should every bookshelf be crafted out of the finest hardwoods with the most precise joinery at every level? No. Absolutely not. That assertion is nonsense and anyone who thinks that is what I advocate about software or even art is providing themselves with a convenient and self-serving escape from what I do advocate.

You can build a perfectly usable and sturdy bookshelf with some very basic tools, techniques, and materials. It can be beautiful. It can be pleasing to the touch. It can fulfill its actual role for decades. It can be a work of art. It can do all these things with a weekend of work as long as the craftsperson takes care of the fundamentals, pays attention, and approaches the process seriously.

Does a bookshelf need hand tools? Japanese joinery? Dovetails? Hardwood? Decorative trim? Would these even be appropriate or desirable in all settings?

No. You can grab pine and plywood from the local home center and combine rabbets, simple miters, and a few other basics to make a piece that does what it needs to do, does it well, and does it for a long time—like, pass it down to your grandchildren long time.

(As an aside, hand tools in the hands of a skilled craftsperson can do many things power tools cannot, sometimes do them faster, and accounting for cleanup, noise, dust and other trade offs are often very much a win in terms of efficiency over power tools. It’s also very hard to accidentally inflict a catastrophic injury on yourself compared to say… a table saw.)

Regardless of what you are about to build or the constraints imposed on the process, sloppy work from someone who does not care about the final product in any meaningful way will resonate in every detail, just as the opposite is true. To take this a step further, you can give a thoughtless, careless individual the best tools, the most exquisite hardwoods, and all the time in the world and the final product will almost certainly pale in comparison to someone who genuinely cares about what they build even if they have lesser tools and materials.

This is the part the AI zombies do not understand. This is why they so easily glorify mediocrity (actually, slop—it’s just slop). This is why they believe shitting out a chat or blog app in a few minutes that solves zero new problems is even interesting. (ProTip™: if boilerplate is a major problem for you as programmer, that says more about your skill than anything else.)

And I realize, just as Thomas Ptacek does, that you can just buy a bookshelf and save yourself a weekend. That’s fine. That might be the answer, but his analogy sucks. AI generated code is not buying the bookshelf. Literally buying software or utilizing existing libraries is the appropriate analogue here.

At some point, your job as a software engineer is building something you cannot just go pick up at the proverbial Ikea. Even if you’re just the person assembling something from Ikea, there is a wide chasm between the end result of someone who assembles with care and someone who merely slaps it together. (And if you’ve ever had to partially disassemble and reassemble one of these pieces of furniture, you know.)

One of the biggest divides between journeymen and masters is the attention given to the basics. Part of the transition to master is the realization that everything you learned as an apprentice still requires care. You never outgrow that. You know when to rely on the basics and when to get fancy. Advanced techniques do not make anything you learned on your first day irrelevant or unimportant.

I grew up working trades with my father. I was helping remodel bathrooms as young as three-years-old (my contributions were tiny) just because I loved being with my dad on job sites. I learned more about what it takes to build a good product framing walls and hanging doors than I ever did participating in the software industry.

One of the things my dad emphasized in my youth as we worked together was, “Your signature goes on everything. When you do a job, do it correctly, no matter what you see others do.” This applied to even the most banal work, such as fixing toilets or patching walls. It doesn’t matter what you’re doing. Do it correctly. Do it with intention.

He hated the dishonesty he had witnessed in his own industry, pointed out terrible work we often had to fix, and taught me to approach my trade with honor and integrity. He made it clear how the poor and lazy decisions of others negatively affected our customers. Sound familiar?

He also had a saying he repeated that came from his own father:

You never have time to do it right but you always have time to do it over.

When you demand quality in everything you do it becomes infused into everything you build. It is natural and effortless. When mediocrity and dishonesty are not options, there’s a lot less noise in your own mind. You’re clear to just do the right thing. You never have to question why or whether you should. You simply do what must be done because you have already settled these questions definitively.

Those who consistently fail to do the right thing make up all manner of reasons why they don’t, and it usually involves the false dichotomy that there is an inverse relationship between the quality of their work and the time it takes to construct something. For systems in particular, this is not just wrong but almost entirely at odds with reality.

A single project like a bookshelf is fairly self contained. If the construction is poor, it can be replaced with relative ease. In the world of professional software development, most of us are not working on small projects. We’re usually working on and maintaining modules and applications that are a part of much larger systems. It’s less like building a bookshelf on the weekend and more like constructing part of a house or a skyscraper over weeks or even years.

Bad design, early mistakes, and poor planning have multiplicative effects over time that can range from expensive fixes to complete disasters for the people using or occupying the constructed space. The compounding nature of interest makes the term “tech debt” a better analogy than most people—including people in the industry—truly appreciate.

Which brings me back to Mr. Ptacek.

If anything we build endures, it won’t be because the codebase was beautiful.

This is complete misdirection.

Make no mistake, bad systems do endure and many good systems have ended up in the digital dumpster. That’s entirely irrelevant. This is the nature of all products in all industries because there are many factors that affect the success of a business and a product that have little to do with the quality of the the actual product (e.g. Microsoft Windows).

What we’re talking about is whether there is a reason to produce something that isn’t the best it can be given the constraints of reality. Is there ever a good reason to allow mediocrity to be your North Star?

Systems that are well designed—dare I say “beautiful”—are more flexible, require fewer resources (e.g. engineers, managers, infrastructure, security, support staff, hardware, etc.) to operate, are easier to change and evolve as needed, allow new hires to contribute faster, and in short do all the things you want a system to do when it’s either the core or a major component of a for profit business!

Sustainability matters for systems. It matters for companies. It should be baked into how we build and what we build.

Imagine a world where we decreased overhead by nurturing software fundamentals like DRY, SRP, documentation, clarity, and boundaries while ensuring our engineers were disciplined in that regard rather than just throwing shit into a black box and hoping for the best. Imagine our corporate masters saying, “Hey, maybe we should invest time and energy into actually building a product that meets the basic needs of our customers and doesn’t frustrate them,” rather than, “We’ll be adding AI use to our metrics and integrate yet-another-pointless-agent into your workflows!”

Just imagine. It’s easy if you try. I can hear John Lennon singing right now…

Again, bad systems can and do endure, but they do so at a considerable cost. (My current job is a masterclass in this concept.) The only “advantage” they offer is employment for more people to do triage work for eternity. This is another one of those problems AI can supposedly solve that wouldn’t exist in the first place if casual acceptance of poor design and bad practices weren’t the industry norm. It’s the reason software engineering will be looked at as a second class discipline by actual engineers until we start acting like actual engineers.

In my own experience (which, of course, is entirely anecdotal) the average plumber is more careful in their work than the average programmer—primarily, I believe, because there are actual consequences and liabilities that come from doing a poor, rushed, sloppy job that doesn’t meet basic building code requirements. The software industry is basically able to just say, “opps, sorry,” when they break all the things.

The big lie—the big fucking lie—that there is an inverse relationship between time to market and system quality is a truly horrific and powerful force. It’s so very seductive to corporate leaders and product departments—I suspect because on average they seem to possess the patience and foresight of a toddler—that it has been more or less infused into our industry’s collective consciousness.

This does not change the fact that it is fundamentally wrong. If you believe it to be true, you are wrong. You are the software industry equivalent of a Flat-Earther. I’m sorry. (Actually, I’m not. This is on you.)

Good software is a lot more than code in much the same way good writing is more than just words. Good programmers and writers alike spend a considerable amount of time on things that do not involve producing code or words at all. Much of the most important work is done scribbling on whiteboards and notepads, or arguing with one’s self during lunchtime walks around the park. It’s about thinking, overthinking, and thinking some more until you reach a comfortable degree of clarity about your route and destination.

I’m not going to tell you that you cannot use AI tools in meaningful ways or that they cannot potentially assist when properly scoped within an already sound and reliable process. The old “another tool in the tool belt” saying—oddly, spoken so often by people who have never worn a tool belt—is fine. However, if you measure its usefulness purely in lines of code, you’re bad at your job.

I am going to tell you that if you believe those of us who do not use AI are falling behind or that you are a 10x developer as a result of using AI compared to your co-workers—”sipping rocket fuel,” as it were—that you are most definitely fucking delusional.

There is a world of difference between super fancy auto complete and “game changer.” If the game has somehow fundamentally changed for you as result of AI coding tools, it’s clear you never really understood how it is played.

End of line.