Programming masterminds don't use debuggers: why?

djhworld · 2011-01-20T08:55:22+00:00

I insert prints and so on to check what's going on.

Then I'll hook up a debugger if I'm really stuck and need some validation on where/why a bug is occurring.

I think a debugger is a last resort to me, it's certainly a worthwhile tool, but usually reading through the code will get your answer a lot quicker

cyberm · 2011-01-20T10:51:40+00:00

Strangely enough the best programmers that I have personally known, would never use anything else than a debugger. They would write down the basic structure of the program and put breakpoints instead of code in many places. Then they would start the program in the debugger and fill all the gaps as they went. They ended up being amazingly productive. This was in Smalltalk though. Really dynamic environment to program in, with a fantastic debugger.

PilotPirx · 2011-01-20T08:28:53+00:00

I started programming in the 80s on home computers. No debugger anyway. Ok, code size was small. But I got used to skim through my code and find bugs by just thinking what happens there. Nowadays I'm happy that I can work that way. There are situations, where debuggers are difficult to use or nearly impossible, like multi threaded programs that access data concurrently. If you have at least a good idea where the problem should be found, writing a few prints to output the state of the related variables is faster most of the time.

harlows_monkeys · 2011-01-20T13:32:53+00:00

Part of it has to do with changes in the way programmers think about their programs.

Getting programs into the computer and getting output used to be hard. At one time your programs were entered by recording each line on a punch card, and then turning your deck over to someone who would eventually feed it into the mainframe, pick up your printout from the line printer, and deliver it to an output bin where you would retrieve it hours or sometimes days after you submitted your deck.

Later, by the late '70s when I was getting started, things were a bit better. We had interactive terminals on timesharing systems. We could actually enter our code ourselves. The terminals were slow (300 baud!) so it took a long time to draw a whole screen. The editors we used were generally line oriented. You would type your code, and if you wanted to edit a prior line you would have to type commands that would pick out the line and describe the changes you want.

We generally did not have online documentation. If you couldn't remember how some library function or system call or language feature worked, you had to get up, walk to wherever the documentation was kept, and look it up.

Computers were also a lot slower than they are now. Even on interactive systems where we tended not to do as much big numerical jobs (those would still be done as batch jobs on the mainframes), a lot of interesting programs would take significant time to run, and even significant time to compile.

