Would Nietzsche say yes to htmx?
Or: why the philosophy of the modern programmer is like a pistachio nut
The modern programmer is a contradiction. He is both artisan and hack conjoined. Years of irrelevant academic puzzle solving under his belt, he is backed by informal training where it matters most. Coasting on biases and hunches, he staunchly debates his way through professional life without acknowledging that neither his successes nor his failures are of his own making.
Armed with blog posts, anecdotes and calls to authority, his views on the trade are entrenched not because they have proven themselves but because deviation would be admitting intellectual defeat. Seeking complexity to prove himself, he finds little in the day-to-day trenches of gluing APIs together and must invent it through convoluted software architecture. Knowing the term only by name, he looks for prefab architectural guidance from the prophets of the current software vogue.
Indeed, the heroes of software engineering are the public figures which succeed in becoming the voice of a generation: to determine what is in vogue for the coming years is a rite of passage that separates the authentic software auteur from the opinionated rogue. Comparing vanilla react to react-fiber is like comparing miniskirts to baggy pants: one supersedes the other for no reason yet there is an industry dedicated to ensuring that you vastly prefer the Next Thing. Further reflection on the software vogue, much like reflection on miniskirts, is unnecessary as the next vogue only has to present itself as the solution, it need not be the solution in any falsifiable way.
This lack of falsification is amplified by an academic world that has no interest in the modern programmer. Stacking clever skyscrapers of proofs on topics that are of no concern to the working professional, the software engineering academic career is well spent in mathematical onanism, ignoring niche topics such as: how do we make a piece of software that works as described within a certain budget. Cleverly, the academic can avoid responsibility by claiming to be from the computer science faculty, entirely unrelated to software engineering. It is still unclear how much the academic knows about computers, though.
In lieu of academics, one might look at industry. Unfortunately, history shows that the paradigms of the software world are shifted primarily by hobbyist effort. Hobbyist inventions include among others the most popular operating system, the most versatile database, and the most important recent contribution to system language design. Wherever the industry will be in ten years, it will surely arrive there through years of thankless Friday nights invested by a bored Microsoft intern proving that the future is now. The industry will then quickly proceed to monetize the work unless legally obstructed.
All the while, serious internal criticism of the status quo remains a fringe punk-rock attitude within the industry. Some arguing with success that estimating software engineering projects is like predicting the weather. Or arguing that releasing a new revision of software successfully is such a rare serendipitous delight that the release process should primarily be approached as something to be recovered from. The most hotly debated topics are of no use to the end user: CI/CD, service design, code structure and testing, while the more on-the-nose topics are avoided. According to Chomsky, this serves a purpose:
The smart way to keep people passive and obedient is to strictly limit the spectrum of acceptable opinion, but allow very lively debate within that spectrum—even encourage the more critical and dissident views. That gives people the sense that there's free thinking going on, while all the time the presuppositions of the system are being reinforced by the limits put on the range of the debate.
Who stands to gain from the presupposition that the development process itself fundamentally cannot become predictable because of the vast demands for bespoke solutions that permeate to the core of any software project? Hard to say. Let’s not attribute to malice that which is adequately explained by stupidity:
Meanwhile, onlookers wonder how this field takes itself seriously as engineering if there is little theoretical basis, measurement or forward evolution in any of the practical work being done, yet attempts at doing the work fail massively on a day to day basis. Surprisingly the most important measurement that is being done does not actually involve measuring whether the end product is getting made. Government projects of inconceivable size solving the most simplistic problems fail not just to meet deadlines but fail to be completed wholesale without obvious repercussions for the parties involved. Further reinforcing the narrative that working software is a fluke and a failing software project is like a force of nature.
Let's look at some examples: It is perfectly normal that the entire country of the Netherlands, a stupidly rich country with an army of supposedly qualified software professionals, cannot make significant changes to taxes before 2026 for fear of the tax software system collapsing. Or that airplane outages in 2023 are caused by mistakes in agreeing on what data means, yet types being a good thing or not is still hotly debated. Or that the majority of online security issues are because we insist on solving problems by parsing strings, and that the solution is to parse all strings early to make sure they don't cause trouble when parsing them later. Or that the biggest security incident in 2021 was caused by a logging library executing code, a feature that nobody wanted and that serves no purpose but to create security issues. Or that even though your computer is 1000x faster than in the year 2000, all programs have slowed down 1000x in tandem, leaving you with the exact same experience. Or that rebooting your computer is still a valid diagnostic strategy. Or that “no” can mean false or Norway. Or that a data format can execute code. Or….
Let’s recap. Some people think that this trend signals the end of civilization. I don't want to be as dramatic, but I think this is a serious cultural issue within our industry. What is the philosophy that drives this? What is the mindset that allows this to happen without (much) introspection? Maybe Chomsky was right, but it sounds too conspiracy-y. Let's also look at someone who did a good job saying things that needed to be said in the past: Nietzsche1.
According to him, the modern programmer has achieved stoic enlightenment:
My formula for greatness in a human being is amor fati: that one wants nothing to be different, not forward, not backward, not in all eternity.
Nietzsche would argue that the modern programmer embraces his situation, recognizes that improvement is beyond his influence, and surrenders himself to fate. I am not sure what Nietzsche would think of JavaScript frameworks specifically, but he mentions them implicitly:
Only great pain is the ultimate liberator of the spirit…. I doubt that such pain makes us ‘better’; but I know that it makes us more profound.
And indeed profound we are! Without the pain and struggle of modern software development there is nothing profound in achieving greatness within software. It is precisely this struggle that elevates the result: the pistachio argument.
So perhaps the modern programmer is lifted by the struggle in his work, and without the struggle he loses his purpose. How legitimate is this struggle though? Do we need massively complicated software as often as we build it? And either way, struggling is not fun, so what should we do about that, Nietzsche?
Amor fati: let that be my love henceforth! I do not want to wage war against what is ugly. I do not want to accuse; I do not even want to accuse those who accuse. Looking away shall be my only negation. And all in all and on the whole: some day I wish to be only a Yes-sayer.
Would Nietzsche say yes to htmx?
We’ll never know. One thing we can start doing though is admit that we have a problem. More generally I would argue the struggle we have is not legitimate. I would base my argument on these observations:
Software engineering is complicated, slow, expensive and fragile primarily through accidental complexity, not essential complexity that is inherent to the domain2
The modern programmer has too much power and wields it poorly3
Bespoke software is often not needed to solve a problem
Most programmers spend their careers reinventing the wheel due to lack of collaboration
Most software is written on the wrong level of abstraction
If we can agree that something is going wrong systematically while we’re trying to fix this with technical solutions rather than systematic (or cultural) solutions, we might have a shot at improving the situation.
Those solutions are probably not simple, and I don’t claim to have all the answers, but the bottom line is that I don’t feel proud of much of the work that we do in our field. That sucks. That should not be the case.
Yes I took all these quotes from a single wiki page. I have no authority to speak about anything Nietzsche. No I’m not sorry.
Yes, some software is legitimately complicated. But how much, though?
This is why Rust is a success: it takes away power from the programmer and provides safety in return.