Wouldn't the low level people given enough time and perhaps mentorship eventually become the second type? It sounds like it could be the same person at different times in their career, or are you saying they'll never get there?
I have a degree, but not in a closely related field. My first job out of college was very much an apprenticeship for me, making the transition from having been a kid who could program, to being an employee who could write software that existed in a wider context. I left that job 20 years ago, mostly because my opportunity for growth was limited, and am now a Principal Engineer at Amazon, and am a little past the hammer/nail stage.
Having presented myself as a counter example, I do have some observations. One of the "leadership principles" at Amazon is "Learn and be curious". It feels like this has been lacking in your experience, while it is everyone's responsibility to look out for themselves, it is a particular responsibility of more senior folks to provide guidance and mentoring to help avoid these traps.
I definitely see your point about leadership though - university is just one thing, the right guidance at the first longer term job is certainly essential, and something I didn't yet have the luck to see.
To sum up, I didn't mean to say that a degree is what you need, rather that people training only in tool usage often backfires later on, and doesn't necessarily help to get at the underlying fundamentals.
Of course people will try to lean on the skills they already have when tasked with solving a problem. This is completely orthogonal to whether they have any trouble adding to their skills. The former is often the correct response to solving an immediate problem as quickly as possible, while the later is something that happens over a longer period of time and many projects.
Your assertion that people get stuck in this "hammer" mindset and have a harder time learning once there does not match my observations at all. From my experience the people who see a brick wall between these two skills fall into two categories. I don't know if you fall into either of these, but it would not surprise me.
1. People on the "architect" side of the wall who want to justify their feeling of superiority, their higher salaries, or their enterprise's highly regimented hierarchy that separates the two. 2. People on the "hammer" side of the wall who suffer from imposter syndrome and seeking to justify their sense of inadequacy.
Both are incorrect. There is no wall. In fact, between those two skills is a well worn and wide road that most developers move along throughout their career. Many don't complete the journey to your (or my) ideal of "software enlightenment", but most make progress, and being trained as a "hammer" doesn't stall the progress, it helps.
Also worth reflecting that software is still relatively new and we really don't know what we're doing. We're all making it up as we go along for the most part, so let's not be so quick to prejudge the capabilities of our peers. All of our enlightened architecture may seem pretty foolish a century from now, or even a year from now.
There is no wall if you define a wall as something that can't be tunnelled through. So I'd agree that a wall is not a good analogy (and I also never used it). But I'm reasonably sure that there is a hill in between, namely the hill to go from one local optimum to another, more deeper one. Whether anyone can mount that hill that depends on her/his drive to learn. All that (good) academic degrees do is basically filtering for people with that drive. That doesn't mean that people without degrees can't have that of course, it just means that some effort needs to be spent finding them.
> Also worth reflecting that software is still relatively new and we really don't know what we're doing.
I agree wholeheartedly, and that's exactly why I'm very skeptical of people falling in love with some hammer-du-jour. It can be an OS, it can be a paradigm, it can be an editor, a library or a programming language - one should always be aware of its downsides, unknowns, alternatives and predecessors (and why/if they failed).
Edit: One more thing:
> I have watched many developers progress from being coders ("hammers") to being thoughtful architects
I don't doubt that one bit. To continue with the analogy, there's two ways to approach a 'hammer': becoming proficient in it, yet keep recognising that it is a tool and only a tool, and its use should be questioned as often as possible. To be able to do that it is often necessary to learn a few other tools at the same time, just to see the other side of the coin. Learning the right tools most certainly makes you a better architect as well though. The other way is to fall in love with the hammer and then start seeing everything as nails. I'm often seeing examples of people stuck in such a mindset and it usually happens with things that have a large community that serves as an echo chamber for people's fandom.