3 ms·
Trying too hard to write good code can be a deadly mistake for an early-stage startup regardless of the language you use. If you're really a startup, looking f
by pornel 4y ago
Trying too hard to write good code can be a deadly mistake for an early-stage startup regardless of the language you use.
If you're really a startup, looking for a product-market fit, then you don't know exactly what you're building yet. There's a high change you're going to throw away a lot of code.
e.g. you spend effort caring about scalability, flexibility, proper architecture, full test coverage — only to hand it to users who will say they won't buy it, it's not actually the feature they wanted. You can learn such lessons with crappy copy-pasted code, and then worry about code quality once you've figured out what to actually build.
- tikhonj 4y agoSure, but good code saves time even on really short timeframes. Every time I've worked on—or seen other people work on—a "we must hurry at all costs project", enough time is wasted on debugging, firefighting and friction that just building a decently clean system from the get-go would have been faster. I've seen this unambiguously on "throw away" data science code meant to produce a single report (or normal science code meant for a single paper), and that's a much shorter-term effort than anything at a startup. The tradeoff is even clearer once you start working in weeks and months, much less quarters or years.
- shadowgovt 4y agoIt all comes down to whether the team is faster at writing safe code in a tight language or debugging a loose language. My experience has been even with the lossage due to initial errors, teams I'm on have been better debugging errors, especially when the task is so small that the errors are obvious.