About

Be a Paranoid Pessimistic Programmer

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

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.

7 Comments

Absolutely, there is a fine line between over-burdening clients with technical detail and not telling them enough about the work so that they don't really understand what they are paying for. This is something that I still struggle with. And it's one reason why I prefer working with clients who are fairly technical - they have a better understanding of the challenges involved in a project without me having to do as much explaining.
I think there is a big difference between dropping problems in a client's lap, and coming to them later with a list of problems plus possible solutions to them all. It is almost always better not to mention a bunch of problems unless you already have some ideas for solving them. Or if it is something that can be resolved without the client's input, that is even better. Although as you say, it is a good idea to bring it up later so the client knows what they are paying for.

I've been practicing this approach for about ten years now -- looking first at the hardest-case scenarios for clients, then after jotting them down, giving a rough outline of difficulty without actually going into nitty-gritty detail.
I have to tell ya, it hasn't worked out as well as I thought. My clients like to joke that every time I say something will take a lot of thought, it seems to them like all I had to do was think about it a little and the solution magically appeared. Like, the less detail I gave them over time about the specific problems, the more they assumed the job was automatic; to the point that when there was a problem, they couldn't understand where it was coming from.
You're trying to convince whining coders to stop dropping their problems into the client's lap, and I think that's fair. At the same time, there's a drawback to setting your clients' expectations unreasonably high by never mentioning what it took to do something.
My solution, as it's been, has been to estimate and gauge the scope of the problems and give a non-technical outline before starting the work, and then as I learned the hard way, to make sure I pound the client with all kinds of gruesome technical details about how hard it was after the work is done. That way at least they know what they spent their money on. Otherwise we really run the risk of being taken for granted.

Very well stated. I agree wholeheartedly... the amount of times I've seen systems crash because a whole load of bits of code which, by themselves, should work perfectly, don't when they're all stuck together is mindblowing. Just a little intelligence and a few extra checks and error handlers would've saved the day... but no: the programmers were too optimistic, and guess what: they were wrong.

This has been very insightful, programming is about solving problems thus being a paranoid and a pessimist are fantastic qualities.
Lol'd at the Swallow those words line, I guess ambition and imagination are for artists not programmers...