I’m not sure the “10,000 hours/5 years” rule is a particularly relevant one, these days. Tech mutates so quickly, it's near impossible to become an "expert." Also, many developers are...how can I put this...a wee bit obsessive. It’s quite possible to hit 10K hours well before 5 years.
I liked the analogy about the quirky bowling style.
That has happened to me -several times.
I’m primarily self-taught in most of my tech. It has tended to result in very highly-developed, but narrow, skillsets. Not necessarily a bad thing, but “brittle.” It has happened so many times, that I no longer feel that I am an “expert.” I am now “experienced.” At least the first five letters match.
But it has been a long road to where I am now. Humility has been forced upon me, and I now have a lot of “narrow skillsets,” to the point that they inform each other. For example, a lot of the stuff I did in PHP has helped inform my work in Swift, and vice-versa.
I’m choosing to specialize in a specific discipline and tech stack, which, just by itself, gives me a lot to learn. I am working to develop a “broad base” in a small-ish venue, with a lot of “sharp peaks.”
It’s really humbling. The more I know, the more I know I don’t know. Also, since I am constantly trying out stuff I don’t already know, I’m a perennial “n00b.” Usually, this manifests by not always being aware of the jargon (I know the tech, but not the name). This may result, I suspect, in my being treated rather shabbily by folks in the field (It may also have to do with my age. I have found that the way people treat me changes radically, as soon as they find out that I'm "long in the tooth," so I now make it obvious to avoid that). This has helped me to just keep my damn mouth shut, and open it only to eat my humble pie.
I haven't hit that point yet. It can get pretty close to overwhelming how quickly people are building new things and it's often not clear to me what problems the new things are solving (which likely means that I don't have those problems and shouldn't even worry about those new things).
Do you remember how it felt when you had that insight that tech is not mutating as quickly as it may seem?
I've described it as the "disappointment of knowledge" in the past.
It's like hearing all the microservices hype, sitting down to read it and thinking that it's "just" SOA slimmed down with some of the more complex vendor offering replaces. And that both are "just" Smalltalk-style message passing that happens to occur on multiple machines. Or that Kubernetes is just a bunch of nodes running processes with Docker as a process manager (reading the paper on its predecessor, Borg, was very enlightening). That C# is "just" Java that has been cleaned up.
The disappointment is that there is all this hype that would imply the world has changed and you realize that it may be a serviceable tool, but it is "just" something you've seen before remixed a little.
It's one of the reasons that I have a hard time getting excited about learning another web framework or another C++/Java-ish programming language. I can learn by diff'ing pretty quickly, so I tend to read broadly, looking for stuff that looks like it might be highly differentiated. I tend to burrow deep onto things of either immediate use or that will provide a different world-view (for example, learning Prolog will probably teach you a different way to look at problems whereas learning, say, VUE.js after having done Angular might teach you a useful tool, but the world view is more or less the same).
What I got from it, is that there's a solid "baseline" of technology/technique that tends to remain fairly constant and relevant.
It will often be "discovered" anew, and repackaged with jargon, but the basics are still the same.
My experience is that the mutations are more of an "accretion," rather than a change. New stuff is added. An old technique might be formalized (like SOLID isn't actually anything new, but the definition is relatively new), which is really a way of "adding" to the older technique. We find ways to combine "classic" techniques, or specialize/derive from them, to provide a different service.
It's hard to find teachers that will keep up with the times. As someone who has done training, I can tell you that creating a course is a fraught process. It has to be correct. That means a lot of testing/review, and often "after the fact" fixes and refactoring, as students (invariably) find problems.
Keeping it updated is a pain. Also, it's entirely possible that the entire class may need to be binned, as the tech becomes irrelevant (I have a whole bunch of DU -Apple Developer University- certificates that are pretty much worthless).
Also, scope and scale. Projects are much bigger, nowadays, than they used to be, and we have found ways to apply classic techniques in new ways. Instead of learning how to write a device driver, we learn a device interface SDK. That's not a bad thing (as long as we choose a good SDK), as it frees us to do a better job on the higher levels.
One example I give, is that I started Apple programming with MPW[0]/Pascal (not Object Pascal)/ASM. It could take a week or two to produce a relatively simple GUI app.
Nowadays, with Xcode and Cocoa, I can spin up a fairly full-featured app in just a couple of hours.
Very little of what I learned with MPW will help me today, but the discipline that I earned is quite valid, and much of what I had to do by hand, is now done in the framework, so I do have a bit of an understanding of what is going on "beneath the sheets."
I see - strong fundamentals are always worth cultivating because they are invariant under shifting fads and trends.
The thing that I find difficult is how quickly trends and fads shift in this industry. I came out of mathematics, which moves much more slowly than tech in terms of what's fashionable. I think it's a function of the sheer number of people working on tech compared to math.
I liked the analogy about the quirky bowling style.
That has happened to me -several times.
I’m primarily self-taught in most of my tech. It has tended to result in very highly-developed, but narrow, skillsets. Not necessarily a bad thing, but “brittle.” It has happened so many times, that I no longer feel that I am an “expert.” I am now “experienced.” At least the first five letters match.
But it has been a long road to where I am now. Humility has been forced upon me, and I now have a lot of “narrow skillsets,” to the point that they inform each other. For example, a lot of the stuff I did in PHP has helped inform my work in Swift, and vice-versa.
I’m choosing to specialize in a specific discipline and tech stack, which, just by itself, gives me a lot to learn. I am working to develop a “broad base” in a small-ish venue, with a lot of “sharp peaks.”
It’s really humbling. The more I know, the more I know I don’t know. Also, since I am constantly trying out stuff I don’t already know, I’m a perennial “n00b.” Usually, this manifests by not always being aware of the jargon (I know the tech, but not the name). This may result, I suspect, in my being treated rather shabbily by folks in the field (It may also have to do with my age. I have found that the way people treat me changes radically, as soon as they find out that I'm "long in the tooth," so I now make it obvious to avoid that). This has helped me to just keep my damn mouth shut, and open it only to eat my humble pie.
I write about that here: https://medium.com/chrismarshallny/thats-not-what-ships-are-...