Neologisms for programmers
A collection of “useful” slang I’ve “appropriated” over the years.
(Sources are listed when I have one — sometimes the source has been deleted as ‘not constructive’ (cough Stack Overflow), or otherwise lost to the bit rot of time…)
Carpet Logging (jdk)
The act of completely filling a piece of source code with debug log calls, each printing out state in the desperate attempt to figure out WTF is going on.
This is done in lieu of using a debugger to step through the code, either by 7337 certification-prodigies who think that only n00bs use debuggers, or by damned souls stuck in environments that don’t support one.
Cut-and-waste code (Dinah)
The result of someone cutting-and-pasting code they found in some blog somewhere into a 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 our code.
Encraption (Loadmaster)
Really insecure encryption; that which gives management the illusion that the code is securing sensitive data, but in reality isn’t. For example, a code base which is stored encrypted, but the password is stored in plaintext at the root of the repository.
Hope Driven Development (Robert)
A software development technique in which an application is developed in a long unplanned development cycle, with minimal testing, all with the hope that everything will work as intended when released.
Working By Accident (anon)
Code that’s been deployed but not tested. If it’s not tested, how do you know it’s doing what it’s supposed to?
Bug-Hunter Testing (anon)
Testing that consists of poking around in an application hoping that you will not have a “Crikey! That’s a big ‘un! Lemme just try to sneak up on it and poike at it till it bites me!” moment.
Click it Harder (Jack)
Developer response to QA testing the developer’s software when the button doesn’t function, or doesn’t function completely.
Smug Report (Aaronaught)
A bug submitted by a user — often a programmer themselves — who thinks he knows a lot more about the system’s design than you do. Filled with irrelevant technical details and one or more suggestions (inevitably wrong) about what he thinks is causing the problem and how we should fix it.
Refuctoring (Jason Gorman)
The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely impossible to maintain by anyone except yourself. (see also: the wrong kind of job security.)
Stringly Typed (Mark Simpson)
(aka “String Oriented Programming”) A riff on strongly typed. Used to describe an implementation that needlessly relies on strings when there are options which are more programmer and refactor-friendly.
For example, code which requires options to be passed in as ‘magicstrings’.
Bug-For-Bug Compatible (jargon)
When a new version of software must emulate bugs of a previous version to avoid breaking customers or downstream code. Windows used to be famous for this.
Common Law Feature (Scott)
A bug that has existed in deployment so long that it is now part of the expected functionality, and user support is required to actually fix it.
(Editors note: too many Common-Law features generally mean you’re going to end up releasing a bug-for-bug compatible version, possibly hidden behind a user preference.)
Hydra Code (jdk)
Code that cannot be fixed. One fix causes two new bugs. It cannot be improved; instead it must be set on fire, buried, and rewritten. (“I say we dust off, nuke the entire code base from orbit. It’s the only way to be sure.”)
