TL;DR; Building good designs is a continuous journey that requires practice,  experimentation and reflection. Look at diagram below. Google the keywords. Practice one thing at a time. Understand patterns and guidelines before using them. when designing and coding to relate it back to desirable properties of good system design. Engage your brain Our journey of awareness of what makes good software And the answer to "what makes a system design good?" is .. drum roll ... it depends. "There is no silver bullet". Even then, there is no perfect design. Theoritcally maybe, but the cost of perfection it so high. So we have a vast body of knowledge that is continuously evolving on this topic in our industry. Whether you learnt a lot of this stuff formally in acamedia or not - it's something that no one ever masters, and it is something we should strive to continuouly reflect upon. Get to the point! : Disclaimer this is a picture of my personal journey which I have been on and will be always growing my entire career. It is not a comprehensive daigram that will stand the test of time, or be effective for everyone. It leans towards an OOP background. Rather than regurgitating the meaning of each topic when there are so blogs and articles covering all these design-related topics and more, I will let you google. A few points from the diagram: aimlessly use design patterns without understanding their intention Don't aimlessly use design principles without understand why they are there to help us Don't allowing specific technology dictate key parts of your architecture - or even at all (notice diagram is void of technology - we dont need to lock into sepcific technologies, and we should defer these decisions as late as possible) Avoid understand the costs and benefits of getting your architecture to acheive desirable properties of system design Do Where to start the journey I would recommend starting at Read around the design topics that underly the principles to gain deeper understanding of why they are their to help us, then work your way up to patterns (or just try your own patterns that satify the principles). SOLID. Experiment and reflect Dont be afraid to experiment - how else do we learn!? Pick one thing at a time and see how yor codebases / systems can improve by applying them. Reflect on your experience and outcome. Code wrangler: "It's not my job to do this stuff" You have a senior / lead architect? It's not all their responsbility: it's everyone's. They are not the gatekeepers of design - these senior roles are just human and are on their journey too.

Google

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Understand the Intent of Patterns And Principles Before Applying Them

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Lessons from 10 Years of AWS (part 1)

10 Lessons from 10 Years of AWS (part 2)

111 Stories To Learn About Architecture

13 Expert Tips to Improve Your Web Application Performance Today

4 Skills You Need to Become a Distinguished Developer

10 Lessons from 10 Years of AWS (part 1)

10 Lessons from 10 Years of AWS (part 2)

111 Stories To Learn About Architecture

13 Expert Tips to Improve Your Web Application Performance Today

4 Skills You Need to Become a Distinguished Developer

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps