Don't Write Simple Code

A response to the article: Write Simple Code

Preface to the preface to the preface: This was meant to be a comment, but I ran out of space by 4,000 characters. My apologies for any missing commas, for the ones that shouldn't be there, and for grammatical, spelling, and stylistic errors in general.

Preface to the preface: If your code is being edited five or more years later — forget about any complaints at all. Nobody along the entire chain, from investor to your direct manager, was thinking on that kind of timescale. Everything useful your code was supposed to deliver for those people (and that was their business) it has already delivered and paid for itself. By now there should have been new framework releases, new languages, quantum computers, AI replacing intellectual labor — and the whole business should have been taken public, sold off, bought back, and sold again. All of this, incidentally, has happened — but your code, your bicycle propped up with crutches on all sides, survived that competitive struggle with the titans of automation without a single edit. And you didn't even have a clear spec. You managed to write something between genius, luck, and indifference — we'll never know exactly which. You captured the spirit of the time. This article is about others — those whose code, by unhappy chance, needed to be changed by someone else much sooner. Or by yourself.

Preface: At one point in my country, programmers weren't paid much. I'll be direct — they were paid insultingly little. So I took side work in a related field as a low-voltage systems designer and installer, and in the evenings I refilled printer cartridges. Strangely, I gained extraordinarily useful experience in programming from that. Of course, analogies are a poor method — but a very vivid one. So what follows is not actually about cable work, despite appearances. It's about coding.

Life Experience

The things I encountered on various construction sites — the things people had done with cables — provoked all manner of reactions. From laughter to horror, from awe to profound secondhand embarrassment. After two or three decades I still haven't formed any understanding of what substances could have been involved in producing some of those installations. I've seen plenty. There were cables tossed across a room by the shortest path to a socket, and telephone twists on live connections serving 30-plus subscribers. Category 6 cables bent at wild angles, twisted into knots. Untwisted cables. Telephone wiring on twisted pair and Ethernet over telephone lines. Insane splices. The probable apotheosis was a half-brick wall that started to fall when we leaned against it, only to hang suspended from an electrical splice that had no business being there — at which point I experienced some extreme degree of despair mixed with enlightenment at the state of things.

Lesson One

Study the standards accepted in your field to the fullest. Best practices. Patterns. Even if you need to screw in a light bulb on a dangling wire, do it as standardly and elegantly as possible — practice your craft on small things. Be a Master in the details. A Master is recognized by their handwriting: by the crimp tool on their belt, by the bend of a cable, by the loop of spare wire left for whoever comes after. By beauty, hard-won across hundreds of jobs.

Lesson Two

Observe and make things beautiful — steal from others. Take as your own habit every best thing you've seen others do. Best practices, best design tricks, best technologies, best tooling. If it won't bring money, it will at least bring satisfaction in your work and the feeling that your years weren't wasted. The respect of colleagues. Self-respect.

Lesson Three (Corollary of the First)

When you see terrible code, press Ctrl+A then Del without hesitation (but keep the five-year rule in mind — it may not be terrible code at all). This is your project now, your responsibility — and responsibility is indivisible; there is no such thing as second-grade freshness. If you can't do a full Ctrl+A, define clearly the boundary where your responsibility ends. Draw it with the boldest marker, document the boundary conditions, and in your Master's handwriting begin your sub-project.

Lesson Three (Repeated)

Choose complexity to match the maximum plausible future development of the project. You've seen a lot — you know how failures happen, how successes happen that never actually succeed because a nail was missing in the smithy. You know where all the trendy directions lead. Don't be shy about building them into the project if it could go there. Believe me, the director of that whole establishment dreams of far greater ambitions than you do — don't clip his wings at takeoff. Simplicity here is worse than theft. Cable channels, conduit, copper, enclosures by the best standards. The next person after you, even just tapping the walls with a metal detector, should see that a Master was here before them and understand the design of your project — they should want to join it. It should be physically painful for them to write bad code on top of your system. Don't ask why. Otherwise everything loses meaning.

Lesson Four

Aesthetics matter. You spend the majority of your professional life at work. Living beautifully isn't about coming home for two hours, eating from nice dishes, and sleeping in a nice bed. Living beautifully is first and foremost about your work, your product, your tools, your thoughts — which are with you even when you're home. First, second, and third priority. In truth you live with your colleagues more than with your spouse or partner. Everything that makes your product aesthetically beautiful — boldly pull it into your project. It will protect you from burnout. It will bring genuine personal engagement to the project, which matters far more than any excessive complexity.

Lesson Five (Philosophical)

There will always be someone who wants to prove themselves by pointing out the differences between your project and its subsequent lifecycle. Even if it was perfect at the moment of creation. This is part of the path. Yin and yang, if you like. Dialectics.

Lesson Six (Debatable, Abstract)

Abstractions. The ideal is to load them to full capacity from the start, in accordance with the project model and business concept. This is my debatable, imperfect point of view. Empty floors of abstraction should be filled with stubs. Abstractions as a means of declarative self-documentation. Naming abstractions well is crucial — a good name turns an obscure abstraction into a helpful guide. But no name, however apt, will save against misuse by an under-qualified developer who, per lesson five, will not hesitate to assert themselves. Or against the rushed passerby looking for easy money through the fastest possible entropy increase. After all, there are people out there who untwist twisted pairs and run electricity through them.

Final Lesson (General)

None of this was about simple or complex code. None of this was even about efficient or cheap code. This is about attitude. Attitude toward your own work, toward professional growth, toward growth in your own life and your own projects. Harmony with your professional life. And harmony doesn't come from agreement, or management approval, or even from following best practices. It comes from an inner satisfaction with the path you've taken.

Create, programmer. You are one of the last representatives of a creative profession — the last citadel.

I, who come after you, will understand and accept your mistakes.

And the perfect code will be written by AI — without any of us.