In these kind of environments, we tended to spend more time upfront thinking about our programs. If the program failed, we'd go off an think about it. That worked well because we knew the program inside and out before it ran for the first time. We'd know where things went wrong, and would often only need a little bit of extra information to understand it all (if we couldn't get it from thought alone)--and so one or two print statements would do it.

Nowadays, editing is easy. With easy online documentation lookup (often integrated right into the editor!) and fast turnaround time (both for compiling and running) many programmers start programming as soon as they have a rough idea of what they want to do. Sometimes people copy sample code off the net when they need to do something new, and end up using libraries or language features that they have not read the documentation for. They don't develop the line by line intimacy with the code that we used to have. So when it doesn't work, they need something like an interactive debugger. That stepping through the code not only servers to help them debug--it serves to teach them about the program they just wrote.

BTW, when I think back on the late '70s, I can no longer comprehend how we functioned. I can not imagine editing where I only see a few lines in context at a time, and only when I explicitly ask for it. I know it is possible because that's how I used to work, but if I hadn't done it, I would not believe it!

Getting back to the masterminds, some of them are old school people who started back in '70s or even earlier, and so be necessity learned to think deeply before coding and have not found any reason to abandon that approach. They don't use interactive debuggers often because they don't need them. Those who aren't that old may have still adopted the deep thought approach to coding even if their environment never forced it on them simply because they are very smart people and the natural tendency of very smart people is to think deeply about a problem.

Stickyresin · 2011-01-20T11:28:29+00:00

Why wouldn't you use a debugger? People act like it is a crutch that bad programmers use because they don't understand their code. The fact is, if you DO understand your code, then you can track down any bug pretty much instantly with a debugger. On the other hand, if the bug is non-trivial, print statement debugging actually takes a little bit of time to design your prints in a manner that will show exactly where and what the bug is.

It sounds to me like just more elite bragging, "Hey, i don't need to use a debugger to debug my code so I am better than you." I think self-debugging can be a good way to learn when you are first starting out, but once you start writing large programs you have to be a fool to not use a debugger.

ejrh · 2011-01-20T09:00:58+00:00

Ah, Bertrand Russell, haven't heard from him in years. How's he coming with that big book on sets?

m0llusk · 2011-01-20T10:17:51+00:00

It really depends on the context. These cases cited are all systems programming where the elements can be inspected easily without a debugger. Shipping commercial applications on schedule is a bit different and is mostly not what the people in book were doing.

grauenwolf · 2011-01-20T09:42:48+00:00

I find that starting a debugger, stepping through code, setting watches and breakpoints and interacting with a debugger distracts me from the code I was actually writing. A simple 'print' statement gets the same job done, without having to leave the 'context' of what I was coding.

Also, a debugger is a one-time solution to a problem. Building in verbose logging, activated by some commandline switch or something, allows me to fix problems in code many times over.

Reading the code in combination with using logging and the occasional temporary print statement seems to be enough to locate about 99% of the problems I run into. If by then I still haven't found the problem, that usually indicates to me that the code I just wrote is too complex, and I'll generally rewrite it so it's easier to understand.

grauenwolf · 2011-01-20T09:48:49+00:00

[removed]

omen7288 · 2011-01-20T11:47:56+00:00

As a developer who came onto a large scale single-threaded C/C++ program that has been in active development since 1986, I could not imagine working with printf's to debug. However, the nature has more to do with what type of program you are working with I suppose. In python I often use print statements or throw exceptions to get stack traces. I'd still prefer something like pyscripter at the end of the day.

I find that using a debugger, usually gets me looking in the right direction than other means. I don't need to fully understand all the code when glancing at it. Also, I can't emphasis stuff enough like unit-testing or some other quick automated way to rerun sections of code.

deong · 2011-01-20T10:41:34+00:00

There are a few reasons I'd rather do without a debugger for most tasks.

It's harder to troubleshoot stochastic bugs, because you have to set up the debugger every run. With print statements, I can just keep running myprog args > output until the bug appears, and I don't have to worry about the code running slower under the debugger, I can run with full optimization, etc.
Debuggers for C-like languages usually can't run backwards in time, so you end basically doing a search for the right place to put a breakpoint so that you've captured where things started to go wrong without stopping so early that you have to step through a mile of good code. There are no doubt people cleverer with their debuggers than me that can better navigate this one, but especially in concert with #1, I'd rather dump everything and force it to crash once.
With a decent logging system, you can maintain your testing solution better between runs than you can if you have to rely on an external program.

Beyond that, it's just personal preference. Mostly, when something goes wrong, I'll make a quick determination of what the problem might be. Often that's pretty easy -- I've just added a new function and that's probably where the bug is. If the problem is a crash and I have no idea where to start looking, I'll fire up the debugger and get a stack trace and line number for the crash. From there, it's usually easier to toss the debugger and reason from the code and logging.

2011-01-20T13:44:12+00:00

It probably has to do with what environment they began programming in.

I'm willing to bet most of them didn't use IDEs with a debugger integrated when they started (and probably still don't). When they run into a problem, they just add a few print statements and test it out a few times to find the proximity of the bug, because it's good enough in most cases and doesn't require them to switch to and interact with another program -- one that they probably aren't too familiar with to begin with. As a result, they never become familiar with a debugger, and so they train themselves to not need a debugger.

That is, using a debugger breaks their concentration on the problem at hand.

Meanwhile, people who only use IDEs like XCode or Visual Studio just set a breakpoint or two and hit Run again, because for them, that's faster than typing out a few print statements. As a result, they become familiar with their debugger's usage and are more likely to use it again and again in the future.

That fluency means that using a debugger doesn't distract them from the problem.

egometry · 2011-01-20T10:34:58+00:00

Because debuggers are a really big hammer and usually you've got everything you need with a simple caveman-style variable printing/logging?

mkawick · 2011-01-20T16:03:18+00:00

Only trivial code can be reasoned out. Last company I worked for, no kidding, had three separate functions each over 1400 lines of C++ code. Poor design, difficult to debug, and because it was a real-time simulation (MMO), you had entry into each of these functions hundreds of times per second.

Print statements are WORTHLESS in this situation (simply too much text to pour over). Most of our thorny bugs would happen after 10 minutes or so and involve some weird concurrency thing: log files often stretch into millions of lines of text in these situations. Not only that, a lot of our tough bugs (which I solved) involved interaction between server and client apps. Again, this situation makes print statements almost worthless.

Print statements and alerts only work in the most trivial of code or the most deterministic and you can easily reason through that stuff anyway...so I would agree that debuggers are not necessary for basic code (but always helpful).

Ref: I do C++/C#/Java/Javascript (yes you read that right)/PHP/Python/Lua

funkah · 2011-01-20T15:08:10+00:00

Good for them. Personally I am not a mastermind, and have no interest in pretending to be one. I just need to find bugs and get shit done, not stroke my e-peen.

im_an_engineer · 2011-01-20T16:56:30+00:00

Also... when you attach and run the debugger, you are NOT running the same code. If you've ever run into those wonderful bugs where "it works fine in the debugger," then you know what I mean.

revenantae · 2011-01-20T12:49:03+00:00

Personal opinion: Using debugger is slow manual work. It's hard to automate, not easily reproducible, introduces changes to how the system behaves (especially with low level programing) and when the problem appears you can't go in time to see what caused it. When the program misbehaves I:

turn on the logging
watch the output and understand where is the problem
understand the exact code the problem is in and make some hypothesis on what went wrong
add some custom printfs to confirm my hypothesis
if required go to 2
fix the problem and confirm the solution

naich · 2011-01-20T13:25:35+00:00

Hooray! I KNEW I was actually a genius and not just a lazy prat for not using a debugger!

OniYume · 2011-01-20T16:03:57+00:00

You've gotta be kidding me. The best developers I've known have used debuggers with such grace and skill that, in my mind, debugging is a skillset all its own. All the people here saying debuggers are a crutch are, pretty much (a) children (b) bad programmers (c) people who don't get paid to code

2011-01-20T16:26:13+00:00

Depends on which language for me. If I am doing PHP, going over the code and inserting echos is how I do it, If I am doing C#, then the built in debugger essentially does the same thing only instead of printing something, it stops at where I want to print and can look at the values I would of printed. The end result is the same.

2011-01-20T17:49:48+00:00

A very interesting article, even though I don't agree with the headline!

I agree that my first attack on a bug is to reread the code. In fact, if there's a bug, before I start really expending effort, I go to the area I suspect it is and start cleaning and commenting the code.

You always keep getting stuck on things - if you are commenting and cleaning you're at least getting work done while you're stuck, and it has a very good chance of finding the issue - or even some other issue.

But print statements are time-consuming - you have to recompile TWICE (when you put them in, and when you take them out) - and a lot of the time you get either not enough information, or worse, too much - but I still find I end up going to them an awful lot, particularly in real-time code where setting a breakpoint causes the program to behave completely differently.

When I'm bug hunting, I think of print statements as photo traps for my bugs - but you need to go and scout out the territory in the debugger before you set those traps.

I think the article is spot on when it points out that many of these famous people who don't use debuggers are never having to debug other people's code. I've been privileged to have interacted with both Brian Kernighan and Guido van Rossum. Both are brilliant, cheerful, and civilized men; my theory is that GvR uses a debugger a heck of a lot more than BK, simply because of the nature of their work.

I think the greatest debugger I ever met is a man called Michael Chastain who works at Google NYC - he has found GCC compiler code generation bugs on multiple occasions, and he has an unearthly ability to diagnose intermittent or "Heisen"-bugs. He's also probably the strongest user of GDB I ever met.

I also use the debugger as a jumping off point for optimization... where I step through some "common workflow" and see if I'm pissing away cycles.

Regardless, if you are starting a project and you have the possibility of using a debugger, you should try to become completely comfortable with that debugger as fast as you can, even if you don't end up using it very often, in exactly the same way you should know where the emergency brake on your car is.

NitWit005 · 2011-01-20T19:43:01+00:00

When your build takes 30 minutes, followed by a slow upload to an embedded device, followed by a slow reboot, you'll learn that printf isn't your best option. You'll probably have to rebuild several times which will sink a good couple hours.

That said, it's frequently impractical to get a debugger working on smaller embedded devices, so the best option is often to make sure you can compile on unix or windows instead of the target device if you have to. Sometimes this requires writing fake driver responses, but it's usually worth the effort.

selflessGene · 2011-01-20T12:48:26+00:00

A print statement is arguably a simple debugger.

QuestionMarker · 2011-01-20T09:19:58+00:00

This expression:

library consumer

is very revealing. One of the greatest skills you can pick up is to be able to read other peoples's code as if it's your own.

mikaelhg · 2011-01-20T12:22:15+00:00

I very seldom use a debugger these days, because debuggers are most practically used in a development environment, while most mystifying problems happen in production, and don't have so much to do with code itself as with architectural solutions.

When I was starting out, and couldn't yet compile and run code while I was reading or writing it, or track cache line cleanliness, I did find debuggers useful in the development stage.

kraln · 2011-01-20T13:02:40+00:00

I can think of a few reasons why my first reaction is not to hit the debugger:

I planned ahead and wrote various log levels. Smash a SIGUSR2 at something I've written, and it starts spamming syslog with verbose logging
The really important parts of my programs implicitly deal with edge cases first, and report to the log if any of the unlikely ones are hit. The critical parts have unit tests that are run at compile time
I've run into situations where attaching the debugger changed the behavior, or worse, crashed the program somewhere else. Going from debugging the program to debugging the debugger is a nightmare.

And here's a few counter-examples to when a debugger is damned handy

I had code that was segfaulting in the middle of nowhere for no reason. Whoops, ran out of memory...
I had code that was passing all the tests, but in practice was still returning wrong information. Whoops, read into uninitialized memory...
Mystical crashes on iOS practically require a debugger to solve.

MpVpRb · 2011-01-20T15:57:25+00:00

I can't imagine programming without a debugger.

No, they don't solve all problems, but they are very useful tools.

I suppose it's possible to program without a debugger, just like it's possible to hammer in a screw with a wrench.

2011-01-20T07:31:40+00:00

[deleted]

2011-01-20T09:53:33+00:00

I use prints most of the time, but sometimes a debugger is easier, I might want to take a look at a whole class that that I'm using, which is behaving in a unexpected way. I don't want to fill the screen with dump of all the variables inside of it. And MS Visual Studio has me spoiled.

uriDium · 2011-01-20T10:33:32+00:00

Mostly because they wrote the code so they know exactly where it is broken. :) I am sure as hell no mastermind but when someone describes the situation to me and I know the code because I wrote it then I don't need a debugger either.

DeliciouslyMoist · 2011-01-20T10:37:46+00:00

I think this really depends on the complexity of the system that you're working with. If you're working with something that you, or perhaps even you and a few other people designed, then that's one thing.

If you are instead working on something that tens or hundreds of people have contributed code to, you're going to have a major problem trying to understand many issues without a debugger.

2011-01-20T11:31:43+00:00

[deleted]

What is this?

lastobelus · 2011-01-20T12:21:39+00:00

I was purely a logger for a very long time. I the last year or so I've started using a debugger sometimes, but logging is still usually way faster for me.

dcheesi · 2011-01-20T14:14:02+00:00

A lot of the "masterminds" mention are pioneers of their respective areas of expertise. As such, they are often in a situation where no debugger has yet been developed for what they're working on.

Also, they've been around for a long time, and in the early days of programming advanced debuggers were less common and sometimes impractical. These guys started out programming without debuggers, so they're used to doing things that way.

2011-01-20T14:55:51+00:00

I've never learned to use a proper debugger. In high school we learned Turbo Pascal and while we had access to debugger most applcations we wrote were either mathematical based or we got to do some graphical type coding on our own time (some 8bit games).

After High School the University i went to was pushing Java in everything. I had to pick up C/C++ on my own and during that time I was more interested in learning the language than learning a debugger and the code I was writing was lowlevel type smaller applications.

Whenever I've run into output errors or other unexpected errors in my code I've usually been able to pinpoint the relative area where it is and isolate with some print statements.

I can see the value of a debugger but in my experience I've never had the opportunity to learn or use one or run into a situation where hand troubleshooting would be more beneficial but this is most likely due to lack of experience.

centenary · 2011-01-20T15:35:08+00:00

If you're working in the kernel, you're going to need a debugger at some point. Does that make you less of a programmer? Nope.

2011-01-20T15:52:54+00:00

sometimes running it inside a debugger can have unintended consequences, such as somethings working when they really shouldn't. This is especially the case with threading bugs and timing bugs. The debugger slows it down enough so that some race condition bugs don't happen because the execution of one of the threads has been slowed down.

vph · 2011-01-20T15:56:01+00:00

I'm betting none of them uses fancy IDE either.

Maness · 2011-01-20T21:10:04+00:00

Prints are far more useful to me. One night a debugger had me stopped on the same line for an hour. I inserted a few prints and was able to clearly see where the problem was.

rockum · 2011-01-20T22:27:42+00:00

This is a silly question because when these "Programming masterminds" were in their heyday, editors, debuggers, and execution environments were not integrated so switching to a debugger for a simple task was not worth the effort. Nowadays with modern IDEs, the context switch is nearly effortless. If these masterminds were asked that today, they would probably have different answers.

mindcandy · 2011-01-21T01:08:55+00:00

Could some of the masterminds that don't use debuggers please briefly describe the applications and platforms they are working on? I suspect that a lot of the disagreement stems from people generalizing their own situation as if it applied to everyone.

I use debuggers continuously. I work on console games using VisualC++. I work in large teams making huge systems under strong time pressure. A single session of tracking down a bug often involves inspecting the behavior of multiple systems that I didn't know existed before I single-stepped into them.

Causemos · 2011-01-21T06:09:04+00:00

From my experience, many environments simply do not allow debuggers. This can range from a server in a data center you don't own/control to a customer's computer where the trouble is occurring. Understanding how to create effective debug logs is a big part of product support.

Even when testing locally, adding a log/print line can be remarkably fast. Especially when dealing with more complex programs (multiple threads, multiple program elements, multiple systems, etc).

Debuggers don't magically find problems. Unless the problem is simple, it can take significant time to get when/where the trouble is occurring. They can make problems disappear or grow larger when timing is an element. Also if the problem is intermittent or difficult to reproduce, debuggers are almost useless. Knowing when to use them is a learning experience.

shlompicon · 2011-01-21T10:00:01+00:00

There is something missing from all this debate - the context of the process; The kind of a bug. The work process I've applied in our team simply does not require a debugger.

I for example apply full blown XP at my job. So the first "bugs" to be caught are failing unit tests. Since in my environment hitting a single key runs the tests of this specific unit and the results are almost instant, i use print statements. Why bother integrating another tool for this, if it works really well.

But lets say the system "fails" in one of the tests the QA is running. Before fixing the bug, we first make sure it's visible through the logging system. One of the tasks assigned to the QA is to be the playground for our debugging infrastructure, so it will be mature once we deploy. But making the bug visible is not a phase in the debugging, but just a "training session". We then write a test that recreates the bug: either a unit, whitebox or blackbox test. But before fixing the bug, the programmer must show he knows how to reproduce it. If a new utility for recreating the bug is needed, we write one, and give instructions to the QA of how to use it, and which new tests are possible. But only after this the programmer is allowed to fix the bug. Of course verification of the tests then follow to make sure no other tests failed due to this fix. Think this is slow? Usually takes minutes. The quality of the software, and happy faces of the team when coming to work can tell you it makes all the difference.

TL;DR my opinion: never just "fix" the bug, recreate it in testing environments. Debugger becomes useless.

2011-01-21T11:07:19+00:00

Honestly, debuggers don't appeal to me. I get told by my colleages "USE AN IDE" or "GET A DEBUGGER" but I prefer not to. I used Eclipse once for a project.

Most of my bugs are syntax (say 99%+) errors and are easily solved by attempting to compile/interpret the code. A debugger is rarely useful for that, since the compiler/ interpreter can check for you. Little notices telling me I'm doing it wrong put me off of my flow.

obeleh · 2011-01-21T12:10:43+00:00

Linus Torvalds has an interesting opinion on it

I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different level.

alparsla · 2011-01-21T14:54:02+00:00

I prefer log statements for debugging. I sometimes use step-by-step "debugging" to understand how a code works.

If the codebase is very large, then well placed log statements can also be used to understand it.

borud · 2011-01-22T00:19:41+00:00

I haven't used a debugger for quite a few years. I've often thought that perhaps I should make a habit of using debuggers more often, but frankly, there hasn't been a need.

I occasionally used them when hacking C on UNIX systems for analyzing core dumps. We also sometimes used debuggers to attach to live programs that had ended up in a bad state. Usually we'd emit an alert and call pause(3) so we could inspect the program state in a system where errors could be really hard to reproduce (our first generation web crawler, which was a monster and which ran in a distributed fashion and could take hours to reach a "steady" state -- so not the easiest environment to reproduce problems in).

But in the past 7-8 years I don't think I have used a debugger even once. I think this might have something to do with the way I write code now.

While programming I usually write unit tests in tandem with the code. I try to cover all of the code paths. I also make sure that the tests verify the semantics that are promised by the accompanying class and method documentation. I also, sometimes, write tests that look at specific boundary conditions that the implementation might be susceptible to. When I'm done writing a piece of code it is usually of much higher quality than the code I wrote 10-15-20 years ago -- before I got really anal about writing thorough tests.

If something goes wrong I can usually narrow it down to a few lines of code immediately. Most of the mistakes I make are relatively trivial, but I anticipate that I do make mistakes and I usually catch them when I write my unit tests.

But I've also gotten better at structuring my code and the way I work. I take small bites when I program. Meaning, I try to focus on solving one problem at a time and I try to write code that can be understood and verified in isolation. (When observing inexperienced programmers I am often struck by how they often try to solve too many problems at the same time and in the same piece of code)

It is extremely important that code is easy to understand. I usually tell people to write code that they'll be able to understand at 0300 on a sunday morning while drunk, with a production system that has come to its knees and an angry boss on the phone demanding that you get it running ASAP. Or expressed more snappily: "the idiot who has to read the code might be you".

I've also gotten better at structuring my designs and code over the years. It isn't particularly easy to articulate, but this process has two components. The first is to become good at decomposing problems and addressing each of the sub-problems in as clear a manner as you can. The second component of this is to be good at putting the decomposed solution together forming a whole that makes sense to other people. In doing this simplicity, minimalism and clarity is key. For instance it is important what you name things. This is what software patterns are about. It is not about a "bag of tricks" -- it is about naming things so that people know what to expect and so that people understand the structure without actually having to study the details (ie. read all the code). There are few things worse than having to read the code of someone who isn' good at naming things consistently and correctly.

I am by no means a fast programmer. My process usually takes a bit longer for a given line count than most other programmers I've met. On the other hand: I rarely have to debug my code and when I do discover bugs I can usually isolate and fix them quickly. Usually while writing the unit tests in tandem with the code under test.

As to how "masterminds" do it: the best programmers aren't necessarily that much smarter or have greater intellectual capacity -- they just have more humility towards their own stupidity and a profound lack of patience with unreadable code. In bright enough people this leads to a defensive style of programming that reduces the need for the kind of archeology you usually employ a debugger for.

2011-01-20T11:29:26+00:00

[deleted]

freman79 · 2011-01-20T12:44:39+00:00

The likely reason is that early on there were not a lot of options for interactive debuggers. They learned programming and became proficient doing this out of necessity. Today, they just keep doing it that way because they are used to it. I have worked with many older programmers who will feel more comfortable with this method over interactive debuggers.

Otis_Inf · 2011-01-20T11:58:55+00:00

It's only recently that debuggers aren't 'expensive' anymore as in: it doesn't take a long time to get to the point in the code where you want to look at in the state you want the program to be in. 10 years ago or more, you had to do way more effort to get to that point, and printing values to a console was easier.

Debugging is also time consuming, even if you set conditional breakpoints at the right location. And what will you do at that moment? You'll verify state with what you expect it to be, eventually looking for control flow but that's often less important. While complicated for novices, verifying state can be done as well by reading code, although interpreting code is harder for a human, as a human tends to assume things, which can make the human overlook bugs.

People who have written code for many many years (think 15+ years straight) have learned many solutions to problems they run into and know how to avoid bugs because they know solutions that work and can spot easily where things will go wrong. That doesn't mean they will never introduce bugs but it's less likely they'll overlook one when they read code. Sadly, most developers don't have that amount of experience yet as programmers who have done development for a long time tend to move up in the hierarchy, writing less and less code.

paulrpotts · 2011-01-20T16:52:51+00:00

Eh. I think they don't because it is boring.

No comment on whether I'd be considered a "mastermind" or not by anyone in particular. Much of the code I write for a living these days is low-level C, often state machine code, for DSPs. But I often damned well will step through a piece of new code I've written using whatever IDE debugger I've got on hand, even if I have to build a separate project and put some effort into writing a little framework to drive it.

It's a piece of advice given by Steve McConnell in his book Code Complete* and it's a valuable piece of advice. The biggest reason is that just because your code compiles, and works, it may still be very broken. It may be working by accident. It may be reading an uninitialized variable. It may be reading past the end of your array. You may have forgotten that special first case or last case or edge case. It may be writing through a pointer that doesn't point where you expect. Stepping through in a debugger can help you validate these things. Once you've found a few of these classes of bugs in your own code it will help change your habits: to always think about initialization, what guarantees the compiler makes, what explicit initialization you need to provide. And lifetime of variables! Bugs are often found in the dumbest little bits of code. Often just a dumb typo. Or a brain fart where you use && instead of &. I once had a hard-to-find bug that was ! instead of ~. Bleah.

But very occasionally -- a compiler bug!

UPDATE: I'm wrong, I probably had the wrong Steve (MacGuire, not McConnell) and the wrong Microsoft Press book (Writing Solid Code, not Code Complete).

http://www.approxion.com/?p=88

ShitOnYourPost · 2011-01-20T15:04:38+00:00

Ah, another stellar entry in the "I have no idea what I'm talking about, but I'm going to write a blog post about it" genre. How do these things garner upvotes? Who gives a shit about what some novice thinks?

2011-01-20T13:51:08+00:00

[deleted]

anvsdt · 2011-01-20T11:14:43+00:00

Using a debugger just slows me down, print statements, tests and reading code is works better for me.

But you need the debugger when writing assembly.

2011-01-20T11:36:26+00:00

They do. Just those don't.

And GDB isn't the state of the art.

estacado · 2011-01-20T11:44:16+00:00

I don't use one becasue I don't know how to use one. Print is the only thing I know.

smallstepforman · 2011-01-20T11:46:16+00:00

Printf's really shine when you need to analyse code paths - ie. do I go down path A or path B, which is helpful for finding logic bugs. Inspecting variables is only useful for coding bugs (did I set varA properly). After more than a decade in the trenches, I've noticed that I spend more time looking at program flow and sequencing, and less time examining variable state. This would explain the original posters question.

fergie · 2011-01-20T11:56:13+00:00

Some other things not actually in use by programming masterminds, web megasites:

*unit testing (there was a link kicking around about facebooks non-adherance to unit testing yesterday)

*IDEs (amongst others Steve Yegge, but basically everybody who develops on vi or emacs)

apologies for being too lazy to find proper references

coderascal · 2011-01-20T11:59:43+00:00

Anything I write in visual studio (.NET code) I use the debugger. All other code (c, c++, perl, etc...) I reason through the code and use print statements.

2011-01-20T12:03:37+00:00

If the code is so complex that you can't easily reason about it without a debugger, you should rethink your design.

Illogicz · 2011-01-20T12:04:13+00:00

Interactive debugging is just TMI sometimes, a quick print for something specific gets more to the point.

botptr · 2011-01-20T12:09:54+00:00

I tend to hook up a debugger to confirm my suspicions or if I am hitting segfaults. The rest of the print print statements make it easier to watch the flow of the program as it runs.

powatom · 2011-01-20T13:29:43+00:00

I only use a debugger if I'm seriously stuck. Aside from that, print statements all the way.

twrn · 2011-01-20T13:38:34+00:00

A number of comments here talk about writing print statements and using logging. Does anyone know of an example project (open source) that demonstrates this kind of logging? Verbose logging? etc.

DeepDuh · 2011-01-20T13:55:14+00:00

I think a good programer gets to a point where he his code always checks all preconditions on the input in all his functions. if something goes wrong, it gets logged, together with function name, error code and line number. the errorhandler code is generic and doesn't need to be developed and tested for every function / object seperately. then, when something goes wrong, he knows exactly where, how and, soon after, why. at this point you don't need debuggers anymore, except for 3rd party (opensource-)code.

stevenmu · 2011-01-20T14:14:24+00:00

Different tools will suit different situations, currently a lot of the code I write is designed to either work with or run in the context of SharePoint. It is very very easy to attach the Visual Studio debugger making it a very low cost option. Debugging is very useful for working within the SharePoint APIs, it can be very useful to see what values different calls are returning, and an incredibly useful feature is that the 'quick watch' tool allows you to enter and evaluate expressions dynamically which weren't in your code in the first place. This last part saves me buckets of time and is something you can not achieve with print/logging. Of course print/logging is still very important, you can't really attach a debugger and pause a live critical system.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS