[ssebro]

Context is what matters here. You're a terrible programmer for established businesses building products they know people want (so it has to be rock solid and easy to maintain/upgrade). But you're great at churning out MVPs, which is really all startups need. The second a startup moves from an MVP, it no longer is a startup - they've proven their business and are building things like betas, where they know exactly what users want and are delivering on that.

[jbattle]

It's harder than that, because it can take years of trying out new features & products before a company really matures and/or ossifies. So you can be in that awkward middle zone for a relatively long time where you don't have the time or resources to build things exactly right, but you might just find something taking off and becoming a core part of the company's technology stack.

Takes a lot of wisdom, discipline, and not a little luck to know where to invest deeply in building robust software and where to get something done quickly so you can start testing it in the marketplace.

[greenyoda]

But if a startup wants to become a successful larger business (rather than just get acqui-hired by Google), then the code quality does matter. Once they've gotten paying customers, they can't afford to drop everything and build a reliable and scalable system from scratch - it would be cheaper and less risky to build on top of their original code.

Also, depending on the business, the MVP may end up being a large and complex code base that can't just be hacked together haphazardly. Not all startups build iPhone apps; some build on-line retail businesses or investment banks.

[Evbn]

Your theory directly contradicts the actual history of Google, Amazon, Facebook, etc.

Larry and Sergey's first hires were for people to replace the crumbling hacks they wrote to launch Google.

[tluyben2]

Having seen millions of lines of code for 'established business building products' I don't see that at all. I understand it, but hardly ever see it in practice. Code is generally 'bad' unless it has been refactored a lot (!) of times. Which most systems don't undergo as it's not a business concern (agile) for management.

[greenyoda]

It's not a concern for management until the code becomes so hard to maintain that adding the simplest feature takes months and introduces dozens of bugs.

[mattdeboard]

So very damn true. I'm trying to unclusterf*ck this in our codebase.

[tluyben2]

Yep. That's why I think people are slightly naive thinking that 'code in bigger companies' (vs MVP/startups) is generally good. I believe, from experience and anecdotal evidence, that it's generally not and that OP should just rather deliver than worry about 'bad programming'.