Abstractions and Systems -- Part 1

Fall 2009, I was sitting in my dorm room at LUMS. It was sophomore year and I had just declared Electrical Engineering as a major. I was excited to learn about circuits! Curious to understand what else is out there, I found a wonderful resource online, OCW.¹

I found 6.002, an introductory Circuits and Electronics course. The lecturer, Anant Agarwal, in the first lecture, talked about the concept of “Abstraction” in engineering and sciences. He then went on by giving some examples, focusing more on electrical systems.

The concept of Abstraction, although seemingly simple, was fascinating. It was how you reason about large systems. It provided a framework to think about these systems. It meant that magic could be understood. It made me think that things were easier than I thought.

As I grew, I went from an EE undergrad, to a EE grad, to a compiler engineer, and to as things stand today, a distributed systems engineer. At each stage, I found the power of Abstraction. From modeling physical control systems, to understanding how a RF radio works, to how LLVM and GCC compile code, to making web services platform centric, to crafting solid APIs, to studying large scale systems like Kafka, etc.

This experience led me to think in terms of systems – in other words, I grew into a “Systems Thinker".

But here, in these posts, I aim to cover common Abstraction patterns that I’ve seen in my career. I’ll focus more on the software systems that I’ve worked with. I’ll present practical examples, and in each case, talk about how adding Abstraction solved common pain points. Spoiler: There’s a cost to Abstraction, like really anything else in engineering. So I’ll discuss that cost too, in the context of those examples.

Stay tuned for Part 2!