Or 'A slightly clickbaity title to something indeed important'.
One of the reasons to create this habit of blogging is to adopt the habit of learning in public. Though the concept is not exactly new, it was beautifully presented by Shawn Wang on one of his blog posts.
This habit on itself is worth an entire post (or a series, even!), but I'd like to address some side effect of it that I realized recently. After watching the video of a talk by Johnathan Blow1, "Preventing the Collapse of Civilization", I was deeply intrigued (and somewhat scared) by its premise.
During his speech, Blow talks about many technologies and apparatus developed by past civilizations. Marvels of knowledge and craftsmanship that intrigue us even with our relative technical advancement. Some items that are unattainable by us today, even with our compendium of brilliant minds and machines.
The main reason that I could grasp for this loss of knowledge is none other than the difficulty to pass forward the said knowledge. How hard it is to explain to the future generations the concepts and context in which we based our methods and achievements! Without this sharing, the knowledge ends up being siloed. The technologies and its technical concepts become stale and wither. Nonetheless, we could use a simple command in our terminals and then everything will work fine! Except when it won't.
All our toolings depend on a series of abstractions. That series of abstractions could be followed to an atomic level for what it is worth. And it is ok to use these tools, they make a big difference in our daily lives. But these are implementations on a lot of layers that can be hidden from view. What happens when the tool fails or we need something slightly different from what is provided out-of-the-box?
When we don't know how something works, and we need to learn its underlying structure to solve the problems, we end up learning a lot. And if we share what we have learned, smaller and simple as it may look, even if it is for our future reference, we unshackle this information and provide a backup to the entire world (thanks, internet). We allow that wisdom to flourish and be remixed, and to serve a lot more than only solving your problem, being stuck in your head until you forget it.
We have this current blessing2 of being able to look for whatever we want, almost anyone, anywhere, just using our fingertips - literally. We can reach the latest academic discoveries about a disease, a material or many more from this world - or even others. And we can find out how to fix that snarky webpack config with the same ease.
How about we start sharing and discussing what we know? We may end up saving our civilization.
This post was originally published at my personal blog, manoel.tech
Top comments (2)
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!