When you begin programming, all of your problems will be of the form "how do I get my program to do X?" and all of your answers will come from stack overflow or similar. You will build things by example, and that's fine: in fact it's great for your motivation because you'll be able to achieve some impressive things, so definitely don't try to skip this step!
But at some point you won't be satisfied with just doing things that other people have already done before, or you'll want more control, or be unhappy with some aspect of the approach people before you have taken. Or maybe you'll just be curious: "I know this code let's me draw a circle... but how exactly does it do that?".
At first, this will be hard because the "how" is often quite complicated. You'll have to force yourself to understand a lot of things that previously you didn't, but you'll also see why certain things you've tried in the past didn't work. This is where you learn the difference between what is easy and what is hard. You'll start to properly plan a project out before just diving in.
Later, you'll get used to processing the complexity of "how" things actually work behind the scenes, and then a strange thing will happen. Instead of seeing complexity and thinking "that person must have been a genius to come up with that", you'll see something and think "wait a minute... what idiot wrote that".
You'll suddenly find that every codebase you dig into is a steaming pile of garbage under the surfacce, and you can't bear to build anything on top of it. Congratulations, you now have NIH syndrome! You'll try lots of different languages, technologies, etc. and although they'll all be a disappointment in one way or another, you'll learn a ton in the process.
After that, there are fewer dramatic step-changes. It will just be several gradual changes:
- Some (although definitely not all...) of those things you thought were garbage turn out to actually be well motivated.
- Your focus will shift from the code itself, to more abstract engineering ideas. The coding part will just be automatic at this point, but you'll be thinking about things like backwards compatibility, ease of use, scale, performance, etc. more and more.
- Motiviation will be a bigger problem. You'll have the mathematicians problem of knowing in so much detail how to do something that actually doing it is just... uninteresting.
The only way to progress through all of this is to keep programming, keep reading other people's code, and keep learning.
But at some point you won't be satisfied with just doing things that other people have already done before, or you'll want more control, or be unhappy with some aspect of the approach people before you have taken. Or maybe you'll just be curious: "I know this code let's me draw a circle... but how exactly does it do that?".
At first, this will be hard because the "how" is often quite complicated. You'll have to force yourself to understand a lot of things that previously you didn't, but you'll also see why certain things you've tried in the past didn't work. This is where you learn the difference between what is easy and what is hard. You'll start to properly plan a project out before just diving in.
Later, you'll get used to processing the complexity of "how" things actually work behind the scenes, and then a strange thing will happen. Instead of seeing complexity and thinking "that person must have been a genius to come up with that", you'll see something and think "wait a minute... what idiot wrote that".
You'll suddenly find that every codebase you dig into is a steaming pile of garbage under the surfacce, and you can't bear to build anything on top of it. Congratulations, you now have NIH syndrome! You'll try lots of different languages, technologies, etc. and although they'll all be a disappointment in one way or another, you'll learn a ton in the process.
After that, there are fewer dramatic step-changes. It will just be several gradual changes:
- Some (although definitely not all...) of those things you thought were garbage turn out to actually be well motivated.
- Your focus will shift from the code itself, to more abstract engineering ideas. The coding part will just be automatic at this point, but you'll be thinking about things like backwards compatibility, ease of use, scale, performance, etc. more and more.
- Motiviation will be a bigger problem. You'll have the mathematicians problem of knowing in so much detail how to do something that actually doing it is just... uninteresting.
The only way to progress through all of this is to keep programming, keep reading other people's code, and keep learning.