How to Speak Geek: Cracking Programmer Jargon

How to Speak Geek: Cracking Programmer Jargon

by Darryl K. Taft

Banana Banana Banana

This is a term to describe placeholder text indicating that documentation is in progress or yet to be completed. Mostly used because FxCop complains when a public function lacks documentation.

Barack Obama

A project management account to which the most aspirational tickets—stuff youd really like to do but will probably never get approval for—get assigned.

Bugfoot

A bug that isnt reproducible and has been sighted by only one person. This is similar to the Loch Ness Monster Bug.

Counterbug

A defensive move useful for code reviews. If someone reviewing your code presents you with a bug thats your fault, you counter with a counterbug: a bug caused by the reviewer.

Drug Report

A bug report so utterly incomprehensible that whoever submitted it must have been smoking crack.

Chug Report

The lesser version of Drug Report, where the submitter is thought have had one too many.

Shrug Report

A bug report with no error message or repro steps and only a vague description of the problem. Usually contains the phrase “doesn’t work.”

Smug Report

A bug submitted by a user who thinks he knows a lot more about the system’s design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.

Duck

A feature added for no other reason than to draw management attention and a directive that it be removed, thus avoiding unnecessary changes in other aspects of the product.

Fear-Driven Development

When project management adds more pressure, such as by firing a member of the team.

Ghetto Code

A particularly inelegant and obviously suboptimal section of code that still meets the requirements.

Refactoring

The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself.

Stringly Typed

A riff on “strongly typed.” Used to describe an implementation that needlessly relies on strings when programmer- and refactor-friendly options are available.

Jimmy

A generalized name for the clueless/new developer.

Unicorny

An adjective to describe a feature that’s so early in the planning stages that it might as well be imaginary.

Workaroundability

This is the feeling when an already hacked approach still can or can’t be hacked further.

Baklava Code

Code with too many layers (also has been known in some circles as lasagna code).

Common Law Feature

A bug in the application that has existed so long that it is now part of the expected functionality, and user support is required to actually fix it.

Code Slush
For the date after which no changes will be accepted, except, of course, all the changes that management will ask for at the last minute. Like Code Freeze

but accepting of the fact that some changes will still get in when deadlines prove to be softer than a snowball in June.

Mad Girlfriend Bug

This refers to the times when a developer sees that there is a definite problem with the code execution but cant tell what is. Then when you look closer at the code, it will act just like your temperamental girlfriend and indicate that everything is just fine.

Hydra Code

Code that cannot be fixed without spawning even more bugs. One fix causes two new bugs. It should be rewritten.

Jenga Code

When the whole thing collapses when you alter a block of code.

Bug Bait

Programming practices that encourage, rather than discourage, program flaws.

Cut-and-Waste Code

When someone uses cut-and-paste code they found online (usually from a blog) in a production product. The result is usually a lot of wasted time trying to track down an obscure bug from a line or variable that undoubtedly made sense in the original context but not in the current project.