Application programs don’t talk to the computer hardware directly; that’s where system
programming comes into play. System programmers make the building blocks used by application
programmers. System programmers need to know about hardware because their code interacts
with it. One of the goals of this book is to teach you things you need to know in order to be a good
system programmer.
Computer hardware includes not only the part that does the actual computing but also how that
part connects to the world outside. Computer hardware is expressed as logic. It’s the same logic
used to write computer programs, and it’s key to understanding the workings of the computer. The
logic is constructed from various types of electronic circuits. Circuit design is beyond the scope of
this book, but you can learn more about it by studying electrical engineering. Consider a double
major in electrical engineering and computer science if you want to rule the world.
Of course, basic science underpins it all, providing everything from our understanding of electricity
to the chemistry needed to create chips.
As shown in Figure 1, each level builds on the one beneath it. This means that poor design choices
or errors at lower levels affect everything above. For example, a design error in Intel Pentium
processors circa 1994 caused some division operations to produce incorrect results. This affected
all software that used floating-point division in these processors.
As you can see, system programming is at the bottom of the software hierarchy. It’s similar to
infrastructure, like roads, electricity, and water. Being a good programmer always matters, but it
matters more if you’re a system programmer, because others rely on your infrastructure. You can
also see that system programming is sandwiched between application programming and computer
hardware, which means you need to learn something about both of those. The Sanskrit
word yoga translates to “union,” and just as yoga practitioners seek to unify their mind and body,
system programmers are techno-yogis who unify the hardware and software.
You don’t have to learn system programming in order to work at one of the other levels. But if you
don’t, you’ll have to find someone else to help you deal with issues out of your domain rather than
being able to figure them out for yourself. An understanding of the core technology also leads to
better solutions at higher levels. This isn’t just my opinion; check out the 2014 blog post “The
Resource Leak Bug of Our Civilization” by Ville-Matias Heikkilä for a similar view.
This book also aims to cover a lot of retro history. Most programmers aren’t learning the history of
their craft because there is so much material to cover. The result is that a lot of people are making
mistakes that have already been made. Knowing some of the history allows you to at least make
new and better mistakes rather than repeat past ones. Bear in mind that the hot new technology
you’re using today will quickly become retro tomorrow.
Speaking of history, this book is jam-packed with interesting technologies and the names of their
inventors. Take some time to learn more about both the technologies and the people. Most of the
people mentioned solved at least one interesting problem, and it’s worth learning about how they
perceived their world and the way in which they approached and solved problems. There’s a great
exchange in Neal Stephenson’s 2008 novel Anathem:
“Our opponent is an alien starship packed with atomic bombs. We have a protractor.”
“Okay, I’ll go home and see if I can scrounge up a ruler and a piece of string.”
Note the reliance on fundamentals. It’s not “Let’s look up what to do on Wikipedia” or “I’ll post a
question on Stack Overflow” or “I’ll find some package on GitHub.” Learning to solve problems that
nobody else has solved is a crucial skill.