How to get better at the "design" part of System Design

Honestly most of my improvement outside of coding skills has been repeated pratice in a broader group. For system design, I started with:

• Asking questions on other people's docs on how does X work or why did we pick Y
• Then I started asking could we do Z instead once I felt like I got the hang of things. Example: whenever service A needs to talk to service B, I usually ask could Kafka work for this.

I also try to design systems to be simple. My prioritiy is breaking down the system into a hierarchy of smaller pieces (needs to be small enough to describe in 1 phrase or 1 word). Ideally I'm going for a structure like somewhat balanced tree or a list. Then I focus on the implementation of each piece.

Good question! I highly recommend going through this related discussion: "How to upskill effectively, especially with the software design aspect?"

You are 100% correct in that system design is very different from DSA when it comes to evaluation and improvement. DSA is pretty cut-and-dry. System design is super fuzzy. When it comes to system design, there are 2 main ways to get better:

1. Ship stuff, observe - It is impossible to ship perfect software, but it doesn't mean we shouldn't try. As you're building, especially in the very beginning of your career when you're bad at system design, your end product will inevitably have problems. Edge cases will be missed. Performance can lag in some places. Code will be hard to scale. Users will complain. Heck, maybe even the "observe" portion will teach you system design as you realize your system has poor observability! Care deeply about those problems and try to fix them with long-term solutions. This will lead to changes in how you write code at a high-level, thus making you better at system design.
2. Learn from others - #1 can take a while, especially if you don't have a lot of support. The "simplest" way to learn system design is to have more senior teammates and be deliberate about planning your code and architecting systems. Make a nice design doc every time you have a meatier project and get feedback. This osmosis process is much faster than #1 as it saves you time: Your teammates will prevent you from making the same mistakes they did.

#1 and #2 are both very important. #1 generally yields the deepest learning as it's the most hands-on. However, #2 in particular is important as you need company/org-specific context for system design. What's good system design in one company could be terrible in another. It's important as an engineer to flow like water and adjust to where you are working.

In terms of measuring your progress with system design growth, it's also relatively straightforward:

1. For the "YOLO, let's ship and see what breaks" learning method, you will notice that your stuff starts breaking less and getting less user complaints.
2. For the osmosis method, you will notice that your system design docs get less and less negative/constructive feedback over time while getting more and more positive feedback like a Staff Engineer telling you that your approach is exactly the same as how they would build it.