It’s all about experience IMHO, just start small projects (and in my experience ignore all these “design patterns”, I learned quite a lot of patterns, but I’m not really using any of them nowadays, maybe sometimes intuitively, (as this thread shows, “dependency injection” which can be a fancy term for generic function parameters).
Well maybe learn them, but take everything with a grain of salt, I think. Intuitively thinking is often better (with the drive to do it better). Try to write code such that it’s easily readable exactly focused on the problem that it’s trying to solve, not anything fancier (this is actually a very simple but effective Mantra). Otherwise it often leads to overengineering (all these “design patterns” for example…), or premature optimization.
(E.g. something like the popular book “Clean code” is IMHO full of antipatterns, like the examples are definitely not something I would do, they are inefficient, boilerplate, and often make the code unreadable).
It’s all about experience IMHO, just start small projects (and in my experience ignore all these “design patterns”, I learned quite a lot of patterns, but I’m not really using any of them nowadays, maybe sometimes intuitively, (as this thread shows, “dependency injection” which can be a fancy term for generic function parameters).
Well maybe learn them, but take everything with a grain of salt, I think. Intuitively thinking is often better (with the drive to do it better). Try to write code such that it’s easily readable exactly focused on the problem that it’s trying to solve, not anything fancier (this is actually a very simple but effective Mantra). Otherwise it often leads to overengineering (all these “design patterns” for example…), or premature optimization. (E.g. something like the popular book “Clean code” is IMHO full of antipatterns, like the examples are definitely not something I would do, they are inefficient, boilerplate, and often make the code unreadable).