19 Worst Case Scenario Coding ⛰️
I am revealing something personal in this letter.
We tend to develop our own methods while performing a certain tasks over a period of time. No matter what kind of task it is. It is not different in the case of programming/coding/building some logic.
As a developer, my job at core throughout my career was to build logic using and on several tools that:
- Satisfies the success path - easy peasy, usually can be done in few lines of code.
- Handles exceptions - logic to avoid system from panicking in case of thinkable error situations.
- Handles dark exceptions - logic of avoiding system panics in the case of rare and unimaginable situations.
- Handles natural disasters - when systems are built with real robustness.
If we go programming from point #1 to #4, there is a lot of repetition involved. Both in coding as well as thinking the logic through. That is not very efficient.
Over the period I learnt to take a step back and think of the most absurd scenarios which could cause the system to fail. I somehow try to simulate such situations when I am not in the office. Office space promotes thinking on conventional paths. Out of office is where you get to think out of the box.
When I keep all the exception cards on the desk, I try to build the logic in the reverse manner. By the time you handle all the exceptions, implementing the core logic is a matter of few lines again. I did notice that my mental processing cycles were reduced and it took me much less time to nail the logic in fewer trials.
This is one of the strategies that I implement and I have named it - worst case scenario coding - where I prioritise natural disasters first before moving towards the core logic. You should try this sometimes and let me know how did you find it?
– Sumeet
LDT | Guest Posts | Resources | Wisdom