I love to cook. I love wandering through a grocery store looking for interesting ingredients, paging through cookbooks, chopping vegetables, measuring, mixing, sautéing, baking. As a programmer / manager, I don’t have that many opportunities to make something physical, but cooking is an intensely pleasurable experience, especially when the results match the intentions.

Unsurprisingly, I don’t like doing the dishes. It isn’t a big deal, and I accept it as an unavoidable part of the process, but it’s a pain, and when it’s my turn I don’t always do a great job. It’s not that I don’t clean individual items well, rather that I usually leave one or two items in the sink. It’s not even a conscious thought (“I think I’ll leave these two water bottles here”), but rather an unconscious reprioritization of something anything else over the nearly complete work.

Needless to say, this has consistently driven everyone who’s lived with me completely nuts. When it’s your turn to do the dishes, and you leave a cup and three forks in the sink, no one cares about the three pots, two pans, and four place settings that you’ve cleaned. The only thing they see is that you didn’t do your job.

The sad thing, of course, is that you did the hard part – all it would take to get credit is to make that extra little push. And yet how many times have I seen talented coders trash their reputations because they just couldn’t do that last little bit. Their projects were incomplete. They consistently broke the build, or left logging statements in committed code. They didn’t respect the team’s coding standard. Their code reviews had obvious, impossible-to-miss flaws (my favorite is the unresolved merge conflict in the diffs). They didn’t test the final code changes, and shipped code that just didn’t work.

It’s frustrating. People who could have been stars were viewed as unreliable and sloppy, and get moved off bigger, more interesting projects to smaller, more constrained ones. And I feel for them, I really do – I DON’T LIKE DOING THE DISHES – but it doesn’t change the fact that easily fixable problems can cause dramatic shifts in performance and perception.

Here are some really simple habits that can completely change this around. None of these are hard or time-consuming, and for most people, just going down this checklist for each project can completely eradicate a whole host of problems.

• Read the project spec before starting. It seems weird to have to write this down, but you’d be surprised how many people only read the headlines of their projects, and miss out on key details. RTFS.
• Re-read the project spec before declaring it done. It’s possible you forgot something. Something big. The key piece of the project. Just give that sucker a quick re-read before turning in your work.
• Review your code first. You should always be the first reviewer of your own code. Seriously, you should be embarrassed if you let an obvious mistake slip through.
• Test your feature first. It blows my mind that I even have to write this down, and yet, I do.

THESE SHOULD ALL SEEM BLINDINGLY OBVIOUS TO YOU, and yet they’re precisely the areas in which most “sloppy” engineers fall down. Hell, even “good” engineers sometimes don’t read the spec carefully, or sneak in a last minute code change that’s so self-evidently correct that there’s no need to test or even compile (with predictable results). These are all easy. You may should already be doing them, but making them a formal part of your process won’t take any additional time, and can only improve your end results.

One last note: since starting this post, it’s been hard not to notice when I’m leaving something behind in the sink. Even just thinking of yourself as the kind of person who finishes projects responsibly (or does all the dishes) can make a big difference.