Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why debugging is all about understanding

futurice.com

Post reply on HN
Print view View original

21–30 of 80 posts

Re: Why debugging is all about understanding

#21

Post by userbinator »

henrik_w wrote: post #14
mtrn wrote: post #10

Earlier quoted context omitted.

I remember stepping through many programs when I started programming as a teenager. It was quite fascinating to see everything in slow-motion. Over the years, I had less and less use for intense debugging sessions, but I've been reading and writing logs all the time. Today, I see server side code without logging statements, I immediately ask myself, how do the authors debug this thing? Related: > If you want more eff…

Had to google the quote about wasting your time debugging to see that it was from "The Humble Programmer". I completely disagree with it! There will always be bugs. It's good to strive to avoid making mistakes, but however hard you try, there will be bugs. It is counter-productive to pretend there won't be any.

It's good to strive to avoid making mistakes, but however hard you try, there will be bugs.

That's basically what the quote is implying - you should not be throwing things together and hoping it will work after debugging, but carefully designing to avoid bugs, so there won't be much if any debugging required.

An analogy to this can be found in the aviation industry: it's known that pilots do make errors and planes do crash, but such errors are treated as unacceptable and they try their hardest to minimise them. It's been a very successful strategy.

Re: Why debugging is all about understanding

#22

Post by mattmanser »

mhomde wrote: post #12

Over the years I've become more and more convinced that debugging has done a lot to develop my problem solving skills and analytical thinking in general. It's like being a full-time modern times Sherlock Holmes with the crime scene and tools neatly at your disposal. Usually breakpoints and stepping through code solves things pretty easily but some bugs can be real stumpers. Here's some of the tools I tend to use: 1.…

1. Can you consistently replicate the bug?

2. Are you sure you can you consistently replicate the bug?

Re: Why debugging is all about understanding

#23

Post by jorgeleo »

If debugging is about understanding, then it will be good to use a language that lets you embed the knowledge in the coding. Knowledge should be easier to read from the code leading to a faster understanding, and more bugs are catch by the compiler instead by the end user.

This is a great page (with a video) about what I mean

http://fsharpforfunandprofit.com/ddd/

Re: Why debugging is all about understanding

#24

Post by dr_zoidberg »

mattmanser wrote: post #22
mhomde wrote: post #12

Over the years I've become more and more convinced that debugging has done a lot to develop my problem solving skills and analytical thinking in general. It's like being a full-time modern times Sherlock Holmes with the crime scene and tools neatly at your disposal. Usually breakpoints and stepping through code solves things pretty easily but some bugs can be real stumpers. Here's some of the tools I tend to use: 1.…

1. Can you consistently replicate the bug? 2. Are you sure you can you consistently replicate the bug?

Those should have been 0 and 0.1 in his list. Agree with all 12 points. My little grain of sand: use all the tools available to avoid bugs: a good IDE and/or code linters/inspectors can work wonders on a codebase. I've seen people still programming with "just a text editor" (not Sublime, vi, emacs or any powerfull text editor, I'm talking little less than Notepad with syntax highlighting) telling you "it's just I don't like IDEs" when asked about it.

Re: Why debugging is all about understanding

#25

Post by spiralpolitik »

userbinator wrote: post #13
JustSomeNobody wrote: post #5

Writing code is about understanding, also. I've seen developers bang away at a problem for days and not be able to describe how it "works" in a code review. They just tried every crazy thing they could think of until it eventually returned results that looked correct. Don't be that kind of developer. For one, all the other developers are going to make you maintain that code for the rest of your life. Two, never be to…

I agree, understanding certainly can't be emphasised enough - I believe that a good programmer must always be able to understand enough to "mentally execute" - manually stepping through code, possibly with pencil and paper or a whiteboard, and making sense of the results at each step. There are some who argue against this, and their argument is effectively "if the machine can do it for you, why should you need to kno…

This scales up to about 10-15 lines of code before it becomes impractical in most modern imperative languages. Functional languages due to their higher level constructs get better mileage out of the technique but there is still a small practical limit to the technique.

It also doesn't work if your team isn't co-located.

Re: Why debugging is all about understanding

#26

Post by mhomde »

mattmanser wrote: post #22
mhomde wrote: post #12

Over the years I've become more and more convinced that debugging has done a lot to develop my problem solving skills and analytical thinking in general. It's like being a full-time modern times Sherlock Holmes with the crime scene and tools neatly at your disposal. Usually breakpoints and stepping through code solves things pretty easily but some bugs can be real stumpers. Here's some of the tools I tend to use: 1.…

1. Can you consistently replicate the bug? 2. Are you sure you can you consistently replicate the bug?

great points, thanks!

Re: Why debugging is all about understanding

#27

Post by exDM69 »

megaman22 wrote: post #15
henrik_w wrote: post #3

+1 for encouraging the use of logs as a debugging tool - they're often better than a debugger in my opinion [1]. Also, bugs aren't only bad - you learn a lot from them too [2]. [1] http://henrikwarne.com/2014/01/01/finding-bugs-debugger-vers... [2] http://henrikwarne.com/2012/10/21/4-reasons-why-bugs-are-goo...

I've found that it is often impossible to debug multi-threaded code in a debugger. Hitting a breakpoint and single-stepping through code on one thread smashes any other reads that are operating and expecting the thread that is stopped to respond in a reasonable timeline. It can also cover up race conditions, and just generally dork up anything that is time-related. Printf debugging forever! ;-)

If you have a race condition in a multi threaded program, a simple printf is enough to screw the timings and make the bug disappear, it's not at all better than breakpoints and stepping in a debugger.

In my experience, the only way to produce safe multi threaded code is to isolate the threading parts and synchronization and stress test them early on. At this point I use a combination of prints, random delays and simple asserts on invariants that the code should hold. Most issues are reproduced within about 10 seconds of 100% CPU core utilization. Some nasty corner cases may require minutes of grinding away.

Multi threaded debugging is an unsolved problem. There are no universal solutions to this problem. Conventional tools often fail so badly that it is best to write and test your multi threading / synchronization code in isolation, and then applying it to the actual workload which is tested in a single thread.

Another option is trying to build a formally verified model ahead of time (e.g. using Spin - www.spinroot.com) and then write the actual program after the model has been verified.

Re: Why debugging is all about understanding

#29

Post by brudgers »

It's an interesting and helpful article, the downside is that it perpetuates the use of the non-technical language of "bugs" and "debugging." Sure it's accepted jargon, but like most jargon "bug" doesn't really convey much of anything beyond a person's attitude. "Bug" is as unscientific as "weed"...a bug may be the wrong color text in some HTML or as in its origin myth, something preventable with a can of Raid.

Fault/Error/Failure provides a better language for talking about systems and their processes. It provides a diversity of solutions from changing the source code, to handling an error, to just letting it crash...the last is impossible to cast as a solution in the nomenclature of bugs.

There are times in which there the ambiguity of "bug" matches the necessary ambiguity of the context...just as there are times when describing the sun moving across the sky is useful. But the geocentric cosmological model breaks down when we're interested in predicting the location of Jupiter in the night sky.

Post reply on HN