so i just random'd onto this middlingly older xkcd:

this pretty accurately describes how i feel about a lot of software. it's cruft built on cruft, accumulating technical debt as prior decisions are unmade and remade, because no one understands anything they're building on or why it is the way it is. xkcd has made this point before, but i'm taking this serendipity as my cue to write about it.

there's this notion floating around: it doesn't matter whether devs understand the underlying tech stack. the whole point is to let those devs stand on the shoulders of giants to continue building. so who cares if a webdev can't write javascript without two layers of transpilation?

"standing on the shoulders of giants" is a phrase usually attributed to isaac newton, or physicists ("natural philosophers") more broadly. there it works well: given the laws of physics can change, previous discoveries, as long as they're well-supported by theory and borne out by experimentation, are the shoulders of giants! if some previous scientist claims to have discovered the truth, the only question is whether they're right. if they are, you genuinely don't need to understand every detail of their reasoning. you can work off the abstraction they've built – the final conclusion – and only worry about its mechanics if they're directly relevant.

but the tale of jan hendrik schön shows that this approach isn't 100% reliable, even in physics. his lies led the entire field of electrical engineering into a tarpit for two years. thousands of people wasted years that could've been spent on real research, not to mention the economic and emotional costs. he built a shoddy foundation, and when people tried to build on it… it cracked.

maybe you can guess where i'm going with this.

unlike physics, technology is not immutable. it isn't discovered, it's invented. people built it, and it's only a single path to take!

so no, developers aren't standing on the shoulders of giants. we're buying into a rickety pile of first drafts and making it harder to clean them up. every line of code relying on, for example, ipv4, holds us back from making desperately needed improvements.

but hey, it could be worse! ipv4 and ipv6 are at least published, open standards, which anyone can implement and only change with public deliberation. what if the "giant" is, say, facebook's javascript framework? what if it embeds stalkerware? what about when it's defined by one company? this tech is popular in part because it's useful, but it's certainly not perfect, and these are hard dependencies to break – which we need to, to adopt better alternatives.

electron alone guarantees the google, noted cyberstalkers, a permanent seat at every web standardization table. that gives them endless opportunities to ask every other browser to become stalkerware too, for example. luckily, that's not something they can unilaterally impose, because those web standards are still open, but when they have control, they use it. and a big part of the reason they maintain power is because their tech gets built on, and built into things, and can't easily be replaced, because people don't know what they use or how it works.

the issue isn't with individuals – if you, personally, as a developer, don't understand your personal tech stack, that's something you should consider changing, but it's not a critical issue. it's also not bad for people to lean on prior art to build their own things faster – just because it's not as good as it could be, doesn't mean it isn't worth using!

but the habitual dismissal of dismay at our mediocre, profit-first tech stack being locked-in by the inexperience and ignorance of the developers using it – the way it's brushed off with "standing on the shoulders of giants" – that is an issue. that needs to stop.

in the same way as we need farmers to use agricultural practices that don't poison the soil, we need devs to build tech that can be moved to better underlying software. devs who understand the underlying technology, and how it interacts with their work, and how to build abstractions, rather than just meeting requirements. this is hard! i am asking a lot of developers!

but without that hard work, without devs who can improve the fundamentals, we're stuck. we need to be building better. instead, we keep building on a decaying stack of prototypes.

it's frustrating.