Win a copy of Programming with Types this week in the Angular and TypeScript forum
or The Design of Web APIs in the Web Services forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Henry Wong
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Joe Ess
  • salvin francis

The survival instincts of a programmer

 
Ranch Hand
Posts: 326
Android Mac OS X Firefox Browser
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 57
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 )
 
Rancher
Posts: 1776
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Do you want ants? Because that's how you get ants. And a tiny ads:
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps
https://coderanch.com/t/722574/Sauce-Labs-World-Largest-Continuous
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!