• original by Bram Cohen (6 Jan 2001)

So, you've been through Dilbert hell. But now you've made it, right? You've got more character and more experience. You escaped with your will intact, and no battle scars. Hah, right. You've got plenty of ingrained bad habits from your years in hell, and you'd better start figuring out what they are and cutting them out of your life.

Not that developing bad habits was the result of stupidity on your part. Your survival skills served you well when they were needed, and made perfect sense at the time, but you're out of there now, and must adapt to better circumstances. Everyone comes back from war a little bit shell-shocked, the trick is to pull yourself back together and move on.

Below are five of the worst bad habits of thoroughly downtrodden programmers, what causes them, and how to get over them. If too many of the causes apply to you right now, then I hate to say it, but you're still in hell. Get out. Get out now.

1. Pre-engineering

An old boss of mine said that every line of code deleted is time wasted. As a purely defensive measure, I did what programmers since the beginning of time have done when there will never be a chance to modify something later - make the first draft do everything you can possibly think of, and then some. Sure, the code won't work as well as if you'd written it after first implementing a smaller version to figure out how it should really work, and most of the fancy functionality will be completely extraneous, but there really is no other option here. If you don't put in the functionality now, you're going to have to hack it in by some awful kludge later, thus lighting the kindling which will burn down the project.

Now that you don't have to worry about a management old code fetish, you can stop wasting time developing a hydraulic drill when all you need is a hammer and chisel. I know you like the aesthetics of beautiful completely general interfaces which can remain unchanged for the next ten years, but chances are you'll never need a hydraulic drill, and if it turns out you really do need one, you'll build it later, and it will be a better one than the one you'd write now, because you'll actually understand hammers then.

By the way, you can't write a new interface which won't be changed for ten years. Trust me on this one. You can't.

2. Glop Refactoring

You've got a lake which you want to use as a source of hydroelectric power. The normal way to do this would be to construct a dam, then dig a trench leading from the lake to the dam to the ocean, and start collecting power. Only you can't do that. There will be interminable political arguments about where the trench should be, how much water it should let through, what the design of the dam will be, and just about anything else which can be argued over. There is no way a dam will ever get constructed.

But you have learned a way. Without getting anyone's permission, as a single unilateral act, you dig a trench from the lake to the ocean and just let water start coursing through. Sure, it's going to drown a nearby town if it keeps up, but that town is certain to make damn well sure a dam is built to keep itself from going underwater, and then you'll have a dam.

I hate to break it to you, but you're going to have to stop doing that. Yes, I know chaos is fun. Yes, I know it's very effective to just change an interface resulting in a build broken in 500 places and wait for everyone else to fix their code to comply with yours, but really, you can do things in a much more orderly way now, and bringing the project to a state of total anarchy is uncalled for, however much fun it may be.

3. Not Sleeping

You can't steal time from your sleep schedule, you can only borrow it. Eventually you have to pay it back. With interest. Yes, you have to get XYZ done by yesterday, or... or... Well, something really bad will happen. Take a minute to consider most deadlines you've had. Is the deliverable going to ship the day after the deadline? Of course not, this is just the regular monthly deliverable. By the time the shipping deliverable rolls around you'll be paying back your sleep debt, with interest.

I'm going to let you in on a little secret. The exact form and date of the final deliverable doesn't matter all that much. Market research always says it would be best to be five years ahead of everyone else in terms of functionality, and able to ship tomorrow. You don't even need surveys to figure that out. The only way to make a useful schedule is with a healthy attention to reality. If there won't be time to include a feature, trim it, and if the bare minimum functionality can't be done in time, let the deliverable date slip.

In the end, all that matters is the code you write, not the hours you put in. If you find yourself falling asleep in your chair, forcing yourself to type to avoid nodding off, go home and get some sleep. You'll more than make up for the lost time the next day.

4. Doing all the code yourself

So you're a genius, and can write anything better than anyone. You've single-handedly held together projects where noone knew what was going on. You've pulled all-nighters to fix someone else's architectural error which had stopped progress completely. You're so cool, you don't even feel embarrassed bragging about it.

Unfortunately, you're still only one person, and like it or not can only accomplish one man-hour per hour. Your coworkers, while imperfect, aren't the idiots you used to work with, and can do not only an adequate job, but a downright good one. Delegate work to other people. Go without checking up on what they're doing for days at a time - paying even loose attention to what problems are turning up will cause you to waste time thinking of solutions, stealing time from your own tasks. Trust me, the project will be better off if everyone has a chance to contribute. You might even be impressed at how cleverly other people can do things too.

5. Not giving information to management

• "How's the project going?"

  "Fine."

  "Any difficulties?"

  "It's going fine."

Bad managers wouldn't be nearly so harmful if they only knew they were bad. The results of their ignorance are mandated solutions which not only make the original problem worse, but cause new ones as well. In the hands of an idiot, useful information about progress turns into the steel which forms the support beams of the Artifice Of Things I Can Claim To Have Done. Political animals need such artifices, it's what the other political animals look for. All the kids are doing it.

If you never tell a bad manager how anything's going, you'll never get a stupid mandated solution, and the project will be that much better off. You've probably even got some standard tasks for management to do to make themselves feel useful, like hold focus groups. The information gleaned from focus groups is usually about as accurate as asking accountants how pushing the plus button makes them feel, but you won't use the information anyway, so it doesn't matter, and management won't notice that you didn't, because they'll be too busy holding another focus group you asked for.

You don't work for those idiots any more. Your current boss will not only not use information against you, but use it to make the world a better place. If the final deliverable is going to slip a bit, management will go tell marketing that the product launch will be a bit later. Marketing might even be having their own problems and appreciate the extra time. Companies run smoothest when management has all the information which might be relevant to corporate decision making.