{ dubovsky.com rantings }

Michael McDonough’s Top Ten Things They Never Taught Me in Design School led to Andrés Taylor’s top ten things ten years of professional software development has taught me, which led me to Coding Horror’s Top 6 List of Programming Top 10 Lists, which inspired me to think about my own. I can’t claim all these as my own, but here’s my take on my oh-so-long career:

1. Be the change you wish to see (a.k.a. actions speak louder than words). Gandhi’s advice applies to more than swaraj. Complain minimally; act instead.
2. Work smart, not hard (a.k.a. hard work is its own reward). If they both give the same outcome on similar investments, choose smart work over hard work: it begets more smart (efficient) work. Example: if I find myself doing the same time-consuming manual task a third time, it’s time to automate it.
3. You are not your code (a.k.a. critique the code but be kind to the coder). Don’t take it personally when someone praises or insults your work; learn from it. We all have written and will write bad code. Be responsible for it, but don’t own it or people will avoid communicating their problems with it. When critiquing code, aim there and not at the author. Problems with the author should be addressed separately.
4. Communicate well (a.k.a. play well with others). Good production is built on teamwork and communication with your peers, customers, and supporting organizations. Communicate with, not to. Remember that you’re all in it together: it’s “us and us” not “us and them.” Support those around you and accept their support when it is offered. Efficient and happy work relies on knowing what is happening. Be honest and direct. Document as you code (automatic documentation generators like doxygen are your friend). Write your use models before you code and your test cases no later than as you code. Speak up when you have a problem. Ask questions when you need to know something. Passive-agressive behavior has no place in an office.
5. Learn to differentiate between the essential and the desired (a.k.a. fight for what you believe in, but don’t push the rest). Be true to yourself. If it’s important, speak up and don’t let yourself be trampled. Support other peoples’ important things. Remember the color of the bike shed.
6. Be slow to hire and quick to fire (a.k.a. using the right tool makes the job easy and enjoyable). There are few things more disruptive in an office than a bad employee and nothing more wonderful than a great one. There are few things more depressing than being hired for a position that (unbeknownst to you) doesn’t fit you and few things more fulfilling than one that does. It’s not fair to the employee or the employer to be sloppy in hiring or firing. Also remember that it’s easier to teach technical details to a smart, nice person than to teach people skills to a knowledgeable jerk.
7. Keep learning (a.k.a. keep your tools sharp and get some more tools). Learn how to better practice your art. Learn new languages, techniques, development styles. There is always a better way. It’s good for both your professional and personal development.
8. Do it right the first time (a.k.a. establish/teach good habits early). To a first approximation, no code is ever re-written, re-factored, or re-documented; there’s never the money, time, or people. If you don’t spend the few extra minutes to do it right this time, it’ll be trouble for the remainder of the product’s life. Train your new hires before they fall into make-do habits.
9. The road to hell is paved with good intentions (a.k.a. no good deed goes unpunished). “The world is not set up to facilitate the best any more than it is set up to facilitate the worst. It doesn’t depend on brilliance or innovation because if it did, the system would be unpredictable. It requires averages and predictables. So, good deeds and brilliant ideas go against the grain of the social contract almost by definition. They will be challenged and will require enormous effort to succeed. Most fail. Expect to work hard, expect to fail a few times, and expect to be rejected. Our work is like martial arts or military strategy: never underestimate your opponent. If you believe in excellence, your opponent will pretty much be everything.” — Michael McDonough. I couldn’t have said it better.
10. Implementations are important; interfaces are critical (a.k.a. few people see the car’s engine). The thin skin of your program that interacts with the outside world is critical. (The same applies to modules written for a larger program.) If you don’t get the UI right, not many will care how well it is written. If you don’t make the interface easy to use, not many will care that does what they need. Some people can design interfaces and some can’t — learn to recognize the first and tap into that talent.