Strong opinion ahead. Written with respect for the craft, not for inflated titles.
There is a quiet crisis in software engineering, and it has nothing to do with AI, remote work, or the next JavaScript framework.
It’s a standards problem.
Companies are hiring more developers than ever, yet:
Delivery slows down
Codebases become fragile
Technical debt explodes
Senior engineers burn out or leave
This is not bad luck. It’s the predictable outcome of optimizing for headcount instead of capability.
This post is intentionally opinionated. Not to attack individuals — but to challenge habits that are hurting teams, products, and the people who actually care about engineering.
The Dangerous Myth: “More Developers = More Output”
Many organizations still think in industrial terms:
If progress is slow, add more people.
That logic might work on an assembly line. It fails in software.
In engineering, every new hire adds:
Communication overhead
Coordination cost
Architectural risk
Quality variance
A team of ten average engineers is rarely more productive than a team of five strong ones. In many cases, it’s less productive.
Yet companies keep scaling teams instead of raising standards.
The Real Cost of "It Works" Engineers
Average engineers don’t just write average code — they create long-term drag:
Code that technically works but cannot evolve
Logic scattered across components and layers
Excessive state and unnecessary effects
Fear-driven development (“don’t touch that, it might break”)
Bugs that surface months later
The hidden cost is paid by the strongest engineers.
They end up:
Cleaning up code they didn’t write
Fixing regressions they didn’t cause
Mentoring people who don’t want to improve
Carrying systems they didn’t design
This is how good engineers quietly burn out.
Titles Are Cheap, Fundamentals Are Not
Let’s say the uncomfortable part out loud.
Years of experience do not equal seniority.
Someone can claim five years of React experience and still:
Misuse useEffect
Duplicate state that already exists
Mix business logic with rendering
Create components that do everything and scale poorly
Seniority is not about time served. It’s about:
Judgment
Simplicity
Ownership
The ability to reduce complexity
Hiring Fewer, Better Engineers Wins
This should not be controversial, yet it often is.
One curious, disciplined, hungry engineer routinely outperforms multiple disengaged ones.
Not because they work longer hours — but because they:
Think in systems
Anticipate problems
Optimize for maintainability
Improve the codebase with every change
Strong engineers create positive compounding.
Weak ones create negative compounding.
There is no neutral.
Hunger and Curiosity Matter More Than Frameworks
Software engineering is not minimum-wage task execution.
We are paid well because:
We solve ambiguous problems
We reason under uncertainty
We design systems that must survive change
That requires curiosity, ownership, and a willingness to grow.
Someone who:
Barely does what is asked
Copies patterns without understanding
Avoids responsibility
Stops learning
Is not a good fit for high-quality engineering teams.
Pretending otherwise lowers the bar for everyone.
The Hiring Process Is Selecting the Wrong Signals
Many hiring processes optimize for comfort instead of truth:
Trivia instead of reasoning
Framework recall instead of fundamentals
Confidence instead of clarity
Speed instead of judgment
The strongest signal is often ignored:
How someone thinks while solving a real problem with another engineer.
Pair programming, code reading, and narrated debugging expose more in 30 minutes than five rounds of abstract questions.
Companies avoid this because it’s uncomfortable — not because it doesn’t work.
Culture Is Defined by What You Tolerate
You cannot claim to value quality while:
Rewarding speed only
Promoting people who create messes others clean
Ignoring technical debt until it explodes
Engineers optimize for incentives, not slogans.
If low standards are tolerated, they spread.
If excellence is rewarded, it compounds.
Smaller Teams With High Standards Win Long-Term
Given enough time, teams with:
Fewer people
Strong fundamentals
Shared principles
Clear ownership
Will outperform larger teams built on convenience hiring.
They ship faster over time. They break less. They retain talent.
This is not theory. It’s observable across high-performing engineering organizations.
Final Thought
Many companies will only realize this when it’s too late — when:
The codebase is unmanageable
Velocity collapses despite growing teams
The best engineers have already left
The solution was always simpler:
Hire fewer people. Raise the bar. Protect your standards.
Engineering is not about filling seats.
It’s about building systems that last!
Top comments (0)