Ask HN: How do you help junior developers learn finding edge cases?
17 comments
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.
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.
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.
* 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.
* 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??)
Does operations performed mean all the function calls associated with said property(like some struct or class object??)
I find that the majority of edge cases come from the business system (the business has a system/process that we turn into a technical system). I try to approach it like a lawyer trying to find a loophole. Try to ask questions that challenge assumptions about what conditions are possible in the system and ask questions that seem absurd but fit the requirements.
For example, if you're building a financial system maybe ask if a negative balance is allowed. If you charge a fee based on balance (like using basis points), can the fee be negative or is there a set floor? A negative fee sounds stupid, which is why the business probably wouldn't mention it in requirements, but it would be important to set the floor at $0 so if a negative balance occurred, we wouldn't issue a fee.
For example, if you're building a financial system maybe ask if a negative balance is allowed. If you charge a fee based on balance (like using basis points), can the fee be negative or is there a set floor? A negative fee sounds stupid, which is why the business probably wouldn't mention it in requirements, but it would be important to set the floor at $0 so if a negative balance occurred, we wouldn't issue a fee.
Thank you. That's a great example.
It gave me 2 new directions:
(1) Are there people helping others learn critical thinking? How do they do it?
(2) What does it take to have "user-friendly, tool-assisted critical thinking"? ("formal methods" [1], perhaps?)
I will dig around those 2 directions and see if anything interesting turns up.
[1]: https://en.wikipedia.org/wiki/Formal_methods
It gave me 2 new directions:
(1) Are there people helping others learn critical thinking? How do they do it?
(2) What does it take to have "user-friendly, tool-assisted critical thinking"? ("formal methods" [1], perhaps?)
I will dig around those 2 directions and see if anything interesting turns up.
[1]: https://en.wikipedia.org/wiki/Formal_methods
I think I've always just been somewhat contrarian/independent, at least to the level of devil's advocate. My teachers were usually quite annoyed with me when I brought up inconsistencies or loopholes in the assignment.
So, I don't really know how to teach it. Not to mention the negative impacts - it might be a positive for requirement gathering, but my independent views greatly stymie my career advancement. So proceed with caution.
So, I don't really know how to teach it. Not to mention the negative impacts - it might be a positive for requirement gathering, but my independent views greatly stymie my career advancement. So proceed with caution.
I understand. It can be a double-edged sword.
I wish you find a place where your talent is valued and appreciated.
I wish you find a place where your talent is valued and appreciated.
Ask “what edge cases are there?” when first describing the task and let them go off and work a while.
Later ask “are there any other edge cases?” and let them work a while longer.
Repeat as appropriate.
Let them find them on their own for a while or two.
Let them miss them on their own for a while or two.
At the right time ask “have you thought about this potential edge case?”
If you want someone to learn to deal with edge cases, they need to see it is something you value and give them time to learn how to do it.
And how not to do it. “Not” in the logical sense not “not” in a punishment sense or job evaluation sense.
Edge cases are hard and everyone screws them up. The context needs to be safe enough that people can own their mistakes and learn something other than to hide their ignorance.
Good luck.
Later ask “are there any other edge cases?” and let them work a while longer.
Repeat as appropriate.
Let them find them on their own for a while or two.
Let them miss them on their own for a while or two.
At the right time ask “have you thought about this potential edge case?”
If you want someone to learn to deal with edge cases, they need to see it is something you value and give them time to learn how to do it.
And how not to do it. “Not” in the logical sense not “not” in a punishment sense or job evaluation sense.
Edge cases are hard and everyone screws them up. The context needs to be safe enough that people can own their mistakes and learn something other than to hide their ignorance.
Good luck.
Thank you. I like your idea of support. Let me try summarizing it with bullet points:
* Maintain a healthy ratio between the knowns and the unknowns.
* Allow time and space to explore, experiment, and especially err -- to build up experience.
* Maintain a healthy ratio between the knowns and the unknowns.
* Allow time and space to explore, experiment, and especially err -- to build up experience.
The Rapid Software Testing course by James Bach is really good for teaching some metacognitive skills of this.
On a higher abstraction layer, iff you can filter for low-bullshit, some social justice stuff can indeed help someone master the main skills needed to spot diverse failure modes in different user stories. For example, this principle is useful: https://thingofthings.wordpress.com/2014/11/15/the-curb-cut-...
On a higher abstraction layer, iff you can filter for low-bullshit, some social justice stuff can indeed help someone master the main skills needed to spot diverse failure modes in different user stories. For example, this principle is useful: https://thingofthings.wordpress.com/2014/11/15/the-curb-cut-...
Thank you. I will check out that course.
The link you shared is very interesting. It reminds me of "perverse incentive" [1] and "unintended consequence" [2].
[1]: https://en.wikipedia.org/wiki/Perverse_incentive
[2]: https://en.wikipedia.org/wiki/Unintended_consequence
The link you shared is very interesting. It reminds me of "perverse incentive" [1] and "unintended consequence" [2].
[1]: https://en.wikipedia.org/wiki/Perverse_incentive
[2]: https://en.wikipedia.org/wiki/Unintended_consequence
cool, are you a software tester?
Bach, and Michael Bolton [1], offer some fresh look at software testing BUT they are also controversial and tend to present their ideas in a demeaning argumentative way.
[1] https://www.developsense.com/index.html
Bach, and Michael Bolton [1], offer some fresh look at software testing BUT they are also controversial and tend to present their ideas in a demeaning argumentative way.
[1] https://www.developsense.com/index.html
Is there a systematic, step-by-step approach to help junior developers improve their awareness/senses of edge cases?
There are some low hanging fruits that are easy to explain and demonstrate. For example, boundary-value analysis [1], division by 0, removal of an item from an empty container, etc. However, sometimes it feels more like art than science (i.e. I know it when I see it. ).
Any feedback and/or idea is greatly appreciated. Thank you.
*1: Borrowed from Dick Guindon's "Writing is nature's way of telling us how lousy our thinking is."
[1]: https://en.wikipedia.org/wiki/Boundary-value_analysis