Dealing With Others

• You are here :
• home
• Java Glossary
• Unmaintainable Code
• Dealing With Others
•  

“Hell is other people.”
Jean-Paul Sartre — No Exit 1934

1. Your Boss Knows Best

   : If your boss thinks that his or her 20 year old FORTRAN experience is an excellent guide to contemporary programming, rigidly follow all his or her recommendations. As a result, the boss will trust you. That may help you in your career. You will learn many new methods to obfuscate program code.

2. Subvert The Help Desk

   : One way to help ensure the code is full of bugs is to ensure the maintenance programmers never hear about them. This requires subverting the help desk. Never answer the phone. Use an automated voice that says "thank you for calling the helpline. To reach a real person press "1" or leave a voice mail wait for the tone". Email help requests should be ignored other than to assign them a tracking number. The standard response to any problem is " I think your account is locked out. The person able to authorise reinstatement is not available just now."

3. Keep Your Mouth Shut

   : Be never vigilant of the next Y2K. If you ever spot something that could sneak up on a fixed deadline and destroy all life in the western hemisphere then do not openly discuss it until we are under the critical 4 year event window of panic and opportunity. Do not tell friends, coworkers, or other competent people of your discovery. Under no circumstances attempt to publish anything that might hint at this new and tremendously profitable threat. Do send one normal priority, jargon encrypted, memo to upper management to cover-your-a$$. If at all possible attach the jargon encrypted information as a rider on an otherwise unrelated plain-text memo pertaining to a more immediately pressing business concern. Rest assured that we all see the threat too. Sleep sound at night knowing that long after you’ve been forced into early retirement you will be begged to come back at a logarithmically increased hourly rate!

4. Baffle 'Em With Bullshit

   : Subtlety is a wonderful thing, although sometimes a sledge-hammer is more subtle than other tools. So, a refinement on misleading comments: create classes with names like FooFactory containing comments with references to the GoF creational patterns (ideally with http links to bogus UML design documents) that have nothing to do with object creation. Play off the maintainer’s delusions of competence. More subtly, create Java classes with protected constructors and methods like Foo f = Foo.newInstance()that return actual new instances, rather than the expected singleton. The opportunities for side-effects are endless.

5. Book Of The Month Club

   “I advocate that “super programmers’ who can juggle vastly more complex balls than average guys can, should be banned, by management, from dragging the average crowd into system complexity zones where the whole team will start to drown.”
   ~ Jan V.

   Join a computer book of the month club. Select authors who appear to be too busy writing books to have had any time to actually write any code themselves. Browse the local bookstore for titles with lots of cloud diagrams in them and no coding examples. Skim these books to learn obscure pedantic words you can use to intimidate the whippersnappers that come after you. Your code should impress. If people can’t understand your vocabulary, they must assume that you are very intelligent and that your algorithms are very deep. Avoid any sort of homely analogies in your algorithm explanations.

6. Pose as a Genius

   Genius types lead (blindly) without caring much whether the average programmers can fully keep up or not (some even take sadistic pleasure from seeing “ferior” colleagues suffer), and because such team leaders are on an intellectual high, they fail to see that their project is heading for disaster. You of course can pretend to do the same thing, even if you are not a genius. Tell everyone if they were smart enough, they would have no trouble understanding your unmaintainable code.

7. Pose as an Idiot

   A clever C programmer chafed at the company policy of insisting on the use of named constants instead of using embedded numerical literals. He followed the letter of the law, but avoided its spirit by defining 100 symbolic constants.
   #define ONE 1
   #define TWO 2
   #define THREE 3
   ...

	Please email your feedback for publication, errors, omissions, broken/redirected link reports and suggestions to improve this page to Roedy Green :
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
	Your face IP:[38.103.63.16]
	You are visitor number 51,924.
	You can get a fresh copy of this page from:	or possibly from your local J: drive (Java virtual drive/Mindprod website mirror)
	http://mindprod.com/jgloss/unmainotherpeople.html	J:\mindprod\jgloss\unmainotherpeople.html