5 ms·

+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 f

+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-versus-logging/ http://henrikwarne.com/2014/01/01/finding-bugs-debugger-vers... [2] http://henrikwarne.com/2012/10/21/4-reasons-why-bugs-are-good-for-you/ http://henrikwarne.com/2012/10/21/4-reasons-why-bugs-are-goo...

mtrn 11y ago
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 effective programmers, you will discover that they should not waste their time debugging - they should not introduce the bugs to start with.
- henrik_w 11y ago
  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.
  - userbinator 11y ago
    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.
    - taeric 11y ago
      All too often, the "carefully designing" becomes some sort of masochistic ritual where all errors are attempted to be piped through a single tool in the dev chain. Static typing is popular nowdays. As are high level functional strategies. It is great when these work. Or when you have a high level team that doesn't abuse the system at all and gets things done using these strategies. I have seen too many times where the result is a system that even the creator does not fully understand. Worse, what should be simple changes turn into giant modifications of a Rube Goldberg machine.
      - mannykannot 11y ago
        Just because it can be done badly is not a reason for abandoning it. To continue the aviation analogy, the solution there was to ensure that the people designing airplanes have had fairly rigorous training and that they have an adequate understanding of the relevant theory.
        taeric 11y ago
        Apologies for missing this earlier. I was not advocating for quitting. I was advocating for using more than a single tool.
sebastianconcpt 11y ago
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
megaman22 11y ago
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! ;-)
- exDM69 11y ago
  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.
  - AnimalMuppet 11y ago
    > 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. If you have a race condition in a multi threaded program, a simple printf may be enough to change the timings and make the bug disappear. But a breakpoint and stepping in a debugger is guaranteed to completely change the timings (unless your timings are on the order of minutes).
    - mannykannot 11y ago
jakozaur 11y ago
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).
ParadigmBlender 11y ago
Thanks for linking to your blog. I enjoyed your writing and look forward to following it.

mtrn 11y ago

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 effective programmers, you will discover that they should not waste their time debugging - they should not introduce the bugs to start with.

henrik_w 11y ago
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.
- userbinator 11y ago
  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.
  - taeric 11y ago
    All too often, the "carefully designing" becomes some sort of masochistic ritual where all errors are attempted to be piped through a single tool in the dev chain. Static typing is popular nowdays. As are high level functional strategies. It is great when these work. Or when you have a high level team that doesn't abuse the system at all and gets things done using these strategies. I have seen too many times where the result is a system that even the creator does not fully understand. Worse, what should be simple changes turn into giant modifications of a Rube Goldberg machine.
    - mannykannot 11y ago
      Just because it can be done badly is not a reason for abandoning it. To continue the aviation analogy, the solution there was to ensure that the people designing airplanes have had fairly rigorous training and that they have an adequate understanding of the relevant theory.
      - taeric 11y ago
        Apologies for missing this earlier. I was not advocating for quitting. I was advocating for using more than a single tool.

sebastianconcpt 11y ago

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

megaman22 11y ago

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

exDM69 11y ago
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.
- AnimalMuppet 11y ago
  > 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. If you have a race condition in a multi threaded program, a simple printf may be enough to change the timings and make the bug disappear. But a breakpoint and stepping in a debugger is guaranteed to completely change the timings (unless your timings are on the order of minutes).
  - mannykannot 11y ago

jakozaur 11y ago

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

ParadigmBlender 11y ago

Thanks for linking to your blog. I enjoyed your writing and look forward to following it.