My motivation: https://youtu.be/tZQkpxgXSGg

A good way to deal with edge cases is to have as little of them as possible.

For example, when you come up with a general solution, check it on some examples by hand. Importantly, check it on the minimal possible examples. For an inspiration, see constraints for the problem, and just plug in the minimum values as input.

Often, the solution won't work on these examples. What to do, what to do?! I know: let's just consider them a special case, patch them up, and our solution will work! Right? Wrong.

A more productive mindset is to see why the solution fails, and find a bug in it. Remember, the example you used is very short, so checking each step of the solution should be trivial. The bug can be an implementation error, or it can invalidate the solution idea. Either way, a test case with a wrong answer is an opportunity, first and foremost. If you patch it up as a special case, the probable bug remained, you just made it one case harder for yourself to find it again.

Sometimes the minimal possible inputs, or other tricky inputs, are indeed special cases. Mark them as such only when you followed your solution through, understood why it doesn't work for them, and importantly, refined your knowledge about the domain where the solution does work.

I prefer to write a brute force approach and generate random test cases and break the loop whenever my answer and answer from brute force method does not match. You can easily print them and then look up for the mistakes in your program. Generally brute force method codes are easy to implement. So if you are unable to figure out the mistake on your own and you know the brute force approach, then quickly code it and print the input whenever the answers don't match.