| This has not been my experience at all. I have watched many developers progress from being coders ("hammers") to being thoughtful architects who have no trouble seeing the forest through the trees and re-imagining problems from first principles. 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.