Eleanor Santos began programming at 67, while Robert Zhang has spent 20 years teaching computer science. They discussed debugging - the skill that separates people who continue programming from those who quit.
What is debugging really about?
Eleanor: Finding out why your program doesn't work. And it never works the first time. I used to take errors personally, like I'd failed. Now I see them as information. The computer is telling me exactly what's wrong, I just need to learn how to read its messages. That mindset shift took months.
Robert: Debugging is systematic problem-solving. Your code does exactly what you told it to do, which is often not what you wanted it to do. The computer isn't broken and you're not stupid - there's a logical explanation for every error. Good programmers aren't those who write perfect code initially. They're the ones who can efficiently track down and fix problems.
What errors frustrated you most at the start?
Eleanor: Syntax errors - misspelled commands, missing punctuation. I'd stare at my screen for 30 minutes looking for a missing parenthesis. Felt ridiculous. Type errors also confused me. Why does adding a number to text cause an explosion? These seem obvious now, but they weren't then.
Robert: Those surface-level errors are actually easier to fix once you learn to read error messages carefully. Logic errors are harder - when your program runs without crashing but produces wrong results. The computer can't tell you "your algorithm is backwards" or "you're calculating the average incorrectly." You need to trace through the logic yourself and spot the flaw.
How do you approach fixing a problem?
Eleanor: I learned to slow down. Read the error message word by word instead of panicking. Check the line number it mentions. Look for typos in that area. If that doesn't work, I add print statements to see what values my variables actually contain. Often the problem is obvious once I see the data. I also take breaks - solutions appear after walking away for ten minutes.
Robert: That's solid methodology. I teach a process: reproduce the error reliably, isolate where it occurs, form a hypothesis about the cause, test that hypothesis, fix it, verify the fix didn't break something else. Beginners skip steps and start changing code randomly, which creates more problems. I also recommend the rubber duck technique - explain your code out loud to an inanimate object. You'll often spot the issue while talking through it.
Does debugging get easier?
Eleanor: Yes, but you also attempt harder things, so you're always somewhat challenged. I can fix in five minutes what used to take me two hours. But I'm also writing more complex programs now, so new types of errors appear. The difference is I don't panic anymore. Every error has a solution.
Robert: Experience builds pattern recognition. You've seen similar errors before and know where to look. But Eleanor's right - you never stop debugging. Even senior developers spend significant time tracking down bugs. The goal isn't perfection but efficiency in finding and fixing problems.