> We are a hammer and every problem is a nail that can be solved by the act of thinking. We fall into the trap of overthinking every scenario because we are paid to poke holes in systems and then patch them before it gets to the user.
I was thinking about this yesterday, but more in terms of how small teams (or solo devs like in my case) can out-perform larger teams just by not even considering every edge-case.
I've discovered these overlooked cases later and been kind of embarrassed, but also happy that I didn't catch them right away, since fixing them wouldn't have been worth it, and the urge to fix them would have been high.
It's easy to fall into the trap of introducing even more edge cases by handling some other edge cases.
The correct way to handle edge cases is to not have them in the design. Easier said than done. And sometimes the edge cases are in the spec. Sometimes they are justified, but often they are not. These should be eliminated before the spec is finalized.
When I find edge cases that are low-stakes and unlikely to occur, I usually just ignore them completely. If they do occur, and someone thinks I shouldn't have allowed that edge case to go unhandled then I have plausible deniability of "I didn't think of that edge case".
I guess I'm fortunate enough not to have the high "urge to fix them".
Exactly! I try to be intentional about what edge-cases I care about and maybe more importantly the ones I don't care about -- for now. I also try to be intentional about time-boxing how long I spend thinking about edge-cases. Again I think context is important here.
I think this overall mentality is the contrarian in me resisting the status quo.
Hubris is an amazingly effective tool that more managers and senior engineers could leverage from junior members.
There are obvious problems and pitfalls that one needs to look out for. But all too often companies and teams grow to a size where their main product no longer has a place for people to try otherwise bad ideas.
I find it useful to write a list of the tests you would write if you were writing tests. Then you have made a list of all the things that can go wrong, instead of being caught off guard if it breaks
Yeah I admit I have wasted too much time solving edge cases that either never happen or happen but the effect is not so big of a deal that it was worth to handle it.
I was thinking about this yesterday, but more in terms of how small teams (or solo devs like in my case) can out-perform larger teams just by not even considering every edge-case.
I've discovered these overlooked cases later and been kind of embarrassed, but also happy that I didn't catch them right away, since fixing them wouldn't have been worth it, and the urge to fix them would have been high.