Learning In Public
When I decided to start a company, I knew that I would build most things myself. For most this wouldn't make sense: it takes up valuable time, there are tools that can do what you need, it’ll take a long time to get things right. While these might be good reasons in the abstract, they didn't align to my incentives. I've built websites with an assortment of tools, but I've had frustrations with nearly all of them. But are those frustrations enough to justify the investment of time and the extra time required to get everything right? Again, most would say no. So, why am I building my own stuff anyway?
The simple answer is because it would counter productive1 for me to not do so. A major purpose of my company is to teach the world computing, and I do that by first teaching myself and then teaching others. It would be foolish if I avoided learning about building websites, a huge area of computing, simply because it's time consuming. It comes with the trade-off that the websites might not be as perfect as they could be from the jump, and it has the risk of taking up valuable time. But if I can write about this experience of learning, then it’s much less of a waste, isn't it? I can document my own journey learning something that is ubiquitous. Building websites is also a skill that most should have understanding of, even if just a passing one.
Even so, wouldn't it make sense to learn the modern tools that are used to build websites instead of going so low level as to build entire software applications from scratch? In the case of my websites, wouldn't it make sense to augment an existing static site generator instead of building my own from the ground up?
Let's again list those three reasons to not build things myself:
There are implicit assumptions in these statements that are actually wrong. Those falsehoods mean that what might seem like a foolish path to take is actually the right path.
First, the valuable time argument holds only if using existing tools or platforms wouldn't also consume that time. I do not think this is the case. I've just run into too many tools that make promises about what they can do, only to spend hours hunting down documentation or digging into code trying to figure out how to get a particular feature I need actually working. And sometimes, the features that one needs aren't even in the tool at all. The tools that are well documented often require a large enough audience that the tool becomes increasingly generic, and with that generality comes more boilerplate and more configuration, at least in most cases. It also creates more surface area for bugs.
There is a tradeoff when it comes to documentation investment: smaller more focused projects usually lack documentation because they are maintained by smaller teams that focus their energy on developing the tool itself; larger more general projects usually have high quality documentation because that is what enabled them to gain a larger audience, but catering to a larger audience requires more flexibility which often comes in the form of added boilerplate and configuration.
To sum up this point, instead of spending valuable time understanding your problem and then building a custom fit solution for it, you instead spend time researching tools, figuring out how they work (either through documentation or reading code), and only then can you actually use the tools. None of that precludes the need to understand the problem, either. This isn't a reductive justification, we don't need to build every single tool ourself, just most of them.
Second, the existing tools argument implies that just having the tools you need exist means that it'll be better to use that single tool or to pull together a few tools than to build your own. This doesn't seem true, since shoving together disparate tools from different authors usually involves quite a lot of glue. It makes your tooling vulnerable to the drift of a tool author if their use case doesn't precisely match yours. In most cases your use case and the author's use case will not completely match. The tools most resistant to feature drift are the ones that do a well defined thing, but those are often smaller tools, meaning you need to bring many of them together. This behavior approximates building your own tools and tooling, and can be seen as equivalent to doing so.
Third, the taking a long time argument. No matter what tools are used, it will take a long time to actually get things right. That's just the nature of learning, it takes times. You can choose to invest that learning time in how to get some else's tooling to work or you can invest in learning how to build your own tooling and make it work. The assumes that it'll take less time to get things right with existing tooling than with building your own. Personal experience has shown me that this is often not the case, and that it actually requires more time to get existing tooling right than it does to build specific and custom tooling.
While I have chosen to build my own things, that doesn't mean the road has been easy. I've actually used quite a few libraries and tools to build the initial static site generator that I've been using. In part 2, I'll document some of the challenges that I've been facing.
And perhaps a bit ironic. ↩︎