November 2, 2025
At the beginning of the year I explored the willingness to code of coders. As the year has gone by, I think it's time to review my thoughts on it. At the end of that post, I ended up scratching my head: Why don't coders want to code? Here I will add some new data points and update my model of the world. And at the current point in time, what I am really wondering is "Do I want these people to code?"
These posts come when I get to put some code in production. On last post, I wrote a cli tool to manage a vendor's arcane permissions system. Last week I wrote a Telegram bot to help me keep up with my German. It sends Nietzsche's aphorisms from "Twilight of the Idols." Yet again, my colleagues where bemused by a piece of working software and wondered how had I done it. Well, you sit down a Saturday morning and read the docs. On the next Saturday morning you write the bot. On two weekends you are done and on Monday you tell your friends. It's quite a simple process. The fact that these paid professionals cannot achieve that level of competence propels this exploration.
A good friend and colleague has a family owned startup. Let's say he is CTO, at least he is the only technical person within the company. He is overseeing the outsourced development of some internal platform. He is also writing some scripts and doing some database work. Over the summer he asked me to mentor him with these development tasks. I helped him organize the steps and asked the right questions about their data so he could figure out his database layout.
Last time we met he had gained some insights. "I have some nerdy and romantic ideas about coding," he said, "but with these no-code tools really help ship useful stuff." Which is great. I do not care what someone else uses. I care useful stuff shipped. What sucks is that his free trial for his no-code subscription of choice ran out during his birthday party and he cannot longer run his useful shipped stuff.
What's about bog standard code that makes my friend unable to ship stuff? Is it blank page syndrome? Or does code invite us to indulge in pure mental masturbation? Do the unlimited options of the editor lure us to aggrandize our intellect into mirages of productivity?
I got involved with another no-code project at work. I actually chose the stack this time. And I only chose that stack because I have a project management role. The no-code solution is an off-brand internal distribution of Node-RED. Which at least is open source and that gives me some degree of solace.
There are two developers in this project. They kept complaining about how coding is better than this no-code platform. And I agree with them. But for this project, we either use this thing, which runs in some managed enterprise k8 cluster or we do not have any infrastructure to deploy the solution. So it's not like there are many choices.
And then, after complaining about how they could do great stuff with code,
they got blocked for two days.
I wrote an email to a senior director while they complained,
trying to get vendor (internal) support.
And while they complained,
I realized they had no idea about how JavaScript and npm packages work.
Then I unblocked the issue deleting some folder and triggering a new package download
on the build step (because managed deploys).
At that point I started to wonder: Do I want these guys handling code in my project? And here we are, still wondering.
The project chugged along and we faced an unknown. The base case for whatever we are building got done. It works for a single document. And now we need… drum roll: we need to handle multiple documents. This is a classic programming problem, solved by, you know: iteration. Which is a basic programming concept. But they were blocked. They did not know how to iterate using this no-code tool. I had to explain that: for fucking sure there is a way to iterate and they should figure it out.
Then they delivered, they figured it out. Iteration. And the endless possibilities of iteration. There was a 30 minute meeting where they explained them, all of them, those endless possibilities of iteration. They are professionals with Master's degrees and years of experience, filled with joy about the possibilities of what you could build with iteration.
I mean, it's cool. You get things working, figure stuff out and it's exciting and motivating. But seriously, iteration is kind of basic. Most people learn about iteration and it's possibilities quite early during their technical education.
At this point I kept wondering: Do I want these guys handling code in my project? And here we are, still wondering.
And then I remembered, a different project with code that the most senior
of these two coders wrote.
Code that nobody could figure out.
Any issue there took hours of debugging
and the code could only be run after deploying to the production environment,
which was aptly named dev. Yes, you could not use a debugger.
You had to deploy to production and print debug.
The code followed Greenspun's tenth rule almost to the letter.
The code was Python, a this guy kept re-implementing pipes and higher order functions.
You might not want to do the Pythonic thing, which is import a library.
The returns library is out there if you want pipes but it's a scary library.
However higher order functions are on Python's standard library.
I like functional programming and all,
but I don't think you should use any of these things with Python.
And yes, this person fell into the trap.
The unlimited options of the editor lured him.
He wrote the code that showed his superior intellect to himself
instead of following the K.I.S.S. principle.
Instead of following the age old mantra: Do the simplest thing that could possibly work.
At this point I kept wondering: Do I want these guys handling code in my project? And here we are, still wondering.
The romantic conception about programming lies out there. And it tends to attract smart people. I've been reading The book Debugging Teams talks about the Myth of the genius programmer, and how it is a lie. Everyone I've talked about is smart. None are geniuses. And most of them are getting caught in webs and traps made by themselves.
My friend in the first vignette is the oldest of them all. And he is beginning to develop wisdom beyond smarts. I think is due to his own maturity as a professional and the hard true fact that when his solutions work, his family's quality of life improves. When his solutions don't work, his family has to keep on grinding.
There is a required level of experience that allows you to begin the fight against your stupid smartness, armed only with this weaponized question: How can I build the simplest thing that could possibly work. When I code, I am working against myself. Against my drive for the endless research for the perfect solution. And I try to write code that helps me manage my own stupidity.
It's taken me more than a decade of programming experience to reach my own point of wisdom. And I believe the climb to to be never ending. I've fallen for all the traps, webs and mirages that everyone mentioned above could have possibly fallen for (bar no-code, I've never no-coded). There is an arcane technology that has helped me acquire wisdom. But I had to actively search for it. Thank god for this arcane technology devised for the acquisition of wisdom: BOOKS. And other people's writings in general.
I was actively trying to learn through reading, working and deliberate practice. I've always had a drive for mastery. And it's taken me this long. But I do not see these guys driven by mastery. They are driven by the romantic idea about coding, the intellectual status of programming and a safe job.
This gets back to my question on the previous post: What are we trying to achieve when we code? Last time I waxed poetic about programming, change and self improvement:
But of all the things that are, the one we change the most as we develop new solutions, is ourselves. Through the struggles and frustrations of birthing an idea into a concrete program, we also give birth to new, wiser, better selves. That gold nugget is technology's true reward. – Myself from earlier
Can programming be a touchstone for self improvement? You get to test your ideas, truly figure out if they work. That appeals to some kind of intellect. But in a professional setting, it's not about who builds the most beautiful ideas into code. It's about solving real issues for real people. Beauty is a driving force of nature. But so is function. And the true test of technology is to produce the simplest, most beautiful solution for a given problem.
The hard limitation of code as a touchstone for self improvement is all these intellectual mirages. You can indulge in your beautiful code and avoid the functional failure of your solution. You need to keep in mind what's the end goal. You can try as hard as possible to make your recursive solution prettier, while avoiding the hard fact that your code is undebuggable and creates more problems than it solves. In order to get the most out of technology, you need to accept your own limitations as a human being. Your own stupid smartness. And if you are clever enough to follow Greenspun's tenth rule, you are clever enough to trick yourself into the mirages of productivity. To strive for mastery, you first need to accept that you are not a master.
Is it sad that I am wondering whether coders should code? I think it is, particularly because I've come to the realization that: No, I do not want coders to code. At least not all of them.
I still think that coding is great. I think that as an intellectual endeavor, it's there with Math and Music in the way it can shape an individual. But you cannot larp being a Math or Music professional and lots of people larp at being programming professionals. While they are indulging in the fiction of being coders, They are not coding working solutions to real problems. Being a professional requires hard deliberate practice to smooth your skills rough edges and limitations. Unless you are convinced that your skills are limited and rough, you will not strive for mastery.
I used to think that programming was rubbery. That the whole flexibility that software is supposed to get you, made the ordeal quite safe, soft, unedged. If you messed your thing, you were an edit away to fix it. After wasting hours of my life debugging someone else's horrible code I'm sad that I am wrong.
After every blog post on no-code, my thoughts were: I should write a blog post about Lua, and how by being simple and approachable it could democratize programming for the everyone: "We don't need no-code solutions, we need more Lua evangelism." That thought is gone today.
I've said quite often that I love changing my opinion. Once I figure out that I was wrong, I acquire a better point of view. While I have the hunch that this still holds, I am not very happy with my new point of view.