As I’ve progressed throughout my brief career, one thing I’ve learned is the value of understanding the inner-workings of the tools I use every day. I’m currently a software engineer, so these tools include: Git, a version control system; Neovim, a terminal-based text editor; Ruby, a programming language, and Ruby on Rails (or Rails, for short), a web application framework; and many other tools that are less prominent as of writing.
These tools are designed to be used by engineers like myself to, most directly, build software “better.” Git makes it easier to collaborate with other developers; Neovim comes replete with quick commands for editing source code; Ruby and Rails provide useful abstractions over machine code and web machinery, respectively. But these tools’ benefits to me as an engineer are limited, in my view, by my understanding of how they work at a deeper level. For example, by understanding how Rails’ database query interface works under the hood, I can make better decisions as to when to write raw SQL in application code.
But mere “understanding” of a tool only gets you so far: there will always be more documentation to read, more blog posts to peruse, new source code to pore over. In my view, the ideal way for me to truly understand a tool — or any system, for that matter — is to build it myself. In most cases this is infeasible, however, both due to time and knowledge constraints. I accept this reality; I continue building software with a necessarily-incomplete understanding of my tools.
Building over understanding
When it comes to building my personal website, however, I’ve made a different decision: I want to build it from pseudo-scratch. (I want to minimize the use of platforms, libraries, design systems. And absolutely no static site generators — those things are inscrutable.)
Why focus my efforts on building a website, rather than the countless other tools I use every day? The Web strikes me as the most influential digital system of the past few decades. The work I do every day is on a web application; and the solutions to many pressing problems, in my view, will reside on the web — as websites, web applications, or some other web-based technology that’s yet to hit the mainstream.
As I see it, the only way I’ll gain a deeper understanding of this fundamental technology is by building directly on top of its most fundamental components: HTML, CSS, and JavaScript.
Design principles
For posterity, I want to define some design principles that I aim to hold myself to as I build. (Unfortunately, and as evidenced by this post’s existence on my website, these principles are coming a tad late — in retrospect, I would have written this post before I wrote any code! Anyway…) Namely, I will:
- Keep the site’s content readable, accessible, and navigable. Especially when it comes to blog posts, I intend for my content to be readable by everyone, regardless of physical impairments. The site should be mobile-friendly and hyper-fast, though these are less important up-front. I’ll test my website’s overall performance via Netlify’s Testmysite.io tool. (As of this writing, my site scored a 99/100.)
- Minimize the gap between the core web technologies and the system that supports my website. I’ve already mentioned my distaste for static site generators (SSG): these systems try to be everything for everyone, and in the process provide an abstraction that is many levels above the core elements of the Web. I plan to eschew technologies like SSGs and their cousins — web frameworks (like React) and CSS frameworks (such as TailwindCSS) — in the hope that I will always be able to reason about my system.
- Build with transparency. Ideally, anyone would be able to clone my process — the source code, build and deployment process, etc. — with confidence. To start, I’ll keep to this principle by (a) keeping my website code open-source, (b) including comprehensive code comments where relevant, and (c) publishing regularly about my process (and any noteworthy improvements I make).
- Automate only when necessary. For example, there are a number of premature optimizations I could make right now vis-a-vis my HTML generation process: at present, I write Markdown locally, in Notion, and once it is done I generate HTML and edit it to make it suitable for publishing. There are micro-steps that I’m positive could be obviated with a little bit of software. That said, my blog probably has one reader, me, and so I’d be spending time automating when I should be spending time writing better content. (Or finding new blog topics, reading, or simply staying away from my computer.) Put another way: I’ll make my blogging life easier when there is an obvious reason to. Similar logic applies to my decisions around website analytics, for instance.
You can follow along with me on GitHub. I’m excited to see how this site — and my mental model of the World Wide Web — evolves.