Dealing With Others  Dealing With Others

home page previous up next Google search web for more information on this topic jump to foot of page translate this page with Babelfish ©2000-2012 Roedy Green, Canadian Mind Products
Hell is other people.
~ Jean-Paul Sartre (born: 1905-06-21 died: 1980-04-15 at age: 74) Huis Clos, (No Exit) 1934
There are many hints sprinkled throughout the tips on how to rattle maintenance programmers though frustration, and how to foil your boss’s attempts to stop you from writing unmaintainable code, or even how to foment an RWAR (Religious War) that involves everyone on the topic of how code should be formatted in the repository.

  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 (Hypertext Transfer Protocol) links to bogus UML (Universal Modeling Language) 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
    …
CMP homejump to top You can get the freshest copy of this page from: or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
previousnexthttp://mindprod.com/jgloss/unmainotherpeople.html J:\mindprod\jgloss\unmainotherpeople.html
logofeedback Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : feedback email If you want your message kept confidential, not considered for posting, please explicitly specify that.
mindprod.com IP:[65.110.21.43]
view BlogYour face IP:[38.107.179.213]
You are visitor number 68,431.