Bad Golfer

A review of intentional bad practices.

I can't stop myself from jumping in at this point. Programming isn't golf, and past that, I am getting entirely fed up with sports analogies; none of them do justice to consequences that aren't immediate. Perhaps we need a page ProgrammingIsNot?...

Recently, while at lunch, I overheard a conversation at a table near mine.

Two young men (TwentySomething?) were discussing their golf game, where they play, with whom they play, and how they play.

They offered up all the usual complaints about hard courses, players too much better than they were, and solutions to these things.

One of them proceeded to expound on his answer to one of golf's well-known problems: the bad lie (where the ball lies in a difficult-to-play position or location after having been hit with a less-than-perfect stroke).

He said that, quite simply, he kicks the ball with his shoe into a better spot so that it's easier to play, so that his game can move forward -- otherwise it slows him down too much. He doesn't "take a stroke" (a self-assigned penalty on his score), he just plays on.

Further, he remarked that when he got better at golf, he wouldn't need to do that any more.

I tried to envision this guy as a programmer, and tried to imagine what sort of practices he might use, and what sort of justifications he would apply "until he got better" at programming.

The vision was not pretty. I've actually seen this phenomenon, but have always been willing to chalk it up to "inept style" or "inexperience" or what have you. Deep down, though, I think I knew it was "irresponsibility" at work -- I just didn't want to think about it.

Am I alone in this observation? -- GarryHamilton

As long as he's not sneaky about it, and the other players all agree to it, I don't see what the problem is. Many courses have "Winter Rules" that allow you to dig your ball out of the mud, wipe it clean and give it a better lie. If the guy's only a novice then having him hacking around in the rough for ages isn't going to improve his game much and will hold up players behind. Obviously part of the game is that you have to take the rough with the smooth, but if his game consists mostly of rough then it seems reasonable to allow him to experience some smooth too.

It's like a novice in the kitchen starting off using packet-mixes, and then moving on to using real ingredients after gaining confidence and feeling more adventurous.

I suppose in a recreational environment there's no harm. I'm not sure I could say the same about an environment where financial outcomes depend on one's choice of practices. -- gh

It comes down to goals and priorities. If the golfer's goal is to become the best golfer in the world, then this may be a bad practice. If the golfer's goal is to enjoy himself, or to finish a round in under four hours, then this might be a very good practice.

Similarly, in the software-development world, sometimes it makes sense to cut a corner. Sometimes it makes sense to just get the thing done in the fastest and simplest way possible. Sometimes it makes sense to bend or break the rules. Sometimes it makes sense to let someone get away with not-quite-perfect work.

Taking the easy way out may get in the way of self-improvement, but sometimes we have to temporarily put self-improvement aside to meet a more-urgent goal. The trick is keeping track of what all those goals are, and preventing the urgency of short-term goals from interfering with attainment of more-valuable long-term goals. (And it is not an easy trick to pull off.)

Usually novice programmers don't know they are cutting corners. A great example of this is the total lack of error handling (in modern languages this looks like try{}...catch(...){/* nothing here */}). Magazine (and now web) programming articles are full of comments like "error handling omitted to save space." How are novice programmers supposed to learn how to handle errors if good error handling code is kept in secret?

TigerWoods? became the world's greatest golfer by, at an early age, routinely practicing unfortunate situations like bad lies, hitting behind a tree, etc.. There is a big difference between learning while enjoying oneself and learning on the job under deadlines, scrutiny, and other pressures. On the job and elsewhere, it takes a patient mentor to help novice programmers learn from their mistakes.

I imagine that Tiger Woods didn't practice this during golf games, but by putting the ball in a bad lie over and over again

Practice your weaknesses, play your strengths. That means, for example, if you just learned about templates, don't put them indiscriminately in production code. Prototype with them, read other code that uses templates well, and get comfortable with their use and misuse before going on to introduce them into your real work.

One way for bad golfers to improve is to read magazines such as GolfDigest?. Likewise programmers can read OpenSource. The level of motivation is purely up to the individual who may require prodding such as NegativeFeedback?.

i think this is a good idea if all others in the party agree

Pardon?

See also: BadProgrammer, BadManager?, RulesOfGeelf