How to upskill effectively, especially with the software design aspect?

Adding on to what Rahul said about concretely measuring your progress, I feel like the main metric here is quite simple: Shipping a software product that doesn't suck.

When it comes to software sucking, there's so many ways this can happen:

For The User

• It doesn't work in all cases (e.g. they have a typo in their input and the flow collapses)
• It's slow (e.g. takes several seconds to load a page due to a slow API call)
• It crashes a lot
• It's unsafe (e.g. bad actors can easily hijack their account)

For The Engineers

• The code is hard to read
• You can't add basic feature extensions without making the existing product collapse
• The code is hard to test
• The code takes forever to build
• It's very easy for another team to break your code due to bad coupling

These are just some examples of how software can suck - System design is effectively the art of doing proactive thinking to minimize the amount of ways your software sucks (there is no piece of software that is great on 100% of axes).

If you can build software where it's hard to tell how it sucks and your software operates at scale, congratulations - You are good at system design. 🙂

Action item: I highly recommend watching our System Design Series course taking a real-world project from Taro and building it out: [Course] System Design Masterclass: Shipping Real Features To Production

It's front-end focused, but a lot of the overall concepts apply to any software project (e.g. checking for messy inputs is applicable to both back-end API development and front-end). You can use the system design doc there for your actual work as well - Just clear out my content and replace it with yours.

That being said, system design isn't something that can be really fully "learned" through studying and reading (it'll get you 25% of the way there max). The system design series I just shared will help (more than almost all online resources as it's very concrete), but at the end of the day you learn system design by, well, going out there and designing systems (i.e. building stuff). After watching the series, I recommend:

• If you're working - Try being more proactive with the work you get assigned. If you get a project that will take 1 month+ to build, definitely try writing a system design doc for it and running it by your teammates for feedback.
• If you can't learn at work - Build side projects! When you build side projects and deeply care about their quality, your learning skyrockets - I break this down in my video here: [Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free. I was able to build several Android apps for fun that got 100k+ users, which is definitely a scale where you need to start thinking about system design: I actually had to refactor some of my apps to be more resilient and scalable.
• Share your projects here - I love system design, so I'm happy to give high-level advice right here in Taro! Let's say you're building a private messaging system (either at work or as a side project), just share that in a question and ask "What are the things I should look out for when designing this system?"

I'll question the premise a bit.

Many engineers often feel imposter syndrome when it comes to system design. In my opinion, the amount of true system design thinking needed for most jobs is pretty minimal. I'd reframe the job to be done as "how can you build intuition around which questions are important to ask?"

I also wonder if you could create some sort of measuring stick for your progress? How will you track if you're getting better at system design? With Leetcode, it's easy -- just answer more problems correctly. But with system design, I'd encourage you to do more interviews (mock or real), or work with someone, to build this skill.

For folks who want to dig deeper into what truly high quality software engineering looks like, I recommend these resources:

• [Course] Level Up Your Code Quality As A Software Engineer
• "How to Learn/Practice Clean Code, particularly by oneself?"
• [Masterclass] How To Write Better Code Faster As A Software Engineer
• [Masterclass] How To Become A Debugging Master And Fix Issues Faster
• [Case Study] Solving A Multi-Million $$ Instagram Bug
• [Case Study] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project

I also highly recommend for folks to attend our upcoming free masterclass around messy/clean code: [Event] How To Stop Writing Messy Code As A Software Engineer