2 ms·
Thank you. Let me try repeating your advice in my own words: * Collect all assumptions (regarding data and actions). * Attack each assumption by throwing kno
by twy30 6y ago
Thank you. Let me try repeating your advice in my own words:
* Collect all assumptions (regarding data and actions).
* Attack each assumption by throwing known/common/trivial edge cases at it.
* Explore each assumption's necessary conditions: what they are ; how they could possibly be false/broken/absent.
- tudelo 6y agoThese seem like a good set of rules to follow. I would also add that in my experience once you get burned a time or two in production you start to develop a healthy level of paranoia and skepticism towards the code you write. I'm not sure if that step can be skipped, realistically we all create a dumpster fire here and there anyways. A healthy code review process helps as well.
- twy30 6y agoThank you. I like your idea. Let me try putting it into a bullet point form: * Get/give healthy feedback to mitigate against tunnel vision or unknown unknowns. * Learn from failures and mistakes.
- gostsamo 6y agoYes, something like that. With the caveat that we have really deep assumptions about the world and something will always surprise you. Be ready to learn from many past mistakes.