What are effective ways to log and track programming mistakes?

Question

On occasion I've heard people discuss the benefits of keeping track of programming mistakes, if for no other reason than it increases awareness of common errors. I've started to keep a list of bugs that I find in my code, along with what could have led to them. The main question I have is this:

• What information related to my mistakes should I be keeping track of so that I can improve as a programmer?

And a couple other questions related to this:

• How do I use this information once I start logging my mistakes?
• Is tracking mistakes truly beneficial?

Answer 1

• what was the mistake
• how can it be avoided

add the latter to an appropriate checklist, and refer to it as often as appropriate

Answer 2

This is only useful if you are actually vigilant with tracking and reviewing. When I was working on a team, no matter how much documented that for example our servers in the production environment were natted and would not be able to resolve their own domain names or public IP addresses, every 6 months, I'd get a call at 4 AM from the deployment team or dev team that a new developer was responsible for, and they either forgot or were unaware.

I remember a particular engineer who was repsonsible for deploying and he had paper checklists, we built him deployment tools that forced him to record his checklist, yet he would always forgot to set the connection string (resulting in the 4 am phone call). Point is it's only worth it if your going to use it vigilantly.

I've found the best way to use this is by implementing your rules into a code analyzer like fxcop.

Answer 3

I would also want to ask the question of how much time would be required to accurately track the mistakes, and if that time could be better spent directly on improving the software instead. If you can do this in a minimal amount of time and are able to refer back to your records to prevent future mistakes, it may be valuable. In the long run though, I think it will be better to stick with an absolutely high level list of common mistakes you make.

Answer 4

I think tracking mistakes can be worthwhile, but in my experience it helps a lot to categorize them at some level.

Every programmer is going to make enough mistakes over the course of their career to fill an encyclopaedia. If you make a huge checklist out of all of them then you're never going to get any coding done because you'll eventually be spending all of your time going over your checklist. So: categorize your mistakes in some way that makes sense to you so you can rifle through your list looking at the most important mistakes for the sort of code you're currently working on.

Also, to add to the above as far as what to collect:

• what are the symptoms of the mistake (so you can find it later)
• how you actually solved it

Answer 5

I'd look for trends or similar types of errors that tend to recur. Once you're aware of the types of errors you make, you can be alert for them, or you can change your coding style to avoid them.

As an example, I worked very closely with my office-mate in a previous life. At one point I was halfway through my first sentence explaining some odd behavior, and he interrupted with, "increment your counter." I still double-check my loop counters today!

Answer 6

I think what is more useful than keeping a log of individual mistakes is making sure you come away with a real understanding of why it was a mistake in the first place. Most mistakes stem from a lack of understanding about one thing or another, correct that understanding and you eliminate an entire set of potential mistakes in the future. If I would log anything it would be what I learned from the experience that I didn't know before, not the specifics of the mistake that was made which is likely to be of limited usefulness when you look back at it later.

Answer 7

Instead of keeping a log of future mistakes, maybe you could review your bugtracker history, and try to find common types of errors which keep ocurring.

I'm so inspired I think I'll try this tommorow.

Answer 8

Yes, tracking your personal mistakes is beneficial. Refer to the SEI for numerous data points (here's one at random). One such methodology is the Personal Software Process (PSP). It's too long to go into here, but here's a book about it. There's also this free SEI publication on PSP.

If you balk at SEI and think Agile is the way to go, you'll probably get better mileage out of a book like Clean Code: A Handbook of Agile Software Craftsmanship (publisher website).

Bottom line: disciplined developer = good, undisciplined developer = bad.

Answer 9

"What information related to my mistakes should I be keeping track of so that I can improve as a programmer?"

Read other people blogs. Write your own. You don't have to publish it. But you do have to turn each mistake into a story.

Don't drown this in metadata. This isn't amenable to a database or even a bug tracker. A mistake is a story where someone made a bad choice and recovered from it.

Here's your outline.

• Context. What was going on.
• Situation. The problem you were trying to solve.
• What you did. Why it was bad.
• What you should have done. Why it was better.
• What changed. What you learned.

You should also record your successes in almost the same form.

• Context. What was going on.
• Situation. The problem you were trying to solve.
• What you did. Why it was good.
• What you learned.

When in doubt watch a movie. Seriously. Characters a confronted with choices, make mistakes and recover from those mistakes. That story line is the essence of drama. A mistake is the same thing.

Answer 10

Be careful what you log. Not every bad situation is a mistake. Some situations are inevitable or so far outside your control that nothing can be done about it.

Bad planning on someone else's part which puts you into panic-mode isn't your mistake. You can meticulously log everyone else's mistakes, but what's the point? If you're tracking what other people are doing, you should seek therapy.

Bad planning which provides inadequate budget, schedule or communication about changes may be a compound problem.

1. You didn't provide enough planning information up front.
2. In the scramble to cope, you made another mistake which lead to problem resolution and recovery.

In hindsight (which is always 20/20) you can see a decision which was wrong. However, at the time, it was based on best available information. That's not a mistake. Any sentence that begins "If we'd known that X..." is useless for mistake analysis. You can try to write a checklist of all the things you need to know next time you make that decision. But next time, you won't be making exactly that decision and some other piece of information will turn up missing.

• Never call other people's actions mistakes.
• Find the root causes. It's a root cause when it's something you can't control.
• Don't retroactively call information that turned up missing a mistake.

Answer 11

I have been thinking the same thing. For the time being I keep a little spreadsheet with bugs I correct. The purpose of this is to make myself aware of the more common errors being made.

Hopefully I will start to see patterns and avoid making common errors over and over again.

I find that this makes my job more interesting, probably since I am an analytical person who likes to collect data and information in a structured manner.

You should try to relate the errors to use of inadequate tools, habits, methods or knowledge. In most cases you will find there would have been ways to catch the error earlier. Things like type-safety, unit-testing, code-review, coding standards, better API design, better documentation and working environment, comes to my mind.