There's an important additional aspect to bikeshedding: the conversation gets sidetracked onto the distraction-level details very much because the main conversations are hard and everyone involved can understand and opine on the simpler topic.
And that might not be true of the more important activity. It's a procrastination-like thing: let's convince ourselves we're being productive planning this trivial thing while the other big, scary, difficult thing lurks behind us ominously...
The canonical case in software teams is arguing about code style guidelines.
Almost never do the structural elements of good code organization get discussed. Instead we wrap around the axle arguing about things like bracket placement and whitespace. Usually in a manner which damages team cohesiveness rather than building it.
But, but, but: bracket placement and whitespace matter! It's a real drag to have to edit a piece of code in which the conventions for brackets and space are all over the place.
It doesn't matter what conventions you adopt. But not adopting any creates unnecessary friction.
Yes, they do matter, but not as much as using accurate words for things. I know people who use the same noun or adjective for four incompatible concepts in their code. Buy a goddamned thesaurus, or use a free one online. It’s okay to reach out for help on things you struggle with instead of making the rest of of us suffer.
You can reduce the white space conversation to picking a good code formatted. But no formatted is going to fix your nightmare code that you claim is “self documenting”. Fuck that guy. Or better, fire him. Get that weak sauce outta here.
Yeah, kind of the same thing as when you check your email and complete a bunch of other trivial tasks because you're struggling with what you actually need to get done.
This is neither the time nor the place to talk about my work ethic.
Cleaning my desk or going through my inbox instead of doing whatever needs to be done is just my brain cargo-culting "working at a computer in an office", not unlike a toddler imitating grown-ups. At this point it's very useful to train yourself to talk to somebody about what you need to do, or write a list of the steps you need to take and keep breaking it into smaller parts, until you find it's easier to do what you were about to write than to write it.
It's a classic trick, I call it "starting with a corner", from when you were a child and you had to color the entire background with blue -- it was so off-putting, even if you knew /how/ to do it, it was so much work. But if you start with a corner, at least you got somewhere.
I used it in conversation with my spouse the other day and was legitimately surprised to realize that it wasn't in common usage. Or that I apparently had failed to use the term in their hearing in the past 20 years of us knowing each other.
1. Exactly you already said: "write a list of the steps you need to take and keep breaking it into smaller parts" :)
2. Play competing heel-dragging tasks against each other, when possible.
I find that doing this ensures that sustained effort is almost guaranteed to be more productive (and it doesn't take long) than trying to do a controlled, focused burst to get something out of the way.
This is related to another CNP thing: committees. It's a long time since I read it, but he says something like: "A committee consists of a number of people with special expertise in various matters; and a chairman, who is expert in none. In a cabinet, the chairman is known as the Prime Minister".
It's related, because that shortage of expertise is what leads the committee to spend more time on the bikeshed's paintjob than on the safety of the reactor. Everyone's an expert on bikesheds.
The definition of yak shaving seems totally wrong to me. I always understood it to following way (as an example):
1. You need component X to carry out the original task
2. To get component X, you need to do something else
3. Several steps of recursion later, you end up shaving a yak - an activity that's unrelated whatsoever to the original task, but is still a dependency.
Although, to the grandparent's point, that's very much a "getting distracted while performing the task" video -- the first several steps didn't show Hal having to divert, after all. He could have replaced the lightbulb and then gone back to fix the shelf, and fixed the shelf and then gone back to oil the drawer.
It's only oiling the drawer that demonstrates true yak-shaving, since he then has to buy more oil and fix the car.
Sometimes I suspect that my current yak-shaving chain might have one step somewhere that isn't strictly necessary... but then I quickly dismiss that idea and start to write a report about why every step is needed, but then I notice how our wiki is disorganized should be split up into the four primary kinds of documentation as described by https://documentation.divio.com/, but then I noticed that our wiki service is running on an old server that hasn't been updated in 2 years and maybe it's time to switch to a saas provider, but wait does the provider I was looking at support the wiki syntax our current wiki uses? ...
My read of the article was quite different. Namely, "Imagine you had to shave a yak. There would be a lot of things involved in getting that done, many of which you don't know ahead of time."
Ultimately the same underlying meaning, but quite a different illustrative scenario.
Yes I've heard this too, but I've also heard both.
While writing this I found a lot of opposing definitions (as mentioned with bus factor). I've also heard "Don't shave the yak!" as part of the definition you gave for yak shaving.
Thanks for the feedback! I'll incorporate this too to make it more complete.
There are a couple that I use pretty regularly even outside of tech that result in weird looks from people because I didn't realize it's not part of the common vernacular:
1. orthogonal - "Well, this issue is orthogonal to that issue"
2. impedance mismatch - "I think we have a bit of an impedance mismatch here. We want this but all we have is that."
It's interesting how I've heard "impedance mismatch" used much more often than "orthogonal" - even though the latter has much wider applicability in various disciplines. Impedance mismatch is a very specific term in high frequency circuits. Orthogonality is relevant anywhere you use vector spaces (including linear algebra, real analysis, PDEs, etc).
I remember years ago, probably in physics circles, hearing modulo [this or that other consideration] . Disregarding.
Edit: Live quote. Most recent Scott Locklin:
A friend of mine tested positive for ‘rona antibodies; he felt a bit run down and wondered if he had been exposed. He had been (modulo false positives).
Orthogonal often seems to be used in place of "unrelated" but deployed by the person to make what they're saying sound cleverer than it really is since they've used maths terminology!
I use orthogonal specifically to say that two or more things can be changed independently without affecting the others. I don't think unrelated carries that connotation with how people actually use it. I've never actually met someone who uses unrelated to mean "the absence of relations" literally. Maybe it should but I won't get too broken up about it as a language descriptivist.
This may well be true, but it can also be an accurate and succinct word for "related to the bigger picture but a separate conversation".
E.g. performance and security of the system both relate to that system but each dimension can be worked on or discussed without necessarily impacting the other.
Our team uses it quite organically and humbly (and not excessively) but yes it absolutely is a candidate for use in an affected manner rather than a genuine one.
I just tried searching HN for occurrences of "is orthogonal", and it does seem that most uses would be better served with "unrelated". In some cases, however, orthogonal sounds more appropriate, and the reason are the geometric associations that it evokes. For example in the sentence "Having chip/pin is orthogonal to the card being a credit or debit card", orthogonal evokes the image of a contingency table where all the cells are non-zero. The word "unrelated" doesn't have the same effect despite being synonymous.
Not really. It's a culture thing. In certain tech fields, (in academia), the concept of orthogonality is important. Hang out with those crowds and they'll use "orthogonal" in their day to day usage all the time. To them it's not a fancier version of "unrelated". It's at the same level.
I've tried to use "orthogonal" in a vernacular context a few times, on each occasion causing wrinkled brows. It's not tech jargon, it's a perfectly good word. OK, maybe it's really maths jargon?
This reminds me of some advice I received from a previous manager. He said that decisions are impossible to make in any meeting larger than 5 people, so I vowed to really pay attention to my invite list and pair it down where possible. His response was, "That's great, but more importantly, if you want to make sure no decision is reached, be sure to invite more than 5 people."
I think many people have independently discovered and use this technique. My wife once had a boss who would always find points to argue in any proposal she authored. She began adding at least one spelling or grammatical error to every document. He red-penned those, and his inner critic was satisfied. The points that really mattered went unopposed.
You are spot-on! Back when I was an anesthesiology research fellow (U.C.L.A. Department of Anesthesiology, 1979) I was first author on a number of papers resulting from my experimental work. As was expected and routine, I passed my manuscripts on to my research director for editing. Invariably he'd make changes each time I submitted a freshly typed revised draft. One day I noticed he'd changed some things back from the way he'd revised them to my original wording. From then on, I submitted papers for publication when I felt they were ready. And they were accepted for publication.
I know an electrician who will reverse polarity on a couple of outlets when they do a large job. It gives the inspectors something to mark down and is an easy fix.
The other side of this is 'brown M&M' issues. Sometimes small mistakes will cause a reviewer to go over things much more thoroughly than they otherwise would.
Definitely a thing that gets independently discovered over and over. I'd heard this described the "hairy arm technique[1]", with similar setup as the Queen's Duck anecdote, but a hairy arm instead of a duck. I remember reading about it and thinking "oh, so that's the name for that".
Can’t find a source, but it was relayed to me as a technique in negotiating a contract for videography. You would put together a contract that includes normal shots and one extraneous, really expensive aerial/helicopter shot. If the client doesn’t notice - cool, you get to do a fun helicopter shot. If they do notice, it can give them something to negotiate away - making them feel accomplished, while you still land a contract with the important shots.
That seems very, very similar, but slightly different in my mind (and is also a great one to add to my vocabulary)
In the Queen's Duck, the extra work gets done in a way that's easy to undo, so management can add their value by telling you to remove it. The artist gets more control of the queen animation instead of tweaking the color, shape, etc. because management wants something to do.
In Helicopter, the additional work is just a proof of concept, to ease negotiations. It's not about having control and making work easier down the line, it's about picking a moonshot, and maybe having fun with it, but at least getting the contract under the terms you want because they're probably going to cut the helicopter, which leaves you with the contract you would have agreed to in the first place.
Which reminds me of another favourite, “Free As In Helicopter”: the software is free, but figuring out how to use it is so insanely complex, and has so many dependencies, that a successful completed deployment costs you thousands in $$$/£££/€€€.
Well you could argue that if a PM focuses on the duck - or something that is fine if there wasn't a duck - said PM needs to reconsider what they do as well. Educate the PM, instead of the developer adding fluff to distract the PM.
And "no" is a complete sentence. I know, chain of command and authority and the like is hard to rebel against, costs energy and brain space, but I think in the example given, the artist should be the authority on what is in an animation, not the PM. They are entitled to an opinion of course and to voice it, but they would be one voice among many.
The one piece of jargon in tech that I loathe is not listed here: "Ask". Not as a verb, but as a noun.
"We have a few asks for your team". - ie: we need something from you.
From what I have heard, this came out of Microsoft at some point. As engineers and managers drifted between companies, it became pretty common across Lake Washington over at Amazon. I can only hope appropriate quarantine procedures are followed to keep it contained in the Seattle region, but I suspect there are cases spreading globally at this point.
I don't even know what it is that I hate about it. It's perfectly reasonable as a word, and usually I'm a linguistic descriptivist. But ugh, that word.
The usage as a noun is quite well established outside tech. For example, in finance, market prices are called Asks and Bids. In the game of cricket, the target score for the team batting second is also called Ask.
That's a really fair point- it's usage in other industries and contexts may be where the term came from.
Specifically, I'm talking about the "ask" noun meaning "request for work". "My team has 10 outstanding asks from the billing team, but we don't report to their VP so we can deprioritize 8 of them".
I would hope that in that context, you don't presume that I mean one of the two definitions you've posted :)
Can't stand 'actionable'. Grew up with it meaning "grounds for a legal action or lawsuit" (I guess I knew to many lawyers) and its still jarring to end meetings with actionable next steps.
Oh thanks for this comment. A little over a year ago I started working for a Seattle based company (remotely), and this is done constantly. I had never heard it before and couldn't figure out if it was a really common thing that I missed somehow or what.
The company does have a lot of ex-amazons as well.
It's funny to see how these new phrases/keywords are born. I've been in the software industry for ~15 years now (longer than some, shorter than others), I always get amused when I see new phrases gaining traction and spreading. It's like a verbal pandemic, from a certain point of view.
Not gonna lie, seeing “ex-amazons” instead of “ex-amazonians” definitely gave me a light chuckle and a mental image of incredibly tall giant women who somehow decided to quit being amazons and ended up becoming of a rather average height.
If you want to live a long and happy life, embrace neologism. Language is fluid, and when you decide to stop learning, you become an irrelevant fossil. Corpspeak is easy to hate, but is it actually the neologism that you hate, or the suits that use them?
Then I'm afraid to say, it reached the UK several years ago. (Perhaps decades.) https://en.wiktionary.org/wiki/ask#Noun definition #2. (Definition #1 is the directly problematic one.)
Sadly this sort of thing caught on in the UK too where the tidal wave of US corporate speak was impossible to hold back. It's rife in the tech sector and beyond.
I find all of this sort of thing; "blue sky thinking", "touch base", "leverage", "reach out" "deliverables" and so on, to be substitutes for clarity and real meaning. Just speak clearly and like a normal person please! Quite apart from murdering the language you often find that, whilst this sort of speech sounds clever on the surface, it's often hiding vagueness and half-baked thoughts. It gives the illusion of substance.
"Lets touch base offline on those key deliverables when we have enough bandwidth and ensure our thinking is joined up". Makes me think of David Brent from The Office!
The first place I ever encountered it was at Microsoft. You'd start the interview day with the recruiter, have a series of interviews and conclude back at the recruiter at the end of the "loop."
Well, it's a euphemism. It's being used a sugar-coated variety instead of the perfectly good words "request", "requirement", "demand" etc (whichever is appropriate).
The one I dislike is "issue" as in "we have some issues". No, you mean "we have some problems". But "issue" just sounds nicer than "problem", I guess. That one is thoroughly lost.
Issue is a euphemism for problem? Those two words are completely equivalent to me, relaying identical information, neither sounding nicer than the other.
> What's the difference between an ask and a request?
An "ask" is part of a business negotiation, a "request" is usually interpersonal. An "ask" invites a conversation about what it will take to make it happen (money, etc.) while a "request" invites acceptance or rejection.
"Architecting" ... you see, us software people don't design things. We're not working with construction, where architects design buildings. We're software people, we architect software. There's no design, just architecting. If you need to design an architecture, you architect, and while you're doing that, you're architecting, since you're an architect.
I am frankly surprised that there are not more noun/verb overloading examples in our field. Once you've verb'ed architect while also using it as a noun, every similar process seems like small potatoes. Or maybe it's just "architecture" that's odd. For example, "implementor(s)", "implement", "implementation". No problems there. Somehow, the thing that architects do ("design" or "design architecture") got lost, and we verb'ed it.
It's annoying that "bikeshedding" isn't properly attributed to C. Northcote Parkinson. And it's not really tech jargon, it's management jargon (same as "ask") - a type of jargon I find much more irritating.
I had forgotten that "Parkinson's Law" was a collection of essays; and I didn't know that the one about bikesheds was called The Law of Triviality. But I knew that the term originated with CNP; I didn't follow the link.
> no matter how trivial a thing is, it will be a showstopper for someone
I used to work for a big web site that produced standardized requirements documents ahead of every project. Part of the standard was the "flexibility matrix": the PM or "stakeholder" who was producing the requirements document was supposed to identify whether scope or timeline was most flexible. Of course, for about five years running after the standard document template came out, every project was "least flexible" on timeline and "most flexible" on scope.
We finally started calling them on their impossible timelines and tried flexing the scope by pushing some of the vague requirements off to later releases. The result? They added another column to the "flexibility matrix" called "resources", as in they were willing to hire more people to meet all the requirements in the mandated timeline.
I often see "we" on internal documents written by one person -- I think it comes from the convention in academic papers where you'd use "we" to refer to the researcher(s), even if it's just one author. I don't personally mind it in this context.
I was taught in science at school that it was incorrect to use the first-person-singular in lab write-ups. "A sample was heated over a bunsen, and it was found on cooling to have turned white".
> "We" instead of "I". on StackOverflow "how do we reverse a string?"
I usually notice this with english as a second language speakers, it's probably a more innocent mistake than people choosing a word like "workflow" or "bandwidth".
I started working with a new team recently and they use the term bikeshedding not as a negative but as a word for spending time discussing and coming to consensus on minutiae. "Let's spend some time bikeshedding what to name this class."
Not an idiom, but the latest dehumanizing thing ive started noticing is referring to people by their slack tags, even in direct messages. Now when my manager has an "ask" for me, instead of a DM with "Hi Name", i get "Hi @jdklsajdls". You don't need to tag me, we're already in a DM. Then, when someone is DMing me and referring to someone else, they use the slack tag instead of their name. Its gotten to the point where people were referring to someone by name on a zoom call and I genuinely didnt remember who that person was. Finally im like ohhhh thats @jkldsajlds
I can try and explain this one - I do this a lot when writing down meeting notes / sending emails. The problem is that when a company has 3 Steves, 5 Freds, and you need to refer to someone, you need an unambiguous way to do so. So I try to write down people's email handles when taking notes or saying "you should talk to @sdlkfj" about this issue.
On calls I will try to use their first name, unless there are multiple people with the same first name there as well. Then I just refer to people by the NATO phonetic alphabet of their last name. I do ask for their permission before I do so though, I'm not trying to be a jerk :)
This is quite weird since slack generally encourages people to use their real names for exactly this reason. In slack, tagging someone has a few added benefits, even in a private convo.
In a DM, if I tell you @fred can help you if you have any questions, you can now hover to see Fred's availability status, and click to message them.
An added benefit is that these tags track the user's displayed name. If Fred changes their name to Francine, the places where you've tagged Francine in the past will update automatically. You can also search for places where users are mentioned this same way.
This one seems to go way back. I had an cousin who started a CS program back when it was a big deal if your dorms had ethernet. I remember when visiting him it was wierd to listen to people actually refering to each other by their university-assigned email address.
Sure I get it, but these are people i worked with in person until last year. It just feels like with the remote working thing we are transforming from people into interchangeable virtual entities.
Only somewhat related, are there any interesting reads about how idioms tend to come into being? This post includes the origin stories and some of them seem to start out as an inside joke of sorts. I guess I’m just curious whether anyone has spent any time looking into what it is that makes a joke or phrase “go viral” to the point that it becomes a widely used idiom. Or maybe the backstories are more apocryphal and part of the “story” to sell the idiom in the first place? Either way, I’d be interested to read more about the factors that allow a new idiom make its way into language.
This would be the domain of linguistics, and my understanding is that there's really no clear consensus on anything. Folk etymologies are rarely any better than a "just-so" story, and often they're an entirely fabricated re-analysis.
When we talk about the creation of neologisms like this, we often put them into various categories: sometimes they're simpler than the previous idiom, sometimes they're more complex/nuanced, often they can act as some sort of shibboleth, but it's all after-the-fact analysis, I don't think there's any real rules.
I beleive you’re referring to the etymology of the terms and when they entered industry parlance.
I think that may be tricky to determine as word tend to spread like viruses. One person hears something and wither knows or looks up the word in context, then starts using the word.
Google fu may tell you when a phrase started being searched for frequently.
Not these idioms in particular, but you might be interested in the book "Metaphors We Live By", which looks into the origins of a lot of common, everyday metaphors that you probably haven't ever consciously considered as even being metaphors before.
HN comments like this are the best! This is exactly the kind of obscure book I’d never know about or even think to look for but I absolutely cannot wait to read it. Thanks for the tip!
An earlier take on tech jargon was published in 1997 by Wired magazine in the form of a physical book entitled “jargon watch”. It was touted as “a pocket dictionary for the jitterati”. Published in San Francisco under the HardWired imprint, printed in Singapore. Collection of submitted terms to a Jargon Watch column to Wired magazine in the early 1990s.
Examples include adminisphere, appeasement engineer, articulizer, balloon help (now mansplaining), bit flip (a personal favorite)…worth a gander. Honor your nerd heritage and revive some of the words the ancients used before the dot-com bubble.
It can be a hard habit to break that association. I work with different ecommerce clients and many folks refer to their stores payment systems as POS - point of sale, took a while to unlearn what I had always known POS to mean.
PoS is a good one also. In retail and restaurants it means 'point of sale', but also the systems and software behind the sale, which often translate a lot of business logic and and CRM-type stuff.
Of course if you're developing one and you mention the PoS POC you could end up in hot water.
I had the misfortune earlier in my career of working for a total megalomaniac chair-flipper. One time he described some fairly vague product concept and I said, "ok, let me put together a proof of concept". He blew his stack and said, "no, I don't want a proof of concept I want a working product!"
The author is a little more gracious than I would have been:
Bikeshedding -- in a past large enterprise that I worked, bikeshedding was most frequently employed in staff meetings that involved multiple levels of management. Middle-management and administrative staff would inject (often extremely project-disruptive) ideas into non-trivial things[0], but things "they understood enough to talk about" in an attempt to appear that they had a deeper understanding of the project. Thankfully, upper management was solid and saw through it, consistently.
[0] Small bullet point to move a task co-ordination database from its MSSQL version to a supported version ends up in an explanation of why our "Data Warehousing Solution" can't solve this problem for us ... it's hard to reason with someone when you're coming from a place of knowledge, and they're in that same place, just in some other universe where things don't mean what they mean here ... I remember "Data Lake" and making a quip about drowning, insulting the guy accidentally but not suffering any fallout.
This is a big peeve for me. I think journalists are responsible for the misuse of "exponential". They use it to mean "grows very fast", while making them look erudite.
It annoys me, because science journalists are reporting on the spread of a pandemic, which absent controlling factors actually does grow exponentially. So having degraded the term, they now lack a word to describe a quantity whose rate of growth is proportional to its magnitude.
"Default" might be one of the most overlooked technical terminology to the point that people don't even realize its technical sense (no-choice choice) is not "default" in English.
One company I worked at started using "tranche" obsessively after an exec used it thrice while talking through a pie chart slide. My team all thought it was ridiculous how malleable people tend to be and used "in the tranches" or "tranche and wave". Felt bizarre never hearing the word once before that event and made me question why people are vulnerable to something as such.
Some others mentioned amazonians and I can confirm this type of thing was incredibly common there (not just tranche, though I did hear that one more than once)
Reading through the comments here, I seem to be the outlier on the usage of these idioms. In fact, of the five in this article, I've only ever heard one in actual usage (Rubber Duck Debugging), though, I could say that "Bus factor" has been used, just not that specific term (more "if you were hit by a bus" as a term). The other three, however, I've never heard in my 20+ years in the tech industry (though I do remember the actual Ren & Stimpy episode...).
Honestly every industry and even every company in every industry has unique lingo and idioms. It's a large part of your first year at a new company: mapping and digesting the differences in language.
Most companies I've worked for had elaborate glossaries for their lingo. Usually dozens to hundreds of pages long.
I'm thankful for this article. I've never explicitly searched the term bike-shedding and yak-shaving prior. I just had a rough idea of what it was. I also enjoyed the backstory explanations.
or, if you’re like most people, you’ve probably just smiled and nodded while thinking to yourself “What the hell does that mean?”
If you do that, you failed the test. People who use inside jargony things love to explain them, and love to be asked what they mean. Also, they can usually tell when you don't pick up on it.
When I interview someone I'll throw in something company specific, that I know they won't understand, just to see if they'll ask me what I meant. I don't want to work with someone that is afraid to admit they don't know something.
I can relate to that and it's really important to ask questions. Also it can be quite irritating when people try to look smart instead of being actually interested in the point.
On the other hand jargon is not an exact science. There are things like false friends, commonly incorrectly used terms and all that. That's why spoken language is usually spoken redundantly. Also sometimes the acoustic is bad and you don't want to ask 10 times a minute. Or the person says something incorrectly but you realize what the person actually means because of the surrounding context.
I like that. Also, on the job, I try to be willing to ask for explanations even if I think I have a good guess. One thing you ending up finding is that other people often don't know either, but everyone was just going to be quiet about it.
That being said, I find a lot of junior devs scared to ask and I've run into some senior devs who are a bit high and mighty and judge you if you don't know. It's why I started writing these articles (junior devs I mentor will ask me what things mean after hearing them in meetings/seeing them in PRs)
But...ideally one should just ask, like with anything else!
I guess i've hit my limit of free Meduim articles and i have to pay to see this now. I'm a little concerned, I wonder how many people don't realize all their content is now behind a paywall.
TL;DR: Assuming you have the bandwidth, please double-click on these concepts, leverage the learnings therein, and then take it offline to iteratively ideate further.
I usually try to avoid using idioms in a group setting, or with people I don't know very well. I also usually cringe when people use them. That said, I do find them useful in private conversations. For example, in candid conversations with my manager I might say "Hey Boss, I think we've got a lot of bike shedding going on; folks on the team are eager to help, but they're attacking problems that they know how to solve first, not the problems that represent the biggest timeline risk." or I might say "Hey Boss, I know it looks like we're all off in the weeds on this project, but there's a lot of necessary Yak Shaving going on - I'd be happy to dig into some specifics/details if you like." ~ In private conversations with people you know/trust, some of these idioms are convenient shorthand.
I agree. I've been in this game 35 years, and it has been true most all that time. The examples in TFA are really all rather recent -- and frankly quite stupid (IMHO). Yak shaving is a thin reference to Ren and Stimpy, but requires complete explanation for it to make any sense; and, when it does, it's just dumb. If an analogy or metaphor requires much explanation, then it really isn't very good. It should 'click'.
But, I go along with it, too. At least the new cliches replace the tired old Star Trek/Wars allusions. Let the new generation have their day.
And that might not be true of the more important activity. It's a procrastination-like thing: let's convince ourselves we're being productive planning this trivial thing while the other big, scary, difficult thing lurks behind us ominously...