Every so often, you'll see someone complain that developers "don't know their fundamentals" or that they only want to hire developers who have "good fundamentals". A lot of this can be arbitrary gatekeeping, but within a context like web development, there are fundamental bits of knowledge than can serve a developer well throughout their career.

Let's talk about those fundamentals, what they are, and how important it is that your average web developer understand them.

What is Fundamental?

When I say "fundamental" as a noun, it means "something fundamental [as an adjective]" (thanks, English!). If something is fundamental, I mean the primary definition:

serving as an original or generating source

To say it another way, a fundamental piece of knowledge is knowledge on which many other things are built. For a web app, HTML is a great example.

Here's a quick list for web development (I'm sure a few things are omitted):

• HTML
• CSS
• JavaScript (the language)
• DOM API
• HTTP (basics)
• SQL
• Asynchronous Behavior

Almost every web application makes use of these fundamentals. But notice how each of them is somewhat useless on its own? If all you know is CSS, you can't do much. SQL can query a database, but to what end?

Consider your average web framework, like Rails. How effective can you be without knowing these fundamentals? Pretty effective!

In Rails, you can't really avoid much HTML, but you can avoid almost everything else (especially if you are using a CSS Design System like Bootstrap). I've known very experienced engineers who get a lot done and who I'd work with again that barely know SQL. Tons of experienced—and effective—engineers don't know how HTTP works.

So why is any of this important?

The Value of Fundamental Knowledge

I wrote in The Katz Conjecture that you will eventually need to understand the thing an abstraction abstracts. Those engineers that don't know SQL will eventually have to learn it when they need to diagnose a slow app. Bootstrap users will need to figure out CSS when they need to make something work that Bootstrap doesn't provide.

Said more generally, the more experience you have as a web developer, the more likely you are to hit a problem that requires understanding some fundamental building-block of your app's framework. And, of course, the more experienced you are with these fundamentals, the more quickly you will be able to assess why your app is behaving the way it is.

Further, the more you understand these fundamentals, the more quickly you can get up to speed when the technology of the day changes. If you know the DOM API really well, that can help you learn React after years of doing only Angular.

The problem is that there isn't a great way to learn these fundamentals outside of a stressful situation figuring out a problem.

Trying to Actually Learn Fundamentals

Simply reading a book on them, or going through documentation isn't a great way for this stuff to stick…at least not for me. You often need to have some practical experience actually using fundamental technologies. The only way I have figured out how to do that is to try to build real projects. My palette generator Ghola is an example of something I built to learn Web Components (very long read on that here).

Of course, not everyone has time to just build random apps on the side. Another option is to deep dive during your normal work. When adding a new feature or fixing a bug, you may be able to go a level down in your framework to understand how it works for your use case. For example, in Rails, you can have Active Record output the SQL it's running. Or, you can open your browser's dev tools and dynamically change CSS to see what affect it has on what you are doing. Or try to test your app with curl. I've used all these techniques, at least during times when I felt more curious than rushed.

What was interesting to me in retrospect is a corollary to the aforementioned Katz Conjecture: Some Abstractions Aren't That Great. In Rails controllers, the headers hash allows access to the headers. But the headers names don't match the standard. You have to figure out the convention for how the header names are modified, for example to access the Accept header, you must use the key HTTP_ACCEPT. While I'm sure there's a good reason for this, it's not to make our lives easier.

Over time, knowledge of fundamentals gives you a new lens to use when evaluating abstractions. If you know what's being abstracted, you can start to get a feel for an abstraction's ergonomics. Will it alleviate the pain of working at a fundamental level, or will it simply replace one set up annoyances with its own? This skill, generalized over time, is very helpful to being a senior engineer.

Fundamentals and the Career-as-a-System

A hard requirement on fundamental knowledge for hiring is extreme. The aforementioned developers who didn't know SQL were able to learn it quickly enough. You can't stay working as a developer for too long without building the skill to learn quickly. If we'd required them to know SQL in order to get hired, we've have missed out on some great developers. It would've been a mistake.

That said, fundamentals can work the other way during hiring. If someone has a lot of Django experience, but you are a Rails shop, they could demonstrate a firm grasp of fundamentals as way to give confidence they could adapt.

As for your career, find a way to understand the stuff on which your stack is built. Then, keep up with changes in those foundational technologies. You don't want to be 100 lines into a modal dialog only to find out the <dialog> tag exists and does almost what you want for free.

12 Factors Revisited - Dev/Prod Parity

I still do want to keep revisiting the 12 Factors. Dev/Prod Parity is basically saying that there should be few differences between how dev works and how production works. Features should be shipped quickly, developers should be involved in deployment and operations, and supporting services should be identical (i.e. if you use Postgres in production, you run Postgres locally).

I do remember when this was a wild idea, but in the last 13 years, this factor is so obviously superior that it feels axiomatic. There are fundamentals I didn't even know about that I only learned being on call for an app I worked on. There's feedback you can only get about your code when you are shipping it quickly.

And, as for dev environments, I can tell you that it's never been easier to maintain a dev environment that is nearly identical to production as it is now. Docker is fundamental knowledge that everyone would do well to learn about.

Unless otherwise noted, my emails were written entirely by me without any assistance from a generative AI.