This week my mentor taught me something very important , something called the art of debugging, or in his words , the System Engineering way of debugging. In essence what he taught me was how to look at debugging as a process, step by step, stripping the issue down to its bones and working your way up from there.
Lets begin,
In debugging we should look at it as a 3 step process , similar to how any system works , theres an input , it's processed and it produces an output.
when we look at the whole system, we start at the input. when debugging an issue , we look at what are the inputs we have entered into the system. For starters we look at the documentation provided , question ourselves if there is any way we deviated from the documentation , or before trying new things you've seen on stack overflow , use the tools provided in the documentation. Secondly we look at the semantics , did we leave out something , or did we not provide the right type needed for the input.
Next we look at the output , asking ourselves , why is this not the outcome i was expecting. Likewise we look at the documentation and semantics, is this supposedly the outcome we are supposed to get? or did i leave something out somewhere.And if all that fails , we look into the middleman , the process.
Looking into the process, is something somewhere within our process wrong , in this case of the image below, with the multiplication process we would expect the result of 2 and 5 to be 10 , but instead it returned 7. So we dive into our process and start the process of checking from input to output to process again.The regression of debugging and checking then begins.
As someone who panics and doesn't have a clear path on how to debug , this showed me a clear structure on how i can go about debugging.
Top comments (0)