JavaScript developer Katharine Angelopoulos recently wrote an article titled Emerging Paradigms for Delivering Content Faster, and while there's much good in her article there was a line in there that stopped me in my tracks. She wrote:
Static Site Generation came about as a solution to the maladies of SSR and CSR.
As someone who's website literally reads, Created: October 14, 1994 by Elf M. Sternberg, that line made me blink three times. I write stories, and there's no way I was going to convert them all to HTML by hand. From 1994 through to today, a total of 29 years, the story site has been statically generated from something resembling Markdown (for a while it was a format called Muse, which almost nobody remembers, and before that it was just called "Usenet emphasis style"), so static site generation can hardly be called "a reaction to server-side or client-side rendering."
It was literally the first thing we did. But the Eternal Amnesia means most people don't know that.
We did it with Perl and sed and awk, but we did it and we did it well. We targeted Netscape Navigator and Internet Explorer 1.0, but we did it and we did it well. We got you here.
And we did it with Makefiles, so we knew what we were building ahead of time and we didn't have to rebuild the entire website because one file changed; Make knew what had changed and rebuilt only those end pages and assets that were dependent upon the change, and nothing else. Because build systems are not command runners, they are something better and smarter and we should do more of that.
Angelopolous is exhibiting a perfect example of The Eternal Amnesia.
Recently, Uwe Friedrichsen wrote an essay about "the eternal amnesia" in the tech industry, in which he attended a conference and listened closely to a discussion on software reusability. He wrote:
The discussion moved at a level as if nobody ever had said or written a single word about reusability in the past 50 years. I felt set back to a pre-1968 discussion, set back to a time before the NATO Software Engineering Conferences were held. Where had all the ideas about reusability from the 1970s, the 1980s, the 1990s and all the years after gone?
And finally he concludes:
We do not value the wisdom of the past.
He goes on to list a variety of causes for this, among them "It's always too new," "The people doing this are young," "The critical insights take longer to take root than knowledge."
I'll add another: there are so many damn layers between us and the past that we can't see the past anymore. Every once in awhile at my last few jobs I'll have someone ask, "How did you know how to do that?" and I'll patiently explain that it's not about React or using Material, it's about knowing your CSS and HTML and using them responsibly; it's about understanding the difference between a closure and an object. Or it's about knowing how continuations work, or being comfortable with recursion.
It's about knowing enough about the past not to repeat the same mistakes.
And one more: we're being asked to know too much. I say that only half-kiddingly, but the whole "devops" movement is about filling developers' brains not just with the responsibility for understanding the code and the target environment, but also about knowing everything about the target environment to the point where you're doing sysadmin work alongside your development work. The limit on what human beings can remember has never been found, but what we can keep active and useful is limited to the hours of the day and fresh, recent exposure. We use cheatsheets and ChatGPT not because we're lazy but because there's just too much being asked of individual developers. We're being asked to move fast, but how can we move fast and well when we're not being given the time to absorb what we've learned.
If you're operating at 100% of your capacity, you literally have no brain left to learn what you're doing. You take the pieces and parts and you assemble them together and they pass the tests, but a week from now you'll have no idea what those pieces do, or how.
The Eternal Amnesia is a consequence of how programming works... it encourages programmers to fill their brains with the sort of intellectual puzzle solving that used to be left to the rare professional mathematician, but without giving us the time to write it all down and explain how it works to other people.