Skip to main content

The Pessimistic Programmer

I decided to change the title of this blog to "The Pessimistic Programmer". Why? Am I a depressed person that thinks nothing will work? No, I am an optimist in life. Something good is going to happen today :-) But in programming, something will surely go wrong.

I don't actually view this as pessimism, but as realism. I want to be prepared for the worst that can possibly happen. Hope for the best, prepare for the worst. But my wife explained to me that pessimists always say that they are just being realistic. So, I might as well face it: I am a pessimist.

I think a good programmer needs to be pessimistic; always thinking about what can go wrong and how to prevent it. I don't say that I am a good programmer myself. No, I make far too many mistakes for that. But I have learnt how to manage my mistakes with testing and double checking.

Über-programmers can manage well without being pessimistic. They have total overview of the code and all consequences of changes. But I'm talking about us mere mortals. But if you are an über-programmer, you should be pessimistic about what the next guy will do to your code. Place some comments and unit tests in there, to keep him out of trouble!

An optimistic programmer doesn't see the need for unit tests. He will run the program and be satisfied when it runs one time without errors. He will say things like "What can possibly go wrong?" Or if something goes wrong anyway, "It must be an error in the input from that other module".

Haven't we all been there? Suddenly, I feel so old...

Comments

Anonymous said…
I agree with you: pessimism is a good trait to have if you're a programmer.

However, my pessimism tends to come in play more in the planning and design phase rather than the coding phase, as I try to identify the nasty little details and choices that may need to be made in order to accomplish a particular task.

Once I figure out how it can be done and assure myself that my approach makes sense, I don't worry as much about the code itself.
Anonymous said…
I think one needs to be very pessimistic about the number and difficulty of problems you will encounter, but very optimistic about your ability to overcome them. One of several contradictory traits one needs as a programmer!
Anonymous said…
Man, you need a holiday! (As do all of us...)
Anonymous said…
There are no Über-programmers, just regular ones that have not yet found the limit of classes and relationships that they can hold in their heads.

The experience only increases the complexity level required to become pessimistic. And when somebody performs a task well, people (or himself!) tend to assign him yet more complex tasks, because people always, always wants more.

After a few iterations, no matter how good you are, you're bound to be a pessimist. And you're bound to return to that state if, for any reason, you get to think that what you do now is easy.

So being pessimistic is not a trait of good developers. It's a consequence.

;D

Popular posts from this blog

The problem with use cases

The greatest benefit I get from use cases is that they focus on the user. Use cases help me to think about what the user wants to do instead of only focusing on implementation details. The biggest problem I have with use cases is that they are not structured. They are basically free text. For instance, if we have a use case Withdraw money from ATM, we may define that it has a precondition that Open account is performed, but we don't get any help from the method to see that. What happens if someone later changes the Open account use case or defines a Close account use case? How do we find which other uses cases that need to be modified? We can look through the old use case diagrams and find dependencies, but I can almost guarrantee that these dependencies have not been maintained after they were initially created. The solution to this is to connect the use cases to an object model. I don't mean a use-case realization with view and controller objects like ATM_Screen and ATM

Use examples to make your code easier to understand

Programmers are used to abstract thinking. To program is to generalize: A method is a general specification of what to do during execution. A class is a general specification of objects. A superclass is a generalization of several classes. Altough our minds are capable of abstract thinking, concrete thinking is much easier, and concrete examples are the foundation for abstractions. For instance, when we were children, our parents didn't try to teach us about cars by explaining to us cars are and what they can do. Instead, they just pointed at a car that was driving by and said ”Look, a car!” When they had done that a number of times, we knew what a car was. Another example is prejudice. We all have prejudices, because this is the way our minds work. If we have met a few people from Denmark in our lives, and those people were friendly, we ”know” that Danes are friendly. And this works even stronger for negative prejudices. My point is that we learn by examples. Einstein said t