Programming

I loved my course on patterns. It was tough, but I now regularly feel like I can apply mastery of this tricky subject to my software projects. The course used a variety of techniques:

• Read the seminal Design Patterns book by Gamma et al., for an overview of the concepts.
• Every week, we'd incorporate three patterns into a preexisting XML processor project. My final one had like 25 patterns, which was challenging to keep working amidst refactoring. (You don't have to do them cumulatively, but I enjoyed it.)
• We'd have to ask pattern-specific questions of our classmates in forum threads; and occasionally we'd be assigned to answer some.
• We each wrote up our own pattern. (I designed one based on my experiences handling data exchange between web apps and clients.)

Together, this taught us

• How the patterns could concretely look in practice.
• Pros, cons, and other considerations for each.
• Similaraties, differences, and nuances. (We'd joke that everything was the Template pattern if you squinted.)
• The impact of modifications to the patterns.
• How to recognize, create, hone, collaborate on, and share patterns.

I appreciate this approach because patterns are an inherently fuzzy subject.

how would I go around learning about different design patterns and approaches to problem solving if I don’t know about their existence in the first place?

Read, and try things. A lot. Read books, read articles, read forums, go to conferences or watch videos from conferences. And try things - do small projects at home, do large projects at home, work in multiple projects at work, if you can. In all these projects, try various things. See how good or bad they are.

There really isn't any shortcut for this. This is why experience is so valuable and sought after. There is no replacement for it.

for example say I need to create a system for inserting a large amount of data from files into the db

Read about how others have done it, and how it worked for them. Ask colleagues, if you have some which did this before. Remeber how you did it (if you ever did it before), and how it worked out for you. Try some prototypes, and see how they work. These are the strategies most people use.

Design patterns are typically just workarounds for the limitations of the chosen programming language. What you might consider a pattern in C might just be a simple language feature in C++, and the patterns in C++ (as popularized by GoF) might just be language features in Lisp/Rust/whatever.

So rather than thinking about patterns, you should first choose the right language for the task. If you're working on a parser, you might prefer Haskell. If you need formal verification, there's C and Idris and little inbetween. If you need to hire lots of developers, something widely-known like JS might be the choice.

After you've chosen a language, you can identify the things that the language is bad at and apply the appropriate design patterns. Sometimes the patterns can be found in books (C++, Java) and sometimes it's just tribal knowledge (D).

Is it just a matter of proactive learning and I should know all of them in advance, as well as their uses?

Yes