Tag Info

Hot answers tagged

139

What looks like guessing from the outside often turns out to be what I call "debugging in your mind". In a way, this is similar to grandmasters' ability to play chess without looking at a chess board. It is by far the most efficient debugging technique I know, because it does not require a debugger at all. Your brain explores multiple code paths at the same ...


93

The usual suspects are: You thought it worked yesterday, but after a full day of work you were too blind to realize that it didn't work. This morning you no longer can refer to what was in IDE cache memory yesterday. The workstation has rebooted last night or a nightly maintenance operation cleared /tmp directories. Something has changed in the code base: ...


92

Well, it's pretty simple: not all exceptions are bugs (and similarly, not all bugs manifest themselves as exceptions). As example of an exception that's not a bug, if you're reading a file from a USB drive and someone yanks the drive out of the socket. That's going to raise an exception (in most languages that support exceptions, that is). But it's not a ...


79

Quit. No, not your job! Just get up and go home. You're done for the day or the weekend. 19 times out of 20 when you come back to the problem next, the solution will present itself within an hour.


78

By using a debugger. For the most part, this is also what an IDE does behind the scenes -- it just wraps the experience in a GUI. On Unix, one of the most commonly used debuggers is GNU gdb, which has largely supplanted the earlier Unix debuggers such as dbx. To get an idea of what debugging looks like / feels like from the command line, you can look at ...


73

Many answers have questioned your boss' methods/tactics/metrics/etc. But that is beside the point. Maybe you ARE slow. Every room of developpers has to have ONE that's slower than the rest, right? (That's just straight set-theory.) So let's assume that's you. The answer is, WHY are you slow? (Clearly that is the question you have to answer before you can ...


60

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it? You should give it your best effort. I know that sometimes there are conditions and environments that are so complex they can't be reproduced exactly, but you should certainly try if you can. If you never reproduced the bug and saw it for yourself, how ...


57

Reproducing a bug that rarely happens. Especially when coping with multithreading.


56

Your boss may be correct: you may be "underperforming" (more on that in a minute). But it may not be just your level of competence that's to blame. I don't think it would be a reach to suggest forces outside your control are causing you stress, which is having a negative effect on your performance. Let's have a look at a few of the reasons your boss may now ...


49

1) If it's not working today, it wasn't working yesterday either. You thought it was working, but it wasn't. 2) There is a problem, and it must be solved. Don't think about who's responsible for this or about blaming others. If nothing has changed between yesterday and today (like I presume reading your question), it means you should do a better job at ...


45

Unit testing. After I started applying unit testing I found that the code I wrote became better structured. It was then easier to avoid and spot bugs. I spent less time debugging, but more time with writing unit test. I also think that the time invested in unit tests has a better return of investment then debugging. After a debugging session I just fixed ...


44

Before ten hours go by, I would get some help. Describe the problem to someone else, anyone else, even your rubber duck. Ask someone else to take a look at the code, or step through it with them. Isolate it. Delete a bunch of stuff, then bring it back bit by bit until the problem reappears. Get some sleep!


41

A Duck From http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html: A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.


40

Build an SSCCE (short, self contained, correct example). If the bug disappears when you remove some of the extra details for the SSCCE, then you found it. Otherwise you will have an SSCCE that you give or post that ideally eliminates the code that you are concerned about sharing.


40

The more I know a code base, the less I need a debugger (but I'd still check the reported error, it is an important clue in any reasoning). It is a fine tool to understand some dynamic behavior of small to medium complexity, but I often find out that it focus me on the details instead of the bigger picture. And after a while, that's where the problems are: ...


39

Yes its very important About that particular candidate, it is possible that s/he was not familiar enough with code-base x to debug it. A good problem solver should be able to debug, as all that is usually required is to have a very logical method/approach.


39

The best programmers are masters of debugging. You're worrying too much friend. Using the debugger every day is a sign that you live in the real world.


38

You want to look at a logging framework, and maybe at a logging facade framework. There are multiple logging frameworks out there, often with overlapping functionalities, so much so that over time many evolved to rely on a common API, or have come to be used through a facade framework to abstract their use and allow them to be swapped in place if needed. ...


38

Some work environments are unworkable. I've seen environments in which no one could survive (save for those who were in at the beginning) because so much was undocumented and questions were so vehemently discouraged. You really need to be honest with yourself regarding the expectations and the resources provided to help you to meet them. The problem may not ...


36

I really have a hard time seeing where I went wrong The major mistake was that you reinvented the wheel. Instead of using default mecanisms for logging, you invented your own, which displayed the information within the page. A logging framework would rather store logs in log files, letting you to consult those logs later by SSHing to the server. As for ...


35

I would say that not using a debugger is a sign of inexperience. Stepping through code line by line is the best way to trace the flow of execution.


35

Unit testing, so that you know whether your code works in the first place. At least some amount of upfront design, so that you know what you are coding. Code reviews, because two heads are better than one, and four eyes are better than two. Not to mention that even trying to explain your code to someone else reveals many problems. Version control, so that ...


35

They may not be bad programmers, but they are probably terribly inefficient troubleshooters. I tend to follow the advice from Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (David Agans), and this one falls squarely under the guidance of "Quit thinking and look"


35

It affects the efficiency in a very good way. I feel that it's used too seldom by developers. Not only is it good for debugging but it can also give you an insight in profiling. For example when line stepping you can feel "ahh" this line took a little too long time to execute and you get a feeling for where the bottlenecks in your app are.


34

I can see a DOS programmer fiddling away and crashing the entire OS when he made a mistake. Yeah, that's pretty much what happened. On most systems that had memory maps, location 0 was marked invalid, so that null pointers could be easily detected, because that was the most common case. But there were lots of other cases, and they caused havoc. At ...


32

I would say that it is essential to understand every single detail about why some bugs were occurring and why certain changes eliminated those bugs, and it is also common among developers to sometimes get the program working without really knowing the details about why the fix worked! The art of changing things until a bug disappears, without understanding ...


31

First, note: this answer may only apply to certain regions where it is illegal to dismiss an employee without severance. That said... This could be a case of Constructive dismissal and which is illegal. The tactic is to demoralize and lower the self-esteem of an employee until they quit the job. It's a way for the company to save money by not having to pay ...


30

The preferred approach in agile development would be to get them fixed as quickly as possible, by whomever is available. This is simply because the ownership of the code does not fall to any one person, but to the entire developer group. If one individual is consistently causing bugs, that is another issue that needs to be addressed separately.


29

I've seen hundreds of bugs that would have been solved faster if someone had written more asserts, and not a single one that would have been solved quicker by writing fewer. [C]ould [too many asserts] potentially be a bad programming practice, in terms of readability and maintainability[?] Readability could be a problem, perhaps - although it's been my ...


29

Logging. Add a bunch of logging to the related module, set it to debug and get the user to send you a copy of the log when the error occurs again. If you can reproduce the error, set your logger to go to the console, and try to reproduce it. Look for anomalies that only occur when the colour is wrong. Back track. Find all references find any line of code ...



Only top voted, non community-wiki answers of a minimum length are eligible