You are exactly right on this description of the the pain that is learning to develop.
Example:
If you want to learn to play baseball. You learn the mechanics of the game. You learn to hit, catch, and throw. You can be an expert baseball player, and you can practice the shit out of mechanics all day long, and play games, and win games all day long for decades.
But if you want to manage a club and win games, you need to take that next step to learning the mechanics of the game beyond playing baseball, or all you will ever be is a player, and you will never be able to actually build a team that wins games.
Telling someone to go practice hitting, throwing, and catching in order to perfect their ability to orchestrate and manage an entire team of different moving parts would sound crazy.
And that is how it sounds when people continually say "just go write, fix, and build."
I do not have an answer for this problem. But, the answers that always rear their heads when this question comes around, have the opposite ideals of how anyone that has taken the time to learn the mechanics of development. Those people that have taken the time and effort to learn the mechanics are mostly those that appreciate clear and concise paths to solutions. And, as far as I know there is not good resource for bridging that big gap between mechanics and craft. I could be wrong, and there could be a wealth of this information on this process stashed away somewhere. But, the problem is that most of these paths are most likely buried somewhere in a course or resource that is shrouded in mechanics, when the learner is just looking for craft.
The person that clearly outlines this path from Mechanic to Craftsmen will undoubtedly be very successful.
I agree with this, but I do think there must be something that we're missing. Many, many skilled developers are saying "just go out there and build." The problem is we don't know how to build.
I think there might be an implied aspect of this that we're not getting. Someone said to (paraphrasing here) "Google every problem you come up against; 'how do I do x with y, how does a work, how do I implement b, etc.'" That seems like it would work--if you Google every problem you have, or look at the docs for every function you use, a pattern will start building in your head that shows you how to do x with y. I think the key here is looking at the core source of the tools you're using and connecting the dots in your head.
I can't relate to baseball but I notice a common pattern that applies to most fields.
You are told to do the basics over & over again so you:
a) Learn the motions
b) Learn how they work
You can't successfully apply your knowledge/tools/skills without knowing what makes them tick.
Let me phrase that with an example from my past. I was big into Starcraft at one point in my life.
Started with SC:BW. I was terrible back then, doing builds like an automaton following a recipe - I lost as soon as someone stepped out of the cannon and did something non-standard. Why? Easy. I had the mechanics but was missing the know-how on what made them work and how to apply them.
Instead of going that route I started to watch better players. They quickly diverged from the builds - enlightenment came when I noticed that they were playing reactionary. They observed their opponents and made decisions.
Why am I expanding now? Not because the build says so but because my opponent invested in tech so will not have the resources to pressure my new base etc. The basics are important, if you have your mechanics down then your mind is clear to react and just execute the movements to achieve the goal you want based on what you observed.
It works the same with programming. If you're stumbling with language syntax, your framework - the basics. You will then loose a lot of time hunting small issues and constantly loosing the big picture. When you're basics are down you are free to experiment and will notice patterns that beg you to apply one of the basics you learned.
Some problems are specific, fall into the 'what data structure, algorithm' should I use. Some are structure/flow related - how do I make those two things connect to each other and pass data around. Some are new - but they all mingle and repeat themselves very often.
When you read a lot of code, write a lot of code - you will start noticing the patterns. In the worst case scenario - knowing the basics will make it easier for you to ask better questions/find answers to hard problems faster.
Example: If you want to learn to play baseball. You learn the mechanics of the game. You learn to hit, catch, and throw. You can be an expert baseball player, and you can practice the shit out of mechanics all day long, and play games, and win games all day long for decades.
But if you want to manage a club and win games, you need to take that next step to learning the mechanics of the game beyond playing baseball, or all you will ever be is a player, and you will never be able to actually build a team that wins games.
Telling someone to go practice hitting, throwing, and catching in order to perfect their ability to orchestrate and manage an entire team of different moving parts would sound crazy.
And that is how it sounds when people continually say "just go write, fix, and build."
I do not have an answer for this problem. But, the answers that always rear their heads when this question comes around, have the opposite ideals of how anyone that has taken the time to learn the mechanics of development. Those people that have taken the time and effort to learn the mechanics are mostly those that appreciate clear and concise paths to solutions. And, as far as I know there is not good resource for bridging that big gap between mechanics and craft. I could be wrong, and there could be a wealth of this information on this process stashed away somewhere. But, the problem is that most of these paths are most likely buried somewhere in a course or resource that is shrouded in mechanics, when the learner is just looking for craft.
The person that clearly outlines this path from Mechanic to Craftsmen will undoubtedly be very successful.