Pilot fish is hired to take over the programming duties of a departing manager who also wrote code — and that’s not quite as simple as it sounds.

“He had several hard-and-fast rules for the programmers under him,” says fish. “Rule number one: Never ever ever comment code, because a good programmer can figure out the code by reading it.”

More of the ex-manager’s rules that fish soon discovers:

  • Never use white space in code.
  • Use the shortest variable names possible. One-letter names are good.
  • Reuse code, even if the code you’re re-using does something completely different than what is needed.
  • Put all vaguely related code into one procedure, and control which pieces actually execute on a call via complicated (and undocumented) parameter combinations.
  • Hide new business logic in whatever code is being worked on at a time. All code blocks must have unanticipated side effects.

“OK, that last one wasn’t a rule — it was just how he coded,” fish says. “After ten years, I’ve refactored almost all of his code. I’ve not been able to get through all of it because there are too many places where I can see what the code is doing, but can’t make heads nor tails of why it’s doing it.

To read this article in full or to leave a comment, please click here