Skip to content

IT Humor

IT Gender

There have been several terms in IT and computing that have been reconsidered and changed due to their potentially offensive or non-inclusive connotations. Here are some examples:

  • Master/Slave: As mentioned earlier, this terminology, especially in database contexts, has been replaced in many instances with terms like "Primary/Replica" or "Leader/Follower".
  • Blacklist/Whitelist: These terms are being replaced with more neutral terms like "Blocklist/Allowlist" or "Denylist/Permitlist".
  • Dummy Value: The term "dummy" can be considered derogatory. Alternatives like "placeholder value" or "sample value" are used instead.
  • Sanity Check: This term can be seen as insensitive to mental health issues. Alternatives include "Quick Check", "Confidence Check", or "Coherence Check".
  • Kill: Commands or processes in computing that use the term "kill" (e.g., kill command in Unix-like systems) can be seen as violent. Some suggest using terms like "stop", "end", or "terminate", though "kill" is still widely used due to its historical presence.
  • Male/Female Connectors: In electronics, connectors are often referred to as "male" or "female" based on their design. Some people are moving towards terms like "plug" and "socket" or "pin" and "jack" to avoid gendered language.
  • Grandfathered: This term, which means to exempt existing entities from new rules, has racial origins related to voting rights in the U.S. Alternatives include "legacy status" or "exempt from new rules".
  • Man-in-the-Middle Attack: This cybersecurity term describes an attack where a malicious actor intercepts communication between two parties. Some suggest using "On-path Attack" or "Person-in-the-Middle Attack" as alternatives.
  • Blind Carbon Copy (BCC): Some argue that the term "blind" in this context can be seen as insensitive. Alternatives like "Private Copy" or simply "BCC" without expanding the acronym are sometimes used.
  • Crippleware: This term was used to describe software that has some of its features disabled until a payment or license is provided. Given the derogatory nature of the term "cripple", alternatives like "Feature-limited", "Demo Version", or "Restricted Version" are preferred.
  • Manned/Unmanned: In the context of space exploration or drones, the terms "manned" and "unmanned" are being replaced with "crewed" and "uncrewed" to avoid gender-specific language.
  • Native Functionality: The term "native" can be seen as problematic when used to describe inherent features or functions of software or hardware. Alternatives like "built-in functionality" or "inherent features" are suggested.
  • First-Class Citizen: In programming, this term is used to describe entities that have all rights and privileges. To avoid potential classist connotations, terms like "First-Class Entity" or "First-Class Object" are used.
  • He/She, Him/Her in Documentation: Many documentation and style guides now recommend using gender-neutral pronouns like "they" and "them" when the gender of the subject is unknown or irrelevant.
  • Chained Promises: In programming, especially with JavaScript promises, the term "chaining" can have negative connotations related to slavery. Some developers prefer terms like "linked promises" or simply "using promises sequentially".
  • Black Hat/White Hat: In cybersecurity, these terms refer to malicious and ethical hackers, respectively. While still widely used, there's some discussion about finding more neutral terminology.
  • Motherboard/Fatherboard: The main circuit board in a computer is commonly called a "motherboard". While "fatherboard" isn't a standard term, the gendered nature of "motherboard" has been discussed. However, alternatives haven't been widely adopted.
  • Suicide Command: In computing, a command that can cause a system to become inoperable is sometimes colloquially referred to as a "suicide command". Given the sensitivity around the topic of suicide, it's recommended to use terms like "destructive command" or "dangerous command".
  • Dead Man's Switch: This term refers to a switch that is automatically operated if the human operator becomes incapacitated. Alternatives like "automatic safety switch" or "life-check switch" can be considered.

PROgramming

Assembler Mnemonics

Secret undocumented instructions:

