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?
Research what other people have done, to be honest.
Most of the time, I find a library that does it for me so I use that.
Then I might run into limitations of that library… so I either extend/wrap it, reimplement it myself following a similar pattern (but how I want it), find a similar library that doesn’t have the limitations, or learn that the way the library implements it doesn’t work for me and try something else.
And all of this contributes towards my experience. Recognising the shape of a problem when starting to work on something, and having experiences using patterns that fit that shape.
It really is a time to be standing in shoulders of giants for a lot of the work. Either find a library, or figure out what other people have done.
I would bet that only really low-level stuff and cryptography are implementing any “new” code.
Everything else is just glue.
For example, right now I’m doing some embedded systems work. I found a project that does something similar, so I learnt from it and implemented something similar.
I’ve worked out the main parts of the system, and I now realise it’s a bunch of state machines where the logic for transitioning between states is more important than what happens in a state (in the states is fairly straightforward, but the transitions are confusing and where the bugs are going to happen).
So now I’m looking at some libraries for how a FSM can be nicely implemented in CPP, and I’ll probably draw from a few examples to get my own working.
But something that I had originally built as a stitch-together of functions, turned into many complex switch statements, and will now hopefully turn into some elegant, descriptive and abstracted-away state machine.
Yeh, I could probably have predicted it would be an FSM from the start. But I didn’t know that, I didn’t even know if the project was viable, and I don’t do much embedded systems programming.
The similar projects I drew reference from were hobbyist and a mess.
So, now I have a little more experience to think “is this an FSM” when it comes to embedded systems, and whether I want to go with switch statements, or if I go for some fancy system to make the transition logic easier.