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 (6)
Shipping teaches a different set of muscles than building in isolation. You learn what breaks after real users touch it: unclear requirements, bad defaults, deployment friction, support burden, and the difference between clever code and useful software.
I would not use shipping as a gatekeeping label, but I do think it is a powerful forcing function. Until something leaves your machine, a lot of engineering judgment stays theoretical.
The funny thing is that all I do all day, every day is write software in various forms and ship it to my company's users. Every single day. I have a captive audience. They all work for the company I work for.
I have done this my entire career.
I have written countless applications for myself. Either to teach myself a new skill or for any number of reasons, but I have never released one to the greater public...
Until now. I finally shipped one for myself, and I'm super proud of doing it. Not because I finally learned how, but because this is the first real time I have put MY software out there for others to use, that I wasn't told to write. It's a little more intimidating than I expected to have my software out there for strangers to see and use, but it's out there for all to see.
That difference is real. Internal shipping gives you production pressure, but public shipping adds a different kind of exposure: unclear users, weak docs, strangers hitting edge cases, and no company context to explain the product for you. It is a useful muscle because the feedback is less protected.
That distinction makes sense. Internal shipping teaches real production pressure, but public shipping adds a different kind of exposure: positioning, support, packaging, and the weird emotional weight of putting your own judgment in front of strangers. That first personal release is a bigger step than it looks from the outside.
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.
I completely agree with you. I've been doing this for many years. I've always worked freelance, sometimes for others, sometimes for clients, always under pressure for the reasons you listed. Now that I'm retired, I've started writing articles and publishing my experiences. Are there any good or bad things in it? I don't know, I've made public my way of working and tackling problems based on field experience, little theory and a lot of practice. Some will argue that certain things could/should have been done differently because "the theory of relativity says that computer science paradoxes aren't defined in any literature and therefore the algorithm isn't good... (I'm joking)", but that's fine; I express myself in my code, and I hope it helps someone.