ARG: Agree to Run Garbage
BDM: Branch and Destroy Memory
CMN: Convert to Mayan Numerals
DDS: Damage Disk and Stop
EMR: Emit Microwave Radiation
ETO: Emulate Toaster Oven
FSE: Fake Serious Error
GSI: Garble Subsequent Instructions
GQS: Go Quarter Speed
HEM: Hide Evidence of Malfunction
IDD: Inhale Dust and Die
IKI: Ignore Keyboard Input
IMU: Irradiate and Mutate User
JPF: Jam Paper Feed
JUM: Jeer at Users Mistake
KFP: Kindle Fire in Printer
LNM: Launch Nuclear Missiles
MAW: Make Aggravating Whine
NNI: Neglect Next Instruction
OBU: Overheat and Burn if Unattended
PNG: Pass Noxious Gas
QWF: Quit Working Forever
QVC: Question Valid Command
RWD: Read Wrong Device
SCE: Simulate Correct Execution
SDJ: Send Data to Japan
TTC: Tangle Tape and Crash
UBC: Use Bad Chip
VDP: Violate Design Parameters
VMB: Verify and Make Bad
WAF: Warn After Fact
XID: eXchange Instruction with Data
YII: Yield to Irresistible Impulse
ZAM: Zero All Memory
PI: Punch Invalid
POPI: Punch Operator Immediately
RASC: Read And Shred Card
RPM: Read Programmers Mind
RSSC: Reduce Speed, Step Carefully (for improved accuracy)
RTAB: Rewind Tape and Break
RWDSK: ReWind DiSK
SPSW: Scramble Program Status Word
SRSD: Seek Record and Scar Disk
WBT: Water Binary Tree

WTF Driven development

