About three months ago, I composed Signs You’re Doing Something Wrong (Part One). I promised more. I did not know how long it would take to get there, but I certainly expected it to be sooner than three months.
Here it is, three months (and change) later.
There are, as I pointed out in the previous installment, many programmers out there who simply don’t know they suck. These are some indicators they (we?) can use to help categorize themselves (ourselves?). You may notice that these signs you’re doing something wrong are attitude-oriented, rather than methodology oriented, but the indicators of suck are no more or less transferrable across activity domains. Arbitrary rules are also a sign that you’re doing something wrong when passing laws in the House of Representatives. Superficial productivity metrics are also a sign you’re doing something wrong when firing someone for procrastination. The inability to describe the benefits of your work without euphemising its failings is also a sign you’re doing something wrong if you’re cooking the books to make your multi-thousand-dollar product package look cheap compared to its one-good-dinner-price competitor. By the same token, the following points apply to many realms of endeavor, though I present them in the language of programming.
- Bandaging: When you find a bug or a vulnerability, don’t just slap a band-aid on it. I don’t care how busy you are, don’t create a behavioral patch for your software (or legislation, or revolutionary new vacuum cleaner design) and attach it to the standard distribution. Temporary solutions last the longest, when they’re applied directly to the problem. When shipped separately, however, there’s a little bit of breathing room. Take the opportunity to find the source of the problem and fix that instead for general distribution. Slapping a bandage on a nice deep cut may prevent you from bleeding to death, but you really need to get to a hospital and get that looked at by a professional. If you never hunt out the root causes of the problems you encounter, you’ll never be an expert, and if you never fix the root causes of your problems, you’ll only be replacing one problem now with four or five more problems later. The better you get at hunting down root causes and fixing them, the better you’ll be at avoiding problems in the first place later. If you’re using a magic number to solve an arithmetic bug in your program, you’re in for trouble later.
- Optimism: You should always, when you’re programming, be asking yourself “What can possibly go wrong?” You should be asking yourself this because you should be planning for every eventuality. This is cynicism, which is not the same as pessimism: as I’m known to say from time to time, a real cynic is an idealist who learns from life experience. Be cynical. Expect the worst but, unlike a pessimist, do not take that as a foregone conclusion of defeat. Instead, take it as foreknowledge of the sort of thing for which you should be planning. Bad, unplanned outcomes are common, and you can best recover from them or even avoid them entirely in many cases by imagining unplanned outcomes and preparing for them. When you’re always “looking at the bright side” and trying to comfort yourself with silver linings, you’re overlooking the potential for things to get worse. Sometimes, they do get worse, and if you’ve overlooked that potential, it will take you by surprise. When that happens, you’re screwed. This is particularly valuable when driving a car in heavy traffic: if you always assume that any random one of the dimwits around you might cut you off without leaving enough room for you to slow down and avoid rear-ending him, you’ll always be able to prepare to the point where you will always be able to avoid rear-ending him. Funny how that works.
- Spelling: No, you don’t have to be an excellent speller. On the other hand, you do have to be able to hide your atrocious spelling from others — more specifically, from excellent spellers. Hint: the spell-checker that comes with MS Word will not suffice (for instance, it doesn’t recognize when the wrong homonym is used, only when you add an extra T to the word TTwo). If you don’t care enough to double-check your spelling, you’ll write bad documentation, suffer from a lack of attention to detail, and fail utterly to appear professional to a great many people. More to the point, you’ll betray your contempt for correctness. The worse your spelling is, the more important it is to get it right: expert spellers can tell the difference between an expert speller who overlooked a typo and an atrocious speller who just doesn’t care enough to double-check. That’s the difference that matters — was it an overlooked typo, or are you both ignorant and irresponsible? One might legitimately ask how much attention you’ve paid to the correctness of your code if you never bothered to figure out whether the documentation should read “send an integer to method foo()” or “send an integer too method foo()”. Correctness matters.
- Tolerance: It has been very popular for many years to pretend that everyone has something to offer and everyone is valuable. It’s simply not true — at least, not for your purposes, whoever you are, and whatever your purposes might be. Incompetence should not be tolerated. I don’t mean that you should march into your project manager’s office and tell him what kind of useless, washed-up piece of crap he is. What I mean is that when your project manager sucks rocks, you should be polishing up your resume. You should be looking for someone who measures productivity by what your code does, and how well it does it, rather than by how many lines of it you’ve written this week, and when you find that person you should get him or her to hire you immediately. When you’re the project manager, don’t just accept corporate policy written by some idiot predecessor: work to change policy so that it makes sense. Tradition is not a justification for incompetence, and tolerance is not a justification for complacency. If you’re in a counterproductive environment, and you aren’t either looking for a better environment or trying to fix the environment in which you’re working, you are just dead weight. That means you’re doing something wrong.
I know some of this must seem downright heretical. Good. If I was telling you stuff that perfectly fits the “common wisdom”, you wouldn’t be learning anything new. Here’s a bonus sign you’re doing something wrong.
- Orthodoxy: If “nobody ever got fired for buying IBM” is the guiding principle of your professional life, you’ll never be anything but a mindless drone. While you may be able to come up with career-saving excuses all the time, you won’t be saving money and time. Nobody ever became great by pursuing a life of perfect averages.