Chris Meistre

I think I was born to be a programmer.  Ever since I can remember, I’ve had this thing I do that whenever I see something in the real world I try and work out in my head how you would go about structuring  an algorithm that would simulate or automate it.

As an example, let’s look at how you wash a car.

1. Spray car with water
2. Apply soap on a part of the car
3. If car is completely soaped up, rinse off, otherwise go back to step 2
4. Dry off part of the car
5. If car is completely dry, stop, otherwise go back to step 4

When I stand at an ATM drawing money, I go through my head the processes that it goes through when I do a transaction. (note, this is obviously not how an ATM works, and is just here for illustration purposes)

1. Read information from my mag stripe
2. Accept my PIN code
3. Send my PIN code along with the unique ID on the mag stripe to a central database to compare and see if my PIN is correct
4. If it is correct return the information like bank accounts, etc to the ATM so that I can do a transaction.  If it was incorrect stop and exit
5. Get transaction information, check it with central database and if possible record that the transaction has gone through
6. etc

I don’t know what the word is for someone with a personality like this, but that is what I am   I am sure that some people who know me wouldn’t expect me to be like this, but I find myself often going through things like this in my head.

I believe the ability and the urge I feel to do this with a lot of things in life has helped me with my programming skills.  It has helped me understand other people’s software as well, which normally results in being able to understand why a certain program is occurring in their software.  As an example, when a program fails at a certain point, I can work out that it’s probably because at that stage it needs to load information from a file but it hangs there.  I am then able to check if the file it needs is indeed there, and if replaced it works.  So without error messages guiding me in the right direction, it’s very often possible to work out what a program is trying to do at what time.

This gets me to an article I read about whether or not you are a good programmer – Bad Programmers.

In short, you are a bad programmer when:

1. You struggle to reason about code
2. Poor understanding of a language’s programming model
3. Poor knowledge of a platform’s features
4. Unable to understand pointers
5. Difficulty seeing through recursion

Signs that you are a mediocre programmer:

1. You’re not able to think in sets
2. Lack of critical thinking
3. Pinball programming – working in just certain states
4. Unfamiliar with security techniques

And then there are signs that you shouldn’t be a programmer:

1. Unable to determine the order of execution of code
2. No ability to think in the abstract
3. Collyer Brothers syndrome
4. Dysfunctional sense of casualty
5. Indifference to outcomes

That is just a summary of it, and I think it’s really worth a read to see where you fall if you consider yourself a programmer.