
Ask HN: How can I learn to design software better? - jjice
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&#x27;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.<p>How can I learn to better design software? Any book recommendations or general tips?
======
davismwfl
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/](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.

