I mean he basically cached the results for viewing later. As cringy as it seems, it was probably the optimal solution.
personally, I would have probably built out a materialized view and added memcache to generate json to make it easier to refactor additional output formats over time but that's just me. It still wouldn't have loaded as fast as sending a pre-generated html file.
> COO invents cache invalidation
I can bang out a basic landing page site in a few hours that will be extremely performant while pulling in zero libraries. But I would never want to maintain that over any extended period of time or added complexity.
In my experience, KISS results in the easiest solution to maintain. Then I get a litany of complaints from devs that "this isn't programming" or "this is a dead end to my career" and then they leave. Which paradoxically makes it more difficult to maintain, as I have no maintainers lol.
Not saying that latter is the case here, but I've ran into devs maintaining some monstrosity and then complaining about others pushing for off-the-shelf solutions not realizing that nobody wants to spend time learning some bespoke system they created that's not actually as great as they think it is.
Not going to bash younger devs in general but the fact is that getting the job done without thinking of their future career... is usually not high in their list of priorities.
You can only anticipate so much up front. You're always going to have to rewrite things after enough growth, so make it easy to add complexity later.
(one of their caching solutions -- which works very well, actually -- is to just cache the slow PHP output of many sites and serve the HTML directly)
And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying to put together a web UI for displaying a number of reports from some computationally intensive data warehouse query crunching. We're talking visualization of tables and tables full of data. Conventional wisdom would dictate that implementing this the traditional way would involve query optimizations, various layers of caching, separation of concerns, a framework to manage all the complexity, etc, etc, etc. His approach? Just do the naive queries (slow as they were), print directly to HTML old school PHP style, then save the HTML file to disk.
He was a bubbly happy type of guy and you could see the child-like joy on his face when he showed me how lightning fast the thing would load from navigating from one page to another because it was effectively looking at a static website once the pages had been generated once. I distinctly recall feeling a mix of confused feelings at seeing the guy break every rule in the "programming best practices" book and the undeniably good performance results from the sheer dumb simplicity of the solution.