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]<p>[1] <a href="https://www.infoworld.com/article/3195285/java-and-c-continue-to-decline-in-popularity.html" rel="nofollow">https://www.infoworld.com/article/3195285/java-and-c-continu...</a>
People get stuck in expert beginner land in no small part due to how shitty the hiring/training process is in most places. Outside of big tech companies and SV, no one hires generalists (past entry-level dev) and your resume gets screened out if you don't tick all the right boxes for language/framework (right down to exact framework..) or have a BigCo brand.<p>No one is willing to take on people who might need the slightest bit of ramp up time on new tech. So if you don't get all the right chances early, the only jobs you can even get hired into are those doing almost the exact same shit you have always done. God forbid someone hires a Java developer without experience in Spring into a <i>gasp</i> role that requires Spring (I see this constantly)!<p>I suspect managers like the authors basically fulfill their own prophecy. They insist on putting people into boxes and pretending they cannot learn, provide little opportunity to do so, and then blame the devs when they do not grow.
Perhaps professionally, being an "expert beginner" is bad, but in other pursuits being content with competency can make them more enjoyable.<p>To build on the bowling example, it is ok to be an average bowler if you are having fun with it. Anyone that's bowled casually with someone that is over competitive knows how obnoxious it is. Accepting that improvement is not always necessary to enjoyment is important.
This reminds me of the saying that you can have ten years of experience or you can have one year of experience ten times. Unfortunately there several forces in our industry that tend to push in the latter direction.<p>One such force is that compensation tends to increase more quickly, at least in the early stages of a career, with rapid job-hopping. This leads to the kind of title inflation mentioned in the article, and in the extreme case you get the 27-year-old founder/CTO who has an impressive-looking list of former employers on their résumé yet who has never built a substantial software system from scratch nor maintained an existing system for more than a year or two.<p>Another force pushing towards short-termism is that lot of new software simply isn’t expected or intended to last. The commercial incentives to invest in building robust, future-proof software are often outweighed by the commercial incentives to deliver early and deal with any problems if and when you get to v2. But then v2 has to be shipped early, and… Issues with reliability, scalability, performance and security just get kicked down the road until the next big rewrite, and writing maintainable code that can support ongoing development for a long time is unnecessary if you’re going to throw it all out and start over within a year or two anyway. Eventually, if the business hasn’t failed along the way, it reaches a level of maturity where it’s worth investing in these things more seriously, and then you do need developers who know what they’re doing. But by then a lot of the cool kids have moved on to throwing stuff at their next employer’s wall to see what sticks.<p>Of course there are parts of the industry that don’t follow this pattern and do have serious quality and longevity requirements for what they are building. However, they don’t tend to be in today’s fashionable parts of the industry like web app and mobile app development. As a result they may not be so attractive to the expert beginner, which is unfortunate because the expert beginner is not then exposed to better ways of doing things that are used routinely out of necessity in more demanding environments.
I feel like I may have wound up on this path... I'm working in a government role where I've been put as the lead developer on some major pieces of software despite only being 5 or so years into my career because the people I'm surrounded with seem to have some significant competency issues.<p>Not sure what I can do but quit and I just don't want to give up on the stuff I'm working on yet and I'm relied upon quite a bit... but I'm almost completely stagnating. Worst part is, I can probably just keep doing it for another 20 years and retire, it's almost too easy to just go that route.
Golf is the same way. I know people who improve a little but it’s rare to find a golfer who shoots high 90s and makes their way into the 70s. I went from a 15 handicap to a 5 in two years, and even now I am just starting to grasp at my core weaknesses and faults. Software development has been similar in past few years, in that the growth has come from facing my feers of talking to people, communication, leading, etc.
In software development, there is currently no more certain route to this state than to read 'Clean Code', take it as dogma, and stop there. Most of its major prescriptions and proscriptions have important caveats that are either glossed over or forgotten.
I fully believe that the Jack Welch style stack ranking school of management, performance and skills acquisition was a very expensive cultural mistake in modern corporate culture, perhaps one of the worst. The idea of stack ranking or internal competition is so naive and practically ineffective that it's no surprise it was an utter disaster in nearly every instance its been implemented -- it's also no surprise that it has been broadly recanted from most large tech firms that once implemented it, as well as disavowed by its original inventor!<p>That's what makes this article (and series) frustrating. It ignores that corporate software engineering is a team sport. Individual contributors need and deserve coaching and constructive working environment to unlock their true potential. But who is responsible for that? Is "everyone equal" or is it the case that the executives highest in the hierarchy are also responsible for the outcomes? I would say it's the latter. Are you a leader that's tired of expert beginners on your team? Take a look in the mirror. You hired them (or chose to retain them). You failed to provide them with the mentoring they needed to grow. You failed to build a constructive environment for them to be an engineer. And sometimes, most damningly, you failed to select the right kind of company or industry for your professional working style, goals, or preferred compensation. The truth is, if you didn't fail in any of these ways, you would never see any of these things you complain about!<p>Being a leader is hard, but doing it properly makes such a disproportionate binary impact on the ability of the organization to function properly that it's almost always my first (and often my last) question I need to ask to assess an organization. I'd like to see an end to these kinds of think-pieces and I'd highly recommend that folks who want real solutions to these problems (whether you're an IC or not) look elsewhere. By no means do I have the all the answers here, but a great place to start is one of my favorite books about engineering management: Camille Fournier's The Manager's Path.
I've seen this (or variations of) this article before, but what is lacking is how to resolve this problem. How to bring programmers out of the "expert beginner" stage once they realize it. Is it just a heavy dose of mentoring? Where do they find companies most fit to put programmers on the right path?
I think this is where a good college curriculum is invaluable compared to say a bootcamp. The reason being is that you get exposed to a lot more aspects of computer science that show you just how much you don't know.