Failing a Contract

We pay a lot of lip service to failure being a teaching tool. We tell this to kids, as we kindly set yet another brick in the you're special, just like everyone else wall to block out much vilified reality. We tell this to friends when we can't think of anything else to say. We tell this to ourselves when we just get plastered against the wall and are scavaging for shards of our ego.

Programming isn't inherently an ego game, but it certainly can becomes one. When you're on the edge trying to do something new--and don't have coworkers or professors to turn to--it's essential to develop a healthy irrational exuberance in regards to your work. When your livelihood depends on doing something you've never done before, you just have to believe you can do it. And you know, you're pretty smart, and you've Gotten Stuff Done before. Sure, you can rewite that massive web app. It needs to be done in two weeks? You'll only cover 40 hours between the two? And you want it translated from CakePHP to ErlyWeb?

Yeah. Sure. I can do that.

The problem is that you're not lying to your client or even to yourself, the problem is that sometimes you can do that. Sometimes you're a demon at the keyboard and you're keeping the entire design in your head while you refactor-refactor-refactor perfectly until the application falls into place. That's why you're not just a self-absorbed prick who doesn't know your limits: sometimes you get this stuff done right.

But you're not going to succeed everytime. Sometimes you're the horse who breaks his leg fifty feet before the finish line. More often, though, you're the horse that breaks its leg ten seconds into the race, finally realizes its leg is broken two minutes later, and then drags itself towards the finish line where it knows it will be summarily executed (okay, that kind of horse may not exist¹ ).

The makeup of a failed contract job is fairly predictable. First, you sign on for a job that seems ambitious, but possible. You start sprinting out of the gate, because you know there isn't much room for error. Then, you start dragging your pace, because you've begun to doubt that what you're doing is possible within your current parameters. Gradually, you begin to know deep in your gut that you're going to fail, and start working inhumane hours trying to prevent the inevitable: telling your client that you've screwed up. Finally, you give up. You type up a project report, spend twenty minutes trying to remember the word postmortum, and you call your client and tell them that the project failed.

You're kind of upset about screwing up, but you're more upset about letting your client down, so you don't charge them. You say you're sorry, and that you're going to do the best to make it better by not charging them. That burns a bit, but your clients are your income, and your job is to deliver what you say you'll deliver. When you fail, you don't deliver, so you don't get paid.

After that experience, you'll probably go through a period of postmortum depression, where you lose faith in your ability to do things you haven't done before. That irrational exuberance that put food on your table goes out for a few days. Then it starts creeping back in, and a few days or a week later you're up and at 'em again.

You might think that the lesson here is to keep your irrational exuberance under check. To tame it until it uses the litter box and chain it so it doesn't lead you off another cliff. But that isn't the moral of the story at all. When you're working for yourself, your faith in yourself is the tool you go to work with. Whether the contract goes well depends on just how justifiable that faith is, but without that faith you'll never start a job, you'll never get paid, you'll never fail, and you'll never succeed.

That's the first take-home lesson: failure is a prime time to reevaluate your strengths and find ways to improve, but you've gotta believe in your abilities, regardless of failure.

Second, everyone is better off--especially you--if you identify failure sooner rather than later. If a project begins to drag, you have to begin accessing if it's dragging because you've begun to accept that it is a failure, and if you won't be able to complete it successfully.

Third, make sure the client doesn't suffer for your failure. This usually involves taking less money or not taking any money at all. Working hard at something difficult and then not getting paid isn't a great experience (as it turns out, neither is working half-heartedly at something easy and then getting paid), but part of earning trust--and being a professional--is to take responsibility for your failures.

Failure is inherent in a field like contract programming, and there isn't much of a safety net beneath you. But it's also important to realize that failure isn't something to get bent up over, nor does the occasional screwup have to sour client relations. Identify failures, acknowledge them, rectify them, and get on with it. You've got work to do.