Skip to content

How programmers think

January 19, 2009

This is based on a real incident.

Henry had asked Tom for a favor. Henry’s car was developing engine problems but since he had to go to work, he asked Tom to send it to the workshop.

Tom: Ok I’ll send your car to the workshop. But what if they need more than a day to fix it?

Henry: No, that shouldn’t be. There’s no reason why they can’t get it done in half a day.

Tom: I know. But what if they are busy or have to order parts? You did say you needed the car this evening. So if they want more than a day, what do you want me to do?

Henry: Nolah, I’ve never heard of such a thing. How can workshops take so long?

Not wanting to argue, Tom took the keys and left.

Meanwhile in another place.

Jake: Ok, I’ll send your car in. But what if they need more than a day?

Sue: That’s unlikely. But if it happens, call me and I’ll decide what to do.

The outcome:
Tom discovers that the workshop did require more than a day so he left Henry’s car at the workshop. Henry, the hot tempered one, was furious. He bombarded Tom for leaving his car there because something might have happened to it (even though nothing did). To this day they are not speaking to each other.

Jake too discovers that the workshop needed more than a day. He calls up Sue. Sue tells him to just bring the car home and she’ll deal with it later. No tension, no fuss.

Sue can be an IT programmer. Good programmers do not assume. They will take every possibility into consideration and make contingency plans of action for each possibility. This mental process is actually a requirement in code writing. Even Microsoft has not got this down 100%.

Henry on the other hand will probably end up killing himself if he tries to become a programmer. When one likes to assume things, one cannot bear the thought that the world might operate differently than expected. Any attempt to make them think otherwise will result in drama.

The mess increases manyfold when groups are concerned. Effective project leaders don’t just focus on skill and experience. They also look at temperatment and attitude. Many take shortcuts of course but they often pay a price – tension, resentment, and even sabotage.

6 Comments leave one →
  1. LC Teh permalink
    January 19, 2009 9:44 am

    One of Henry’s relatives was Hitler… or maybe, Bush. Haha…
    Then there was another old time favorite quote about some great leaders, “He wouldn’t take ‘No’ for an answer”. They depend on their publicity agents to get their public approvals afterwards.

    Technical guys should know, most problems don’t get solved by bull-dozers or sledge hammers. They either get covered up or smashed beyond solution.

    Yeah, and the comedy always breaks out when hardcore techies go for a people-oriented roles and vice versa. Many senior people still believe that if you know how to deal with a machine, then you must know how to deal with a person. And then they go on to make disastrous decisions for the company.

  2. January 19, 2009 12:43 pm

    haha, i’m not surprised that they ARE a lot of programmers who love to assume. “Nolar, the users won’t do that”, “This is not something the users will like”, etc.

    My answer will be quite typical – “you’re not the customer, so don’t assume. if you want to know the actual answer, go ask the customer”

    What they assume is correct might not be correct at all. Always think from the customer’s perspective because the perspective/opinion of a business user,can be very different from those of a technical person.

    Have you met techies who assume, “If users don’t see this like I do, it means they’re stupid.” I’ve seen it ruin projects, where the techies get into arguments with the user. Most companies don’t take the trouble to identify such traits in people before they hire. If you tell them its necessary, they’ll tell you, “Why make life so complicated?” 😀

  3. LC Teh permalink
    January 19, 2009 3:06 pm

    Which is why you have engineers and you have project managers. Or you have designers, artists and you have account executives. You put the people handlers in between. Otherwise the techies would chew up the ‘stupid’ customers. Or the ‘idiots’ spend their dough elsewhere.

    Personally, I have introduced simple solutions to production people only to have them throw my ideas back at me as ‘too simple’, ‘unsafe’, ‘not idiot-proofed’, etc. They don’t want it simple. They want it to look good. And some customers happily pay for it. Smart techies need to learn when to let someone else do the talking…

    I’m not sure which is funnier, a techie pretending to be a people expert or a people person pretending to be a tech expert. Both can have me in stitches sometimes. 😀

  4. January 20, 2009 1:17 am

    like yr take on this. i think it applies beyond a programmer but to life in a whole 🙂

    Thanks. The thing is, when you prepare for all possible outcomes, people will advise you not to think too much. I hear this a lot in Asia but almost never in western countries.

  5. January 20, 2009 8:41 am

    Yea, i’ve met those programmers before. They will go on and say the users are stupid, and why make things so difficult, bla bla. That’s where the consultants should come in, to explain to the users the so-called best practices and also the reason consultants are being paid so much. They SHOULD know what’s the best for the user. Some users are troublesome, but that doesn’t mean they’re wrong because remember that some of them are not familiar with IT at all, and they donno the best ways to do certain things. And some can be rather stubborn. So consultants should educate them.

    But if there’s no consultant…we’ll just have to follow what the client wanted. In the end, if things screwed up, they cannot blame us. But if we act smart and decide on our own….then the customer can blame us and tell us to redo. =_=

    Sounds like what is happening to my current project. That’s why I’m not active in blogging lately (my blog posts…all of them were written last week).

    This is why specification signoffs are critical. Even more critical is the type of study that culminates in a signoff. Once the user has signed, they cannot later turn around and say they’re not satisfied, unless they want to pay for revisions outside the agreed specs.

  6. January 20, 2009 11:18 am

    I would say risk taking though… Well, it still depend. Some programmer I know is freaking furious…

    Yeah, I’ve met some good programmers. I’ve also met programmers who regret being programmers.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: