Quotes About Debugging

Seibel: I was looking at one of your papers from the 70s about your Fortran profiler. In the preamble you were very enthusiastic about how that tool changed your programming from figuring out what you were going to write, writing it, and debugging it, to figuring out what you were going to write, writing a really simple version, profiling it, then optimizing it.

There was a bug in GDB!

When you're debugging something and then you figure out that not only is the map wrong but the tools are broken—that's a good time.

The most depressing thing about life as a programmer, I think, is if you're faced with a chunk of code that either someone else wrote or, worse still, you wrote yourself but you no longer dare to modify. That's depressing.

Seibel: What are the techniques that you use there? Print statements? Armstrong: Print statements. The great gods of programming said, "Thou shalt put printf statements in your program at the point where you think it's gone wrong, recompile, and run it.

Using JavaScript Error objects to reject promises can capture the call stack for troubleshooting

The rest of us lined up for debugging and muumuus.

After the debacle of the party, debugging the code running in his own brain was bliss. His body lay safely in his bed. His mind exulted inside the Nexus development environment, tracing the events that had led to the fault. Here he was in his element.

Doctors troubleshoot the human body—they never got a chance to debug it. (It took God one day to design, prototype, and release that product; talk about schedule pressure! I guess we can forgive priority-two bugs like bunions and male pattern baldness.)

It's hard enough to find an error in your code when you're looking for it; it's even harder when you've assumed your code is error-free.

Watching a program run is not as revealing as reading its code.

Debugging: what an odd word. As if bugging were the job of putting in bugs, and debugging the task of removing them. But no. The job of putting in bugs is called programming. A programmer writes some code and inevitably makes the mistakes that result in the malfunctions called bugs. Then, for some period of time, normally longer than the time it takes to design and write the code in the first place, the programmer tries to remove the mistakes.

When debugging, novices insert corrective code; experts remove defective code.

Programming allows you to think about thinking, and while debugging you learn learning.

Given enough eyeballs, all bugs are shallow (e.g., given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone).

The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.

The three most important aspects of debugging and real estate are the same: Location, Location, and Location.

The first step in fixing a broken program is getting it to fail repeatably [on the simplest example possible].

he de-bugged and de-moused the office ...

Programmers are constantly in maintenance mode.

You're not dealing with people," Jerry told him. "These are programmers, boy. Programmers!

If you're good at the debugger it means you spent a lot of time debugging. I don't want you to be good at the debugger.

Science requires a society because even people who are trying to be good thinkers love their own thoughts and theories - much of the debugging has to be done by others.

Fiddling with a program until it appears to work is a reliable way of obtaining a program that almost works