“How to Keep Your Best Programmers,” in which I described what most skilled programmers tend to want in a job and why they leave if they don’t get it.
"How Developers Stop Learning: Rise of the Expert Beginner," Erik Dietrich explores the concept of the "Expert Beginner" in programming. This article discusses how some developers get stuck in their ways, opting for comfort over growth, and how group dynamics can foster a culture of mediocrity in software teams.
Dietrich delves into the idea that while talented developers often leave for better opportunities, those who are less skilled tend to remain in stagnant positions,
As he puts it, "The best developers will often leave when conditions sour; the less skilled stay, often leading to a cascading decline in group competence."
how environments can inadvertently reward mediocrity.
"Individuals opting into permanent mediocrity reap rewards for doing so."
Bruce Webster’s “Dead Sea Effect” post, which describes a trend whereby the most talented developers tend to be the most marketable and thus the ones most likely to leave for greener pastures when things go a little sour. On the other hand, the least talented developers are more likely to stay put since they’ll have a hard time convincing other companies to hire them.
I was a jack of all trades and master of none. This inspired in me a sort of mildly inappropriate feeling of entitlement to skill without a lot of effort, and so it went when I became a bowler.
But then a strange thing happened. I stopped improving. Right at about 160, I topped out.
I asked my old manager what I could do to get back on track with improvement, and he said something very interesting to me. Paraphrased, he said something like this:
There’s nothing you can do to improve as long as you keep bowling like that. You’ve maxed out. If you want to get better, you’re going to have to learn to bowl properly.
the worst part is that you’re going to get way worse before you get better,
Software is, unsurprisingly, not like bowling. In bowling, feedback cycles are on the order of minutes, whereas in software, feedback cycles tend to be on the order of months, if not years.
And what I’m talking about with software is not the feedback cycle of compile or run or unit tests, which is minutes or seconds, but rather the project.
They fail even while convinced that the failure is everyone else’s fault, and the nature of the game is such that blaming others is easy and handy to relieve any cognitive dissonance.
