HACKER Q&A
📣 jjice

How can I learn to design software better?


I can write code just fine, but I feel like one of my biggest draw backs is not having a formal understanding of how to design a large piece of software. I can draft a piece of software, but when it comes it implementing it, I feel like my solutions could be much better after they're done. I often find myself having to change more code than I feel I should when I add a new feature in the future.

How can I learn to better design software? Any book recommendations or general tips?


  👤 davismwfl Accepted Answer ✓
How many years have you worked professionally? Do you have a team (or tech friends) to bounce things around with and learn from? What are you writing, websites or IoT or ??

Just some general comments not knowing those answers, this is usually what a mentor or team lead is there to help you with, they guide you and show you why one solution might be better than another etc. Read architecture blogs, read about failures as much as successes, read postmortems from startups they are great learning. Seriously study well design open source software that most people agree is done well, as well as bad. Studying both will show you patterns you are using and shouldn't be or ones you aren't using and should be etc. That is honestly the best way, open source software makes studying larger systems so much better today then when I was learning.

I do suggest you study some of Fowlers teachings/books https://martinfowler.com/ as he IMO is well balanced and sees value in many different architecture styles based on the problem you are solving. There are others of course, but he is the first that comes to mind for building larger or more complex systems.

The goal of software design/architecture is to use the least complex solution you can to solve the problem, that makes the software the easiest to maintain and usually makes it performant. There are exceptions of course, but that is the general rule I follow. Also, minimize unnecessary external dependencies which will also keep your code easier to change and maintain, the more external dependencies the more chance a simple change turns into touching larger sections of code.

Last point, we all look back and problems we have solved later and are like geez, I was an idiot I could've done XYZ instead of ABC and it would have been a lot better. That's normal and is a sign to me that I am continuing to learn, which is good IMO. There are only a few things I look back on and say damn that was perfect and I wouldn't change a thing about it (very few).


👤 the_hoser
It comes with experience. Those times you find yourself changing code more than you think you should? Analyze the decisions you made (or that a co-worker made) that got you there. Figure out what you could have done differently.

Books are great, but nothing beats lessons learned by making mistakes.


👤 karmakaze
Two things come to mind. (1) work on large software projects that have been in production for many years. This will show you patterns that have emerged to solve issues that have crept up over its lifetime. (2) except in specific cases a large piece of software grew from a working smaller piece of software. Learn different ways of being prepared for future features and adding features. YAGNI is important too. Practice, lots of practice. Reading without practice is like watching a movie and nodding along, quickly forgotten if not committed through habits.