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 exist1 ).
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.
I'm still bitter that I spent so long trying to find an interesting heuristic
for the horrifying game, and the best heuristic was something
along the lines of 'your stones minus the opponents stones.' I guess it
was still a better foray into AI than writing n-armed bandit
simulators in Java.↩