Golfers are the Worst Computer Programmers

Author/Rant: Neil Rieck
Date: 2004-04-30 when I was forced to repair some else's crashing code "on my time"
Note: golf terms (and puns) are highlighted in turf green

The main objective of a golfer is to shave strokes off his game. Likewise, the main objective of a golfing programmer is to shave key strokes off his keyboarding efforts so he can get back to  "the links". This will be achieved in the following ways:

1. new programs written from scratch will be produced using the fewest number of key strokes
   1. there will be little or no formal documentation
   2. there will be little or no imbedded remarks or inline comments
   3. the program will not be self documenting because:
      • the program will not be modular (because cut-n-paste from working programs is faster than program design)
      • variable names will usually be short or meaningless
        • just how the hell can i% be a better variable name than transaction_counter% ?
        • why should every variable (including important non-temporary ones) be called junk% or temp% ?
      • run-time errors will be trapped but the error information will be discarded (turfed)
        • golfing programmers seem to think that the only purpose of a when-error-use block (try-catch in other languages) is to keep the program running so they can spend more time on the course (reminds me of the British upper class twit; while society attempts to progress forward all they can think about is "planning the next fox hunt")
           
2. existing programs will acquire new functionalities in a few ways:
   1. more new code will be added in the same devil-may-care fashion

      • these guys are in a hurry to get past the linker so they can get back to the links

   2. cut (slice?) and paste from within the same program
      • this means that almost every thing will end up being inline (previously I thought that spaghetti-code was difficult to debug; links-logic is the only thing that comes to mind when seeing 18 inline modules pasted together and not a single GOSUB in sight)
   3. cut (slice?) and paste from another program

      • usually every thing will end up being inline

      • variable names from the source program will usually not be be changed which will add to future confusion

      • if cut from someone else's work, remarks will come with the copied lines but the golfing programmer won't bother to modify them (see rule #1 above about fewer key strokes)

      • depending on the programming language, "programmer un-initialized" variables are often introduced. They don't cause problems until some other poor soul tries to modify the golfer's program in which case you now have got a bug. As far as the users are concerned, you were the last person to touch the code so you are to blame; meanwhile the golfing programmer who caused this mess is off the hook

   4. jumping from program to program
      • this is a new spin on the phrase spaghetti-logic where execution noodles (spaghetti) span the whole computer platform. Now when you renovate program-x, program-y and program-z no longer function properly 

Stopping the Golfing Computer Programmer

When confronted with his sloppy effort he will usually respond with a flippant remark like "hey it runs" which really means "I have no intention of changing my work habits" (this really makes me Tee'd Off). These people are so dense (or egotistical) they don't see the disaster they leave in their wake. In fact, they are proud of the fact that they are occasionally asked to back to do some work that the remaining programmers just can't figure out because "those non-golfing dolts just aren't up to the golfer's own technical skill level". This ego bolstering event is amplified if the inviting person is not a programmer and also believes the same thing.

The main reason for writing bad code is that they assume the boss will never see it. So the embarrassment of a weekly or monthly "code review" is probably one way to stop these people in their tracks. However, most large western companies have already cut budgets to the bone so will never return to code reviews (we're all supposed to be self-policing professionals, right?).

Note: referring to a golfer's programs as code is, most times, literally true; the logic is usually so convoluted that only the golfing programmer can decode it. (see previous comment on links-logic)

Relying on Open Source software is another good way to stop the golfing programmer; in the open source world, your peers do the code review which usually means that poorly written code doesn't make it into production. In fact, it his highly unlikely that a golfer would ever think of being connected to an open source community because golf is not a team sport so they just can't relate.

Outsourcing your programming efforts sometimes works; the outsourcing company is trying to make a profit and quickly realizes that they must get rid of the golfing programmer because of the required effort to fix up so-called golf-code at a later date.

Promoting the golfer to management is probably the only way to stop them. Occasionally they'll be tempted to "help out the old team" but that just won't be practical if they are "on the links". Send them an email though and they'll answer as best they can with their BlackBerry's.

---

Addendum: "Peer Reviews" work in the world of science so "Code Reviews" (either by internal audits or peer-review by the Open Source community) should be sufficient. We wouldn't be in this mess if western corporations hadn't become hyper-capitalists. (Adam Smith was a "moral philosopher" looking for a way to redistribute the new wealth generated by the industrial revolution; He did not invent theories of economics to maximize profit via demand-supply charts)