The engineers who leave disasters behind
I just joined a startup as tech lead. Four engineers. Eight months of development. An MVP that was supposed to be ready.
There is nothing.
Let me be more precise. There is code. Thousands of lines of it. Repositories, branches, commits with messages like "fix" and "wip" and "asdf". There are Jira tickets marked as done. There are Slack threads where people discussed architecture decisions. There are invoices paid.
What there isn't: a working product.
What I found
The backend is a maze of half-implemented features. Three different authentication systems, none of them complete. Database migrations that reference tables that don't exist. Environment variables scattered across five different .env files with no documentation about which one is correct.
The frontend has components that import from packages that aren't in package.json. There are TODO comments from six months ago. There's a utils folder with 47 files, most of them duplicates of each other with slight variations.
The infrastructure is a graveyard. AWS resources that no one remembers creating. A Kubernetes cluster running nothing. Terraform files that don't match the actual state of anything.
The tests don't run. The CI pipeline is red and has been red for four months. No one noticed because no one was looking.
Eight months. Four engineers. Nothing to show.
The pattern
This isn't the first time I've seen this. It won't be the last.
There's a type of engineer who has mastered the art of looking busy. They know the vocabulary. They can talk about microservices, event sourcing, domain-driven design, clean architecture. They can fill a whiteboard with boxes and arrows. They can stretch a two-week task into two months with status updates that sound reasonable.
They create complexity because complexity hides incompetence. The more convoluted the system, the harder it is for anyone to evaluate whether they're actually delivering value.
They job-hop before the consequences catch up. By the time the company realizes the codebase is a disaster, they're already at the next startup with a shinier title and a higher salary.
They leave behind engineers like me to clean up the mess.
The damage
Let's talk about what this actually costs.
The startup I just joined burned through eight months of runway paying four engineers. Let's say average salary of $4,000 per month. That's $128,000 in engineering costs alone. Add AWS bills, software subscriptions, office space, equipment. Call it $200,000 total.
For nothing.
But the real cost isn't the money. It's the time. The founders spent eight months believing they were building something. They pitched investors based on a timeline that assumed the product would be ready. They delayed sales conversations. They passed on partnership opportunities.
Now they're starting over with a fraction of the runway they had.
This is what bad engineers do. They don't just fail to deliver. They burn resources that can never be recovered. They destroy companies.
How to spot them
They have opinions about everything but ownership of nothing. Ask them about their previous project and they'll tell you about the architecture. Ask them what they shipped and watch them deflect.
They reach for complexity first. Every problem needs a new framework, a new service, a new abstraction layer. Simple solutions are beneath them. They're not here to solve problems. They're here to build impressive-sounding systems.
Their code is write-only. They understand it when they write it. No one else ever will. Documentation is "on the backlog." Comments are for people who don't understand the code.
They're allergic to deadlines. Everything takes longer than expected. There are always blockers. The requirements were unclear. The third-party API was poorly documented. The product team kept changing things.
They blame the tools, the process, the team, the company. Never themselves.
What I expect from engineers
Ship something. I don't care if it's ugly. I don't care if it's not scalable. I don't care if it doesn't follow every best practice you read about on Hacker News. Ship something that works and solves a real problem.
Own your work. If you wrote it, you're responsible for it. If it breaks, you fix it. If it's slow, you optimize it. If it's confusing, you document it. Don't throw code over the wall and walk away.
Be honest about timelines. If you don't know how long something will take, say so. If you're stuck, say so. If you made a mistake, say so. I can work with uncertainty. I can't work with bullshit.
Delete more than you write. The best code is code that doesn't exist. Every line you add is a liability. Fight the urge to build. Solve the problem with the minimum amount of complexity.
Respect other people's money. Someone is paying for your time. That money came from somewhere. Investors, customers, founders who mortgaged their houses. Every hour you waste is their money burning.
The uncomfortable truth
The tech industry has a hiring problem. We optimize for credentials, not competence. We ask people to invert binary trees on whiteboards instead of evaluating whether they can actually build things.
We let people fail upward. The engineer who spent two years on a project that never shipped gets a senior title at the next company because they have "experience with large-scale systems."
We don't fire people fast enough. We give second chances and third chances and fourth chances because firing is uncomfortable and maybe they just need more mentorship.
We don't talk about this because it's impolite. We're all supposed to be supportive and positive and assume good intent.
I'm done being polite about it.
What I'm doing now
I threw away almost everything. Kept a few utility functions that actually worked. Started over with a clean repo.
Two weeks in, we have a working authentication system. One authentication system. That actually works.
The new rule is simple: nothing gets merged until it's deployed and working in production. No more phantom progress. No more tickets marked done that aren't actually done.
We have daily demos. Every day, you show what you built. Not what you worked on. What you built. If you can't demo it, you didn't build it.
Code reviews are mandatory and brutal. I'm not here to make friends. I'm here to ship a product. If your code is bad, I'll tell you it's bad. If you can't handle that, this isn't the team for you.
To the engineers who do this
You know who you are.
You've hopped between three or four companies in the last five years. Each time, you left just before the technical debt caught up. Each time, you had a good excuse. The company was poorly managed. The requirements kept changing. The team didn't have the right culture.
You've never stayed long enough to maintain what you built. You've never been around when someone else had to understand your code. You've never faced the consequences of your decisions.
You've gotten away with it because the industry lets you get away with it.
But here's the thing: people talk. Circles are smaller than you think. Your reputation exists even if you're not aware of it. The mess you left behind has your name on it.
One day you'll find that the referral you needed didn't come through. That the company that seemed excited went quiet. That the offer you expected never materialized.
It catches up. It always catches up.
To the founders and hiring managers
Stop being impressed by vocabulary. Start being impressed by shipped products.
Call the references. Not the ones they gave you. Find people who actually worked with them. Ask specific questions: What did they ship? How was their code to maintain? Did they meet deadlines?
Look at their GitHub. Not the stars on their repos. The actual code. The commit messages. The documentation. How they respond to issues.
Give them a real problem to solve. Not an algorithm puzzle. A small version of something you actually need built. See how they approach it. See if they ask clarifying questions. See if they ship something that works.
Fire faster. The cost of keeping a bad engineer for six months is catastrophic. The discomfort of a firing conversation is temporary. Make the trade.
Final thought
Software engineering is one of the highest-paying professions in the world. We have leverage that most workers can only dream of. A single engineer can build something that generates millions in value.
That leverage comes with responsibility. When we waste time, we waste serious money. When we build poorly, we create problems that compound for years. When we fail to deliver, companies die.
Most engineers understand this. They take pride in their work. They ship. They own their mistakes. They leave codebases better than they found them.
But too many don't. And the industry is too tolerant of it.
I'm not tolerant of it. Not anymore.