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

11–20 of 80 posts

Re: Why debugging is all about understanding

#11

Post by sebastianconcpt »

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...

They are good for being faster to debug in completely different ways. Logs do not provide you of exploratory inspection nor interaction with the objects present in a given point of the stack (a specific closure). On the other hand, logs are valuable when you want to see the chronology of what's happening, specially when there are async or parallel things going on

Re: Why debugging is all about understanding

#12

Post by mhomde »

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. What has changed? What could have caused this bug to appear?

2. Verify fundamentals: Is it actually running the code I think it does. If I change something that should change something, does it change? If I break something does it break?

3. Verify Input: Make sure it's valid

4. Verify output

5. Timing issues?

6. Slowly remove code "around" bug until it works again

7. Or start back at something you know works and add back code until it breaks.

8. Break out the functionality into an isolated environment so you can test it separately so you'll know if the problem is within the feature or a side-effect of something else

9. If your code makes it too complicated to see and find the bug refactor until it isn't.

10. Go to sleep / Go on a walk. Let your subconscious process it

and finally, lot's of bugs are made self evident by well structured and refactored code, so don't get too busy working on the symptoms rather than the root cause.

Re: Why debugging is all about understanding

#13

Post by userbinator »

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 know how to do it mentally" --- it fails miserably when debugging, precisely the time when the machine can't do it.

I've heard it phrased thus: "If you don't understand precisely what you need to do, what makes you think you can tell a computer how to do it?"

Re: Why debugging is all about understanding

#14

Post by henrik_w »

mtrn wrote: post #10
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 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.

Re: Why debugging is all about understanding

#15

Post by megaman22 »

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! ;-)

Re: Why debugging is all about understanding

#16

Post by JustSomeNobody »

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…

I think a pencil and paper are a programmers best friend. I find it helps me work through complex logic easier when I'm debugging. I find it helps me write cleaner code when I'm tasked with something challenging. I keep a notebook next to me when coding or debugging. I try to write down my thought process when writing new code. When debugging, I write the recreate steps (if there aren't any already), and any insteresting notes about the bug while I'm tracking it down. I write down anything I think the 'fix' may impact (I also email the team about those). Basically anything and everything.

Re: Why debugging is all about understanding

#17

Post by cognivore »

While understanding if of course important, sometimes it's possible to just "zen" the bug. After working with the same codebase for long enough I've been able to see behavior and think, "That's probably down in the login handling code..." and then start there. I don't necessarily have to understand the login code, but it's gnarly, and I've seen similar bugs before from it. I'm right more often then I would expect. When the zen fails it's off to the methods mentioned in the article.

Re: Why debugging is all about understanding

#18

Post by mwcampbell »

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…

But how can I mentally execute code if the whole point of the code is to interact with a third-party OS facility or application that's closed-source and therefore opaque? In that case, my mental execution of the code will depend on a mental model of the third-party component that's probably incomplete. Might as well just let the machine run the real thing.

Re: Why debugging is all about understanding

#19

Post by userbinator »

mwcampbell wrote: post #18
userbinator wrote: post #13

Earlier quoted context omitted.

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…

But how can I mentally execute code if the whole point of the code is to interact with a third-party OS facility or application that's closed-source and therefore opaque? In that case, my mental execution of the code will depend on a mental model of the third-party component that's probably incomplete. Might as well just let the machine run the real thing.

It does get a little more difficult when execution flows into code you didn't write, but you can still validate your post/pre-conditions at those boundaries.

Re: Why debugging is all about understanding

#20

Post by jakozaur »

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...

Also if you run on production scale it is worth investing in log tooling.

It's so much easier if you can search what has happened instead of guessing. Also customer experience is much better if you tell them that is fixed instead of asking for details :-).

Disclaimer: I work for log management company (Sumo Logic).

Post reply on HN