Every field comes up with its own jargon, and oftentimes subgroups within a field come up with their own specific words or phrases (those of you familiar with Microsoft Canada’s Developer and Platform Evangelism Team know that we have our own term for “broken”, named after one of our teammates who is notorious for killing all sorts of tech gear).

A question recently posted on Stack Overflow asked for people to submit programming terms that they or their team have coined and have come into regular use in their own circles. I took a number of the submissions and compiled them into the alphabetically ordered list below for your education and entertainment.

Have you come up with your own jargon? Tell us in the comments!

Banana Banana Banana

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

Example:

/// <summary>
/// banana banana banana
/// </summary>
public CustomerValidationResponse Validate(CustomerValidationRequest request, bool ...

Barack Obama

A project management account to which the most aspirational tickets – stuff you’d really like to do but will pobably never get approval for – gets assigned.

Bicrement

Adding 2 to a variable.

Bloombug

A bug that accidentally generates money. [Joey’s note: I have never written one of these.]

Bugfoot

A bug that isn’t reproducible and has been sighted by only one person. See Loch Ness Monster Bug.

Chunky Salsa

A single critical error or bug that renders an entire system unusable, especially in a production environment.

Based on the chunky salsa rule from TVTropes: Any situation that would reduce a character’s head to the consistency of chunky salsa dip is fatal, regardless of other rules.

Configuration Programming / Programmer

Someone that says they are a programmer but only knows how to hack at configuration files of some other pieces of software configuration to make them do what they want.

Counterbug

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

DOCTYPE Decoration

When web designers add a proper DOCTYPE declaration at the beginning of an HTML document, but then don’t bother to write valid markup for the rest of it.

Drug Report

A bug 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 have had one too many.

Duck

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

This started as a piece of Interplay corporate lore. It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn’t, they weren’t adding value.

The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen’s animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the "actual" animation.

Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, "That looks great. Just one thing – get rid of the duck."

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. [Joey’s note: I’ve written ghetto code before, but that’s because I’m street, yo!]

Hindenbug

A catastrophic data-destroying bug. Oh, the humanity!

Hocus Focus Problem

Unexpected behavior caused by changes in focus, or incorrect setting of focus. Could also be used to describe an app stealing your focus.

Hot Potato / Hot Potatoes

A fun way to pronounce http:// and https://.

IRQed

Annoyed by interruptions. Pronounced like and has a similar meaning to “irked”.

Jimmy

A generalized name for the clueless/new developer. The submitter at Stack Overflow writes:

We found as we were developing a framework component that required minimal knowledge of how it worked for the other developers. We would always phrase our questions as: "What if Jimmy forgets to update the attribute?"

This led to the term "Jimmy-proof" when referring to well designed framework code.

It’s probably best not to use this term around IronRuby developer Jimmy Schementi.

Loch Ness Monster Bug

A bug that isn’t reproducible and has been sighted by only one person. See Bugfoot.

Megamoth

MEGA MOnolithic meTHod. Usually stretches over two screens in height and often contained inside a God Object (an object that knows or does too much).

.NET Sandwich

When .NET code called native code which calls other .NET code and makes the poorly designed application crash.

n-gleton

A class that only allows a fixed number of instances of itself.

NOPping

Not napping, but simply zoning out. Comes from the assembly language instruction NOP, for No OPeration, which does nothing.

Pokemon Exception Handling

For when you just gotta catch ’em all!

Reality 101 Failure

The program (or more likely feature of a program) does exactly what was asked for, but when it’s deployed it turns out that the problem was misunderstood and the program is basically useless.

Refuctoring

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. It’s job security!

The Sheath

The isolating interface between your team’s (good) code, and the brain-dead code contributed by some other group. The sheath prevents horrible things (badly named constants, incorrect types, etc.) in their code from infecting your code.

[Joey’s note: I’ve heard the term “shim” used for this sort of construct. I’ve used the term “transmogrifier” for this sort of thing.]

Shrug Report

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

Smug Report

A bug report 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.

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.

Examples:

• Method parameters that take strings when other more appropriate types should be used
• On the occasion that a string is required in a method call (e.g. network service), the string is then passed and used throughout the rest of the call graph without first converting it to a more suitable internal representation (e.g. parse it and create an enum, then you have strong typing throughout the rest of your codebase)
• Message passing without using typed messages etc.

Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find.

Unicorny

An adjective to describe a feature that’s so early in the planning stages that it might as well be imaginary. This one comes from Rails Core Team member Yehuda Katz, who used it in his closing keynote at last year’s Windy City Rails to describe some of Rails’ upcoming features.

Yoda Conditions

The act of using

if (constant == variable)

instead of

if (variable == constant)

It’s like saying “If blue is the sky”.

This article also appears in Canadian Developer Connection.

On Friday, the Stack Overflow DevDays travelling conference, which covers ten cities in North America and Europe in a month, took place in Toronto’s St. Lawrence Centre for the Arts. The sold-out conference was packed enthusiastic developers from both the Toronto area as well as cities within driving distance as well as a large number of volunteers (in fact, there were too many; the conference typically “overbooks volunteers in anticipation of a drop-off, but every volunteer who signed up showed up!).

It was a fun conference, and I was honoured to be selected as a speaker for the event. It was good meeting Joel again (it’s been a number of years now) and speaking on the same stage with some good local friends (Reg Braithwaite and Greg Wilson) as well as some new ones (Jordan Baker and Ralph Whitbeck).

At the end of the conference, Joel took a show of hands of people who’d attend next year. When nearly all the hands in the audience went up, he said “All right – we’re going to be back here next year!”

For the benefit of all, I’ve posted the slides from all the presentations below:

ASP.NET MVC: Barry Gervin and Joey deVilla

Our presentation followed Joel’s opening keynote and was centred around a live-coding demo in which we built a quick-and-dirty ASP.NET MVC-based clone of RunPee.com, a site that lets you know at what times you can take a bathroom break from a movie in a theatre and not miss any crucial plot points.

I’ll admit it right now: this presentation could’ve been much better, and as the one who gets paid to promote Microsoft’s tools and technologies, I assume full responsibility for this one (Barry’s a great presenter who volunteered and took time out of his extremely busy schedule to do this). Watch this space for a "lessons learned" post, as well as some ASP.NET MVC posts that take the material from the presentation and explain it a little better.

Python: Jordan Baker

Jordan’s presentation was an introduction to Python by way of a walk-through of Peter Norvig’s How to Write a Spelling Corrector exercise, which comprises 21 lines of Python 2.5 but in those few lines, covers a lot of the Python programming language.

jQuery: Ralph Whitbeck

Ralph’s presentation was a walk-through of jQuery’s features, and how it will make your web applications sing. I need to get more familiar with jQuery (I’m far more acquainted with Prototype and Scriptaculous), so Ralph’s was the technology demo that was the most useful to me.

Academic: Greg Wilson

By my own judgement, as well as the judgement of the attendees, Greg Wilson’s presentation was by far the best one of the day. This was sole no-code-at-all presentation of the day, featuring the sort of "let’s change the world" vibe that we strive for at DemoCamp. In it, Greg challenged us to weed out the false or faulty maxims based on poor or no research that are now an accepted part of programming practices, find out what we really know about the practice of software development, and do our best to expand what we do know about programming, with research and rigor, not anecdotes and assumptions. This presentation got a lot of applause, and deservedly so — there’s nothing like a great topic delivered by a great presenter.

Ruby: Reg Braithwaite

Reg Braithwaite’s talk — made up of slides consisting entirely of Ruby code (or Ruby pseudocode, where appropriate) — wasn’t so much about Ruby as it was about metaprogramming, with Ruby examples. Following the quip about a man (one account says it was Winston Churchill) who is chastised by a woman for being drunk who then retorts "Yes, but in the morning, I will be sober and you will still be ugly", he encouraged the audience to "turn ugly problems into drunk ones".

Other Writeups

There are a couple of review of the conference:

• at Meta Stack Overflow
• at Geoffrey Wiseman’s blog, Tech Scene

This article also appears in Canadian Developer Connection.

This article also appears in Canadian Developer Connection.

Just in case there’s nothing good on TV and you’re having a “lazy Sunday”, here’s a video of Joel Spolsky’s recent presentation at Google, Learning from StackOverflow.com, in which he talks about the design decisions that went into and the lessons learned from the Stack Overflow site. It runs for about 52 minutes, so you might want to get yourself a nice beverage before you watch it:

Over at Canadian Developer Connection, we’ve got one more video from PDC in which Yours Truly conducted the interview: it’s with Jeff Atwood, the guy behind the blog Coding Horror and co-creator of Stack Overflow. It’s a brief interview; there were many people who wanted a slice of Jeff’s time, and we were lucky to even be able to buttonhole for as long as we did.

We’ll catch up for beers and Rock Band soon, Jeff!

Links

• Video interview with Jeff Atwood
• Stack Overflow
• Coding Horror
• Where the name “Coding Horror” came from