Build a simple database, a simple interpreter, and a simple web application (backend and frontend). Read about “distributed systems”, “devops”, “Conway’s Game Of Life”, and “fractals”. Read about these technologies/techniques (in whatever order is comfortable), how they work, their pros and cons, why they were created, how they compare to alternatives: “TCP”, “Open Sound Control”, “Plan9”, “REST”, “Lisp”, “Erlang”, “Smalltalk”, “Forth”, “Datomic”, “event sourcing”, “reactive programming”, “communicating sequential processes”, “APL”/“J”/“K”, “Ansible”, “jq”, “graph databases”, “Apache Kafka”
The idea is not to become an expert in any of these, but to digest the wisdom that lies in their design and surrounding literature. Each was created after lots of careful thought by brilliant people about how to build sustainable systems.
This is how it worked out for me. I tried to build the system myself and note the abstractions, edge case. It didn't make me an expert in all things but gave me the right questions to ask. As you do enough of these your expertise will crystallise in a particular domain.
Started by building my own build system, monitoring solutions, taking at stab orchestration problems, graph databases etc.
The problem statement would be super simple like how do I install my application on 100 servers? And I will start off with bash, tar, ssh and work my way up.
The goal isn't too finish. You want to discover the problems first hand, decide upfront how you would evaluate an acceptable solution, attempt a naive solution, and then look at an open source system, note the family of algorithms + data structures then loop back and move onto the next set of problems in the domain.
Ideally the system you're building is distributed.
Mostly I work from the outside going in and counterintuitively I start with the two non-functional requirements, as questions: how fast do you want it to go, secondly how badly can the system fail. I find that I'm peculiar in this approach.
This won't work for everyone. It has for me because it's allowed me to build a handy library of interrogative and evaluative heuristics and develop strong understanding system architectures and design
Huh? I currently work with some of the technologies you mention, but fail to see the connection to systems theory. Can you elaborate why e.g. jq or Erlang are relevant here?
- There is general systems theory [0] and within that systems engineering[1] where you will find software systems [2]
- OP is most likely talking about how to use of general theory of systems in different domains and not specifically software systems.
- If one considers JQ, SED and "One input stream, one output stream" and then compares that to a model of a system using a CLD (Causal Loop Diagram). A CLD is effectively "An input, followed by an output"
- Another word that could be used for "input stream" would be 'flow' from system dynamics [3]
- One could apply general systems theory (the abstract concept) to just about anything
Yes this is how every Unix command line utility works.
There is nothing unique about jq in this regard, and there is nothing particularly “systems thinking” about any of them. You can and people have used them for decades without doing any special “systems thinking”.
The Unix model is really useful in my systems thinking precisely because thousands of components all use the stream in/out approach. This made then reliable within a system to be used together in many different combinations and interactions.
Also a good example of loose coupling that allows for good thinking of systems.
I took your "e.g." to mean inclusive of jq and Erlang, but extensive to the entire list. What I said applies to Erlang, OSes, and LISP, but maybe not to jq (I wouldn't know).
Missing the thing that has had the single biggest impact on how I personally think about programming: Learning a properly typed language (e.g. Haskell).
I'd also substitute Ansible with Nix/NixOS because the conceptual takeaways are much greater there.
An absolutely _fantastic_ book. It was also one of the scariest books I've read recently. Made me realize just how much I don't know (and don't know that I don't know!) about the failure modes of distributed systems.
Careful with that word ("ACID"), it's ridiculously easy to get screwed by the filesystem arbitrarily lying about things like the order of system calls: https://queue.acm.org/detail.cfm?id=2801719
If you are a software engineer:
Build a simple database, a simple interpreter, and a simple web application (backend and frontend). Read about “distributed systems”, “devops”, “Conway’s Game Of Life”, and “fractals”. Read about these technologies/techniques (in whatever order is comfortable), how they work, their pros and cons, why they were created, how they compare to alternatives: “TCP”, “Open Sound Control”, “Plan9”, “REST”, “Lisp”, “Erlang”, “Smalltalk”, “Forth”, “Datomic”, “event sourcing”, “reactive programming”, “communicating sequential processes”, “APL”/“J”/“K”, “Ansible”, “jq”, “graph databases”, “Apache Kafka”
The idea is not to become an expert in any of these, but to digest the wisdom that lies in their design and surrounding literature. Each was created after lots of careful thought by brilliant people about how to build sustainable systems.