wood burning stoves*
The moose likes Meaningless Drivel and the fly likes The survival instincts of a programmer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Other » Meaningless Drivel
Bookmark "The survival instincts of a programmer" Watch "The survival instincts of a programmer" New topic
Author

The survival instincts of a programmer

Ove Lindström
Ranch Hand

Joined: Mar 10, 2008
Posts: 326

In the motorcycle world, we often talk about the 7 survival instincts of a driver that kicks in when in a stressful situation.

The survival instincts are:
1. Go off throttle
2. Taking a firmer grip on the handlebar
3. Narrowing down the field of vision
4. Target lock
5. Steer towards the locked target
6. Don't steer at all or to slow
7. Hit the breaks hard.

Over the years, I have noticed that this is also true for the average programmer. When a programmer finds himself (or herself) in trouble, this is what happens.

1. Go off throttle
The programmer stops coding, compiling and committing code. Instead, time is spent on browsing Facebook and sending out incomplete questions and code on different forums.

2. Hold firmer on to the code
Instead of wiping the erroneous code and start all over again, the programmer holds a firm grip on the code. You might hear "I've done nothing wrong! They must have changed the framework or the API. Or the compiler is broken."

3. Narrowing down the field of vision
The stack trace clearly states that it is a null pointer exception but the programmer is only looking at the row where the error occurs. Not on the incorrect assignment of the variable two rows up. Or on the if-statement that states if(x == null) and not if(x != null).

4. Target lock
It must be the class X, that is written by Mr B, that is wrong... even if class Y, that is written by me, is sending crap to class X.

5. Steer towards the target lock
Yell at Mr B. Flame him on all internal and external forums you can find. And on the coffee break. And on the daily Scrum. But whatever you do, don't correct your own code.

6. Don't steer at all or to slow
Well, since I've done no wrong, why should I do anything at all until it is fixed?

7. Hit the breaks hard.
I can't work in this f--- environment. I quit!

And then Mr B get the code and fix it in 4 minutes.
Daniel Doboseru
Ranch Hand

Joined: Sep 26, 2011
Posts: 57
nice one thanks for making me smile. Right now I'm fighting with a WebService that doesn't work, even the code I wrote seems correct, so I guess I should not follow the guide-line above )
John Jai
Bartender

Joined: May 31, 2011
Posts: 1776
Daniel Doboseru wrote:nice one thanks for making me smile. Right now I'm fighting with a WebService that doesn't work, even the code I wrote seems correct, so I guess I should not follow the guide-line above )

Beware of Mr.B sitting next to you
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: The survival instincts of a programmer