In a previous post, I talked about what it was that stars did differently, and how it didn’t require either 80 hour weeks or incredible genius to shine. But there’s another side to this, and one that doesn’t get as much air time. Everyone wants to know how to be a big success, but the first step, as always, is not to screw up. With this in mind, I’ve come up with the following list of some of the most popular ways to fail.

• Be slow

When you first start a job, you want to take a long time to get set up. First impressions are important, and you don’t want people to get the idea that you’re capable, aggressive, energetic. Getting your development environment set up and knocking off your first set of tasks quickly (they’ll usually give you easy ones to start off, in order to introduce you to the codebase and give you some quick successes) will only lead to tears. It’s never too early to lower expectations. It’s also never too late. Consistently demonstrating a lack of urgency, going over schedule, and sandbagging on time estimates is a great way to destroy any positive expectations or lingering respect.

• Write poor quality code

When you aren’t worried about quality, you can cut down on a lot of unnecessary busywork. Unit tests take time to write and run, and are never seen by the end-user. Code documentation is completely unnecessary, and descriptive variable names are for sissies.* Big-O is the kind of thing you learn in college, but should never bother with in real life. Common libraries are a pain to learn, and when the chips are down it’s faster just to roll your own. Bubble sort works just fine, and is fast to implement. Understanding how data structures work isn’t important – you can Google anything you need to know. Code reviews cause bad feelings, since everyone’s always harshing on everyone else. Besides, you’re more of a “get it done” not “make it pretty” kind of programmer – and proud of it! Don’t bother testing on multiple browsers – if it works on one, it should work on all. Ignore compiler warnings and don’t use any kind of static analysis tool – they’re too nitpicky. It’s too much of a pain to set up a debugger, and stepping through the code takes too long, anyway.

• Disappear down the rabbit hole

Continuous integration is a fad. Creating internal milestones to demonstrate progress is going to add overhead without providing any value. Regular meetings to make sure stakeholders are aligned is a waste of time. Providing regular status updates is just administrative overhead. You know better than anyone else what needs to get done, and you’re the one doing it. They just need to leave you alone. Listen, the project is 90% done. All you need is a little more time, and all this BS about communicating status is just another bureaucratic hoop you’re supposed to jump through. With the project already this late, filling out some TPS reports and putting together a list of all of the remaining tasks is just going to be a waste of time – you know what needs to get done, and all you need is another week to finish things up. Never mind that you said the same thing a week ago.

• Be a dick

Not everyone can pull this off easily, but with training, effort, and patience, even the nicest, most rational of engineers can learn to be a schmuck. First, remember that you’re right, and that people who disagree with you are idiots. Constant sarcasm is an acceptable conversational style, and sycophancy is a necessary skill. Kissing up and kicking down works! Be honest with your opinions, especially when they relate to your coworkers. Cynicism about the motives of your manager and company leaders is endearing, and you should insert yourself into random conversations in order to subvert them with funny (to you) anecdotes. All of these contribute to create the delightfully unpleasant atmosphere of a toxic team.

• Cost other people time

There are many ways to do this, and I encourage you to try a variety of different methods to see what works best for you. For instance, code reviews can take a lot of time – if you post sloppy code on your first revision, the code reviewers are going to have lots to say, and you may even be able to force a second (or third) round of reviews. If you don’t follow the coding standard, it amounts to a tax on everyone else who tries to read your code. Asking lots of questions without first trying to find the answers on your own is another effective tactic, especially when you’re preventing someone from getting into a state of flow. Call unnecessary meetings, don’t create agendas, arrive late, and let them go horribly off topic and over time (bonus points for delaying another team’s meeting). Also, if you’re unreliable, people will constantly have to check up on you to make sure you’re completing assigned tasks.

• Play it safe

Taking risks can lead to failure – it’s much better to take the safe path: the comfortable job, the well-defined task, the unchallenging work that lies squarely within your abilities. This is work that needs to get done, and though you will never stand out, never do more than just get by, and probably never survive a layoff, you can feel comfort in the knowledge that you’ll be assigned the crap work that allows other, more ambitious people to focus on important and challenging work.

• Neglect unpleasant tasks

Work isn’t always fun. Everyone has to do less interesting stuff from time to time, from fixing bugs, to running reports, to searching for unused CSS rules (my personal favorite). My recommendation is simple and effective: don’t bother. Don’t do the boring stuff. Don’t ever spend time on tasks you don’t enjoy. Life’s too short, and there’s usually a sucker who’ll get so frustrated that s/he’ll do it for you. The best part is that if you consistently blow off tasks you dislike, your manager will stop assigning them to you! She may also stop assigning other tasks to you, but every innovation is seen as a threat to the status quo, and this is a risk you’ll have to take.

• Don’t respect anyone else’s priorities

You have important things to get done, and ultimately you’ll be judged on whether or not you accomplish them. As such, consider completely ignoring everyone else’s priorities. The squeaky wheel gets the oil, and when you need support from someone else, scream loudly enough to make sure you’re at the top of their list (regardless of what else is on it).

• Don’t follow through on promises

When stated so baldly, people tend to have an extremely strong reaction to this item, which suggests it touches a universal nerve. And yet, it’s one of the most common things we all do. Minor instances include forgetting to send a report, missing meetings and skipping scheduled interviews. There are, however, as many ways to do this as promises to be made. You can fail to send a deliverable, not take care of a time-sensitive task, or show up when expected, but without proper preparation. The key in all of these cases is not to tell people ahead of time. The whole goal is to create expectations, then to disappoint – though it won’t ruin things completely, proactively letting people know that you won’t be able to fulfill a promise will destroy a significant amount of the effect.

• Hide problems

When things go wrong, the last thing you want to do is tell people who will be affected. This might give them an opportunity to react, help think through possible solutions, and/or get involved in pulling things out of a nosedive. It’s preferable to wait until there’s no way to avoid disclosing the issue, and hope that things will magically fix themselves before then. Far better to tell people on the due date that there’s still work to be done, than to sound the warning a month ahead of time.

• Don’t care

One of the most effective strategies is really a meta-strategy – the icing on the cake, if you will. Sure, you missed a deadline. Oops, oh well. No big deal. So you almost brought down the servers with some bad code. Hah! Pretty funny, right? So what you’ve been ignoring some boring tasks for weeks. Chill out! They’ll get done. Eventually. By someone. The neat thing about not caring is that although it isn’t itself a specific, actionable problem, it’s also one of the most damaging things possible to a team or a relationship. Nothing gets people so bent out of shape as someone who just doesn’t give a damn.

Final Word

OK, that was fun :)

Although hopefully none of these are things that people would choose to do intentionally, or that anyone would look at and think of as positive, you see them happen all the time. Some of them are so common we tend to think of them more as facts of life, rather than as a tax on everyone’s productivity (e.g., when was the last time you went to a meeting where everyone was on time, there was an agenda, and the meeting was kept on topic?). Many of them are the kind of mistakes we all make when starting out, and (hopefully) gradually stamp out as we mature. And most of them are relatively easy to address once identified. You don’t have to be a super-genius or work 120 hour weeks to communicate problems early, be respectful of other people’s time, or follow through on your promises. Which makes them great fodder for performance reviews, one-on-one discussions, and personal development goals.

_____________________________

* True story: I knew a guy at Activision who’d decided that the best way to achieve job security was to use variable names like “a” and “aa”.