I’ve tried studying CSa d programming, both formally and informally, for long enough to know most of what y’all are talking about, but failed terribly enough that I still have no idea how people can actually build code. Syntax is easy enough, I always started a class like oh cool I can do this. And then they drop me off the deep end and I fail, every time. I work in IT infrastructure now and I’m happy to say I never have to worry about coding, though my foundational knowledge is useful for troubleshooting.
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).
I’ve tried studying CSa d programming, both formally and informally, for long enough to know most of what y’all are talking about, but failed terribly enough that I still have no idea how people can actually build code. Syntax is easy enough, I always started a class like oh cool I can do this. And then they drop me off the deep end and I fail, every time. I work in IT infrastructure now and I’m happy to say I never have to worry about coding, though my foundational knowledge is useful for troubleshooting.
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).