I like software built with care , healthy teams and puzzle pieces that fit
The prevailing, unquestioned orthodoxy of modern software engineering is simple: never build what you can buy, rent, or copy-paste from GitHub. If you dare to suggest writing your own library, let alone your own static site generator, you will be met with the kind of looks usually reserved for people who suggest returning to the gold standard.
Yet, I built this blog using a completely custom, handcrafted static site generator. Why? Because I am deeply, unapologetically biased toward building my own software systems.
In this post, I want to mount a defense of what the industry disparagingly calls Not Invented Here (NIH) syndrome. The next post will cover the actual technical details of what I built. For now, let’s talk about the why.
In software, dependencies are like renting an apartment. It looks great on paper—someone else handles the plumbing and maintains the roof. But eventually, you discover the landlord has some deeply eccentric house rules, the plumbing is made of papier-mâché, and they can raise the rent or evict you on a whim.
My architectural thinking has been heavily shaped by Rich Hickey's talks (for a quick digest of his philosophy, Daniel Higginbotham’s unofficial guide is fantastic). Hickey’s core lesson is that we should possess a healthy fear of systems we don't understand, written by people whose goals and biases we don't share.
Every time you pull in a heavy third-party framework or outsource a capability to a SaaS provider, you inherit their future roadmap, their bugs, and their licensing decisions. We’ve all been there: you invest weeks learning a complex new tool, only to hit a wall because its core abstraction makes your simple use-case incredibly difficult. Suddenly, instead of building your product, you're spelunking through the GitHub issues of a foreign repository, praying for a workaround.
With SaaS, the risks are even more immediate. You aren't just relying on their code; you're relying on their network stability, their database team, and their business model. When their server goes down, your system goes down with it, and you're left with no recourse but to refresh their status page.
There is a deeper, more insidious risk to depending on other people's abstractions: they capture your mind.
In his famous graduation speech, "This is Water", David Foster Wallace tells the story of two young fish swimming along who meet an older fish. The older fish nods and says, "Morning, boys. How's the water?" The two young fish swim on for a bit, and then eventually one looks at the other and goes, "What the hell is water?"
The longer and deeper you submerge your mind in a specific framework or tool, the more your thinking begins to resemble the limits of that environment. If you only write React, every problem looks like a component lifecycle issue. If you only use static site generators built around markdown, you begin to accept markdown's limitations as the natural laws of web publishing. You forget that other classes of design and entirely different paradigms of simplicity even exist.
At this stage in my career, I’ve stopped chasing the industry's flavor-of-the-month framework. Instead, I find myself returning to Ken Thompson's UNIX philosophy: build small, sharp, reliable tools that do one thing well and compose together.
Earlier in my career, I wasted countless hours learning broad but shallow frameworks, chasing the latest hypetrain only to watch it derail a year later. Mastery doesn't come from memorizing the APIs of ephemeral libraries. Mastery comes from deep, compounding knowledge of fundamental principles.
Building your own small tools is slow in the short term, but it carries a massive long-term dividend. The more small tools you construct, the larger your mental library of design patterns and clean code becomes. You can compose these simple components to solve massive, complex problems without inheriting the incidental complexity of a monolithic framework.
Software mastery isn't about writing perfect code; it's about practicing the art of composition. And to compose effectively, you must understand the notes you're playing.
If you want to dive deeper into the intellectual foundations of this approach, I highly recommend:
Published: 2020-11-24