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
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