How to become good at system design? if I don't have hands on experience on designing large scale applications How can I be good at it? Any open source projects for the same or the books/videos..Thanks |
How to become good at system design? if I don't have hands on experience on designing large scale applications How can I be good at it? Any open source projects for the same or the books/videos..Thanks |
https://www.youtube.com/c/SystemDesignInterview
https://www.educative.io/courses/grokking-the-system-design-...
System design is, primarily, a way of thinking -- identifying how given things are actually connected, thinking through how they are connected, what happens up and down those connections as things change. Software systems are just one particular example of this (and, as a bonus, when you start to include non-software parts, such as the humans actually using the software, your software system design will be stronger).
I'm sure others will cite this too, but I don't see it yet at the time I'm writing this, so for a specific book let me recommend Thinking in Systems by Donella Meadows[0]
[0]https://www.chelseagreen.com/product/thinking-in-systems/
Or another way to try and explain it -- you can't keep everything in your mind's "RAM" -- when trying to think systematically, you need to offload the details onto disk for later retrieval. Don't throw them away! People who are "vision people" and brag about not sweating the details become really annoying to work with as a software engineer -- but you won't be able to grasp the system if your mental RAM is cluttered up with those details all the time.
Have you any thoughts, books or resources you turn to, to make sure the whole pipeline is balanced - or doesn't fall over when one part is overloaded?
Back pressure is refusing to let the queue unbounded or take in more requests than slots available. That's pretty much it.
After some initial reading try to get your hands dirty with any large scale application you can get access to.
Check out some of the free videos on our site[0] and YouTube channel.[1]
don’t rely on interviewing people to test yourself. you have to practice talking or writing and stop settling with the feeling that you just learned something and will have the judgement to know when to use xyz when problem abc comes in front of you.
i built enumerable.co so that i can evaluate myself, to practice producing the knowledge i’m consuming, and reach the edge of my understanding.
there’s no database and i built over a few days, so it’s just a single player way to figure out how much you really don’t know
Use formal API definitions.
GNS3.
Docker.
Remember that large scale, complicated systems that work invariably start out as small simple systems that work, so build it virtually first, where you can break and re-build to your hearts content.
I learned that it was wrong to casually point a firearm at someone before I had the experience of firing a gun. I also first learned to direct my visual focus to the front sights. Knowing that rule enabled me to then gain more nuanced skill and helped me avoid building bad habits.
After 8 years in the software industry, I dearly wish that I’d been able to find such guidance about software estimation when I was starting out. At this point, I’m going to need some sort of therapy to be able to give software estimates.
But its subtle things that make all the difference between average and really good in something, these ones you can’t really learn without gettyhands dirty and making own mistakes. Even though often it seems different looking backwards, but it’s nothing more than a curse if knowledge.
I strongly agree here. It was the subtle things about breath control and muscle-tension control were what I learned while practicing marksmanship.
It is simultaneously true that a person starting out can sometimes see they need guidance to learn the 'trivial common knowledge' that others in a field are already familiar with. These things that seem 'trivial' to experts are things that help them avoid the "many ways to fail at getting good at something while doing it a lot."