If you’re a programmer of any kind and have done it for any length of time at all; particularly as your profession, not just a hobby, you know this one rule:
Good programmers expect things to go bad.
One of our prime directives as lord or lady of the bits and bytes is to predict what can go wrong and prevent it. Or at the worst case, handle it gracefully.
Being a developer isn’t exactly all baby giggles and sunbeams so a healthy amount of pessimism is certainly warranted.
Just Because You Don’t See Them, Doesn’t Mean They Aren’t Watching
First off, it’s ok to be pessimistic or even paranoid. Let’s just say that right out loud, now. In this profession, you have to expect the problems and stave them off before they happen, otherwise you’ll not be long for this career.
We have to be ready for each eventuality. Personally I have a saying that goes like this:
“Hope For the Best But Be Prepared for the Worst”
Because, the problems are certainly out there.
Users that click here when we expected them to click there, an unexpected value returned from a query, a file shared between companies but containing entirely the wrong data, or users that decide they want certain math rules to work in a custom way.
We developers have shielded our code with a plethora of defenses against the dark forces that beset our glorious subs, functions, classes, and screens.
We write error traps routing to logs, raise flags that trigger emails, pop-up messages to allow users to handle simple problems themselves, return values to other developers who are using our “black box”, and we write unit tests to quickly find the dark threads in the fabric off our beautiful code.
And yes, in a nod to personal responsibility, we ask our users “Are you sure?”
“Is the Dark Side stronger?” – Luke. “No.” – Yoda
The great thing about development is that with practice, all problems can be overcome. If you’re paying attention, most are even repeatable and thus the way they are handled is repeatable as well.
One of the main benefits of being a pessimistic programmer is that is builds on two other strengths we all share.
We’re lazy and we like to create.
Healthy pessimism plus those two ingredients will lead to cuddly things such as:
- Having source control to secure our code.
- Log errors that communicate in human terms to you.
- Using explicit declaration of variables.
- Serializing long data input to files.
- Using assertions to keep your code on track.
- Creating simple pass/fail tests against requirements.
- Keeping code simple and straightforward.
[pullquote]The nice part about being a pessimist is that you are constantly being either proven right or pleasantly surprised. ~George F. Will, The Leveling Wind[/pullquote]
Much like the Way of the Jedi, it’s a hard life but a good one.
Too seldom the appreciation comes along and when it does, it’s usually from your own satisfaction that you’ve done things to maintain your own sanity. Most of your code will never be seen or appreciated by anyone but you.
So perhaps we’re more like The Men in Black than the Jedi.
Outsourcing Your Pessimism
Whenever possible you should create other pessimists to work with you or surreptitiously .. for you. This is basically summed up by saying, surround yourself with other people who have skin in the game and learn to communicate your pessimism in a positive fashion to them.
This does a few things:
- It illustrates to them that you care about the end product.
- By doing that, you create buy-in from the user to help you.
- The relationship then becomes you and the user, working with the software.
Let me explain that last point. Have you ever heard the idea that when meeting in a small group of three, that humans naturally tend to pair up, leaving the third part to fend for itself?
I’ve seen this time and time again. Learn to use this rule to your advantage my young padawan. Consider this:
Most users naturally consider themselves and the software to be two of those three with you on the outside, fending for yourself. The blame then tends to fall on you, regardless of what they themselves do, with you getting responses like “well it worked yesterday, you IT guys must’ve done something”.
Pay attention now.
If you can change this relationship so that you and the user are on the same team, with the software being the third wheel, THAT is where you want to be.
With enough communication, honesty and integrity on your part, you can get there too. Here are three tips to help that relationship along whether your user is a client or co-worker.
- Be honest. Never try to hide important things from them.
- Don’t be THAT honest. Give them what they need but don’t bore them with too much geeky stuff; they have their own job that keeps their brains full.
- Every time you fix a bug, include them on the credit. Turn it into a team effort.
There you go.
We started with pessimism and ended with professionalism. It’s all part of the GeekLife!