Sunday, November 6, 2011

funny programming terms that we share in workplace

I have maintained a list. Please feel free add.


It mean cheap-less code but it works well.


Impressive code that was written in very short time.


Things are properly understandable.

Quantum bug

The bug that fails to occur when trying to observe it (ie tracing through code a line at a time).

Code Monkey

An insulting term to describe a poor programmer, usually who does not grasp basic or common programming concepts, and sometimes whose best coding capabilities can be described as "GoogleCut&Paste".

Ghost Bug.

Referring to a bug that cannot be reproduced in controllable conditions, a bug that seams to have appeared but no one is sure about it. A bug that requires voodoo for fixing. A bug
that drives a developer to think that a mutex should be used in a single threaded app.


The process of taking code and refactoring it without consequence to make it do what management demands that the code do.

Faith based programming

When "Jimmy", instead of using a more.. "scientific" approach to problem solving, just randomly delete, comment or rename a variable/line of code and prays for it for compile/runs.

Pixie Dust

A "tool" used by developers to "magically" fix certain issues via abnormal/illogical/unexplained means. (coined by the leader of our support team) When an issue completely baffles the
development team we are "out of pixie dust".

A**hole Features

Features that are thought of during release planning that add little to no actual value to the software.


To use Agile methodologies and have people totally screwing it up.

Hi-driven development

When you debug your program by writing alert('Hi') statements in a trial-and-error fashion

Disaster Driven Development

When Your PMs and salesmen promised that You will build "space shuttle" in one month.

Hope Driven Development

A software development technique in which an application is developed in a long unplanned development cycle, with minimal "Steve Irwin-style testing", all with the hope that
everything will work as intended when released.

Different kinds of bug reports:

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.

Drug Report - a report so utterly incomprehensible that whoever submitted it must have been smoking crack. The lesser version is a chug report, where the submitter is thought to 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."


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.


Can't take credit for this, but it is awesome!
A computer bug that disappears or alters its characteristics when an attempt is made to study it.


A catastrophic data destroying bug - "Oh the humanity!"


A bug you present when presented with a bug caused by the person presenting the bug


A bug that accidentally generates money (just did this one)

Fear Driven Development

When project management adds more pressure (fires someone or something).

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.

Hydra Code

Code that cannot be fixed. One fix causes two new bugs.It should be rewritten.


A prototype that ends up in production.

Ninja comments

Also known as invisible comments, secret comments, or no comments.

Chunky salsa

Based on the chunky salsa rule, a single critical error or bug that renders an entire system unusable, especially in a production environment.


Sometimes, you just have to talk a problem out. I used to go to my boss and talk about something and he'd listen and then I'd just answer my own question and walk out without him saying a thing.

I read about someone that put a rubber duck on their monitor so they could talk to it, so rubberducking is talking your way through a problem.


"Hey, I'll put all of our customers into a Word document and then we can X." "No, we should do that database-ically so that we can keep that list up to date."

Hooker Code

Code that is problematic and causes application instability (application "goes down" often).

1 comment:

  1. Hi Ravi,

    I posted a load of bug report definitions at