comment on

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!! */ }"

In reply to Hoss'ss Last Words by hossman

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		`&`
	<		`<`
	>		`>`
	[		`[`
	]		`]`

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.