Forget about writing perfect code

Recently, I went to the games arcade and saw a bunch of people crowding around a game machine. Must be some friendly tournament going on. So I went to take a look, since if there’s a crowd, it’s likely the players were good.

The game was Tekken 6. One fellow consistently beat the other. Then there’s this battle where the better player defeated the other with nary a scratch. A perfect score. And this triggered some distant memory I had…

Street Fighter

When the game was out, it was the hottest thing among my friends (this was around 1990). I happened to own a console machine (find out more in a previous post), which makes one of a more “prestigious” level (you have to read that previous post to get the context).

So a close friend wanted to hone his skills, and we played on my console. Let me tell you this. I suck at fighting games initially. Probably still do, but we’ll leave it at that…

Anyway, when we were practising our moves, the first thing he did was fire a projectile at me (his favourite character was Ryu. Whose wasn’t?). I’d defend myself, because I was too scared (or inept) to successfully jump over the projectile. And I’d get hit. And a small fraction of my health bar disappeared.

After a few practice sessions, I asked him why he always fired something at me at the beginning of the battle. He’s much better at the game than me, and it’s obvious that he’s letting me get a few hits on purpose.

His reply? “So you’re not perfect.” When you have a perfect health bar, and you defeat the opponent, you get bonus points. Plus the feeling that you rock.

I was disturbed. “I’m not perfect?”

Be obsessive in the right areas

Accept that your code can have flaws. I’m not talking about glaring inefficiencies or obvious errors. I’m talking about the code being good enough to do what it’s supposed to do, and you fussing over it to make it better, at the expense of other productive tasks you can do.

I’m currently the only programmer dealing with user interface related coding (I’m in a small team). This usually means users call me as a first line support.

Time, tasks and temper forced me to come up with my own way of prioritisation. This meant programs and code had to only be good enough, not perfect.

I still write code as best as I can. I just don’t obsess over its quality because I already know it’s good.

Turn of tides

The players were feverish on the controls. One of them was launching attacks in a flurry, forcing the other into a defensive pose. The defender crouched a split second too late, and got hit consecutively. He jabbed back but was blocked. Then the attacker launched into another series of blows, pinning the defender against a wall.

The attacker did a move and it didn’t connect. The defender took advantage of this and started a whirlwind of counterattacks.

Hit, connect, hit, connect.

The attacker was on the floor, and the defender swept the floor with his leg, and hit again. Made a jump attack, and the attacker wasn’t ready.

Hit, connect, hit, connect.

With another series of moves, the defender threw the attacker onto the wall and finished the battle.

Ultimately, in a fighting game, having a perfect health bar isn’t the goal. Winning is.

  1. Aaron Falloon

    Great post, as I’ve mentioned in a few of my blog posts, I’ve got a problem with this.

    I create an application which does its job fine, but I try to tweak and perfect it. As a result I lose patience with it, or I’ll mess it up.

  2. Vincent Tan

    Such is the nature of tweaking… It’s a fine line to tweak and inch towards perfection, or tweak and inch towards anarchy.

    I’ve messed up stuff too.

Comments are closed.