[#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:

1. Satisfies the success path - easy peasy, usually can be done in few lines of code.

2. Handles exceptions - logic to avoid system from panicking in case of thinkable error situations.

3. Handles dark exceptions - logic of avoiding system panics in the case of rare and unimaginable situations.

4. 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