Most Software Developers are Amateurs

Gregory Leman
Software Grognard
Published in
3 min readMay 2, 2022

Ben “The Hosk” Hosking has an excellent article titled “Software development is a loser’s game

In it, he makes the claim:

“I estimate 80 percent of software developers are amateurs and 20 percent professionals.”

He then goes on to define amateurs as being developers that don’t like widely accepted best practices.

But there’s another way to look at this. Uncle Bob posits that the number of programmers has been doubling every five years. Given the number of self-taught programmers being churned out due to access to online resources, this number might be even greater. This means that at any given time, roughly half of our current pool of programmers has less than five years of experience. 75% will have less than 10.

Another factor at play is what I call the Expectations Vs Experience relationship.

When you are first starting out, everything seems possible. You don’t know what you don’t know. Your estimates of what it takes to do something are usually wildly off. You haven’t been burned by the perils of software projects yet. You haven’t had to work with a team. They didn’t teach you about the best practices The Hosk talks about at your code camp or even your top university. You know how to code and you’ve got youthful exuberance. Those bothersome practices such as code reviews, SOLID design, and standard just seem stupid and in the way of pouring out code on caffeine and adrenalin.

As you gain experience, your expectations of what can be done fall like a rock. You’ve been burned a few times. Perfectly good projects have resources yanked away halfway through. You’ve learned about the corner case. You’ve learned that users often have no idea what they really want. Coding under unreasonable deadline pressures can cause tiny mistakes that become incredibly painful. You start to gain respect for those best practices because you’ve seen what happens when they are ignored. At the bottom of the curve is when you think everything is impossible.

This is where a lot of developers burn out.

If you survive and get enough experience you start to follow those best practices. Now you’re gaining confidence in what can be done. It’s rare that you run into a problem that you at least haven’t seen some variant of before. Eventually you end up at the top of your game and your expectations of what can be done are very high, but tempered with the knowledge of what it takes.

I remember listening to a post-game interview with Dean Smith after they had lost a game. He was asked why with superstar freshmen he played his seniors in the final minutes of the game. His answer was “I like seniors. They know our system.” Then again, there’s the old joke “What coach either college or the NBA was able to hold Michael Jordan to under 20 points a game? Dean Smith.”

I like experienced developers who have gotten past the burn out stage and are on the other side of the experience curve. But if our industry is going to avoid devolving into a complete mess, those seniors need to step up and help the juniors. Those best practices are important.

By far, one of the most destructive influences in our industry right now is the idea that older programmers become outdated. They’re too expensive. They have too many demands for work-life balance. A self-taught 25-year-old willing to work 80-hour weeks is the best bang for the buck. This is the same idea that you can win a championship with a team of rookies. Sure, it’s possible, but the best teams have a mixture of rookies and veterans.

There’s also the rampant idea among less experienced developers that they know everything. I also was once young and stupid. It’s up to the seniors to help out the juniors and show them the way, but it’s also up to the juniors to take the advice. Unfortunately, most people have to get hit in the head with a proverbial frying pan a few times before it takes. At least that’s the way I was.

The Hosk is right about the 80/20 rule, but it’s not that most people are just amateurs and we should design our methodologies and practices around that.

The real answer is that we need to turn our amateurs into professionals.

--

--