Debugging When The Recipe Breaks

Every recipe breaks sometimes. The chapati does not puff up. The kite that flew yesterday will not lift today. The traffic signal in the model you built turns red two seconds too late. When the recipe breaks, most people give up and call themselves bad at it. A computational thinker does the opposite. They get curious. They debug. Debugging is just the calm habit of finding where the steps stopped matching the world.

Take the chapati that will not puff. The recipe in your head says, knead, rest, roll thin, hot tawa, flip once, press lightly, it puffs. Today it does not puff. The first debugging move is to ask, which step is different today. Maybe the atta was old and dry. Maybe the rolling was thicker on one side. Maybe the tawa was not hot enough because the gas pressure dropped. Each of these is a hypothesis, not an answer.

There is a small set of debugging questions that work everywhere. What did I expect to happen. What actually happened. Which step is the first place where the two stories disagree. What is different today from the last time it worked. What can I change quickly to test one idea. These five questions sound simple. They are also what every engineer at NESPAK or every doctor at Shaukat Khanum is doing under the hood when something goes wrong.

Now take the traffic signal model. You built one with cardboard, an Arduino, and three LEDs. Red, yellow, green, with timings of 30, 5, and 25 seconds. You notice the red turns on two seconds late after green. You expected exactly 25 seconds of green. You measure with your phone stopwatch. Green actually lasts 27 seconds. The first place the stories disagree is the green timer. So you read your code. The yellow delay is firing inside the green loop, not after it. One line moved. Bug fixed. The cardboard was never the problem.

Today's habit. Find one small thing in your week that did not work the way you expected. A jhola strap that snapped. A torch that flickers. A bicycle gear that slips. Use the five questions on it. Write your hypotheses, change one thing at a time, and find the bug. Then write a short note saying what the bug was and what fixed it. After ten such notes, you will notice you have stopped saying I am bad at this and started saying I have not debugged it yet. That switch is the whole point of computational thinking.