Some jargon, like “foo” and “dotfile” are pretty widespread. Most jargon is personal to you, your work, or your local community. That’s the stuff I’m I want to hear about. People’s jargon is often useful and always interesting! Some of mine in no particular order:
-
Slurping: From an old workplace, for scraping a data source and turning it into structured data. Like “We slurped the CSV into a bunch of dictionaries.”
-
Salamander: A fuzzer that randomly walks a program’s state space, like randomly clicking links on a webpage. I have no idea why I call it this.
-
When writing property-based tests, some properties aren’t “directly” related to the function’s spec, like “this should still get the same result if we shuffle the list”. These make good but unintuitive property tests. I call them tactics, like “the shuffle tactic”.
-
Most unit tests are oracle tests: you’re testing that a given input gives you an exact output.
-
Khlaaf’s Law is “the average internet opinion is wrong.” I just named it after a friend who tweeted it first. Probably doesn’t help that I have to explain it each time I say it in public.
-
I took adverse (Do x and if it fails, do y) and obverse (“moral” inverse that’s not the mathematical inverse) from J.
-
foois a noun so we need a generic verb, too. I usefarbleas the verb-equivalent, like “go farble the widgets”. I think it comes from an old joke thing I wrote in college.
This is such a great discussion question. It’s so hard to identify these for myself, because I use them so often that they don’t stand out as novel to me, but I’ll try…
The ground you’re standing on is the sum total of the technological and social systems that lead you to be writing this code today, and on which the code relies to fulfill its function.
The technological aspect is most likely to be of practical relevance; for example, if you’re coding in PHP and not aware of how it co-mingles strings and integers in its array indexing, you are on shaky ground because there’s a layer you rely on that you don’t understand. If you haven’t checked whether the build system is actually reading the source file you’re modifying, that also falls in this category. When you’re on shaky ground, it’s possible to waste a lot of time debugging at a layer that isn’t the problem.
The social aspect is also important if, for example, you are contemplating getting into a technical dispute with somebody who has the power to fire you, or if you are going to sign a public petition which puts you at odds with the people who have always funded the tech industry. If you take the time to make sure you understand what the ground beneath you is, and that the actions you’re planning to take are supported by it, you are on firm footing. If you’re working to change the world, there may come a time when you have to step off of these social systems and find somewhere else to stand.
The failure modes of a piece of technology, or of a person or an organization, are the ways it behaves when things don’t work. When the battery in an old handheld device dies, the device’s screen and audio fade to the point of unrecognizability, and at some point it may lose the contents of RAM or stop executing instructions. The power-on LED may also fade out gradually, with no clear distinction between on and off. In a modern device, instead of this behavior, the power management IC turns it off, possibly flashing a “no battery” symbol on the screen first. This illustrates how careful engineering can change the failure modes and make sure their edges aren’t as sharp.
Speaking of which, a technology, or a social group, has sharp edges if newcomers can easily injure themselves with it by accident.
A technology or a societal pattern is safe if its failure modes are well-understood, it has no sharp edges, and the long-term ramifications of its use are, on balance, more positive than negative. The language of safety may be taken either as a relative assessment, or as a Boolean. In common use it is a Boolean, but this is an anti-pattern; being absolutely safe is typically an unobtainable goal, and it is also a harmful ideal to strive for because, if it were attainable, the pursuit of it would justify many other horrible things.
One percent of the traffic is millions of people every day. This is a personal saying that I came up with while working on improving the safety of Google’s advertising systems; it may not be literally true outside that context, but is still an important attitude. It functions as a reminder to stay self-critical and to not forget about corner cases, because something that seems too small for me to count may be life-changing to somebody else. (I intentionally learned this saying in a format which redacts the actual order of magnitude, which would be a business secret. “Millions” should be taken as rhetoric, not as a literal number.)
The two genders are the elements of any multiple-choice question with two items. “True, false”; “east, west”; “I would like to receive marketing, opt-out”. This is a joke common in trans communities, combining gallows humor about how hard it is to get people collecting demographics data to ask their questions in ways that are possible to answer truthfully, with an invitation to engage in postmodern deconstruction of the concept of gender.
It struck me in writing this just how many of my personal sayings treat technology and society as … well, similar. I’m sure I’ll be criticized for that someday, but I stand by it as a useful lens, as long as it isn’t the only lens.
From wikipedia:
Technology can be the knowledge of techniques, processes, and the like, or ....I’m increasingly convinced that ‘being able to form a society’ is a technology in this sense. We have developed sophisticated techniques and processes for decision-making at every level from the household to the globe, and we teach them to each new generation.
I do agree. An engineering approach to the humanities, and a humanities approach to engineering. That’s my message for the world in its most general form.
Failure mode is general jargon, I’d say: https://en.m.wikipedia.org/wiki/Failure_mode_and_effects_analysis
A lot of mine is fairly “standard” like “frob” or whatever, just old (like me, I suppose…)
A couple that seem to only apply within my friend/coworker groups and are really more “slang” than “jargon”:
Your definition of materialize is super useful. I’ve always used the word hydrate though. If something is dehydrated it’s usually a struct containing only an ID or cheap stuff to grab. You can then hydrate it by calling an API or DB, or maybe computing the rest.
Point is: dehydrated is minimal and cheap (in memory, CPU, time) and hydrated is complete but expensive.
[Comment removed by author]
I always used “reify” for that, as it stuck in my head after a friend used it and I had to look it up to figure out what it actually meant. I like the metaphor of hydrate/dehydrate, but the actual words don’t seem to compel me.
I use “materialize” for that. Or “realize”. It’s not useful if it’s still in the pattern buffer and not materialized, so beam me up Scotty!
I use hydrate as well. I want to say I first saw it in some java ORM in the 90s/2000s. I like the meaning about having some data, but it’s not as valuable without adding water. In hiking, it’s lighter to carry food dehydrated, and then adding water to prepare the food a little at a time to eat.
Dehydrate/hydrate makes a lot of sense; where I work, we use deflate/inflate, but that gets confusing when the data structures we’re dealing with are also subject to lossless compression. I might try to switch to hydration metaphors for that reason.
My version of “the mysterious future” is after the festival, from a time when I was living in a kind of neighborhood activist commune and all our time and energy went into planning and working for an annual festival so all of our own personal projects and desires would be satisfiable only “after the festival.” Now applies also e.g. in the weeks before Christmas when all one’s real plans are on hold until, well, after the festival.
I like this one and have used it for a long time, as well. Jargon for conversations reminds me that I appreciate when conversations are high context: the speakers know the topic and each other so well that they become incredibly dense: a couple words can stand in for what could otherwise be minutes of explanation. Basically never happens online.
ElseWhen - The past being things that can effect the present causally, future are things than can be effected by the present, elsewhen things happen that effect nor can be effected by the present.
Traditionally referring to speed of light, but useful to extend to the notion of slower propagating things.
You should read about vector clocks and happened before if you haven’t.
Also “Vector Clocks and Happened-Before” is a good band name.
Following the Gary Bernhardt trend, where Ruby is the nice OO language that’s really consistent and easy to use while Rubby is the horrible mess of Gems, Bundles and syntactic warts borrowed from Perl, I tend to use “Open Sores” as the nasty underbelly of open source - corporate-sponsored projects with CLAs and “enterprise editions” are an example of open sores software.
Boring: A praise for things that could go very badly and haven’t. As a teenager I joked that I want to be boring to doctors, lawyers, and police because, if I’m not, something is terribly wrong in my life. I’ve been using the term this way ever since. In August I got a performance review at work that was boring: I knew everything that would come up in it and believed it was fair. On Lobsters, almost all of our deploys and database migrations have been boring, and all but a dozen users are boring at any given time.
I end up talking to auditors a lot, $work’s product is highly regulated so there’s a lot of time spent talking about processes and regulations and so on. One of the lines that comes up is something to the effect of, “We try very hard to be boring and reliable, so sorry for this being a pretty uninteresting part of your audit today.” Usually gets a laugh or two, but it’s very true, in my world, it’s best to aspire to be as boring as possible.
I sometimes use “A Great Roe” to describe a problem where there are two different but indistinguishable objects (like symbols). It’s from an old Woody Allen routine about mythical beasts, where he says “The Great Roe is a beast with the head of a lion and the body of a lion, but not the same lion.” I’m pretty sure I got this from a quote in an old LISP book.
I always love old Lisp metaphors, they’re full of weird things. One example is “vietnamization”, where the code gets indented further and further and then curves back around, like the border of Vietnam. Interestingly enough, Vietnamization is also a term that refers to the policy of the USA to withdraw from the Vietnam war.
Since I’m from a place where English isn’t the main language to communicate in (Austria), many of our jargon isn’t English either: my favourite is (eini-)pfriemeln, a dialect word originally meaning to forcefully push an object through a slightly undersized hole. In our context it means to insert additional rows or columns into a database or system, sometimes even to bodge together a software fix, in a not-100%-satisfactory way.
Anyone else have other non-English jargon?
In a German punny reference to “chips” I like to call RAM units “Knusperriegel”, albeit it’s probably not healthy to eat them.
I believe Germans (at least some of them), call “dip switches” by the delightful name of “maus klaviers”. (Mouse Pianos)
I use “frickeln” for “coding in a quick and dirty way”.
My day job is pretty neologism-averse & we stick to fairly conventional stuff (entries found in ESR’s jargon file, plus regular technical terminology), though we do overuse vomit metaphors (to mean failure, logging, and output).
Xanadu, on the other hand, was extremely neologism-friendly. We’d invent or reinvent an idea and then it would accumulate five or ten different names, depending on what we thought was most important about it at the time (and this is part of why Xanadu documentation is so hard to read for the uninitiated – there’s no dictionary that explains which words actually mean the same thing but come from different eras). Most of these terms were pretty technical and specific to some data structure or operation that’s rare outside our project, though.
A couple examples from xanadu proper (i.e., translit):
Any append-only file is a permascroll. (Append-only files are important because they let you add information without invalidating existing pointers.) We work with edit decision lists, which are lists of fat pointers in insertion order (for assembling documents) – this term comes from filmmaking, where before the era of non-linear editors you’d have to write timestamps for where to cut & how to arrange the bits of film you have. The fat pointers in an edit decision list are spanpointers (previously called threespans), and they point to spans or chunks, which when rendered in the UI are called noodles. When rendering in the context of a longer document, noodle is in a shape called a tetroid (because, like a tetris block, it’s a rectangle with between zero and two bites taken out of it – the leading part of the first line and the trailing part of the last line). We also have an overlay decision list, which contains links (either transpointers, which connect two or more spans, or formatting links, which merely associate a span with a string that indicates how to interpret it at render time – indicating for instance the font, color, or actual data type if it’s not text). The elements in the overlay decision list are links or overlays, and they consist of a type plus one or more endsets, each consisting of one or more spanpointers. A transpointer is visually indicated by a translucent colored bar called, variously, a beam or a bridge, and the kind of visual display that includes beams between and within documents is called transpointing windows or parallel presentation. Text is laid out onto rectangular blocks called pages or slabs, and a collection fo slabs with their associated tetroids and beams is called a flight. To animate a transition is called sworfing (a portmanteau of switch and morph, or maybe shift and morph).
A couple examples from zigzag:
The currently selected cell is accursed, because it bears the cursor. A collection of cells is called a slice. Indirect connection between slices is called intercalation and is performed by something called a preflet. A set of cells connected along the same dimension is called a rank, and if the first cell is connected to the last cell along that dimension then it’s a ringrank. The first cell in a rank is the rankhead and the last is the ranktail, and you can perform head optimization by storing a pointer to the head of the rank in each cell in the rank (which is useful if the structure is frequently traversed but infrequently modified). The tendency to treat a central cell as representing some object and various ranks of cells hanging off of it as attributes is called object eversion.
There are a whole host of others, and one of these days I ought to write an actual dictionary (though I might need to enlist help from former XOC folks, because the jargon used in Gold / XU92 is mostly beyond me).
Oh a chance to share brainworms!
Brainworms was a term from a friend of mine to describe memes and jargon shared between friends. Particularly good brainworms get spread and mutate over time.
The money funnel (smooth be its functioning \ / ) is the core function of a business: users come in one side and emerge as money. Our jobs as engineers are varied but all tie into some aspect of the money funnel–we neglect this at our own peril. Often used to inform which parts of the tech stack should be handled carefully.
Sometimes something doesn’t work out because reasons. This is usually used to denote a complex, frustrating, and usually inviolate operating condition often caused by political constraints. I think I picked this one up from Grandpa Zawinksi.
When you need to totally scrap something and burn it down, you zorch it. This I picked up from an old robotics professor of mine.
When faced with an unpleasant yet necessary task, you may have to do the needful. Sometimes this is used in the form of asking permission for an implied dark act. I picked this one up from a friend who worked at HostGator.
When you hand a colleague over a neat thing/feature/song/whatever, it is good to signal that they should please to be enjoying it. Forget where I picked that one up, though I once had a boss who used a variant of this formation (speaking in progressive infinitives) he’d picked up from Laumer’s Retief stories.
As technologists, many of us are helping increment the depersonalization and oppression of humans, thereby helping bring about the grim meathook future. This one I definitely picked up from Grandapa Zawinski.
When somebody is in meetings for too long, they made need to stretch legs, ingest nutrients, or expel waste. This is usually referred to as a biobreak. I forgot where I first got this one, I think it was LAN parties.
When somebody is about to undertake an action that is potentially hard or could fail, we often tell them good luck have fun don’t die. This is used from deadly serious situations to friendly dismissal of biobreak notifications. Picked this up from a friend.
A wonderful law of an old coworker of mine was Krog’s Law: every time your critical path crosses a political boundary, double the time it takes.
When you deploy to production, you’re really just using staging 0. This was a term I invented at a company where we had numbered staging servers, but still sometimes it was just simpler to do acceptance testing in production.
Business is full of ever-changing requirements and tends to suck in unwary engineers. Thus, it is important to have a shield from the howling vortex of crazy of business.
for those who might not know, “do the needful” is a popular indian english phrase that has been gaining currency in the software world at large. “please to be” is likewise a very common indian construction, usually with the amused awareness that it is not “proper” english.
“bio break” might be indian too; i was working in bangalore when i first heard it but we might have gotten it from the americans.
Ah, thank you! It’s always fun finding how other people have used/improved/innovated on my mother tongue and backporting those innovations. :)
another popular indianism is using “on”, “off”, “up” and “down” as verbs, with an implicit “turn” in front of them, e.g. “on the lights” or “down the volume”
turdlets: unrequested, unwanted output files generated by poorly-written programs that litter their users’ filesystems (may also include editor backup files, e.g.
*~,.*.swp). “Stupid Acrobat Reader’s leaving turdlets in my$HOMEagain.”splat: an inverse of snarf. “Snarf that blob from the file and splat it into memory at 0xf00dface.”
I always called turdlets, “raisins” due to a very funny (but unfortunate) story that involves my sister, a pet rabbit, a some culinary mistakes that occurred.
It cracks me up every time and that makes it so I don’t get mad at the programs leaving raisins all over.
https://wiki.mozilla.org/Glossary :)
Oh man I really like “Chop wood” as a term
I tended to coin and spread my own jargon more when I was in college or startups; now that I’m woking for a big company I usually just go along with what’s current. A few I remember from my past:
Regarding alternate pronunciations:
For many years, I pronounced SQL as “sqall” and UI as “yooey”. Both save some time when speaking, and both give a nice sense for the feel of working on these things.
Do you think there is anyone that pronounces SQL as squeal? That would be hilarious if it came unexpected.
I haven’t seen anyone who does, though I’ve heard sequel.
That’s the only way we pronounce it in my circles. It took me awhile to adjust to My ESS QUEUE ELL (and I still think of it as My Sequel in my head).
I’ve always pronounced it “squirrel”. It started as a joke in protest of “sequel”, but it’s starting to stick at work.
[Raises hand]
Every single buzzword that management and PM uses at work. Holy crap there are a lot of them. I’ve never had to synergize so many KPI’s across team barriers.
BORP an object from the future with AI that understands everything and removes the need for programming. Every program can be reduced to two calls- BORP.get() to get all data needed and understand everything and BORP.do() to do everything. This was created to represent some combination of 1) an idyllic future state where programming is easy; 2) a cynical reference every time some product promised a “no code” environment like “I saw the demo of that new analytics tool, it guess they finally implemented BORP to actually work”: 3) a joke call and response with managers who would create schedules assuming that BORP worked
blargh any string, activity, or noun where the content was not important for the conversation. “I wrote this blargh that makes sure the input gets mapped to the output”
functional narrative “use case” and “user story” were deemed too jargony one day and couldn’t be referenced anywhere on the chance that it confused the client, so we came up with this term. Oddly it was deemed not jargon and started being used in various works. I was very happy when we had a visitor who asked what the fuck a functional narrative was, the manager spent a few minutes trying to explain it. A developer eventually leaned forward and said “it’s a use case” and the visitor said “why don’t you just say that.”
I use something like BORP a lot when explaining things that need to be built to other engineers, except I usually call it “PBM” or “AM” – for “purpose-built magic” and “accidental magic” resp.
or
to mean “Show me the weird parts of this service.”
Mostly it’s used for things that are complicated, perhaps even necessarily complicated, but usually just a result of organic growth over many years. AM came first, but I use PBM more these days. AM also variantly means “Arcane Magic”, “Asinine magic” or any other fun variant I come up with on the day.
Probably the main one I use a lot is “Order Imports”, it comes from a phrase I use when training people for dealing with some of the safety-critical parts of the application my team supports, “In chaotic situations, order is an import commodity.” The idea is to remind people that you can’t “Grow your own order” when things get chaotic, you have to rely on borrowing it from other people, or have a stockpile of it handy. Your goal in most situations isn’t to solve the problem yourself, but be the person who can quickly and expertly expend your reserve of order to acquire more, and then spend the sum of it to solve the problem you can’t afford to solve alone. In my work, a number of our systems have a “TTK” (another entry for my personal jargon file), a TTK is the length of time before unavailability of a service results in significant harm to a user of the service. Working in a safety-critical environment is about managing a very certain kind of stress very efficiently, so having a good model for what is actual required of you in those high-stress situations is important.
Do you have a link anywhere that documents that idea of importing order? I’d like to hear some more about it, and/or have it fleshed out/clarified a bit mroe.
No, it’s just something I came up with when on a midnight call w/ a junior guy. He was pretty frustrated that I wasn’t as stressed out as him, and I was trying to explain what I was doing and how I was handling it.
The problem he was having was that he was so focused on trying to solve each new problem himself, “I have to jump on to this machine and then execute on that machine and review these logs to find blah blah” that he didn’t step back and think to delegate or try to see the bigger picture. Oftentimes when things go wrong, they go wrong in a constellation of errors that is recognizable without actually having to review any given error. He was so focused on the chaos that he spent all his reserved order trying to solve each problem and was left without any resources to move solve the root problem.
Part of that is inexperience, but part of it was having a bad model of what it is we were hired to do. Most often the right answer to a problem is to ask someone else to solve it. Often the imported commodity is of better quality than the domestic. The point of the phrase (it actually comes with a second part, “In calm situations, order is an export commodity.” – a thing that mostly has value when you can give it to someone else), was to emphasize the need to recognize that the problem was bigger than he was and he needed to focus on marshaling resources effectively.
The idea kind of comes from a concept in psychology about interpersonal relationships, as well. The idea is that we all have a kind of ‘square’ which delineates what we are responsible for, and what others are responsible for. In this square, we grow our own resources. Our own crop of happiness and resilience. Occasionally you may find someone who needs to borrow from your square because something has happened to theirs, e.g., when a friend leans on you for support after a traumatic experience. The metaphor extends in lots of ways – if we think about chaotic situations as a kind of traumatic experience, the real damage done is rarely to the system, but to the people in it. To that end, the goal as the point person on that chaotic situation (in our case, we’re part of an on-call team for a safety-critical product) isn’t to put out the fire, but rather to organize the bucket-brigade.
As an example, a recent issue (not rising to the level of an outage) involved a kind of pathological use case which knocked over a webserver every couple of minutes by rapidly (MB/s) wrote to a couple logfiles. Our alerting system lit up like a tree, and I get a call as the primary on-call guy. Couple people are working (based in another TZ, it’s early morning for me, late morning for them). They have order in good supply, I have very little in reserve, so while they’re not expert on the particular systems with failures, they are smart folks so I pull them on a call and start talking through what’s happening – borrowing their awake brains to do the task of debugging while I just drive around. In that situation I am coming to their square and taking their resources, but the problem gets resolved quickly and the total amount of resources we had to spend were far more minimal due to the fact that I didn’t wait for me to scrounge up enough order to solve the problem.
It’s not a novel concept, it’s just a way of looking and justifying something that can feel bad. It’s not uncommon to not want to take from someone what you could, in theory, provide for yourself; but the point of having teams is to have a system of mutual dependence precisely for chaotic situations where it is more expensive to not rely on others. Looking at it in an economic metaphor helps, in my experience, clarify why it’s okay to think in these terms and not be afraid to import order when you need it.
That’s actually a pretty good metaphor, and a good way of expressing it, IMO. (and novel ways of expressing known ideas are also valuable). Definitely going to feature it in my best-of feed.
alwaysneveralways be used. A great source of contention in the team.We have a “build –for-checkin” that does a precheckin sanity test of the most common product / platforms / tool chains to go wrong.
Naturally, it’s universally pronounced as “build –for-chicken”, which naturally I have wired to playing the wonderful Chicken Yodel!
Turn the volume up to LOUD.
https://www.youtube.com/watch?v=Ppm5_AGtbTo
I love this question.
I have some ideas where a few of those you listed came from.
The oracle test actually comes from oracle machines!
Slurp is also defined in the glossary of the camel book (Programming Perl)
see also perldoc perlvar:
An argument is excessively binary if it relies inappropriately on a model where there are two possible choices or states. “Either you’re with us or against us.”
Note that binary classification is a hazard of language, since you either decide a word applies or it doesn’t. It’s also a hazard of logic where statements are modeled as being either true or false. By the principle of charity, you should look deeper and see if the argument actually depends on there being two choices, or it’s just a manner of speaking.
[Comment removed by moderator pushcx: Removing dupe comment.]
This is a really interesting question, but as I’ve predominantly worked in German-speaking offices (with a few years’ exception)… I’m coming up blank right now. Most of what I read here makes sort of sense, but I guess even if our terminology is super-penetrated by anglicisms (and rightfully so, many German translations are downright unwieldy and you might know them from university, but most wouldn’t) but this sort of talk doesn’t come so naturally if you don’t have a roster of native speakers, at least that’s my impression on thinking about this for a few minutes.
For me, the only bit of personal jargon that comes to mind, and I don’t use it in speech, is “XEH”, as a debugging log string of choice, since it usually stand out.