Preach. The hardest problems in computer science may be cache invalidation and naming things, but the hardest problem in modern application development is navigating the ocean of enshittification caused by short-term thinking and a socioeconomic backdrop that empowers non-technical managers and commoditizes engineers.

My goal is not release cadence. My goal is to be able to write "this repository is stable, secure, optimized, and feature-complete" in every project readme.

We should do this for ourselves, and for the future. We could build a world of stable, feature-complete ecosystems that move (voluntarily) together on a quarterly release cycle. We could focus on writing nearly perfect software with a long shelf life.

I take a tremendous amount of inspiration from the Jump team building Firedancer, though my understanding of their work barely qualifies as surface-level. What a public demonstration of software engineering excellence while doing cutting-edge work.

I also think younger engineers are being brainwashed by modern engineering culture. I am fortunate to have a mentor who had a career before Agile and worked in zero-bugs-tolerated environments. I realize this level of quality is not always realistic or optimal, but I suspect many younger web engineers just assume Agile is the best way. I did.

Younger engineers: agile has merits, but it has become the mechanism that managers (a) use to keep you keyed-up and short-term focused, and (b) deal with the fact that neither they nor their clients know what they are doing. Find the people who can rebuild the Information Age from scratch, and listen to them.

There are definitely systems out there that can get away with being built primarily through kanban boards and fungible coders of average skill. The industry has decided that this is the default "best practices" for keeping a team productive. I'd prefer to never work on such a team myself ever again.

The problem is when project leads assume that their project should also be built like that, when actually it's mission-critical infrastructure that has to be architected up-front for scale, stability, security, graceful degradation, testability, provability, etc. and if you tried to chart that in story points and sprints it would be a comical farce. So they just don't do that, they try to wing it like it's a much simpler and lower-stakes project.

Now not only is it a total writeoff technically, but the kind of people that build projects this way are also sold on the idea that you never rewrite a project (thanks, Joel) so they're stuck with it forever. Major refactoring will never be a user story on the board, and even if it did it would be hard to do safely without better testability, and testability can't be improved without that refactoring, and etc. and the project has passed the event horizon of crushing failure from which no light can escape.

I have seen FAANG teams build world-scale mission-critical production infrastructure this way, including by people who claimed to be oldschool and claimed to know better, yet their names are in the git blame clear as day. I take nothing for granted any more.