Debugging Quotes

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.

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

The wages of sin is debugging.

Testing proves a programmer’s failure. Debugging is the programmer’s vindication.

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

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

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%

To err is human, but to really foul things up you need a computer.

Premature optimization is the root of all evil in programming.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Premature optimization is the root of all evil.

As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.

I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

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

If you're as clever as you can be when you write it, how will you ever debug it?

Building technical systems involves a lot of hard work and specialized knowledge: languages and protocols, coding and debugging, testing and refactoring.

There has never been an unexpectedly short debugging period in the history of computers.

If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with.

Each new user of a new system uncovers a new class of bugs.

If debugging is the process of removing software bugs, then programming must be the process of putting them in.

Rushing to optimize before the bottlenecks are known may be the only error to have ruined more designs than feature creep. From tortured code to incomprehensible data layouts, the results of obsessing about speed or memory or disk usage at the expense of transparency and simplicity are everywhere. They spawn innumerable bugs and cost millions of man-hours - often, just to get marginal gains in the use of some resource much less expensive than debugging time

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

The process of debugging, going an correcting the program and then looking at the behavior, and then correcting it again, and finally iteratively getting it to a working program, is in fact, very close to learning about learning.

Another effective [debugging] technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed "Never mind, I see what's wrong. Sorry to bother you." This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor.

System debugging has always been a graveyard-shift occupation, like astronomy.

System debugging, like astronomy, has always been done chiefly at night.

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

The most frequent complaint is that it's hard. True. it's a hard game to win Also, many people ask me how to use the secret debugging commands, apparently under the impression that I'll tell them.

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.

Early Apple machines - don't know how to answer what it was like since there were so few tools. Just had to keep debugging by isolating a problem, looking at memory in the limited debugging (weaker than the DOS DEBUG and no symbols) patch and retry and then re-program, download and try again. And again.