There is a "shortage" of developers. And what we really mean, is that we can't find enough developers who have the skills and temperaments that business need to meet market demands. This will always be true. (I'll explain later) And it's caused by the way we work in our industry. Here, I propose a radical idea, which will solve the problem and improve the industry.

This is a first draft of this proposal. It came to me as an insight while reading Modern Software Engineering, by Dave Farley. But the ideas behind it are sourced from numerous sources.

TL;DR
The Idea is simple. You'll hate it. Read the long version to learn to love it.

• Step 1: Hire more Junior Maker engineers to "get things done", quickly and without much discipline. Like a good chef. Err on the side of less experience.
• Step 2: Hire and train a few Senior Mender engineers to refactor and "reduce the volatility in the marginal cost of features". Like dish washers and culinary cooks). Err on the side of more experience.
• Step 3: On the first day, Have the Maker and the Mender pair together on the start of the feature. Do not spend any time on testing, refactoring, etc. Let the Maker drive the day, with the Mender acting Mostly as a Mentor and learning context about the goal.
• Step 4a: Until your next "First day", the Mender will spend each day refactoring, testing, securing, and making the previous days' code, written by the Maker, more resilient.
• Step 4b: Until your next "First day", the Maker will continue building the feature, working on the recently recently modified/refactored code.
• Step 4c: On some days, the two will pair, or join a mob

What? Read The Long Version Where should I start? I'll start with a brain dump.

1. Developers are expected, nae, required to know too much to make good software.
2. Every 5 years, the number of developers in the industry doubles. We are forever surrounded by noobs.
3. As JBrains explains, TDD and good engineering, reduces the cost of the next feature, after "some amount of time". Getting stuff done and not doing TDD or good engineering, is faster up until "some amount of time" passes. Nobody knows when that point in time is.
4. Software engineering, is a real thing, but it's not like physical engineering. As Dave Farley points out, our production costs are nearly "zero". Many of the rules of engineering, or working with information is backwards from how we work with with physical things. One of the things that is backwards, is that it takes more experience to " tidy up" , and to engineer good software, than it does to get something into production and "working". Unlike with Chefs, where anybody on the street can be a good dishwasher, in code, anyone on the street can write most code, but fewer have the experience to know how to simplify, find the right abstractions, and clean up the code base, while keeping everything working.
5. There is no better way to transfer knowledge across teams, than to pair or mob together.
6. How can we do TDD if the Maker writes the code first? Simple. Delete it once it's working. Make Many More Much Smaller Steps, and do so incrementally, finding the better API and the better abstractions, modularity etc.
7. Some developers don't feel comfortable pairing. Most, haven't experienced the pain of being prevented from working fast because of the code base. They haven't been around long enough. Let them learn at their own pace.
8. If the more experienced developers are only there to improve the code quality, then new developers will be incentivised to learn how to improve code quality to get paid more and have more prestige, creating pressure to hire more makers to get new features out to users to feed our data and feedback cycles.

For now, I'm publishing this article, to get some feedback, then I'll write more, unless it doesn't resonate with anyone, then I'll write more one day, maybe...