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
seizure.
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
following:
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
self-perpetuating.
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
environment.
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.
Humor collection