Hoss'ss Last Words

A little over a year ago I left my job at a company I had worked for for over 11 years to pursue a new opportunity. In the month of so leading up to my departure, I tried to think of all the nuggets of wisdom I could remember getting or giving over those 11 years, and added them to a text file, and then on my last day I emailed out the best of the bunch with the subject "Hoss'ss Last Words"

Cleaning up some files on my laptop today, I found that text file and figured I might as well share them with the world at large....

If you copy an existing class (or method), and modify less then 3/4 of the existing lines in your new copy, then you are doing something horribly, horribly wrong.
When was the last time you wrote a unit test? When was the last time you commented out a unit test because it was broken and you didn't have time to fix it? If A < B then shame on you.
Having an office sucks. Cubes are much more social and enjoyable. If you are in a cube and need to have a private conversation with someone, just go take a walk and get some coffee -- fresh air is good for you. If you are in an office, make sure you wander around all the cubes in the department at least once a day to say hi to people and catch up on what they are up to.
IDEA makes it really easy to start with an object, and look up what methods you can call on it, and see the Javadocs for each of those methods, and tab-complete your way throw method calls on method calls until you have the result you are looking for. But you should never call a method on any object w/o reading the Class level Javadocs for each of those classes as well -- There are lots of subtleties in how certain objects behave that you will only be made aware of be reading about the class as a whole, and not just the method.
You should always contribute to the company 401k plan -- if you don't you're missing out on the company paid match, which is like turning down free money.
If Java is the only programming language you've used/read in the past 6 months, you are failing yourself as a developer.
Don't be afraid to look stupid. The smartest thing anyone has ever said is "I don't understand."
Never eat alone at your desk.
If you think something looks broken, you're probably right -- investigating into it will likely help the company/department, and you will look like a rock star. Even if you're wrong, investigating it will teach you something, and you will be a rock star.
Putting Easter eggs onto the site is fine, just make sure: a) the likely hood of finding it by accident is inversely proportionate to how offensive it is; b) it doesn't increase the memory footprint of the servers by 65MB per thread. (saulj=true!)
If you have to implement some logic that you think is stupid, say so in a code comment -- but include the reason you were told to do it, in addition to your objection. Years later, those comments will be more valuable then gold to your coworkers who will otherwise beat their heads against their desks for days trying to make sense out of why something so bizarre would have ever been implemented in the first place.
Eavesdrop on conversations people are having about projects you aren't involved with -- you might learn something that will help you on your projects, and you might have information you can share with them to make their project easier.
If something seems like it's more complicated then it should be, it probably is, and you should simplify it. If you try to simplify it, and realize there's a reason why it's as complicated as it is: add a fucking comment explaining why for the next poor bastard.
Don't ever be afraid to say "No, I won't do that under any circumstances" -- but be prepared to provide a compelling reason. No one will care how gung-ho and positive you are if the end result is a pile of shit, but pessimism and negativity will be rewarded if you can back it up with sound reasoning.
Old business cards taped together make great white elephant gift wrapping paper. Especially if you use old cards that belonged to {nickname for person who was fired for stealing}.
When you are given a requirement/request from your client, always verify that you aren't dealing with an XY Problem: http://people.apache.org/~hossman/#xyproblem
Every department has a budget for training and education. If you don't occasionally ask your manager to buy you books, or pay for training classes that you think sound useful, then you are just letting that money go to waste (or to somebody else).
Eat lunch on the grass at South Park at least once a month every Summer.
Practice being a good interviewer. If you suck at interviewing, you won't be able to tell when an applicant sucks, and the good applicants won't want to work with you anyway.
When you write equality comparisons, get in the habit of putting the constant on the left side. It will make the compiler complain if you accidental type "=" when you mean "==" instead of getting silently screwed by code like "if (someVariable = true) { /* BUG!! */ }"

Comment on Hoss'ss Last Words Download Code

Replies are listed 'Best First'.
Re: Hoss'ss Last Words by davido (Cardinal) on Jul 17, 2011 at 02:07 UTC
Pearls of wisdom. I love these. Sound advice interspersed with humor and common sense. However, the times I've worked in cubes I've seemed to have the misfortune of having a loudmouth nearby, which isn't conducive to concentration. Dave	[reply]
Re^2: Hoss'ss Last Words by Anonymous Monk on Jul 17, 2011 at 02:15 UTC
a loudmouth nearby, which isn't conducive to concentration. Noise canceling headphones + anonymous complaint to the supervisor to remind everyone to keep a pleasant working environment (ie STFU)	[reply]
Re: Hoss'ss Last Words by AnomalousMonk (Archbishop) on Jul 18, 2011 at 00:19 UTC
When you write equality comparisons, get in the habit of putting the constant on the left side. You may have intended that the word 'equality' include them, but this advice applies also to 'not equal' comparisons: `someVariable =! true` is usually a valid expression, so `if (someVariable =! true) { /* BUG!! */ }` is a valid statement.	[reply] [d/l] [select]
Re: Hoss'ss Last Words by locked_user sundialsvc4 (Abbot) on Jul 18, 2011 at 03:56 UTC
Nicely done. The best bits of programming wisdom that I ever caught were these: Above all else, capture the designer’s intent,” even if ... especially if ... that designer is you and there is no one else working with you. Any fool can see what the code is. No one can see why. No one has a cucking flue why. Six weeks from now, even your own work will have become the work of a stranger. See #1.
Re^2: Hoss'ss Last Words by cavac (Prior) on Jan 24, 2012 at 00:51 UTC
Six weeks from now, even your own work will have become the work of a stranger. Words of wisdom, indeed. Just today i had to bugfix a project a colleage of mine based on some old, alpha-version of my web framework. My reactions where something like this: Why has this file a timestamp of early 2010? Has it really been this long? Oh god, i'm getting old... Why wont this jQuery command work? Whoops, that was before i started using jQuery... How the f..k do i install this? Where is the Makefile.PL? Oh, yes, that was before i made it into a module... Uhm, i managed to accidently kill the running instance. Now how do i start it again??? On the plus side, i realized that all the hard work in the 2 years since then really paid off. I even managed to document ~~all~~ uhm ~~most of~~ ok, well ~~part of~~ some of my codebase. And the double-plus side, nowadays hardly any configuration file requires misspelling keywords for the program to actually work... "You have reached the Monastery. All our helpdesk monks are busy at the moment. Please press "1" to instantly donate 10 currency units for a good cause or press "2" to hang up. Or you can dial "12" to get connected directly to second level support."	[reply]
Re: Hoss'ss Last Words by perl.j (Pilgrim) on Jul 18, 2011 at 02:11 UTC
Great Advice : ) perl.j-----A Newbie To Perl	[reply]