Ignore design patterns. In practice, I find that they create a lot of extra code that turns into tech debt. It is occasionally useful to know what the design patters look like, along with the names of those patterns, so you can figure out what the heck that previous coder was trying to do five years ago.

Ignore algorithms. It is very, very rare when you'll be called upon to write an algorithm. Most algorithms you might need are already in your language library(ies). Outside of those cases, there are commonly-needed algorithm that isn't common in language libraries. Stackoverflow or AI will provide the algorithm you need. For example, calculating distance from latitude and longitude.

Systems design is useful, sort of. The problem here is that the tech changes much faster than you can learn it. The standard architecture of the 2000s is vastly different from that of the 2010s, is vastly different from the 2020s. About the only constants are SQL for database and JavaScript for browsers. In particular, security concerns frequently arise that change the landscape. Don't expect to learn recipes. Learn principles.

That said, I find myself recommending these two books frequently in the past week or so:

• A Philosophy of Software Design By John Ousterhout
• The Pragmatic Programmer by Dave Thomas and Andrew Hunt

These books work more like "proverbs" than design patterns. They aren't recipes, they're advice on how to think about how you write code. If writing a script is base-level coding, and using objects is a level of abstraction, and using abstract classes and interfaces is yet another level of abstraction, and using design patterns is yet another level of abstraction on top of that, then these "proverbs" are meta-meta-meta-abstractions.