A list of management systems. This list was created by Google Driven Development.

  • Asshole-Driven development (ADD): Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. Asshole breaks them and people follow anyway. Likely driven by a culture that makes it impossible to change or make decisions. People who want to make things better are forced to be an asshole about it because if they don't then they are not heard. Not everyone makes great decisions and I bet you ever single asshole is doing what they honestly believe is best.
  • Cognitive Dissonance development (CDD): In any organization where there are two or more divergent beliefs on how software should be made. The tension between those beliefs, as it’s fought out in various meetings and individual decisions by players on both sides, defines the project more than any individual belief itself. Likely evolves from an organization that punishes rocking the boat. Rather than spending your time changing and make a decision on how to improve you end up needing to focus on how to make that change without causing trouble. Disagreement is fine - an organization that punishes for disagreement just ends up forcing everyone involved to focus on how to get their way without showing active disagreement.
  • Cover Your Ass Engineering (CYAE): The driving force behind most individual efforts is to make sure than when the shit hits the fan, they are not to blame. Ignore your engineers and their suggestions, then punish them when what you did anyway didn't work, and you have CYAE. Plenty of consultants have learned this one: "I recommend against this but it's your choice and the consequences will be on you when I'm gone".
  • Development By Denial (DBD): Everybody pretends there is a method for what’s being done, and that things are going ok, when in reality, things are a mess and the process is on the floor. The worse things get, the more people depend on their denial of what’s really happening, or their isolation in their own small part of the project, to survive. Hire managers that don't manage if you want this environment. No one makes decisions, engineering team isn't given the time to find their own process, so they just do their best with what they have. If you want to strengthen this then I suggest yelling at your engineers whenever you find there isn't a process in place and immediately follow it up with enough engineering work that they will be working 60 hour work weeks.
  • Get Me Promoted Methodology (GMPM): People write code and design things to increase their visibility, satisfy their boss’s whims, and accelerate their path to a raise or the corner office no matter how far outside of stated goals their efforts go. This includes allowing disasters to happen so people can be heroes, writing hacks that look great in the short term but crumble after the individual has moved on, and focusing more on the surface of work than its value. This is an easy environment to create. Just don't recognize ANYONE who seems to consistently do a good job and never has a disaster. If you have someone who generates good work and never seems to need to fire fight then they clearly are just doing the minimum and not doing such a good job that the firefight isn't necessary.
  • Don’t Rock The Boat Development (DRTBD): Satisfies all those senior developers that are looking forward to retirement and don’t want to develop on anything that was not tried and proved during the 90’s, the decade in which their latest mindset update took place.
  • Hormone Driven Development (HDD): Development done by some young guys who think they know it all (evident by posts like that from the little tyke OldCoot). These HDD kids lack social skills and tend to write convoluted, over engineered code hoping to impress everybody (even the old guys they despise). Instead of taking advantage of being mentored by older developers who have been writing code since these young dummies were still in their mother’s ovaries, they are arrogant self-promoting, blowhards who are TOO STUPID to know they suck as a developers. They are too immature to understand that the older guys have met and overcome challenges in their careers unknown and unfathomable to these young maggots. Sometimes these young ‘uns are even promoted into an ADD position for a short term until they fail and are removed. Go ahead now kids – think of something clever and condescending to write in a reply now.
  • Fear Based Development (FBD): Nothing ever changes because every decision that might make things better is instantly poo-pooed by senior developers who all cite the same apocryphal story from the nineties about how they tried that and it is expensive and doesn’t work regardless of how far the rest of the software industry has come with the technology or tools since then. FBD Real world example #1: when considering upgrading to git (from dimensions) the idea that git could do automatic merges of any kind was literally and loudly laughed at. FBD Real World Example #2: when considering doing any level of automated testing anywhere in the building an apocryphal story from the nineties is always cited as other senior developers get nostalgic and nod and the idea dies a quick and painless death.
  • Error Driven Development (EDD): Cubicle dwellers are constantly putting out fires, chasing bugs, fixing bugs, debugging, patching bad code, breaking data type interfaces, all because of short-sighted managers who love golf more than software quality. Combined with silly rules like "be here by 8am" regardless of 60 hour weeks and saturdays/sundays. EDD mimics natural control systems found in nature.
  • Hacker driven development (HDD): It is important to do it, no matter how you did it. Any type of constraints, weather from a language, design or methodology is refused. If it is not performing well, throw more hardware at it. And of course the less lines of code you use the better, specially of you are using a cool feature from your scripting language the does some sort of magic, regardless of the fact that you are the only one who understand this code, and even you will not understand this code when you read it 3 month from the day you wrote it.
  • Smothering Hen Driven Development (SMDD): An addendum to ADD, where the asshole smothers you by sitting beside you all day like a hen does with her eggs and suggests a plethora of ideas that will render maximum counter-productivity and clobber any progress back to the stone age. This methodology is further supplemented by CTRL+Z Driven Development, when you follow the asshole’s advice but scraps it after spending much time, effort, and personal life once the client finds out you did something outrageously not in the design. – Reward Incompetence Punish Success (RIPS): In an ADD-driven environment, the most incompetent get rewarded by the more incompetent, for being members of the same ‘Stupid Club’. The successful, competent developers are punished for making the incompetent managers and their little kiss-asses look bad. Their goal is to force the competence out so the incompetents can continue unexposed and unchallenged. They follow the AABC rule–‘A’ people hire ‘A’ people while ‘B’ people hire ‘C’ people. Eventually there are only ‘C’ developers being lead by ‘B’ or ‘C’ managers.
  • Soviet Union Factory methodology (SUF): Documentation is not existent, one dev doesn’t know what other one is doing or what an overall project should do. Given small and specific tasks they stumble in the code blindly. Communication is kept to zero. Code is full of methods who perform exact same function. Patterns are either non existent or there’s as much of them as there’s developers rendering any effort to keep structure clean useless. Management thinks project is too big to fail
  • Sales-Idiot Driven Development (SIDD) Where, in flagrant violation of the correct procedures, a maverick sales-droid has sold something that doesn’t exist, probably can’t exist, or would take an eternity to make exist, it’s the company’s BIGGEST BREAK EVER, and must be done next week to exacting specifications already agreed with the customer. By the sales-droid. Alone. Given the deal value, the CEO’s reluctantly had to support it. Off you go, then. Fully working prototype by – um – Thursday work for you? (BTW, most sales-folk know to discuss and negotiate with Engineering before making commitments. These fine, upstanding and honorable people never come onto developers’ radars. Sadly the small minority that are SalesIdiots do, and give the whole profession – which pays everyone’s wages – a bad name.)
  • Innovation-Driven Development (IDD): Everything you ever knew – everything you read about only last week as the Next Big Thing – is sooo yesterday. We’re going to refactor the project to use Gurgle.js and the Glorp framework. Yes, I know, it’s only two weeks to release. Yes, I know, Gurgle’s in first alpha, and Glorp’s on early preview. But we can do this, people!
  • Wheel-Reinvention-Driven Development (WRIDD): MySQL can’t hack it, and doesn’t support an obscure feature that we probably don’t need anyway. PostgreSQL had a bug in the last release. So. We’re going to write our own database, because we can do in two weeks what Oracle, MySQL/MariaDB and PostgreSQL couldn’t manage in a decade or three.
  • Golf Driven Development (GDD): Chief Exec plays a few holes with big cheese at prospective client company, during which big cheese hints at a sale if a certain feature exists. Chief Exec responds "what a coincidence: that’s in our next release!" and seals the deal. Dev team then has to implement it by yesterday, with the added bonus that they can’t ask the prospective client to clarify exactly what they wanted the feature to do because as far as he’s concerned it’s already implemented.
  • Kick The Can Development (KTCD): All important design and architecture decisions are delayed to finish a couple "critical" features in the next two weeks. In two weeks, six more features will be deemed "critical" and four more weeks added to project, but still no time for design or architecture. Continue process for the next 2 years, then scrap the steaming mess for a new technology that promises to rewrite the entire project in just 6 weeks. Repeat process with new technology.
  • Despair Driven Development (DDD): It’s clear the project/company is going to fail anyway, so hack on anything you want, it doesn’t really matter.
  • I’m Gone Anyway Methodology (IGAM): Where you know that you’ll leave the company by the end of the month and don’t care about anything.
  • Ayn Rand Driven Development (ARDD): Every class does only what’s best for itself with no thought or concern given to any other class, any objects created are held on to privately forever and any object that needs something is considered a parasite.
  • Timecard driven development (TDD): Hack for a while. commit at 4 PM. you may not be able to separate features, but you can back code out to the most recent "runs" commit before the rollback you need!
  • seagull management (SM) Where the supposed leaders are totally uninvolved in the work, they just swoop down once in a while to shit all over everything "This is wrong, and this, and this looks bad" etc, before flying away again. Then just swoop in, yell "MINE" and take credit for all your hard work.
  • Demo Driven Development (DDD): Requirements appear in a flash because managers bragged about something their people do or sales guys talked about a nonexistent feature, and now you have to make reality fit theirs. Soon enough you'll realize that you haven't made anything substantial because all your time was spent on spike projects and management will wonder where all their features are in production. They will view it as the project running out of control and micromanage more to "fix" the problem.
  • Bug Driven Development (BDD): You know your code is going to have bugs so you should always write bugs first. That way you can find and fix them earlier in the process and for the remainder of the dev cycle just write bug free code.
  • Interrupt Driven Development (IDD): Where a ridiculously large number of people in the company have the authority to order you to drop whatever you're doing and work on whatever they've just decided absolutely has to be done right now. The result is that nothing gets done because everything gets interrupted.
  • Google Driven Development (GDD): This person does not believe in writing anything on his own, copy/paste from blogs, articles, source code is a way of life. And since I have not written it I don't care how it works as long as I see something working. His best friends are Ctrl-C, Ctrl-V and Google. Cannot write 5 lines of code or code for 5 minutes without doing a Google search. His productivity is directly related to performance of corporate network, and how fast Google searches. If the network is down, it's better to go for a coffee. Search hours on Google for "Object reference not set to an instance of an object" and then believes that the whole world is facing the same issue. Who cares what the context of problem is. He then tries each and every solution that Google GOD provides. If by fluke he is able to fix or camouflage the issue, he considers himself something special, but in his heart he knows he has no clue what happened. Thanks Google for saving his day and continues his pursuit to become a better GDDer. If not, then it's time for the Lead, the next GOD in Line. The Lead should be able to fix this issue, What else are Leads there for :)