I once wrote a sprawling post about HEX architecture. It is a structure rather like a honeycomb or an onion: dependencies point inward from the outer layers toward the core, while the core remains clean and self-contained.
Just looking at it made me happy.
Recently, while thinking about how to call external systems safely, I suddenly realized that the “transform - process - transform” pattern it contains, together with the logic of “the outside depends on the core,” is strikingly similar to the HEX architecture I wrote about back then.
There is something fractal and recursive about it. I still find it beautiful and ingenious.
I decided to write it down. But after getting a few sentences out, something began to feel wrong, as if I had written the same thing countless times before. And when I thought about it, I had. A beautiful refactoring gives me a hit of dopamine, and that mechanism has never changed. So I keep following the dopamine trail, going round and round in the same place.
From a craft point of view, an elegant code structure shows real ingenuity. But it is far removed from anyone who does not write software.
These clever ideas and variations are meant for fellow programmers. The “Aha Moment” only appears when you look at the old code someone else left behind. Beyond that, I struggle to imagine who would care this much. A Manager will not care. A user will care even less.
It seems that, other than me in that moment, most people in the world will not care. Clever strategies like DRY and KISS may let you show off your taste in code during an interview. But most of the time, I have no time to put my own taste to use, let alone appreciate someone else’s. They can only nudge, by the tiniest degree, the direction in which the code rolls and changes: sometimes toward a gem, but most of the time toward a heap.
I admit that it matters, but only on a timescale of at least five years. Anything shorter, and you cannot see it.
Focusing too much on elegance in code makes me forget the food, clothing, shelter, and transport that people depend on to survive. It makes me forget the things that are real and boring, and the things that have to do with love or courage.
You might ask: it’s only code. How did love and courage get dragged into this?
The more time I spend with code, the less it feels like engineering alone. It is also an exercise in tinkering with the human heart. Once the code is running, humans are the ones watching it, testing it, waiting for reports and feedback, and, above all, using it. I am just a translator in the middle. I translate human language into language a machine can understand, then put it to work for us. When it stops following orders, I have to cover for it.
When something goes wrong, either I talk to the machine and check where my earlier translation went wrong and where my instructions fell short, or I turn the other way and explain things to the people involved. Of course, my explanation has to sound reliable enough to convince them. At that moment, another kind of art appears: the art of explanation. “A BUG is not a BUG, but another kind of FEATURE” is exactly that kind of art.
“The art of language” belongs on the same level as “how to write elegant code.”
As I see it, AI has now solved the coding problem, but it still has not solved the engineering problem. Much of the engineering problem is communication. Before AI, coders could stay inside their comfort zone without having to communicate too much. Then AI came along and pulled away the cover. People have no choice but to leave that comfort zone.
Humans need to couple with humans, and decouple from machines.
I do not know where this thought came from, but it feels simple and comforting. But the future will probably move in exactly the opposite direction. That is only my guess.
