We aren’t copy writers or social media experts; we’re programmers. We need to constantly foresee and prevent problems before they happen. Cultivating a healthy paranoia and a heavily pessimistic attitude is the path to becoming a better programmer.

Why Be Paranoid and Pessimistic

Being paranoid and pessimistic will save your ass constantly. Before even talking about actual code – backups, debuggers, source control, error logging, automated deployment scripts, and almost all tools of the programming trade are predicated on the pessimistic idea that stuff goes wrong often, and there must be procedures in place to identify, correct, and prevent errors.

Another side effect of being paranoid is coding defensively. No matter if you are coding against libraries, code written by other developers on your team, or code written by yourself, it is important to code defensively, because everybody and everything is fallible.

Defensive code makes fewer assumptions and carefully handles error cases instead of failing silently or producing undefined behavior. This leads to code that is easier to maintain and less prone to bugs.

Libraries are updated, frameworks evolve, requirements change. Programmers are constantly fighting against entropy. Defensive programming guards against the effects of software entropy by reducing the possibility that changes in one part of a system will cause subtle bugs somewhere else.

It is important to expect the unexpected in all things.

It seems that there’s a mantra that every programmer must memorize early in his or her career. It is a fundamental tenet of computing, a core belief that we learn to apply to requirements, designs, code, comments, just about everything we do. It goes

THIS CAN NEVER HAPPEN…

– The Pragmatic Programmer by Andrew Hunt & David Thomas

Embracing paranoia and pessimism will automatically lead to wonderful things like:

• Explicitly stating preconditions, postconditions, and invariants
• If it can’t happen, using assertions to ensure that it won’t
• Always using source control
• Crashing early – a dead program normally does a lot less damage than a crippled one

All of the above are widely considered good practice, and techniques recommended in The Pragmatic Programmer.

When to stop being paranoid and pessimistic

You should never stop being paranoid or pessimistic, but when interacting with non-technical people, you should probably change your game face.

Let’s say you get a phone call from your boss who is a search engine optimization guy. He is wondering if you can build a tool to check how a website ranks in the search engines for various keywords.

You are a good programmer. A paranoid programmer. A pessimistic programmer. You immediately start thinking about the most significant challenges involved. That to do this project right, you will need to account for differences in search results across geographic areas. That means a distributed architecture of some kind, and most likely reports with combined rankings plus rankings broken out by geographic area. Now, if we use too many geographic areas and check them too often, we will significantly change the search volume for a particular term, which can have indirect effects on rankings. Plus scraping results is probably against Google’s ToS…

Swallow those words.

Your boss is a marketer at heart. He is an optimist. He needs to be an optimist in order to sell stuff. He doesn’t want to hear about worst case scenarios or most significant challenges. He needs to know about them, but wrap them up in a language he is better equipped to understand.

“Hrmmm. There are already similar tools out there, so I’m sure this is something we can do. However, I don’t think creating this tool will be as simple as it first appears. The most straightforward way to collect the data is to do some searches programmatically and then scrape the page to get rankings, but I think this is against Google’s ToS, and could get us in hot water with Google. We will also have to account for things like geographical rankings differences. I’m sure there are ways around these issues, but I’m not sure what the solution will look like yet without doing a bit more research.”

See the difference? Instead of your boss getting what sounds to him like a litany of problems, he is now getting some reassurance that it can be done, it just isn’t as easy as he probably thinks it is, and will take some thought to get everything right.

The only problem with pessimistic problem solving is that it is often misunderstood by optimists (read: management, sales, marketing, etc.). You don’t want to be known as the person who spits out a list of problems at every new idea. It is better to be known as the person who solves problems before anyone else realizes that a problem exists.

So unless you are communicating with optimists, go forth and spread paranoia and pessimism.