How Developers Stop Learning: Rise of the Expert Beginner
daedtech.com
daedtech.com
[1] https://www.infoworld.com/article/3195285/java-and-c-continu...
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.
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.
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.
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.
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.
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 gasp role that requires Spring (I see this constantly)!
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.
Ironically - I got hired into a product company which mostly works on their own internal java frameworks and didn't have a spring requirement. I figured I'll have to give time to learning Spring on the side since most Java jobs require it, but my first project here was on Spring Boot/Hibernate/Angular because of a client requirement, and I was put on it purely because of my Angular knowledge.
I'd understand if a company required complicated stuff done in Spring/Hibernate, but most organizations use of Spring Boot is limited to building rest APIs, for which no previous knowledge is necessary. I haven't yet run into an issue I couldn't solve by less than an hour of googling despite having no experience in it beforehand - even making interceptors and adding Spring Security.
Because of its simplicity I do wonder if I've barely touched the edge of it, and the usual usecase is much more complicated than this, but I'm planning on learning spring on Udemy anyway, so I guess I'll find out.
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.
All the expert beginner developers I've met act as if they are not beginners. You only find out piecemeal, and that can end up in frustration and wasted time.
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.
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.
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.
> If you’ve ever heard the aphorism about “ten years of experience or the same year of experience ten times,” the Expert Beginner is the epitome of the latter.
I agree with the factors you listed. As always I think company culture plays a big role too. If you're surrounded by expert beginners it's like an echo chamber where everyone thinks they are rockstars. Being surrounded by people who genuinely want to learn and improve instils the opposite mentality and drives progress.
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.
Please don't quit yet. Please work on some pet project or something in your free time if you'd like. As you saw, we need people who care in government IT projects. We won't magically find people who care. We are the people who care.
It would be noble to stick around, but maybe a person owes it to him or herself to find an organization already doing things the right way that is willing to hire and train eager inexperienced team members.
I worked with many who had a 10-20 years career, but only 2-4 years "experience"
As long as you can keep your current job, that is.
Don’t quit your job. The article is elitist nonsense. The reality is that most of us are just plumbers, we’ll always be just plumbers, and that’s ok. You’ll probably never do anything world changing or cutting edge in your career. But you are among the most blessed human beings on the face of the earth to be getting paid triple the median salary to sit in a chair typing on a keyboard. Keep that in perspective and focus on pursuing meaning in your life that doesn’t involve a manic drive to sacrifice more time for more money.
- lack of optionality: If for some reason you don’t like your job, you’re stuck because it’s harder to find a job if you don’t check at least some of the boxes.
- alternatively, your job lays you off after you’ve been at a company for 15 years doing ASP.NET Web Forms and you start looking for a job and you find that you aren’t hireable. Then you start screaming “ageism” (I’m 45).
But you are among the most blessed human beings on the face of the earth to be getting paid triple the median salary to sit in a chair typing on a keyboard.
The median salary in the US is $56515 (https://wallethacks.com/average-median-income-in-america/). The median salary for a software developer is $100,690 (https://money.usnews.com/careers/best-jobs/software-develope...)
Also the best way to even get that is statistically to job hop at least early in your career.
I also assumed most people here are bay area, where $100k is intern pay. That means your average software developer out of college is earning more than twice the median income of two working adults.
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!
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.
Read books, lots of them. Books about programming, math, computer science, game design, user interfaces, graphic design, productivity, investing, meditation, history, criminal justice, fantasy, science-fiction, and everything else.
Watch conferences. Go to your local tech meet-ups. Meet people. Ask questions.
Take classes that interest you in your city.
If I get too bored at a job I find a new job. You can't stop learning. What you are going to be good at is what you do for your day job.
Have a schedule. Work out frequently, keep my health in order. Wake up EARLY in the morning and work on side projects BEFORE WORK. If I wait until after work, I'm going to be too tired to actually get anything useful done. Turn off the computer/tv for a few hours before bed every night, and read books instead of surfing ( social media of choice ).
If you want things to improve for you, you have to improve.