Carl Sagan once said, “We live in a society exquisitely dependent on science and technology in which hardly anyone knows anything about science and technology.” Katrina Hayes is clearly an exception to that—she uses her knowledge and skills to great effect to debug code.

Katrina took time from her busy schedule prior to her presentation, Logging in the debugger’s toolkit at the upcoming ScaLE 14X to talk to Opensource.com. She talks to us about her surprisingly minimal use of tools and a bit about her debugging process.

How did you get started in coding and debugging in particular?

I was exposed to code at a young age, as my father and grandfather both worked with computers at SAS and BCBS. Debugging I was mostly introduced to during my days teaching myself Perl in college. You have to get real good at spotting missing semicolons real fast if you’re learning coding by running your own scripts through the command line.

Tell us about your own introduction to debugging tools.

I’ve actually always been kind of prideful about using minimalistic tools. I don’t even really use IDEs by default—on most of my own development I just use TextWrangler, and at work I currently mostly use UltraEdit. Just give me the code, a good description of behavior, and the ability to throw things at it and see what it spits out. That’s probably part of why I grew to use logging so much—I don’t have to do as much recording or testing if I can get my system (and possibly my users) to do that for me.

Every sys admin and programmer has a favorite bug that they like to tell about, whether because it was particularly difficult, humorous, or whatever. Please tell us about yours.

While perhaps not strictly a “bug,” one of my proudest incompatibility-surmounting moments involved integrating a particular type of rich HTML5 document produced by an educational presentation software package with the rest of the custom in-house educational software that had been built up as a mostly PHP application over a decade or so leading up to that point. This was when HTML5 was only really just beginning to catch hold. It involved 13 separate manual code changes that had to be made to each presentation output by the presentation software. I discovered all 13 of those by trial-and-error over several months, aided by logging and other notification mechanisms I utilized.

The abstract for your talk mentions poorly understood legacy systems with bug circumventions rather than fixes. How big is this problem and how critical is it to address?

Just my impression from talking to other programmers, but this seems to be the standard situation if you ask around the IT department of any company that’s had its doors open for more than a year or two. Really, unless a company puts a lot of emphasis on having a highly maintainable code base over its entire lifetime, this situation is inevitable eventually. And considering maintainable code only shows its value over the long-term, there is always going to be the temptation to trade off maintainability for more rapid deployment.

There are a lot of good arguments for rapid deployment, but I think there is a lot of space for firms to develop better habits here. I think going forward one important thing that might distinguish between firms that survive and firms that perish is which firms can best domesticate and nurture their code bases. It can’t just be a matter of throwing it out there and seeing what sticks anymore.

Do you have a defined personal process for debugging? Could you briefly describe it for us?

Not any highly developed process or anything, but generally I just spend some time thinking about the system affected by the bug in question and the way the bug fits into that system in particular. If it’s a part of a system I’m already familiar with, I might scan through some code or doodle things out. If it’s something I’m not familiar with, I will read as much code (or logs, or database dumps) as I can get my hands on. Unless it was quickly solved, I’ll usually then take some time to just chew on it before coming back again and more seriously looking for where the bug might be lurking. At this point, depending on the bug and my access rights, I might read logs or data dumps and make tweaks to code to see how that affects things. At that point it’s mostly just iteration. Poke at things, turn over rocks, see what spiders come crawling out.

How do you choose your debugging tools?

If it works, deploy it. If it’s hyped, ignore it until it’s required for use in an assignment for a continuing education course you’re taking.

What do you hope to accomplish with your talk at SCaLE 14X?

Share some experiences I’ve had with people who might get some use out of them, distill what I’ve learned in my career so far on a particular topic into something hopefully useful, and hopefully start some interesting discussions!