-> Humor collection -> Rules for being successful in software development

Ad: netjeff recommends rShopping app for Android, for your shopping list needs.

Rules for being successful in software development

(from Pat Carey)

First Rule of Communication:
  Never talk directly to someone when you can
  just as easily flame them in email.

Work Ethic:
  Nine out of ten people who come into your office
  will dump more work on you.  Discourage this  
  behavior with irritated glances, deep sighs, and signs in  
  your cube indicating that you have no tolerance for  
  other people's problems.  If all else fails, fake a  

The Huntley Heuristic:
  Use words like concomitant, tertiary, obfuscation,
  and rotarywankleshaft at least once in every  
  meeting you attend.  Observe the blank stares.

Martin's Maxim:
  Be sure to reserve at least 30 Mb of disk space for	 
  your "humor" email repository.

Koenig's Conundrum:
  a) You'll never be respected by your fellow  
     developers unless you have one or more of the  
        1)  a beard
        2)  really thick glasses
        3)  a "unique" sense of fashion
        4)  toys at your desk
  b) You'll never be respected by management if you  
     have any of the above.

The Workspace Indicator:
  You can tell how technically competent someone is  
  by how customized their Workspace is.  If someone  
  can't figure out how to setup a fancy background or  
  customize their sounds, how can you expect them to  
  help you debug an inlined virtual template method?

The Hype Corollary:
  The amount of hype and misinformation surrounding a  
  new technology (object, web, java, etc.) is directly
  proportional to your salary.  Exploit this by  
  convincing management that all of the current problems  
  will be solved by adopting the latest technology.   
  Conveniently forget to mention the myriad of larger  
  problems that accompany it.  This law is  

The Theory of Relative Estimation:  (E = MC^2)
  The trick here is to figure the factor (M) by which  
  your manager is going to divide your numbers and to  
  multiply your "real" estimate (C) by an exponentially larger	 
  factor.  For example, if you think a task will take you		 
  10 hours and you know that your manager always divides		 
  your numbers by 2, you should quote your estimate (E) as  
  200 hours (200 = 2x(10^2)).  That way you'll have		 
  time to read humorous email and customize your

Management Overviews:
  When writing technical documentation, you can  
  quickly create a "Management Overview" section by  
  copy/pasting the text from the "Conclusion" section.  In  
  general, people who read the "Management Overview"  
  section never make it to the conclusion anyway.

Categories for this item: Workplace, Computers, Programming -> Humor collection -> Rules for being successful in software development