I majored in Computer Science because I was obsessed with learning how things worked “under the hood.”
I also liked building stuff, sure. If you got into a time machine and traveled back ten years, you’d find eleven-year-old me making my first forays into photo editing with Photoshop knockoff software and DIYing jewelry based on cool stuff I’d seen on the Internet. Programming is like like doing arts and crafts with an understanding of how complex systems work.
But I was never satisfied with just making stuff. I wanted to know why code ran the way it did, how integrated development environments (IDEs — the place you write and run your code in) were built, how they could autocomplete and highlight syntax, and how people figured out how to put all the stuff together.
My never-ending curiosity annoyed a lot of my software engineer friends; they just wanted to build stuff and learn on the go. “You’re too academic,” they’d complain whenever I stopped to ask a “why” question or spend an hour going down some obscure language-specific rabbit hole. “Just get the damn thing working.”
I learned to embrace the just-get-the-damn-thing-working approach for my job and prioritize shipping product, but I also remained “academic” at school, where I spent hours poring over my textbooks and eating up all of the conceptual stuff. There’s something really peaceful about sitting alone in a quiet place with a knowledge source (like a textbook or your laptop), reading and taking notes at your own pace, and coming out of the Zone feeling like you finally understand something.
This may seem like a waste of time for someone who wants to be a professional software engineer — a SWE’s objective is to write code as cleanly as possible, make their software work according to specifications, and ultimately ship products that users want. Software engineers embrace the practical, not the theoretical, and do good amount of learning on the job as they develop the product.
However, I found that although my conceptual knowledge certainly didn’t replacing the need to learn things on the job, it made me a lot more comfortable looking at complex problems and figuring out where to start. I could listen to two senior engineers having an abstract mathematical conversation and be able to follow along. And (this is my favorite part) I made some of my best friends today from lines at various conferences and events, where we’d nerd out about certain parts of our favorite languages and algorithms. Thanks to the theory I absorbed, I was able to see both the forest and the trees, and had an extra way of connecting with others who were equally passionate about computer science.
One of my favorite topics of conceptual study was Operating Systems. The operating system is what enables a computer to carry out all of its tasks, coordinating the programs on your computer with the hardware that they need to run. The OS course at my school is an elective recommended for people who are interested in systems or low-level programming. If not for my voracious curiosity about the inner workings of computers, I wouldn’t have thought that I needed to learn about operating systems at all.
I’m so glad I did — immersing myself in the study of operating systems was like opening a black box that answered a good amount of my core “why” questions. I learned about storage management and concurrency (instances of programs running at the same time), deadlocks (when multiple programs  are sharing resources and effectively blocking one another from being able to use them), and the multiple levels of complexity required for an OS to function properly.
Although they’re somewhat removed from my “practical” duties as a software engineer, these things are crucial for any computer scientist or programmer to understand. Like, okay, you may not have to know what a hypervisor is or be able to implement resource-allocation algorithms, but a sound understanding of multithreading should definitely be in your developer toolbox. 
Anyway, I thought that the things I learned in OS class were really interesting, and wanted to share them with you in a new Operating Systems blog series. Now that I’m back at school, I’m getting back into learning by teaching. Although a programming background is always a plus, you won’t need any knowledge of programming or computers to follow along. This will be a strictly conceptual series, and I’ll define and explain things as we go along. I’m expecting to publish at least one post a week, most likely on Thursdays. I’ll let you know if things change in the future; check back often to see new updates.
Even if you aren’t planning on writing code ever, you probably use a computer pretty frequently (what are you reading this post on, anyway? — yes, smartphones do count as mobile computers). Wouldn’t you like to know how your devices work?
 Technically, this should be multiple processes (a process is an instance of a program running on the computer), but I didn’t want to overwhelm anybody with excessive jargon on an intro post. I’ll get into all of these differences in the actual series!
 Flashback to my first software engineering internship, where if a chunk of code wasn’t working, I simply pushed it onto the main thread without knowing why 🙃 Yikes.