HACKER Q&A
📣 twy30

How do you help junior developers learn finding edge cases?


Edge cases are nature's way of telling us how lousy our programming is. (*1)

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

  👤 brudgers Accepted Answer ✓
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.

👤 giantg2
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.

👤 afarrell
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-...

👤 gostsamo
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.

👤 tmaly
I would recommend they read the Mom Test book, then have them talk to the business side. You can learn a lot more than what was written down by doing this.