I see this often with both new and old developers, they have one way of doing a thing and when presented with a new problem they will fall back to what they are used to even if it's not the optimal solution. It will probably work if you bruteforce it into your usual patterns but sometimes, a different approach is much easier to implement and maintain as long as you are willing to learn it, and more importantly - know it exists in the first place.
On a less abstract level, I guess my question is - 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? Is it just a matter of proactive learning and I should know all of them in advance, as well as their uses?
Let's for example say I need to create a system for inserting a large amount of data from files into the db, or you need to create some service with many scheduled tasks, or an user authentication system. Before you sit down and start developing those the way you usually do, what kind of steps could you take to learn a potentially better way of doing it?
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).
Maybe I'm using the word pattern wrong but I meant like builder, factory or visitor pattern, but on a more wide scale also stuff like dependency injection / IoC - basically "techniques" that are not bound to a specific language but rather provide a design by which some things can be accomplished better. Afaik those are not related to specific languages
I would call those language-specific. While they are useful in more than one language, they are also replaced by language features in many languages.
It's more like languages evolved to incorporate the most common idioms and patterns of their ancestors. ASM abstracted common binary sequences. C abstracted common ASM control structures and call stacks. Java leaned hard on object orientation to enable compositional and inheritence-based patterns widely used in C and early OO languages. Python baselines a lot of those patterns, and makes things like the Null Object pattern unnecessary.