Debugging When Stuck

Sooner or later, your code will not work. The screen will be red. A line of English will accuse you of something. Your heart will beat faster. You will be tempted to close the laptop and walk away. Do not. The single biggest difference between people who become programmers and people who do not is what they do in the first minute after a bug appears. The good ones lean in. The rest panic and reach for their phone. This lesson is about the leaning in.

Read the error message. Read it again. Read it out loud, in Urdu if it helps. Most error messages are written in plain English by people who wanted you to understand. NameError, name balance is not defined. SyntaxError, missing colon on line four. ZeroDivisionError, division by zero. Each one is honest. The system is telling you what went wrong, where, and almost always how to fix it. The first habit to build is, before reaching out for help, finish reading the error to its last word. In four cases out of five, the message contains the answer.

Sometimes the program runs without error but the answer is wrong. This is harder. The computer is not shouting. It is silently lying. The fix is binary search the bug. Print the value of every variable at the start, the middle, and the end. Wherever the value first looks wrong is the line near which the bug lives. If a function returns three thousand instead of three hundred, print the inputs as they enter the function. If they are right, the bug is inside. If they are wrong, the bug is upstream. This habit cuts the time to find a bug by ten times. Senior engineers in Lahore office buildings still rely on print statements every day. There is no shame in this tool.

Three rules to live by during debugging. One, change one thing at a time. If you change three lines and the error disappears, you do not know which of the three was the fix. The next time the bug appears, you will be lost. Two, before fixing, can you reproduce the bug. If running the same code with the same input always gives the bug, you have a strong handle on it. If it appears sometimes and not other times, the cause is something else, often timing or hidden state. Stop and think. Three, if stuck for more than thirty minutes, walk away. Make chai. Pet the cat. Pray asr. Come back. Half of the bugs in the world have been fixed during a five minute walk in the verandah, by people who had been staring for two hours.

Where to ask for help when really stuck. Stack Overflow is the world's biggest forum for programming questions. Search the exact error message in quotes. In nine out of ten cases, someone, somewhere, has had the same bug. Their question, and three answers under it, are waiting for you. Read the top answer, then the second, then the third. Sometimes the second is better than the first. ChatGPT and other AI tools are also useful. Paste your code, paste the error, ask, what is wrong with this and how do I fix it. Treat the answer as a hint, not gospel. AI is confidently wrong about ten percent of the time. Always test the suggestion before believing it.

An exercise to close. Open your last working program. On purpose, break it. Change a variable name in one place but not another. Remove a colon. Divide by zero. Run it and read the error. Then fix it. Do this five times this week with five different bugs. By the fifth, you will recognise the error message before it finishes appearing. Programmers are not people who never break things. They are people who have broken so many things on purpose that the breaking has become familiar. Breaking is part of the job. Mastery is mostly the speed of recovery, not the absence of mistakes.