233 reads

Fullmetal Alchemist and The Philosophy of Debugging

by AravindNovember 17th, 2020

Too Long; Didn't Read

Some things in the world have to be authoritatively "true" - the principles that you follow depend on those to be "true," and without that, everything can fall apart. The paradoxical principle of not being bound by principles serves the Elric brothers' well ultimately due to the nature of their quest. The Elrich brothers also hit these repetitive walls; one can even those events as a "loop" of their own. Real-world replay would be excellent where feasible; else, build a virtual setup and teardown of issue's environment.

Companies Mentioned

featured image - Fullmetal Alchemist and The Philosophy of Debugging

Finally got through all the content around the much-hyped Fullmetal Alchemist in 2020, and I was not disappointed; quite the opposite. It evokes philosophical questions on the things we do and how we do them. So naturally, with software engineering for me.

One of the standout things for me is Alphonse Elrich's statement when discussing his brother and his fate. Some things in the world have to be authoritatively "true" - the principles that you follow depend on those to be "true," and without that, everything can fall apart.

"We must seek a possibility without being bound by principles." - Alphonse Elric (Fullmetal Alchemist: Brotherhood)

The paradoxical principle of not being bound by principles serves the Elric brothers' well ultimately due to the nature of their quest (no spoilers here) through the series.

This perspective is very compelling when seen from debugging an issue since it is similar to their quest, albeit in a different context (and importance - not a life-or-death situation like theirs but significant for your customers)

Here is my go-to algorithm to debug for reference.

Step 0 - If you are taking over a colleague's review, get a brain dump. I am biased towards a written note, considering we are all remote and work asynchronously.

Step 1 - Did the issue occur as described? Do you have all the signals necessary to indicate that something abnormal happened?

Step 2 - If yes, proceed with Step 4

Step 3 - If no, why not? Find what is missing in the issue report and your assessment. Then go back to step 1

Step 4 - Can you create a replay and safely run it multiple times?

Step 5 - If yes, proceed with Step 6; else, go to Step 3. Real-world replay would be excellent where feasible; else, build a virtual setup and teardown of the issue's environment

Step 6 - Congratulations, you are looking in the correct place. Dig deep and propose potential solutions after high-level validations in the replay environment.

The challenging bit is when you find yourself stuck at a 3-5-3-5-3 loop. The Elrich brothers also hit these repetitive walls; one can even those events as a "loop" of their own.

Bringing back the question of truths, you have the choice of asking the question at step 3 or 5, but do not restrict to just that. Question Step 1, as well. How complete is our picture in Step 1 with the information you have uncovered so far?

With enough exposure, you can make the jump quickly from 1 to 4 without difficulty. But be aware that you can still be wrong, exceptionally so. That's what helped the Elric brothers find their answers consistently without falling prey to shortcuts even when the answers were not what they were ultimately looking for, but that is the nature of the truth.

P.S There is one other step that you can think of adding to your process.

Step 0 - Part 2 - Ignore all of that. But keep it in your back pocket in case you need to look it up later.

Though caution - treading the same path is time-consuming, do it only when you can afford to.

References