Getting overwhelmed about edge cases when coding

Question

I'm a software engineer currently working on a dynamic page that replaces a more static, hardcoded version. The issue is that much of the existing code was written with a "just make it work" mindset — hardcoded values, minimal abstraction, and very few edge cases handled.

Now that I'm trying to do things properly and account for various scenarios, I'm running into situations that weren’t considered before. When I raise these edge cases or try to clarify requirements, I feel like I'm coming across as scattered or overly concerned with "what-ifs." It’s starting to feel like I’m that person who overcomplicates things, when in reality I’m just trying to build something maintainable and future-proof.

Has anyone dealt with a similar situation? How do you raise valid concerns and push for better practices without seeming like you're overthinking or slowing things down?

Alex Chiou · Accepted Answer

First of all, it's great that you have this instinct! Much better to be an engineer who cares about the edge cases than one who doesn't.

At a high-level, my main advice here (as with many things in tech and in life) is to prioritize. As I talk about in my code quality course, there will always be an effectively infinite amount of edge cases and at some point you'll need to start making trade-offs.

Concretely what happens is you tackle some amount of edge cases efficiently (so code quality trends up while still moving fast) but then you consciously decide to ignore/backlog the remaining ones as ROI isn't good (i.e. you hit diminishing returns on code quality while tanking velocity).

When it comes to edge cases, you need to grade them across 2 axes:

Commonality - Is this edge case relatively big for an edge case, like a 10% possibility? Or is it tiny like 0.1% or less?
Severity - How bad is it when this edge case occurs? Is it bad enough that the NYTimes will write a scathing article about how evil your company is? Or will it just make a user slightly inconvenienced?

So take all the edges you found and grade them on common/uncommon and severe/not severe. You will have 4 buckets:

Common, severe - Obviously fix these
Common, not severe - Probably fix these
Uncommon, severe - Probably fix these
Uncommon, not severe - A lot of edge cases will be here. Deprioritize unless they're low-hanging fruit (<5 minutes to account for)

Once you have this structured table, you (and your teammates) will have clarity.

For what it's worth, engineers doing thoughtful writing and planning like this was a good sign that they were ready to grow from mid-level to senior from my experience.

Hope this helps!

Getting overwhelmed about edge cases when coding

Discussion