I agree to some extend, but for a lot of jobs the degree is your skill. I employ a lot of low level coders who are trained to do what we want them to do. Haven't had trouble finding those.
What I do have trouble finding is someone with the theoretical knowledge on how to utilize machine learning patterns, which design patterns, paradigms, techs and libraries we should use and why and so on.
There’re people that have CS degrees but can’t code. After learning the syntax of a language, anyone can write simple programs, and with some experience and dedication some can even write well-crafted code that others can use. What matters is one’s approach to problem solving and this is learnable and you get better at it as and when you work on such stuff as machine learning, and if you’ve adaptability that’s an advantage.
While I definitely agree to some extent, I'd just like to note that those things can be learned without the need for a degree.
In fact, many people with degrees in those areas skirt by and never actually develop a deep grasp or understanding of the material. Not saying this is true for everyone, but I'm just pointing out that a degree is no guarantee.
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?
In my experience, once people are trained to think about the hammer (some programming paradigm/language/library), rather than the table (the underlying theoretical problem to solve), it's very hard to unlearn. They become superb at weilding a hammer, hitting the nails at a perfect 90 degree angle every time, and are very proud about that fact. But start asking them about the statics of the table, whether we could maybe make one with half the nails that can bear the same forces, and they'll simply get annoyed about your utterly impractical attitude.
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.
This is all fair and tempers my interpretation of your original post. Some people do get stuck, and members of echo chambers are a good example. I think this observation is likely a snapshot of people who usually do move forward, but take a bit of a pause as they indulge. Another example would be people who just don't care, who found a reasonable 9-5 "job" and aren't very interested in seeing it as more than that. They often have to be pushed hard to advance their skills. Thanks for the thoughtful reply.
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.
Maybe my point wasn't entirely clear. I actually think that an out-of-field degree may rather help than hurt, because you have an additional perspective - especially if it's a degree based in math.
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.
> What I do have trouble finding is someone with the theoretical knowledge on how to utilize machine learning patterns, which design patterns, paradigms, techs and libraries we should use and why and so on.
As someone who is much more comfortable with learning the principles and ideas behind tech and considering its pros and cons, that's surprising to me. Being fluent and confident in the details, minutiae, syntax, very specific tasks within those topics feels much harder to achieve.
> What I do have trouble finding is someone with the theoretical knowledge on how to utilize machine learning patterns, which design patterns, paradigms, techs and libraries we should use and why and so on.
All that is learnable. I have seen people with good background in math and basic coding ability pull that off reasonably fast.
What I do have trouble finding is someone with the theoretical knowledge on how to utilize machine learning patterns, which design patterns, paradigms, techs and libraries we should use and why and so on.