Half of All Developers Have Less Than 5 Years of Experience: Myth, Reality, and Why It Matters
A data-driven investigation into one of the most repeated claims in software engineering, and what it means for technical education in 2026.
TL;DR
- In 2017, the data was remarkably close to Uncle Bob’s prediction.
- For decades, the observation remained broadly accurate due to sustained industry growth.
- Starting in 2024, the growth rate of the developer population began to decelerate.
- The developer population is aging, changing the experience distribution.
- Software engineering continues to expand globally, creating entirely new audiences that must relearn established knowledge.
- The core insight remains profoundly relevant: software engineering is still a young field with constant influx and insufficient knowledge transfer.
- The rise of AI does not reduce the need for education. It increases the need for fundamentals, validation, and critical thinking. It is raising the bar.
- We are no longer just training developers. We are training engineers who can guide, constrain, and validate machines that build.
- Is learning and teaching the Spec-driven Development the way to go?
Table of Contents
- 01 - Where Does the Claim Come From?
- 02 - What the Survey Data Actually Says
- 03 - The Doubling Hypothesis in 2025
- 04 - The Developer Population Is Aging
- 05 - The Verdict: Mostly True, But Evolving
- 06 - Why This Still Matters. The Case for Continuous Education
- 07 - Conclusion: Keep Teaching, Keep Writing, Keep Explaining
- 07 - Conclusion: Keep Teaching, But Teach Differently
- 08 - Webliography
01 - Where Does the Claim Come From?
You’ve probably heard it before, in a conference talk, a blog post, or a podcast: “Half of all developers have less than five years of experience.” The statement is striking, almost alarming. It suggests an industry in perpetual adolescence, where the majority of practitioners are still figuring things out. But where does this claim actually originate, and is it true?
The primary source is Robert C. Martin, universally known as “Uncle Bob.” Co-author of the Agile Manifesto, author of Clean Code and Clean Architecture. One of the most influential voices in software craftsmanship, Martin has been making this argument in his famous “Future of Programming” talk since at least 2014. His reasoning is elegantly simple: if the number of programmers worldwide doubles every five years, then at any given moment, half of them must have been hired within the last five years.
If the reasoning is not crystal clear, read this page which explain what is a percentage and where I take the time to explain exponential growth plus many other things like the rule of the 70 etc.
“The number of programmers in the world doubles every five years, which means that half the programmers in the world have less than five years of experience. And this leaves our industry in a state of perpetual inexperience.”
Robert C. Martin, “The Future of Programming” (2016, repeated in every edition since)
Martin’s reasoning begins in 1946 with Alan Turing writing the first lines of code, and traces exponential growth through to the present day. In his 2014 blog post “My Lawn,” he estimated roughly 22 million programmers worldwide and calculated a growth rate of about 14.5% per year, a doubling time of approximately five years (because 70/15 ≃ 5). The mathematical consequence is inescapable: if the population doubles every five years, the newest half of that population necessarily has less than five years of tenure.
This idea has been enormously influential. It’s cited in podcasts (The Changelog #367), Hacker News threads, LinkedIn articles, conference talks, and countless blog posts. But does the data actually support it?
02 - What the Survey Data Actually Says
Stack Overflow, Developer Nation, and JetBrains paint a nuanced picture
Let’s start with the most authoritative source of developer demographics: the Stack Overflow Developer Survey. With over 65,000 respondents in 2024 and 49,000+ in 2025, it’s the largest annual snapshot of the developer community.
~50% of developers had ≤5 years professional experience (SO 2017) Stack Overflow Developer Survey 2017, 64_000+ respondents
In 2017, when the claim was most frequently repeated, the data was remarkably close to Uncle Bob’s prediction. Stack Overflow found that 50.1% of respondents had been coding professionally for five years or less. The number was even higher for mobile developers at software companies (60%). The claim, at that moment, was essentially true.
Professional Coding Experience: Stack Overflow 2017
But fast-forward to 2024, and the picture has shifted. The 2024 survey reports that 25% of professional developers have 1 to 4 years of work experience, while the majority of respondents are described as “early-to-mid career professionals” with nine or fewer years of experience. Crucially, the survey notes that respondents have started to “skew more experienced” compared to previous years.
Professional Coding Experience: Stack Overflow 2024
The 2025 survey reinforces this trend: 38% of respondents have been coding for 15+ years, and the age bracket 35+ has been growing steadily (from 31% in 2022 to 39% in 2024). The Developer Nation survey (SlashData, 2022) reported that close to 60% of developers had less than five years of experience, higher than Stack Overflow’s figure, but using a broader definition that includes hobbyists and self-taught learners.
03 - The Doubling Hypothesis in 2025
Has the exponential growth continued?
Uncle Bob’s claim hinges on one key assumption: that the developer population doubles every five years. For decades, this was roughly accurate. But the latest data tells a more complex story.
Global Developer Population (2018–2025)
According to SlashData’s 2025 report, the global developer population has reached 47.2 million (including both professionals and amateurs). Professional developers alone grew 70% in three years, from 21.8 million in 2022 to 36.5 million in 2025. But here’s the key finding: the growth rate is decelerating. After a 21% spike in 2023–2024, growth dropped to just 10% in the last 12 months. SlashData warns this may mark the beginning of a plateau.
10% annual growth rate (2024–2025), down from 21% the year before SlashData, Global Developer Population Trends 2025
This deceleration means the “doubling every five years” assumption is no longer holding. At a 10% annual growth rate, the doubling time stretches to about seven years. And the composition of that growth matters too: the amateur developer segment is actually shrinking (down over 1 million in the past year), while professionals are staying in the field longer.
04 - The Developer Population Is Aging
Fewer juniors entering, more seniors staying
Developer Age Distribution Shift (2022 → 2025)
This is perhaps the most striking finding. The developer community is getting older, not younger. The share of developers aged 18–24 fell from 33% in early 2022 to just 23% by early 2025, a dramatic 10-point decline in three years. Meanwhile, the 35–44 age bracket climbed from 22% to 26%.
The Stack Overflow 2025 survey corroborates this: 66% of professional developers are now between 25 and 44. The 35+ age group has been growing for three consecutive years.
Several forces explain this shift. First, the tech industry’s 2023–2024 layoffs (347,600 workers over two years, according to industry trackers) disproportionately affected junior roles. Second, AI tools are enabling smaller, more senior teams to do more with less, reducing the need for entry-level hires. Third, software development has matured as a career path, people are staying longer instead of transitioning to management or leaving the field.
05 - The Verdict: Mostly True, But Evolving
The claim was accurate and the underlying logic still matters
The original claim (Uncle Bob Martin, ~2014–2016): Mathematically derived from the observation that the developer population doubles every five years. If true, half of all developers necessarily have <5 years of experience.
Empirical support (2017): Stack Overflow’s 2017 survey confirmed 50.1% of professional developers had ≤5 years of professional experience. Developer Nation (2021–2022) reported ~60%.
Current situation (2024–2025): The figure has declined. Stack Overflow 2024 puts the <5 year group at roughly 25%. Growth is decelerating (10%/year), the population is aging, and junior entry has slowed.
Verdict: The claim was substantially true for two decades (roughly 2000–2020). It is now becoming less accurate as growth slows and the profession matures. However, the core insight, that software engineering is a young field with massive influx and insufficient knowledge transfer, remains profoundly relevant.
06 - Why This Still Matters. The Case for Continuous Education
Perpetual inexperience requires perpetual teaching
Even if the exact “50%” figure is softening, the structural problem Uncle Bob identified hasn’t gone away,if anything, it’s become more complex. Let’s consider why technical education, vulgarization, and returning to “already covered” topics is more critical than ever.
| Key Stat | Value | Source |
|---|---|---|
| Developers who learned a new skill last year | 69% | Stack Overflow 2025 |
| Developers using or planning to use AI tools | 84% | Stack Overflow 2025 |
| Developers who trust AI output | 33% | Stack Overflow 2025 |
| Developers who actively distrust AI output | 46% | Stack Overflow 2025 |
How Developers Learn (2025)
1. The renewal is constant
Even in a slower-growth industry, 69% of developers learned a new language or technique last year. That’s an astonishing level of churn in professional knowledge.
The tooling landscape keeps shifting:
- Docker → Kubernetes
- REST → gRPC / event-driven systems
- Manual testing → CI/CD pipelines
- jQuery → React → Server Components
- Monoliths → distributed systems → modular monoliths (again)
A developer with 15 years of experience may still be a beginner in Rust, WebAssembly, or LLM integration. Every generation of tools resets part of the learning curve. Remember when C++11 was “modern”? Entire mental models had to be rebuilt.
Experience accumulates but relevance must be continuously renewed.
2. The Developer Population Is Expanding Geographically
The global developer base is not static. It is growing rapidly in regions that are encountering many software engineering concepts for the first time:
- South Asia nearly doubled its developer population (≈4M → 7.5M since 2022)
- Greater China more than doubled (≈2.4M → 5.8M)
- South America roughly doubled (≈1.7M → 3.4M)
For many of these developers, ideas like clean architecture, testing discipline, or domain modeling are not “old news.” They are new discoveries.
Content that feels repetitive to a Western audience can be foundational elsewhere. What seems like rehashing is often knowledge diffusion at planetary scale.
3. The Profession Is Aging But Mentorship Hasn’t Scaled
Developers are staying in the field longer, while fewer newcomers enter through traditional academic pipelines.
That creates a paradox:
- The experience pool is deeper than ever
- But structured mentorship has not scaled with it
As the survey shows, developers primarily learn through:
- Documentation (68%)
- Online content (62%)
Formal education barely registers (18%).
In practice, blog posts, talks, tutorials, and open-source examples have become the industry’s informal university. Writing educational material is no longer “giving back.” It is part of maintaining the profession itself.
4. Tools Change. Fundamentals Don’t.
Uncle Bob emphasized this years ago: the major programming paradigms (structured, object-oriented, and functional) were all established before 1970.
What we call “new” ideas are often rediscoveries:
- Hexagonal architecture
- CQRS
- Event sourcing
- Data locality optimization
- Concurrency patterns
A Rust tutorial on hexagonal architecture reaches a completely different audience than a Java one written in 2012, even if the concept is identical.
Each generation must re-learn the same principles through the lens of new tools.
5. The AI Era Increases the Need for Understanding
This already changed in early 2026 but the 2025 survey revealed a striking paradox:
- 84% of developers use or plan to use AI tools
- Only 33% trust the output
- 46% actively distrust it
- The #1 frustration: solutions that are “almost right, but not quite” (66%)
“Three quarters of developers said they would still want to ask a human rather than AI because they don’t trust AI answers. 61% cited ethical or security concerns. 61% said they want to fully understand their code.”
Stack Overflow 2025 survey: free-form responses
AI doesn’t remove the need for fundamentals. It raises the bar.
To validate AI-generated code, developers must:
- Understand architecture
- Detect subtle correctness issues
- Recognize security risks
- Debug systems they didn’t directly write
Blindly accepting generated code is exactly the kind of failure mode Uncle Bob warned about: software that works until it catastrophically doesn’t.
Again, it is clear that perceptions shifted dramatically in Q1 2026 with the widespread adoption of AI agents, systems like Opus 4.6, and coordinated teams of agents. Who would have imagined, just six months earlier, that we would be comfortable letting AI agents work for two weeks and produce, with little to no supervision, something as substantial as a nearly complete C compiler?
Trust in these systems will absolutely continue to grow. But we cannot lose sight of the fundamentals. If we do not want to find ourselves five years from now with an entire segment of developers missing, we must keep hiring junior engineers and take the time to train them properly.
6. Early 2026: From Assistants to Autonomous Teams
We are living through an extraordinary transition.
In less than a year, we’ve moved from a “ping-pong” model (chat mode, ask -> answer) to a “team sport” model where multiple agents collaborate, iterate, retry, and deliver substantial systems with minimal supervision.
This is powerful and disorienting. The pace of change is now faster than most individuals can comfortably track.
The result is not less need for education, but more: we must now learn how to direct, constrain, and verify these systems.
7. Like Electricity, AI Will Eventually Become Invisible
AI will likely fade into the background and become infrastructure. People who are not programmers will increasingly describe what they want, and software will be generated for them.
They may never realize they are “programming.”
But someone must still understand:
- How to validate results
- How to test behavior
- How to define specifications clearly
- How to detect failure modes
Trusting generated software is fundamentally different from trusting a human-written system you can inspect. If an AI designs the recipe, chooses the ingredients, cooks the meal, and serves it… Do you trust it without tasting?
The same question applies to:
- Medical analysis
- Financial software
- Business automation
- Data interpretation
As AI becomes more seamless, critical thinking must become sharper, not weaker.
Disciplines like TDD, validation pipelines, and explicit specification become even more important because they are how we constrain automation.
8. The Economic Case for Continuous Education
Training developers is often seen as a cost center. In reality, it is a form of risk management.
Replacing a developer is expensive. Rebuilding shared understanding is even more expensive. A team that does not continuously learn ends up paying in different ways. They accumulate technical debt, misuse new tools, and ship systems that nobody fully understands. The price is paid later through outages, rewrites, and slow delivery.
Investing in education is cheaper than recovering from misunderstanding. Up skilling an existing team preserves context, domain knowledge, and ownership. Education is not charity. It is operational resilience.
9. The AI Second-System Effect
Fred Brooks described the “Second-System Effect” as the tendency to overbuild the second system because confidence grows faster than judgment.
AI amplifies this effect.
Developers can now produce large systems before they have internalized the constraints that usually come from experience. The tooling removes friction, but it does not replace architectural maturity. This makes it easier to create software that looks sophisticated yet lacks coherence, observability, or long-term maintainability.
Faster construction without deeper understanding increases the probability of fragile systems. Education is what keeps speed aligned with sound engineering decisions.
10. Creation Is Faster. Maintenance Is Still Human
AI dramatically accelerates the act of writing code but it does not eliminate the need to understand and maintain it.
Most software effort has always been maintenance. We write something once, then read, adapt, debug, and extend it for years. Investigating defects, responding to new requirements, improving performance, and understanding unintended side effects remain deeply human activities. Generated code still has to operate inside real systems with real constraints, dependencies, and business expectations.
When teams stop learning because “the AI can write it”, they risk producing artifacts that no one can safely evolve. The bottleneck does not disappear. It simply shifts from creation to comprehension.
Even if the nature of the maintenance changes, the need for humans who can audit the code, who can understand what the system is supposed to do, who can define how it should be validated, does not go away.
Side note. To tell the truth I’m not 110% sure and this view about maintenance may not hold forever. It is possible that, over time, regenerating an application with a coordinated team of AI agents will become more efficient than maintaining it in the traditional sense. Alternatively, from the very start of a project, we may embed agents directly into the CI/CD pipeline that continuously search for vulnerabilities, optimize code paths, audit design decisions, and stress test the system (for what I understood testing was a key element in the C compiler story I mentioned earlier)
In practice, this already possible. For example, adding one agent dedicated to testing and another dedicated to code auditing, with the explicit goal of simplifying what can be simplified, creates a feedback loop (write feature request on GitHub, open an issue…) that is faster and more systematic than many human processes.
User driven changes will still define what evolves, but maintenance itself may increasingly be performed by automated systems. And there there are at least two compelling advantages:
- Agents detect and report issues extremely quickly. The speed and quality of the feedback loop are critical to the quality of the end product.
- Cost dynamics are different. An experienced human tester is expensive, far more expensive than the compute resources required to run continuous AI driven analysis. But… Again, the cost of not training new testers or loosing all our testers five years from now will be dramatic.
11. The Risk of Losing Tacit Knowledge
Not all knowledge is written down. Some of the most important engineering insights exist only in experience (call it instinct, gut feeling if you want)
Senior engineers carry mental models about tradeoffs, failure patterns, and system behavior that rarely appear in documentation. When this knowledge is not actively transmitted, it disappears. No tool can regenerate it automatically.
Documentation scales. Tribal knowledge does not.
Continuous teaching is how that invisible layer of expertise becomes shared capability instead of institutional memory loss.
12. Teaching Is Part of the Engineering Job
In many professions, transmitting knowledge is considered part of the work itself. Software engineering is no different, even if we sometimes pretend otherwise.
Code reviews, design discussions, internal talks, blog posts, and mentoring are not side activities. They are mechanisms that keep the discipline functional across time. A team that does not teach eventually stops improving because each person must rediscover the same lessons alone.
Writing educational material is not just giving back to the community. It is maintaining the profession’s collective competence.
Engineers do not only build systems. They build the people who will maintain them.
07 - Conclusion: Keep Teaching, Keep Writing, Keep Explaining
Uncle Bob Martin’s observation that half of all programmers had less than five years of experience was originally a mathematical consequence of rapid exponential growth. For nearly two decades, the data supported that claim. In 2025 and beyond, growth is slowing and the developer population is maturing, so the exact ratio is changing.
But the deeper truth has not changed.
Our industry continuously absorbs new practitioners. Tools, platforms, and practices evolve faster than institutional knowledge can stabilize. Fundamentals must be rediscovered, relearned, and re-explained in every technological generation.
The Responsibility of Technical Educators and Content Creators
Do not hesitate to revisit so-called basic topics. Do not assume your audience already understands the foundations.
An article about SOLID principles written for Rust does not reach the same audience as one written for C# in 2009, even if the principles are identical. A modern tutorial on gradient descent using today’s Python ecosystem connects with readers who would never encounter the 2015 version. A guide to hexagonal architecture using NATS and distributed services addresses realities that did not exist ten years ago.
Every shift in technology, every new wave of developers, and every geographic expansion of the profession creates a new audience that deserves clear and thoughtful explanations.
Technical education is not just about exploring new territory. It is about making established knowledge accessible and relevant again and again.
A New Educational Challenge: Leading AI Systems
Education must now prepare developers for roles that did not previously exist.
We need to train team leads of AI agent teams, architects, and managers who understand how to create environments where AI can produce reliable outcomes. Their job is not simply to write code. Their job is to define constraints, validation strategies, and feedback mechanisms so that automated systems deliver results that meet expectations.
This raises an important question.
How do we teach young developers to become architects and leaders of AI-driven engineering?
A young architect is not placed in charge of the Jeddah Tower. A young architect is not assigned to design a nuclear submarine. A young architect is not made responsible for an A380.
They begin with smaller structures. They learn materials, constraints, safety margins, and verification methods. They work under supervision. They study failures. They develop judgment before they are trusted with scale.
The same progression must exist in the age of AI.
We cannot expect someone who has only experimented with prompts or assembled small applications to suddenly orchestrate autonomous agent systems that generate production software. Leading AI requires architectural thinking, testing discipline, traceability, and risk awareness. The complexity has not vanished. It has moved to a higher level of abstraction.
Designing the System That Builds the System
The modern architect must design:
- The clarity of the specifications that guide the agents
- The guardrails that constrain their behavior
- The automated tests that define what “done” means
- The observability that reveals drift and failure modes
- The review structures that keep humans meaningfully involved
They are no longer just designing software, they are designing the system that builds the software.
From Teaching Programming to Teaching Supervision of Automation
Education must evolve from teaching only how to code to teaching how to supervise automated creation.
Developers need to learn how to decompose problems, express verifiable requirements, and construct rigorous validation suites. Practices like test driven development, incremental delivery, and formal review become even more critical because they are how we align fast AI generation with real world correctness.
We are no longer just training developers.
We are training engineers who can guide, constrain, and validate machines that build.
07 - Conclusion: Keep Teaching, But Teach Differently
Uncle Bob Martin’s observation that half of all programmers had less than five years of experience was originally a mathematical consequence of rapid exponential growth. For nearly two decades, the data supported that claim. In 2025 and beyond, growth is slowing and the developer population is maturing, so the exact ratio is changing.
But the deeper truth has not changed.
Our industry continuously absorbs new practitioners. Tools, platforms, and practices evolve faster than institutional knowledge can stabilize. Fundamentals must be rediscovered, relearned, and re-explained in every technological generation.
What did change was the inflection point we crossed in November 2025 with the release of GPT-5.2 and Opus 4.5, which marked the transition from AI as an assistive tool to AI as an active participant in the software delivery process. Since then, especially entering 2026, the nature of the skills we must transmit has begun to shift accordingly.
The Responsibility of Technical Educators and Content Creators
We must still revisit foundational topics. We must still explain architecture, testing, and design clearly and repeatedly. Every new technology stack and every new generation creates a fresh audience that needs those ideas.
Technical education is not just about exploring new territory. It is about making durable knowledge accessible and relevant again and again.
However, repeating the same lessons without adapting their focus would be a mistake.
Using AI as a Fancy Chatbot Means Missing the Point
If in February 2026 we are still using ChatGPT, Claude and friends as luxury chat interfaces, we are at Level 0 and getting it all wrong.
The strong signals we have been receiving since the beginning of the year point in a different direction. These tools (especially Claude, and Claude Cowork) are not just assistants that help write code faster. They are becoming production actors capable of designing, generating, testing, and evolving software under supervision. ANd no, I’m NOT either talking about “vibe coding”.
This shift requires us to learn and teach new ways of building software. One example is spec-driven development, where the primary artifact is no longer the code itself but the precise, testable specification that guides automated generation.
When the marginal cost of producing code and even tests approaches zero, the economics of software change dramatically. The expensive mistakes are no longer syntax errors or missing implementations. The real costs become:
- Poor design decisions
- Weak architecture
- Lack of evolvability
- Ambiguous specifications
- Inadequate validation strategies
In other words, when building becomes cheap, thinking becomes expensive.
A Changing Industry Demands Different Skills
We are already seeing the emergence of highly automated delivery environments, sometimes described as dark factories for software, where large portions if not all of the production are handled by coordinated AI systems.
At the same time:
- Hiring rates for junior engineers are declining in some sectors
- Retention of experienced developers is becoming harder
- Organizations are searching for leverage rather than headcount
The market is not eliminating software work. It is changing the profile of the people needed.
Demand is shifting toward engineers who can orchestrate teams of AI agents to design, build, test, deliver, and maintain applications. These roles require stronger architectural thinking, clearer communication of intent, and rigorous validation discipline.
There will not be less work to do. There will be different work to do.
Designing the System That Builds the System
The modern architect must focus on:
- Writing specifications that are unambiguous and testable
- Defining guardrails that constrain automated behavior
- Providing exhaustive validation suites that encode expectations
- Ensuring observability so deviations are detected early
- Structuring human oversight where judgment is required
They are no longer just designing software. They are designing the system that builds the software.
From Teaching Programming to Teaching Orchestration
Education must evolve from teaching only how to write code to teaching how to direct automated creation.
Developers need to learn how to decompose problems, express intent precisely, and construct feedback loops that keep AI driven production aligned with the expressed needs. Practices like test driven development, incremental validation, and architectural reasoning become even more critical because they anchor a process that can otherwise scale faster than our ability to control it.
We still need to teach. We still need to write. We still need to explain.
But we must increasingly teach how to think, specify, and supervise, not just how to implement.
We are no longer just training developers, we are training managers who can guide, constrain, and validate machines that build.
08 - Webliography
- Robert C. Martin, “My Lawn”, Clean Coder Blog, June 2014.
- Robert C. Martin, “The Future of Programming” talk (2016). YouTube
- Robert C. Martin, interview on The Changelog Podcast #367 (2019).
- Robert C. Martin, interview on Tech Lead Journal #90 (2022).
- Stack Overflow Developer Survey 2017.
- Stack Overflow Developer Survey 2023.
- Stack Overflow Developer Survey 2024.
- Stack Overflow Developer Survey 2025.
- SlashData, “Global Developer Population Trends 2025”, May 2025.
- Developer Nation (SlashData), Pulse Report DN22.
- JetBrains, “Global Developer Population Reaches 19.6 Million in 2024”.
- Evans Data Corporation, Worldwide Developer Population Report 2024.
- Dice.com, “Most Devs Have Less Than 6 Years Experience”, March 2017.
- Global Nerdy, “Robert C. Uncle Bob Martin: The Future of Programming, 2019 edition”.
- What is a percentage?
- Building a C compiler with a team of parallel Claudes
- Mythical Man-Month, The: Essays on Software Engineering (Fred Brooks)
- Junior Dev Jobs are Gone
- Spec-driven development
- How AI Impacts Skill Formation
Article researched and written with data collected February 2026. All survey data cited is from publicly available reports.