Thank you for posting this. The talk was amazing, and I discovered that I had a lot of the same ideas underpinning the way I develop apps now. I had thought of it less as preventing the collapse of civilization... more as making the app understandable and maintainable for Future Me.
The phrase I had been going with was "libraries over frameworks". Because libraries tend to accomplish some small piece functionality for you. Then you knit together your own solution, using libraries as necessary for specific pieces. Whereas frameworks hide all the functionality it can from you behind grand and inscrutable abstractions.
A lot of the frameworks and other abstractions make apps not understandable on the whole. You can accomplish something like answering an HTTP request if you find the right magic words from the docs. But if the magic words don't do exactly what you want, then it usually creates a lot of accidental complexity (what Jonathan calls "trivia" in his talk) to make it work. In the end you often have to understand their code base, in addition to yours. If you have to create a job posting that requires "at least X years experience in Y framework", have you really saved anything? (The only reason you need a person who understands the framework deeply is because of all the accidental complexity from work-arounds.)
Being a games developer, Jonathan then goes even deeper than that. There's no reason why the same machine code can't run as-is on many different pieces of hardware. Except the Operating Systems are different between them, and they refuse to allow it. Operating Systems are frameworks. My brain exploded.
Now for myself as primarily a business web app developer, I don't have the same low level requirements as games developers do. So my experience is not as raw there. But I certainly feel it.
As far as learning in public, I have been trying to do that. From my posts about using messaging-based APIs instead of REST or GraphQL. To my post about Mere Functional Programming. All of which I believe lead to one of the most straight-forward and maintainable ways to develop apps. (I really want to write a game engine with this simplified FP, with a library approach to plug in rendering and so forth.) The main downside is that developing frameworkless takes a little longer to get started. And for many people, getting started is the significant hurdle. Or they are willing to trade maintainability/scrutability later for speed now. (See also this question from a recent talk.)
Fortunately, my work allows us to decide how we do things. And we train new devs much like apprenticeships. We have shortcut functions or examples which they use to perform common tasks quickly. They have space to grow into learning how those shortcuts work and therefore how the code base is structured. So the knowledge transfers over time, and even if it doesn't transfer before I leave, the code is right there in our own repo for anyone to learn. And with simple FP, it is generally straight-forward.
So much more to say, but too little time. Thank you again for posting this.
Thank you for posting this. The talk was amazing, and I discovered that I had a lot of the same ideas underpinning the way I develop apps now. I had thought of it less as preventing the collapse of civilization... more as making the app understandable and maintainable for Future Me.
The phrase I had been going with was "libraries over frameworks". Because libraries tend to accomplish some small piece functionality for you. Then you knit together your own solution, using libraries as necessary for specific pieces. Whereas frameworks hide all the functionality it can from you behind grand and inscrutable abstractions.
A lot of the frameworks and other abstractions make apps not understandable on the whole. You can accomplish something like answering an HTTP request if you find the right magic words from the docs. But if the magic words don't do exactly what you want, then it usually creates a lot of accidental complexity (what Jonathan calls "trivia" in his talk) to make it work. In the end you often have to understand their code base, in addition to yours. If you have to create a job posting that requires "at least X years experience in Y framework", have you really saved anything? (The only reason you need a person who understands the framework deeply is because of all the accidental complexity from work-arounds.)
Being a games developer, Jonathan then goes even deeper than that. There's no reason why the same machine code can't run as-is on many different pieces of hardware. Except the Operating Systems are different between them, and they refuse to allow it. Operating Systems are frameworks. My brain exploded.
Now for myself as primarily a business web app developer, I don't have the same low level requirements as games developers do. So my experience is not as raw there. But I certainly feel it.
As far as learning in public, I have been trying to do that. From my posts about using messaging-based APIs instead of REST or GraphQL. To my post about Mere Functional Programming. All of which I believe lead to one of the most straight-forward and maintainable ways to develop apps. (I really want to write a game engine with this simplified FP, with a library approach to plug in rendering and so forth.) The main downside is that developing frameworkless takes a little longer to get started. And for many people, getting started is the significant hurdle. Or they are willing to trade maintainability/scrutability later for speed now. (See also this question from a recent talk.)
Fortunately, my work allows us to decide how we do things. And we train new devs much like apprenticeships. We have shortcut functions or examples which they use to perform common tasks quickly. They have space to grow into learning how those shortcuts work and therefore how the code base is structured. So the knowledge transfers over time, and even if it doesn't transfer before I leave, the code is right there in our own repo for anyone to learn. And with simple FP, it is generally straight-forward.
So much more to say, but too little time. Thank you again for posting this.
Thank you very much for taking your time to read the post and add so insightful comments, Kasey!
Indeed, this topic and its ramifications may fuel discussion for ages!