Hacker News Reader

Comment by gostsamo | Hacker News Reader

List the properties of an object. List the operations performed. Fill in the matrix. Remember it mostly by remembering your own failures.

One should know about all versions of null and empty or overflowed, about stuff being too big, about operations being performed out of sync.

Maybe, the easiest is to ask yourself: What can go wrong? on every line of the code.

View on HN

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.

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.

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.

Can you elaborate on what you mean by property of an object?

Does operations performed mean all the function calls associated with said property(like some struct or class object??)

Reply on news.ycombinator.com