Interesting phrases

I was just reading an essay called "How to be a Programmer: A Short, Comprehensive and Personal Summary" and was struck by the many phrases and slang words that we as programmers use and Joe Public have no idea as to the meaning.

This is a general problem in any industry. The tribe (I'll get to this) have a sort of short-hand for communicating. When in front of customers/clients, using this slang can be detrimental as the client feels stupid or left out of the loop.

So for my zero readers who are planning specialised software, here is a quick breakdown of key phrases we as developers use:

Tribe: The group of people you work with to achieve a single goal. This can mean the direct task force, the specific project or the entire company/studio. Using this phrase builds a sort of group pride and can benefit towards better teamwork and moral. Also a good idea for t-shirts.
Unk-unk: Short for "unknown unknown". Management people should understand this. When planning a deadline you can estimate for certain unknowns. unk-unks are those unknowns that you never would've thought of until they happen.
Low-hanging Fruit: Simple things you can change that dramatically improves the product.
Garbage: As the word implies, things that are no longer needed but take up space. Most modern program languages have a system for clearing this called Garbage Collection.
Memory leak: When some useless reference to a garbage object prevents it from being collected. This has the effect of the memory leaking away and a gradual loss of performance... By gradual I mean over the course of a few seconds...
Vapour/Vapor/Vape: A programming, technology or development component that is advertised and promised and in some cases even already bought, but isn't available yet. Too many times a development project is cancelled even weeks before the scheduled release date. If it's not out there, don't bet on it.
Scroll-blind: The condition of being unable to find what you're looking for because it's lost amongst a lot of useless information or documentation. Think of scanning your finger down a page in a book looking for a single word.
Wall-clock: The actual time measured by a clock on a wall, as opposed to CPU time which is how long a command takes to execute.
Bottleneck: A single thing or group of things that limits performance or prevents the developer from solving a problem or bug.
Hitting the Wall: To suddenly run out of a specific resource, causing performance to degrade sharply rather than gradually. Those times when the program you're working in just suddenly stops responding.
Speculative Programming: Producing a feature before it is really known if that feature will be useful.
Flinging / Boxes and arrows: Generally known as brainstorming. Often when planning a system, the design team will call a meeting and pull out a whiteboard and just plan everything out, using boxes and arrows. Or just throwing (flinging) ideas around and hearing what everyone thinks. A good idea for customer relations would be to invite your client to one of these flingings so they get an idea of (1) how complex the system really is and (2) what exactly you do all day when you're not flinging or writing documentation.
White-paper: An informative document that is meant to explain or sell an idea to an audience different from the people/tribe that produced it. This can be a proposal to a client or a functional specification to another other tribe. Basically any physical paper-based document that doesn't have too much technical information associated with it.

Now for the slightly harder-core terms.

Method: A section of code that executes on its own to perform a specific task. Usually a developer would be tasked with coding a specific method in the style of "You receive this information and must accomplish this task, then return this information." The method can then be executed anywhere in the application to perform that task.
Code Reuse: Basically the reason for the above described. If the task can be normalised to a generic point a single method can be used to perform the task a million times in different places. This means you don't have to write the same code over and over with minor changes and if a bug is found it only needs to be addressed in one place.
Class: A hypothetical entity for grouping methods and properties of similar functionality. For instance your code that performs tasks can be grouped in a logic class and your code that produces visual feedback can be grouped in a UI (user interface) class. This also means that certain sections can be recoded or modified without the entire system needing to change.
Information Hiding: A design principle used when producing decoupled components or classes. A component only exposes the properties or methods (don't you feel smart now?) that is needed by other components to communicate with each other. This prevents developers that don't know the system by heart from accidentally calling the wrong methods.
Lingua franca: A language so popular in a specific field that it is almost accepted as the standard. In many cases a team would benefit from learning the de facto language from scratch rather than trying to do it in the team's language of preference, as many common problems in the field has inevitably been solved by someone else.

And that's the basic jist of it. Something you must get used to is "If you don't know, ask." Developers usually don't mind explaining what they're saying. We do this all the time. Some are better at it than others, though.