The Importance of Fundamentals

At the risk of tooting my own horn, I would say at this early stage of my career that I’ve been successful. Now entering my ninth year of professional employment as a software engineer, I hold a Staff Engineer title, lead a small product team, and have more or less complete autonomy over the way I build software, run the team, and organize my work life. I’m paid well and enjoy the work I do.

If I were pressed to recount how I got here, I would be forced to admit that I started by simply building things I wanted and using the tools and languages I liked. Unlike many of the excellent colleagues and friends in this space that I’ve had over the years, I don’t have a formal computer science education. Also unlike them, I started from the top of the stack and worked my way down, whereas now, working in virtualization and infrastructure, I’m surrounded by engineers whose careers took the opposite approach. I don’t regret my trajectory in any way, but I’m frequently reminded that there are gaps in my knowledge toolkit that these engineers don’t have. So envious have I been at times that I’ve flirted with the idea of going back to school and made numerous false starts at studying C and computer architecture on weekends.

But the truth is, while those things are inherently interesting in certain ways, I’ve just been far more motivated to continue building out my homelab using Go and Kubernetes, or tinkering with firecracker VMs, or working on my agentic biometrics workflows in Python. Am I doing myself a disservice by treating the fundamentals of my field with less weight than they deserve? I’m beginning to think so.

I love Oz Nova’s work and writing. For a while, he ran the Bradfield School of Computer Science and now has a self-paced curriculum focused on these fundamentals of computer science. His article Cutting Through to What Matters has earwormed me for years. I come back to it several times per year, especially when I’m having one of my phases of discontent during periods where it feels like my rate of progress is slowing. At the end of the article, he provides a succinct synopsis of his position on the question of whether engineers should (in my interpretation) prioritize the expediency of learning immediately relevant tools and concepts versus focusing on the enduring fundamentals of their craft.

In short:

1. Be a chef: work on important problems, do unique work;
2. It’s possible: it will take only a few years to get to the edge of a sub-field of computing;
3. It’s necessary: otherwise your expertise will become redundant; and,
4. Doing unique work at the edge of a field requires foundational knowledge and basic, timeless tools.

I’m deeply compelled by his argument. It takes a long view of one’s career and exhorts readers to do deep and meaningful work.

And yet, I resist Oz’s sage wisdom. This is not to say that I haven’t spent time reading computer science textbooks and figuring these things out on my own. I have and I do. But I interpret Oz as making a deeper point. He’s describing a mentality by which the devotee can achieve a state of equanimity amidst a bewildering and shifting technology climate while maintaining steady improvement in their abilities.

I’m writing this in an attempt to demarcate a turning point in my approach to skills development. Already in my short career, frameworks, languages, and tools, have come and gone. I’ve spent many hours learning technologies that I no longer use. There is no guarantee the next Kubernetes certification I earn, or framework or tool I learn, will avoid obsolescence. However, such guarantees do exist (within the timespan of my own career, anyway) for the fundamentals of computer systems, networks, unix, and so on. These skills also generalize better to popular abstractions than the other way around.

I’m not sure where I’ll start yet, but I did discover a lovely collection of guides by Brian “Beej” Hall (no relation) and I’m intrigued by his Beej’s Guide to Network Programming. I’ll post updates as I go along.