Hacker News Reader

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.

Yes, 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.

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

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

Reply on news.ycombinator.com