How to Speak Geek: Cracking Programmer Jargon

by Darryl K. Taft

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.

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.

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

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.

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

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

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.”

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.

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.

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

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

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.

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

A generalized name for the clueless/new developer.

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

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

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

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.

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

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.

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

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

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

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.