Embarking Into Systems

I've always had an odd fondness for the concept of a system.

At some point, as I child, I stumbled across a definition of 'system', that seemed to describe everything.

• Faced with the choice between:

• a

  - This definition of a system is wrong.

• b

  - Everything is a system.

I chose (and still choose) the latter, so I've had a healthy personal relationship to systems for a while, looking at scales as systems for producing melodies, music groups as systems for producing, well music, and on a more colloquial level, gaming 'systems', which we unknowingly referred to with an incorrect bifurcation: by system, we meant the games, discs, culture and canons, but we weren't really thinking about the actual mechanical/software systems that underlaid them, or we discarded them as entirely separate (yet still somehow appreciating resolution quality, backwards-compatibility and framerate).

So, with this background, you can imagine my surprise, after venturing into programming, at finding out that there existed a whole school of thought for thinking about, analyzing and creating systems, and all this, related to their inputs and outputs too. I also felt (and still feel) rather validated about a way of thinking that tended to come off as peculiar, or perhaps unnecessarily detailed to others- often being told by adults to 'get to the point', and made to feel as if my explanations 'touched on too many things'. Neither me nor the adults, friends, or coworkers I was around realized that I was trying to wrangle with, and reduce the complexity of some (sub) system, be it social, circumstantial or operational, that generated some output, which was undesirable, or at least, in question, and complexity is one of the hallmarks of systems- something I unknowingly appreciated about the vastness of the things I pondered, or was tasked with pondering.

Anyway, since I don't remember that specific definition, we'll have to make do with Wikipedia's:

A system is a cohesive conglomeration of interrelated and interdependent parts which can be natural or human-made. Every system is bounded by space and time, influenced by its environment, defined by its structure and purpose, and expressed through its functioning. A system may be more than the sum of its parts if it expresses synergy or emergent behavior.

This, while more verbose than the definition that changed my thinking as a kid, is pretty much the perspective from which I am most comfortable approaching things, because I think it's the most 'zoomed out' perspective you can take on anything, and many things, like the elephant, become dangerously unrecognizable if you look too closely.

Now, having swan dived into tech, I'd read about many sub-types of systems, mainly operating systems, decentralized/distributed networks, and database management systems, but it wasn't until March of this year, when I started studying for my AWS Cloud Practitioner certification (which I earned last Thursday, w00t!), that I began to really explore the abstract concept of systems- I was looking for resources for passing Triplebyte's interview, and stumbled onto The System Design Primer.

The repo opens up with a really fantastic diagram, that I immediately felt could map onto many things, could be useful for designing any system, even though the nodes were labeled with technical terms, those technical terms had corollaries in other fields, and domains, and I decided it was time to formalize my relationship with systems- there's a lot of jargon, systems design, systems engineering, systems architecting- I didn't and haven't spent much time delineating the nuances between them. I decided to focuse on being able to build, maintain and think about complex systems, in a very abstract sense, feeling that the context in which I found myself donning any of these given roles would provide clarity about their nuances.

Studying AWS, to me, qualifies as the study of a complex system, as the components of AWS are certainly systems in their own right, and building a cloud-computing solution qualifies as a architecting a system, so I took very specific notes on the technology, but tried to abstract away a lot of that specifity in my thinking, in terms of what I walked (or wanted to walk) away with- being able to think in (distributed, complex systems) of which AWS is only one, and is simply the exemplary tool with which I started my journey and began building my foundation in systems thinking, or theory (I suppose if I had to pick, it'd be systems thinker/theorist).

Having passed the certification exam, I've gained a lot of confidence about my ability to navigate the world of systems, and have since been working my way through the aforementioned GitHub repo, gearing up to knock out my next certification, along with this one on Resilience Engineering, and working through the late, great Joe Armstrongs paper on Making Reliable Distributed Systems in The Presence of Software Errors, and while I am now remiss that I wasn't aware of his brilliance while he was with us, beginning to grasp why this individual was so respected throughout the software community the way he was, has been it's own joy, as the level of insight and clarity that this paper delivers from the start, is staggering.

I intend to stick to technical systems for the near future, but hope to expand and grow into a systems thinker such that I can apply these techniques to other fields, music, mathematics, philosophy, physics- fields that I feel contain problems, questions, and challenges to large that the only way to approach them is from the point of view of a complex system.

With that being said, I'll leave you with this quote from Joe Armstrong:

At the highest level of abstraction, architecture is a way of thinking about the world.