The hard part of programming isn’t how you do something, it’s why you do something the way you do.
So when the problem isn’t how you’d go about writing the language of your program, it becomes one of why should I write it like this. This is the kind of thing programming is full of, and there’s no indication when you’re writing something that there might be a reason for doing it in a different way. It’s also very rarely mentioned in programming tutorial books above a basic outline.
To go back to my previous example (and it’s a classic one in learning a language), the if/else statement is used to check a condition and then decide on an action to take. Likewise, the switch statement will check the value of something and then decide on an action to take depending on that value. You’re told early on that if you have many possible conditions, then you’re better off using switch than if/else because a) it’s easier to follow the program flow and b) it’s faster in execution. This is all good stuff.
Another good example is being told to split your classes out into different files. You could put everything in one file (and even one class), but splitting them out makes things easier to navigate and encourages you to think a bit more about the structure of things.
But take a more complex idea, like why should I use dependency injection and inversion of control to pass in objects to my classes rather than instantiating them within the class. These are some big old words we’re throwing around here. Things you won’t be told about in a course or book (at least until the more advanced, technology specific ones). But equally it’s one of the most important practices I use in my day-to-day work. Something which simplifies the code I have to write and maintain, and makes me more productive. It’s understanding concepts like this which are the real achievement in programming, far more than just being able to churn out lines of code. And it’ll come to you with time and practise.
So my suggestion to you is this; don’t ever stop reading. Even when you finish a tutorial book, carry on with another one. Something related. Something completely different. Either one could contain that valuable fragment of knowledge which could save you time, money, or headaches. Look for articles and blogs online about the kind of thing you’re working with and see what they’re doing to solve their code problems. You’ll come across stuff you’ve never seen before, and more often than not you’re going to read it and have a eureka moment when you suddenly realise how it all falls into place. Mess around with that idea in your own projects. Create neat little applications that you can use to practise with it, even if you just stick it in a folder somewhere afterwards and never use it again.
Knowledge is power.
Practise makes perfect.
Remember these two things and you’ll be a more effective programmer in no time.
As a sub-note, I’d like to give a list of concepts which I wish I knew about (even just in name) when I first started coding. However I realise this post is getting long as it is, so I’ll probably follow it later with a more comprehensive one where I can go into a bit of detail on what these things are rather than just name dropping them.