Part of being a good programmer is learning not to trust yourself

... and to actively guard against yourself.

Over the years I've found that I can be my own worst enemy when I code. Part of the problem stems from paranoia

Early in my college days, a professor of mine, Jim Greenlee, instilled in me the virtue of paranoid programming. He taught an introduction to C class on a Linux/Unix environment. Our code had to compile with no warnings or errors on Linux and Unix, pass lint, and withstand all manner of evil input the TA's could throw at it. Catching a mistake and printing out an error was bad, but acceptable. Crashing was an immediate 0. Towards the end of the semester, I usually wrote two programs for the each assignment: 1) the assignment and 2) a Perl script designed to automate and generally speaking cat /dev/random into the program.

Over time, this process led to a healthy suspicion of any code that I used (not so much my code, but code I didn't own or didn't actively work in). As a result, I now rarely make assumptions about how other people's code works. I probe, search, test and investigate any assumption about resource management, lifetime, etc . When I'm working on my code, however, I tend to assume I got it right and followed such patterns as RAII. And therein lies the problem: no one is perfect, and I should be as paranoid about the quality of my code as anyone else's.

I find this problem happens most often on the border of my code and the rest of the program. I think this is true for most programmers. You understand your model and the manner in which you expect it to behave. On the fringes of your program, you expect other code to behave properly or your code to account for various conditions. In reality, it's doubtful that both you and the programmer owning the other end of the code had exactly the same thought pattern.  Also it's doubtful you understand all the variations in behavior in the other programmers code.

To further complicate matters, you are not the same programmer you were yesterday. Hopefully you're better. As a programmer you constantly learn new patterns, better methods and discipline. So when you program against code you've written, you're approaching it with a different mindset and hence you take different paths. In short, you're programming against someone else's code and assumptions. 

For instance there was a time where I didn't actively use RAII in my code.  Now I base all my C++ classes around this pattern and use it everywhere.  These days I tend to assume my classes implement this pattern.  I've been bitten a few times when using older code that pre-dated my use of RAII. 

The best way to avoid making bad assumptions is to actively question them at all times. Guarding against your assumptions can occur at several levels. Over time, I've found the following methods to be the most effective:

1) Don't trust yourself

Be as paranoid about yourself as others.

2) Turn Assumptions into Compiler Errors

This is most effective when coding in C++. Occasionally I run into a situation where we find certain classes are invalid inputs to a template, function, etc ...  The best way to prevent using the type in the wrong context is to turn it into a compiler error.  Typically this is accomplished with a combination of macros and templates. It's not pretty, but catching an error at compile time is the cheapest way.  You can't ship a bug that doesn't compile. 

3) Unit Testing

I once heard an engineer say that "1 test is worth 1000 expert opinions." It doesn't matter how good you are or how simple the code is; given enough time, you will make mistakes. The most effective and lasting way to ensure that you don't make mistakes is to test your code relentlessly.

The other great aspect is it allows you to freeze an assumption in time. The point at which you write the code is the best time to catalog the intended behaviors of your code. Adding a unit test will preserve and enforce it for the perceivable future.  

4) Retail Contracts

Retail contracts are similar to debug asserts. The difference is that they run in retail as well as debug builds. Generally speaking in retail it will cause a crash and Watson dump.

I've debated the merits of such an approach many times. But the principal that wins for me is "if it's wrong at debug time, it's wrong at retail time". It's much easier to catch a problem sooner rather that later. This is especially true for C++ where problems can behave unpredictably and result in "random" failures. Crashing on a line which says Contract.ThrowIfNull() leaves little doubt to where the failure came from. It doesn't necessarily make finding the underlying cause easier but it's a start.

I've heard the argument that checks are non-performant and shouldn't be done in retail code. Most retail checks resort down to "if(!ptr) throw". Yes, if you put many,many of these checks into a hot path of your code base it can cause a performance problem. In my experience it's very unlikely that this will happen. And if it does show up on a profile, it's a simple matter to switch them to a debug assert, or move the retail assert further down in the stack and out of the hot path.

5) Debug Asserts

I find debug asserts are nice for verification that is to expensive to run in retail. I don't mean this to include simple NULL checks but more deep verification of various data sets.

*) Code Reviews

I didn't put this into any specific order because this is highly dependent upon the person reviewing your code. I feel the other listed points add a consistent level of quality to your code.  Bad code reviewers offer little help in guarding against yourself and hence do little for quality. Good code reviewers offer good protection but it's a one time shot so I still would put it between unit testing and retail contracts.

There are the few people who have an amazing talent for code reviews. They will make even the most experience programmer come out feeling like an incompetent novice. They are invaluable and even though they are able to shame me at times I insist upon code reviews from them when writing a feature. 

Comments (8)

  1. insert name here says:

    [insert Trusted Computing wisecrack here]

  2. Manny says:

    This is very true!  One of the things our developers did was sign on with Server Intellect for web hosting, which has been a great asset to our business.  Now they can work in concert with knowledgeable pro’s, which is really time effective for them.

  3. These are the web’s most talked about URLs on Mon 24th Mar 2008. The current winner is ..

  4. Jeff says:

    This is also the same for engineers.  It’s summed up in the corollary to Murphy’s Law:  "I helps to plug it in".

    You really can never allow yourself to assume anything about your own abilities of observation or to screw-up something basic.   After 30 years I still "forget to plug it in" on a regular basis simply because system complexity assures that there will always be some simple but critical mistake made somewhere in every project.

    This is where good engineers usually will have an explicit or mental checklist of serious fundamental things to check which can include going back in ohm-ing out cables, switchs and such (the hardware equivalent of unit tests actually).

  5. Ezra Klughaupt says:

    try not using ms products, good code follows

  6. Making a blanket suggestion about avoiding an established product line without any evidence or reasons isn’t really offering much to the conversation.  That’s true for any product open source, closed, etc …

  7. Nick Black says:

    Ahhhh, I am pleased to see that one of my students has learned their lessons well.

  8. Joshua Volz says:

    I actually had the opposite situation; I had to learn to trust my previous code.  While that code was written by the previous me, that doesn’t mean it needs to be entirely re-engineered to meet with the current fad-best-practices.  Sometimes, I’ll see things that don’t entirely make sense in my own previous code, upon subsequent investigation it becomes clear that it was a bug fix / work around / alteration made to meet some specific set of requirements.  

    Yes, I agree a healthy level of distrust is necessary to make sure that you keep you avoid land mines.  But I think that some level of trust has to be present otherwise you end up with NIH Syndrome along with its nastier cousin NIN (not invented now) Syndrome.  

Skip to main content