Kate goes to conferences!
One of the ironies of a conference dedicated to all things digital and virtual is that the best ways to connect with people are surprisingly old-school. Social media tools can improve the odds of a serendipitous encounter at SXSW, but old-fashioned hustle, palm-pressing and -- above all -- creativity go a long way.Ryan Holmes
- November 2020 -- Stitches Expo at Home
- October 2020 -- HashiConf Digital
- October 2020 -- Stitches at Home
- September 2020 -- Stitches at Home
- February 2020 -- Stitches West
- February 2017 -- Southern California Writer's Conference
- August 2016 -- World Domination Summit
- January 2016 -- SCaLE 14x
- October 2015 -- All Things Open
- August 2015 -- MAA MathFest
- July 2015 -- World Domination Summit
- July 2014 -- World Domination Summit
- February 2011 -- Southern California Writer's Conference
- September 2007 -- Burning Man
Full-stack engineer with four years' professional experience on LAMP stacks, Kate has been playing with Internet technologies for a decade and a half. Her professional life has been dominated by bug-hunting and expansion on sprawling legacy systems, necessitating a love of diving deep into code, trawling through crontabs and dusty log files, and learning how to poke at live servers without upsetting their inhabitants.
Logging in the Debugger's Toolkit
In this talk I will walk through two examples of particularly insidious bugs on legacy systems that I encountered in a previous life as an independent contractor. As these were poorly-understood but critical systems at companies with stretched resources, they were simply trusted to remain running, bugs handled with workarounds.
As the Internet comes of age, more and more of these neglected legacy systems remain online - it is key now more than ever to dig into code and carefully add new logging points to turn potential ticking time-bombs into well-polished, reliable assets.
Interview by David Both for opensource.com
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!