What that tells us is to design development environments for the expert beginner. Expert beginners are cost-effective. Competence and expertise in web development is not cost effective. By the time someone reaches the expert level, the technology in which they are an expert is obsolete. Like Java programmers.[1]
> the technology in which they are an expert is obsolete
A lot of the principles, idioms, patterns, and instincts experts pick up transcend technology. Sure, they won't be able to optimize a framework they've never interacted with, and some bugs will probably require a trip to stack overflow, but they know how different pieces fit together, where to go for help, what it looks like when something isn't working, best practices for avoiding a huge catastrophe, and - probably most importantly - the wetware people skills required to get things done and done right.
Being a master software engineer, in other words, has almost nothing to do with the particulars of the software.
When I was working with a react code base, there are a lot of brittle and bloated components, which didn't follow React idioms at all. Make a lot of data flow out of sync.
It turns out there are a lot of senior programmers use their experiences from Java or other background to build things. They've read some redux docs, but they refuse to use follow those idioms just because it looks weird.
I don't about master software engineers. But I see front-end development or WebSocket programming differs from plain old stateless HTTP back-end programming because there's a major partaway from request response programming model. For those scenario even typical hexagon pure domain model starts to falling apart, because the model is simply not reactive.
This is a very narrow way to look at software expertise. The technology stack may change but the fundamental problems are unfortunately quite stubborn. And once you understand fundamental approaches like OOP or functional programming the only thing many “new” technologies bring to the table is a bunch of new syntax for expressing the same ideas.
It’s rather like mechanical engineering. Every decade brings new equipment, software tools, and manufacturing techniques but the problems (and solutions) of stress, strain, and heat transfer remain stubbornly similar.
Competent (web) developers can roll with changing technology, leveraging fundamental skill and understanding; beyond superficial differences, the basics haven’t changed all that much in the past two decades. “Expert beginners” seem to complain about rapidly-changing technology (as well as basics like proper usage of version control); they also make giant messes, which can’t possibly be cost effective.
"the basics haven’t changed all that much in the past two decades"
I did some front and back-end development in the mid 00s and almost nothing still applies. Even the HTML standard is different, CSS has gotten much more complicated and JS has changed immensely.
Most importantly, people don't build web sites any more, they use various frameworks to build so-called SPAs.
The front-end is in eternal turmoil and front-end skills expire fast, good thing I got off this carousel.
I don't want to trivialize learning modern frontend development with a clean slate, because it is a long process to get familiar with the tools. But I think those are the details and not the basics. Whether you use html templates rendered server side, or JSX in an SPA, the experience is quite familiar.
That’s an interesting premise, but how do we know? What if expert beginners aren’t cost-effective but the true cost of relying on them is hidden because there isn’t enough evidence available about the success of alternatives built by developers who have reached higher levels of skill and experience?
By the time someone reaches the expert level, the technology in which they are an expert is obsolete.
I respectfully disagree. Focussing on specific tools seems to be exactly the kind of danger we’re talking about with the expert beginner syndrome. Someone who sees the bigger picture will understand common principles and techniques that are applicable with many tools, allowing them to reach proficiency with new but similar tools very quickly. This leaves them free to focus on any genuine differences and, more importantly, on the problem to be solved rather than the tools used to solve it.
This effect is seen only with scale. If you have thousands of developers like my former employer, IMHO it's best to develop a tool that will help these "expert beginners" to not make mistakes, e.g. make them form designers, rule engine and composable rule blocks etc.
The problem with the expert beginner is that they refuse to learn the new tool, because in their mind the old way worked perfectly fine. The developer who recognizes the value of these systems and takes the time to learn their intricacies is the least likely to fall into the trap.
Though even with those systems, there's the danger of people becoming experts of those specific systems, and resisting any push for an upgrade, no matter how important.
If you have thousands of “expert beginner” level developers, perhaps a training programme would be a better option? At that scale, you would surely have the resources to systematically increase the skill level of your whole staff instead of merely trying to compensate for their current limitations indefinitely.
That is a good point but that requires either having training in place or having time to do that. The workplace I worked at had a pretty high turnout of developers and short term projects using various languages and technologies (our "expert beginner tools" largely abstracted that as well, thankfully), training them was not really an option (and we lacked the required infrastructure). It was an outsourcing/staffing firm btw, not a product company.
[1] https://www.infoworld.com/article/3195285/java-and-c-continu...