Debuggers are strange people


My last post on what to look for in a good programmer attracted some debate which is a good thing.


I thought that I would throw out some ideas on things that might be handy in someone who debugs a lot.


 




1. Procedural thinking. We very often perform the same actions in the same order.


2. A good memory. Experience is that which enables us to recognise a mistake when we make it again. When debugging, you are looking for things that are unusual. To spot them, you need to remember what the usual is like.


3. An associative mind. Often a new problem is similar to but not identical with previous problems. Seeing similarities can short circuit the troubleshooting process allowing you to leap forward. Of course, sometimes this will mislead you.


4. Pattern recognition. A lot of time when debugging is spent looking at apparent noise. We sometimes refer to this as fishing. Imagine that you are debugging a leak and all that you have is a hang dump. Looking at the activity of each thread is unlikely to be revealing. Looking at the assembler will not be revealing. That leaves only one thing to look at – the data. If you can spot patterns in the data then you are more than half way to solving the problem. For example, largish hex numbers that consistently rise by smallish amounts as you look forward in memory are immediately interesting. They could represent a VTable or a table of objects allocated sequentially. Data structures make patterns as well although they are less obvious. Look for order in the chaos. Equally, look for chaos in the order.


5. A suspicious mind. When looking at code, all code is guilty of doing something wrong until you have established that it is innocent. A good programmer will see the intention. A good debugger will try to see what is unintentional.


6. Flexibility. Sometimes one approach works and sometime you have to try something else.


7. The ability to work backwards. Very often, the question to ask is "How did I get here?"


8. Patience. Stepping through code is dull. Sometimes it is the best way to get a feel for the flow of a routine.


9. A rather obsessive nature. No well balanced person could spent weeks hunting for a tiny error


10. A fondness for coffee. The hours are long.


Does anyone else have any suggestions?


Signing off


Mark


Comments (2)
  1. ChrisC says:

    11. Intelligence.

    Though it is often overrated, this is needed in a person who will need to take in all of the details of multiple applications quickly and determin if they are working correctly (without bothering me or the bus person excessively)

    Personally I see people move to QA when it is revealed* that they don’t have talent as developers. (*=sometimes only revealed to them, not mgt/others)

    12 Pattern recognition in found errors.

    If the app has an error when you press save, and fails to save the new address… don’t enter three more bugs to tell me that the city state and ZIP won’t save either.

    If the prog is doing their job they will notice the city/state/ZIP.

    However: Do check items of different types; even if they’re in the same screen. For a personal record that might be: failed to save phone, last name, or tax id#… because those MIGHT NOT be near the same code. Example: they might not be in the same db table. (multiple addresses per person, multiple phone per person, one name per person, one tax id# per person/business)

  2. MSDN Archive says:

    Valid points.

    I don’t know how much of #11 you need though. I seem to get by without very much 🙂

    May I suggest a number 13?

    13. The ability to fall back on what is known when in unfamilar territory. When all else fails, basic troubleshooting is good and always will be.

Comments are closed.

Skip to main content