Hacker News Reader

Comment by ssebro | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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

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'.

Reply on news.ycombinator.com