4 ms·
Depending on the details of what you mean by your description of how you work, you'd either be a godsend to a startup or a nightmare. It's kind of funny how it
by TameAntelope 5y ago
Depending on the details of what you mean by your description of how you work, you'd either be a godsend to a startup or a nightmare. It's kind of funny how it could still be either!
I personally have gone in the opposite direction, where I spend most of my time making sure I'm not going to cause irreversible damage, and then just letting the not-critical bugs into the wild, because I'd rather ship a flawed product now and get feedback on it from actual users, than wait to ship a product until it's "perfect" and get no feedback until then.
But I respect the hell out of what you're describing here, because for every one of me, there needs to be one of you. The trick, in my experience, is getting you and I to work happily together. It's very difficult, but when it works, it's wonderful for both of us.
I just wrote a "guiding principle" for my dev team that reads:
"As long as a risk doesn't have catastrophic (irreversible) harm severity (consequences), it may be worth allowing the risk to actualize before attempting to mitigate or eliminate it."
I'm guessing you'd hate that? Any way I could make it marginally more tolerable?
- ChrisMarshallNY 5y agoI suspect that this comment might answer your question (Godsend or Nightmare -probably both. Old Testament Godsend): https://news.ycombinator.com/item?id=28211073 https://news.ycombinator.com/item?id=28211073
- tharkun__ 5y agoDisclaimer: I'm not who you are answering to. But whoa that's quite the story. I suspect that you are a godsend for the typical startup which will probably tend to be on the "physically sick from looking at the code" side of things and you are gonna pull in the other direction. In the end the startup would end up in a great 'middle ground' if neither side quits in frustration over the other. Which is basically what your parent says is the hard part. To balance it out. There's a lot of 'good enough' code and functionality you can 'get away with' that will actually be useful for your customers. And they can get it and use it now and not in 1 year from now. What is missing in a lot of companies is the 'sticking with it' meaning actually not just throwing the MVP out there and leaving it but collecting and _acting on_ that user feedback. Which is next to impossible with sickening code but easy enough with '80/20 rule code'.