There's a quiet lie rotting at the heart of modern software development, and almost nobody wants to say it out loud: the industry is drowning in people who can ace a LeetCode interview, argue endlessly about architectural patterns, and hold strong opinions about tabs versus spaces — but who have never actually shipped a product that real people use.
We've built an entire culture around the performance of engineering rather than the practice of it.
Walk into any dev team today and you'll find brilliant people who can recite the SOLID principles from memory, who have strong feelings about hexagonal architecture, and who will spend three weeks bikeshedding a folder structure — but who have never felt the particular anxiety of watching your own code process a real user's real money. Never felt that accountability. Never shipped something and then lived with the consequences.
That's a problem!
The industry has confused credentials and vocabulary with competence. A computer science degree, a GitHub profile full of tutorial clones, and the ability to reverse a linked list in a whiteboard setting are now routinely mistaken for the ability to build software that matters. They're not the same thing.
The people who actually make software work — who ship under pressure, who fix production bugs at 11pm, who make pragmatic calls with incomplete information — often look terrible on paper. They'll choose a boring, proven technology over the shiny new thing. They'll skip the elegant abstraction in favour of something they can debug in a hurry. They understand that a running system that's 80% right beats a perfect system that's still in design.
AI has made this worse. Now you can generate plausible-looking code, confidently-written documentation, and technically-accurate architecture diagrams without ever having built a system that stayed up under real load, without ever having migrated a production database at 2am, without ever having owned something from idea to invoice.
Knowing how to prompt Claude is not the same as knowing how to build software. Assembling AI-generated components is not the same as engineering. These tools are powerful and genuinely useful — but they're accelerators for people who already understand the fundamentals, not a substitute for earning them.
The fundamentals aren't LeetCode. They're: have you shipped? Have you been responsible for something in production? Have you been the person who gets paged when it breaks?
None of this means credentials are worthless or that there's no value in theory. There absolutely is. But the industry has badly over-rotated toward paper qualifications and interview performance at the expense of the one thing that actually matters — evidence that you can build something real.
The best developers I've worked with in 20 years had one thing in common: they'd shipped things. Messy things, imperfect things, things built under constraints and deadline pressure. Things that users actually touched.
That's the job. Everything else is preparation.
Top comments (1)
A shipped product creates feedback. An unfinished project creates opinions. Real users don’t care whether the architecture is elegant, the design pattern is fashionable, or the codebase is academically perfect. They care whether the system solves their problem reliably. The fastest way to learn engineering is to put something in front of real users and listen carefully when reality disagrees with your assumptions.