Deep dives into software, hardware, and the ideas reshaping how we build things.
Deep dives into software, hardware, and the ideas that change how we build things.
We write about the technical side of technology. Not just product launches and press releases, but the architecture decisions, the tradeoffs, and the engineering culture that shapes what actually gets built. Our…
Topics we cover: Software · Hardware · Developer Tools · AI & Machine Learning · Open Source · Security
Conclusion first: The Not Friendly Do Not Touch shirt borrows the visual grammar of a hazard placard to make a personal claim, and the mismatch is the whole point. A warning sign exists to protect you from a thing; this shirt exists to protect a person from you. The design is legible, the joke is dry, and the boundary is doing more work than the punchline.
The artwork, as observed on the live US listing, is blunt: the words NOT FRIENDLY and DO NOT TOUCH set in warning-sign lettering, a yellow caution triangle, and a crossed-out hand symbol. No mascot, no winking subtext, no decorative flourish. It reads like something you would find stenciled on a locked cabinet in a utility corridor, except it is printed on a t-shirt and the cabinet is a person.
Industrial warning signs work because they compress a decision into a glance. The triangle says attention. The crossed-out hand says do not perform this action. The lettering says this is not a suggestion. When you put that grammar on a body, you are not describing a hazard; you are declaring a perimeter. The shirt is not warning you that the wearer is dangerous in the way a wet-floor sign warns of a slippery surface. It is warning you that the wearer has already decided how much contact they want, and the answer is less than you were about to offer.
That distinction matters because it is the difference between a slogan and a usable promise. A slogan is a mood. A promise is a statement you can act on. Not friendly alone would be a mood. Do not touch alone would be a command without context. Together, with the triangle and the hand, they form something closer to a contract: here is the boundary, here is the symbol that makes it legible, and here is the consequence of ignoring it. The shirt is not asking you to guess.
The retail title includes the word introvert, and that is where the design gets more interesting than it first appears. Introversion is not misanthropy, and the shirt does not actually claim the wearer hates you. It claims the wearer is not friendly in the default, open-plan, small-talk sense of the word. That is a narrower and more honest statement than a generic grumpy slogan. It says: my baseline is not warmth toward strangers, and I would like the physical boundary to match the social one.
I read the crossed-out hand as the load-bearing element. Without it, the shirt is a moody text graphic. With it, the design becomes a diagram of consent applied to casual contact, which is a strange and useful thing to put on cotton. The caution triangle is the frame that tells you how to read the rest: this is not decoration, this is instruction.
Most novelty shirts over-explain. They add a second line, a parenthetical, a little arrow, a character reacting to the main text. This one does not. The restraint is the design decision I keep coming back to. Four words, two symbols, one color accent. It survives being read at a distance, which is the only distance at which a warning sign is useful. If you have to lean in to get the joke, the boundary has already failed.
That is also why it reads as a work-culture object rather than a pure gag gift. Open-plan offices, conferences, and team offsites are full of people who would benefit from a legible perimeter and who have no intention of explaining themselves to every passing extrovert. The shirt does the explaining. It is terse, it is a little rude, and it is honest about what it is. I would rather see this on a colleague than watch them perform enthusiasm they do not feel.
I want to be careful here, because it would be easy to overread the design. The shirt does not demonstrate anything about software, security, or engineering practice. It is not a case study. It is a piece of printed language that happens to use the same visual system as a hazard placard, and the interest is in how that system behaves when you point it at a social situation instead of a physical one. A warning sign protects you from a thing. This shirt protects a person from a thing. The grammar transfers; the stakes do not.
What transfers usefully is the discipline of the message. A good warning sign does not hedge. It does not say please consider not touching. It says do not touch, and it gives you a symbol so you do not have to parse a sentence while your hand is already moving. The shirt borrows that discipline. Whether you find it funny or merely accurate probably depends on how many times this week someone touched your shoulder during a standup.
If you want the object itself, the listing is here: Not Friendly Do Not Touch Funny Warning Sign Introvert.
Editorial note: This publication and Quirky Cotton Collective share an owner.
Before you put a boundary into words, run it through three questions. First, can it be read at a glance by someone who is not already thinking about you? Second, does it name the action rather than the mood? Third, does it survive being repeated without becoming a lecture? The Not Friendly Do Not Touch shirt passes all three, which is why it works as a design and not just as a joke. The same test applies to a deprecation notice, a rate-limit header, or a DO NOT EDIT comment at the top of a generated file. If the boundary needs a paragraph, it is not a boundary yet. It is a hope.
The shirt says meh. in large, bold, lowercase white letters on a dark ground. The word is a shrug. The typography is not. That mismatch is the whole object, and it is worth reading closely because it exposes a distinction technical teams blur constantly: the difference between a message and a contract.
I keep coming back to this because I have spent years watching APIs promise things in prose that their behavior never delivers. A slogan is a sentence someone typed. A contract is a set of obligations someone can test. The meh. shirt is, visually, a slogan wearing contract clothing — and that is what makes it funny rather than merely rude.
The native garment preview shows large bold white lowercase meh. lettering on a dark shirt. No animal illustration is present. That is the full visual inventory, and it matters that the inventory is short. There is no mascot, no secondary line, no decorative frame. The period after the word is the only punctuation, and it lands like a full stop in a log line: terminal, unappealed.
Lowercase is doing quiet work here. Uppercase MEH. would read as a declaration, maybe a brand. Lowercase meh. reads as a transcript of a feeling — the sound a person makes when a meeting could have been an email. But the letterforms are heavy and wide, sized to be legible across a room. So the visual channel is shouting while the verbal channel is shrugging. That contradiction is the design.
I read the period as the most important glyph on the shirt. Without it, meh is an interjection, still in progress. With it, the word becomes a verdict. The period converts a mood into a statement, and a statement is the first step toward something another person can hold you to.
In API work, the gap between what a response says and what it means is where incidents live. A 200 with a body that says "status": "ok" is a slogan. A 200 with a documented schema, a stable error taxonomy, and a deprecation policy is closer to a contract. The meh. shirt sits on the slogan side of that line while looking, typographically, like it belongs on the contract side. It is a visual demonstration of the failure mode.
That is not a claim that the shirt is about software. It is not. The observation is narrower: the shirt’s design teaches a distinction that transfers cleanly to design review. Loud presentation does not create obligation. A bold word is not a guarantee. You can print meh. at 200-point weight and it still means meh. — which is to say, it still means nothing you can build against.
The listing title bundles several retail phrases — funny, sarcastic, introvert, dry humor — around the word. I would not treat those phrases as printed on the garment. The visual observation is the word and the period on a dark shirt; the rest is retail prose describing an audience, not ink on cotton. This distinction matters for the same reason it matters in documentation: the marketing copy and the artifact are different documents, and only one of them is authoritative about what was shipped.
Still, the framing is legible. Meh. is a boundary word. It declines enthusiasm without declining the interaction. It is the verbal equivalent of a 204 No Content: the request was received, nothing further will be said. For readers who spend their days calibrating how much affect to spend on any given thread, that is a recognizable register.
Here is what I take from the shirt into my next design review. I call it the period test: when a document, a status message, or a UI string ends in a confident full stop, ask what obligation that period creates. If the answer is none, the period is decoration. If the answer is a promise someone can test, the period is a contract. The meh. shirt passes the test in the most literal way: the period is there, the obligation is not, and the gap between them is the joke.
Run it on your own artifacts. Your health-check endpoint that returns {"ok": true} with no dependency checks — that is a meh. with a period. Your deprecation notice that says this will be removed soon without a date — same. Your README that says production-ready without a single named failure mode — same. The typography can be as bold as you like. The period does not make it a promise.
The shirt is available at the Quirky Cotton Collective listing if you want the object itself. I am not going to pretend it will improve your incident reviews. It will not. It is a shirt that says meh. in a font that says otherwise, and that is enough.
Editorial note: This publication and Quirky Cotton Collective share an owner.
The shirt prints the word meh. in very small, centered lowercase type on a dark ground, and that scale is the entire argument. A slogan wants to be read across a room; this wants to be read only by someone already close enough to be disappointed.
I keep a folder of interface copy that fails the same way. A banner screams ERROR at 48px when the actual condition is a retryable timeout. A status page declares DEGRADED PERFORMANCE in red for a p99 that moved four milliseconds. The typography promises catastrophe; the system is merely unimpressed. The meh. shirt inverts that failure. It takes a small, flat, low-stakes word and refuses to inflate it. The restraint is the message, and the message is that there is no message.
The native garment preview shows very small, centered lowercase meh. lettering on a dark shirt. No animal illustration is present. That is the whole design, and it is worth being precise about what that means before we start assigning it personality.
Three typographic decisions carry the weight:
I want to be careful here. I am reading the design, not reporting a fact about it. I have not worn this shirt, and the listing does not tell me what the wearer intends. What I can say is that the visual choices are consistent with understatement, and that understatement is a legitimate design position rather than an absence of one.
Most novelty shirts are slogans. A slogan is a sentence that asks you to agree with it before you have thought about it. It is optimized for the glance: big type, high contrast, a punchline that lands in under a second. Slogans are fine. They are also the reason so many API error messages read like slogans — confident, loud, and useless when you are actually on call at 3 a.m.
A usable promise is different. It is specific about what it will and will not do. It survives contact with the person who has to act on it. The best error messages I have written are boring: Retry after 30 seconds. Your request was not processed. No exclamation point. No apology. No metaphor. The reader knows exactly where they stand.
The meh. shirt sits closer to the usable-promise end of the spectrum than the slogan end, even though it is not promising anything at all. It is a bounded statement. It does not claim enthusiasm, and it does not claim despair. It occupies the narrow band between fine and not fine, which is where most production systems actually live. The shirt is not a joke about caring too little. It is a joke about the enormous amount of energy required to care precisely the right amount, and the relief of admitting you have stopped trying to calibrate.
If this were a large MEH across the chest, it would be a different object. Large type is a performance of indifference, which is a contradiction — you cannot loudly not care. Small type is the real thing. It is the visual equivalent of a one-word reply in a thread that has gone on too long. The person who sends it is not angry. They are done.
There is a useful heuristic buried in that distinction, and it applies well beyond apparel. Call it the scale test: when you are tempted to make a message bigger, ask whether the size is doing work the words cannot. If the answer is no, the size is compensating. A 48px error banner over a retryable timeout is a large MEH. A small, centered, correctly punctuated line in the right place is the shirt.
This is not a claim that small type is always better. Some things genuinely deserve to be loud. A security breach deserves a banner. A data-loss warning deserves red. The scale test is not always be quiet; it is match the volume to the stakes. The meh. shirt passes because the stakes are low and the volume is low. Most of the interface copy I audit fails because the stakes are low and the volume is high.
The listing title calls this a funny sarcastic introvert minimalist saying, and the related queries people use include meh introvert shirt and meh sarcastic shirt. I understand the association. A small, quiet, noncommittal word reads as introvert-coded, and there is nothing wrong with that reading. But I want to separate the marketing language from the artwork.
The retail title is a description of a mood, not a specification of the design. The design itself is a word, a period, and a scale. It does not depict a person, an animal, or a social situation. It does not tell you who should wear it. The introvert framing is a reasonable guess about who will find it funny, but it is not printed on the shirt, and I would not treat it as evidence of anything beyond how the listing is categorized.
What the artwork does support is a narrower claim: it is a low-volume statement for someone who has run out of patience with high-volume statements. That is a temperament, not a demographic. Plenty of extroverts are tired. Plenty of introverts are loud. The shirt does not check.
The shirt is sold as a standard t-shirt under the Quirky Cotton Collective brand. If you want the exact listing, it is here: Meh Funny Sarcastic Introvert Minimalist Saying. I am linking it because it is the object under discussion, not because I am recommending a purchase. The design is the point; the garment is the substrate.
What I can say about the object is limited to what the preview shows: a dark shirt with small centered lowercase lettering. I have not tested the fabric, the fit, or the print durability, and I am not going to pretend otherwise. If you are the kind of reader who wants a wear test, this is not that column. If you are the kind of reader who wants to think about why a two-word design works, keep going.
It is not a pride variant. The observation is explicit: no animal illustration is present, and the design is the minimal lowercase wordmark. That matters because the same phrase circulates in several visual forms, and the differences are not cosmetic. A design with an animal or a flag is making a different kind of statement — it is identifying with a group, or making a joke about one. This design is not doing that. It is a solitary word on a dark field, and its solitude is part of the composition.
It is also not a software artifact. I have seen people try to read shirts like this as commentary on engineering culture — the burned-out SRE, the on-call engineer who has seen too many pages. That reading is available, and I am not going to forbid it, but I want to be honest that the shirt does not demonstrate anything about software. It is a word. The engineering reading is an analogy, and analogies are useful only when they are labeled as such.
The analogy I find most useful is not about burnout. It is about response calibration. Every system that talks to humans has to decide how much affect to put into its messages. Too much, and you get the 48px banner. Too little, and you get a silent failure. The meh. shirt is a calibration point: the minimum viable acknowledgment that something happened and it was not worth a paragraph.
I close these columns with something reusable, and this one is short enough to actually use. Before you ship a user-facing message — an error, a status, a notification, a shirt — run it through four questions:
The meh. shirt passes all four. It is small because the stakes are small. It has a period because the thought is closed. It is readable at the distance it will be read. And it is not promising anything, which is the most honest thing a shirt can do.
Editorial note: This publication and Quirky Cotton Collective share an owner. This is not an independent review.
Conclusion first: The shirt’s slogan is not one promise but two, and the second one is a trap. Let’s root for each other is mutual support; and watch each other grow quietly converts that support into a growth target. The artwork knows this — four root vegetables, smiling, with their roots fully exposed in soil. You cannot see a root vegetable’s roots and also claim the growth is invisible. The design is honest about the mechanism and sentimental about the outcome, and that gap is the whole argument.
Here is the artifact, as observed on the live US listing on 14 October 2026: the words LET’S ROOT FOR EACH OTHER AND WATCH EACH OTHER GROW wrap around four smiling root vegetables — a carrot, a radish, a beet, and an onion — each with its roots visible in soil. The lettering surrounds the illustration rather than sitting above or below it, which matters: the sentence is a frame, not a caption. The vegetables are inside the promise. So is the soil.
I want to read this closely because it is a better piece of work-culture design than most internal slogans I have sat through, and also because it contains the exact failure mode those slogans contain. The pun does double duty. Root is the verb of support and the noun of the thing underground. Grow is the outcome and the thing the roots are for. The design puts the roots on display — that is the visual joke — and in doing so it makes a claim that most team charters avoid: the support and the growth are the same system, and you can see it working.
That is the good part. The uncomfortable part is the conjunction. And watch each other grow is not a neutral addition. It sets an expectation of visible progress, and it makes that progress a shared spectator sport. Support is something you give; watching is something you do to someone. The shirt collapses the two into a single cheerful sentence, and the vegetables smile through it because they are cartoons.
I have written before about shirts that function as contracts with missing clauses. This one is the opposite: it has too many clauses, and one of them is an implied service-level agreement. Root for each other has no metric. Watch each other grow implies one. If you wear this to a team offsite, you are not just signaling warmth; you are endorsing a model in which mutual support is instrumentally justified by observable growth. That is a fine model for a garden. It is a load-bearing assumption for a team, and it is worth saying out loud that the shirt does not distinguish between the two.
The illustration is where the design gets interesting. Root vegetables are the correct choice for this pun precisely because their edible portion is underground. The carrot, radish, beet, and onion are all crops where the visible top is not the harvest. You pull them to see what happened. The shirt shows the roots — it cheats the reveal — but the soil line is still there, and the roots are drawn as if cross-sectioned. That is a diagram convention, not a photograph. The design is telling you that growth is legible if you cut away the ground, which is exactly the assumption a good engineering manager should be suspicious of.
I do not think the shirt is wrong. I think it is a slogan, and slogans are compressed arguments. The compression here is elegant: four characters, one sentence, one pun, one frame. The failure mode is not in the design; it is in what people do with it. A shirt that says root for each other is a gift. A shirt that says root for each other and watch each other grow is a gift with a performance review attached. The difference is one conjunction and a verb of observation.
If you are going to wear it — or give it to someone who gardens, or to a teammate who would get the joke — the useful move is to notice which half you are actually promising. The Let’s Root For Each Other And Watch Each Other Grow Garden shirt is a real object with a real design, and the design is smarter than the sentiment. The roots are visible. The growth is not. That is the honest reading, and it is also the one that makes the shirt worth wearing to a place where people will ask about it.
The reusable heuristic is this: when a slogan contains an and, audit the second clause. The first clause is usually the value; the second clause is usually the metric. Root for each other is the value. Watch each other grow is the metric. If you cannot state how the metric is measured, you have not agreed to the slogan — you have agreed to the vibe. The shirt is a good reminder of the difference, and a better one because it is funny about it.
Editorial note: This publication and Quirky Cotton Collective share an owner.
Editorial note: This publication and Quirky Cotton Collective share an owner.
The shirt prints a notification banner, not a security alert. That distinction is the whole joke, and it is also the reason the design works as a piece of interface criticism rather than a generic cat meme.
Look at the artwork as rendered: a white rounded banner with a small bell icon, the sentence There is motion at your front door set in plain sentence case, and below it a circular, green-tinted view of an orange tabby pressed absurdly close to a doorbell camera lens, porch siding and lights visible behind it. The banner is the notification. The circle is the evidence. The cat is the event.
What makes this more than a cute picture is the wording. It does not say someone is at your door. It does not say package delivered or visitor detected. It says there is motion. That is the lowest-level, most technically honest thing a doorbell camera can report, and it is also the least useful thing a human wants to read at 2:14 in the morning. The shirt is funny because it captures the exact moment when a sensor’s vocabulary and a person’s expectations diverge.
I have spent a lot of my working life on that divergence. APIs promise one thing and deliver another; documentation describes a contract and production traffic finds the seam. The doorbell notification is a small, domestic version of the same gap. The device is not lying. Motion was detected. The user, however, wanted to know whether to put on pants. The banner answers the question it can answer, not the question being asked.
The visual composition reinforces this. The banner sits above the camera view like a status line above a log excerpt. The green tint reads as night vision, which is itself a kind of interface convention: we tint the image green so you know the camera is working in low light, even though the actual sensor data is not green. The cat’s face, wide-eyed and close, is the payload. The porch behind it is the context. The banner is the schema. Everything is in the right place, and the message is still useless in the way that matters.
That is the argument I want to make about this shirt: it is a diagram of a notification that is technically correct and practically empty. The humor comes from recognizing that pattern in a low-stakes setting. Anyone who has ever written an alerting rule, a health check, or a status page knows the feeling. You can report motion all day. The hard part is reporting meaning.
The design also does something subtle with scale. The banner is large and white and rounded, the kind of notification card that has become the default visual language of consumer software. The camera view is circular, cropped, and slightly distorted, the way a wide-angle lens makes a close subject look. The cat is not framed as a portrait. It is framed as a detection. The shirt puts the interface first and the subject second, which is exactly backwards from how a person experiences a doorbell camera, and exactly right for how the system experiences it.
If you want the object itself, it is listed as There Is Motion At Your Front Door Funny Cat Doorbell Meme from Quirky Cotton Collective. I am not going to pretend the shirt solves anything or improves your home security. It is a printed joke about a specific kind of interface failure, and it works because the failure is recognizable.
What I keep coming back to is the sentence itself. There is motion at your front door. It is a complete, grammatical, accurate statement. It is also a sentence that has been stripped of every piece of information a human would use to decide what to do next. Who or what is moving? How long has it been moving? Is this the first notification or the fourteenth? The banner does not say, because the banner is not designed to say. It is designed to fire.
That is the reusable heuristic I would take from this shirt, and it applies well beyond doorbells: a notification is not an alert until it tells the reader what changed and what to do about it. Motion is a signal. A visitor is an event. A package is an outcome. The shirt prints the signal and lets the cat supply the rest. In production, the cat is usually a customer, and they are usually not laughing.
The design is not trying to teach that lesson. It is trying to be funny, and it is funny. But the reason it lands is that the joke is structural. The banner is doing exactly what it was built to do, and the result is still absurd. That is a familiar feeling for anyone who has ever shipped a feature that worked as specified and failed as experienced.
The shirt does not resolve that tension. It just puts it on a shirt, which is a reasonable thing to do with a tension you cannot fix.
The shirt prints four periodic-table tiles — 53 I, 74 W, 22 Ti, 16 S — and asks you to read them as a sentence. The joke works because the sentence is not actually spelled out; the tiles are a compressed notation, and the compression is the point. That is also the problem. A slogan that depends on the reader completing the mapping is a promise with an implicit clause, and implicit clauses are where production incidents live.
Here is the artwork as observed on the live US listing on 14 October 2026: the words I WEAR THIS SHIRT PERIODICALLY sit above four element-style tiles. The tiles read 53 I, 74 W, 22 Ti, 16 S. The symbols are I, W, Ti, S. They are not a literal spelling of the sentence. The pun is that periodically is doing double duty: it means “from time to time” in ordinary English and “according to the periodic table” in the visual grammar. The shirt does not explain which reading is primary. It trusts you to hold both.
That is a specific kind of design decision, and it is the one I want to examine. The shirt is not a chemistry lesson. It is a sentence that has been compiled into a denser format and shipped without a decoder ring. The reader has to know that 53 is iodine, 74 is tungsten, 22 is titanium, and 16 is sulfur, and then has to notice that the symbols concatenate to IWTiS, which is not a word but is close enough to I wear this that the brain fills in the gap. The gap is the joke. The gap is also the risk.
I have spent enough time in API review meetings to recognize this pattern. A contract that requires the consumer to infer a missing step is not wrong, exactly. It is underspecified. The consumer who knows the domain will succeed. The consumer who does not will produce a plausible but incorrect reading and then act on it. In the shirt’s case, the incorrect reading is harmless: you might think the tiles spell something else, or you might not get the joke. In an API, the incorrect reading is a retry storm, a duplicate charge, or a pagination loop that never terminates.
The element tiles are a notation, and notation always carries an implicit contract. The tile format implies “this is an element symbol, and the number is its atomic number.” That implication is strong enough that most readers will follow it. But the shirt does not print the element names. It prints only the numbers and symbols. The reader who does not recognize Ti as titanium has no fallback. The shirt offers no legend, no footnote, no hover state. It is a printed surface, and printed surfaces do not negotiate.
This is where the shirt becomes useful as a design artifact rather than just a garment. The question it raises is not “is this funny?” but “what does the reader need to know for the joke to land, and is that knowledge assumed or supplied?” The shirt assumes. That is a legitimate choice for a novelty tee, where the audience is self-selecting and the cost of a missed joke is zero. It is a less legitimate choice for a public API, where the audience is not self-selecting and the cost of a missed contract is measured in pages.
The retail title calls it a “Funny Chemistry Science Pun.” That is accurate as a description of intent. The visual observation is more precise: four tiles, four atomic numbers, four symbols, one sentence that is not literally spelled. The difference between the marketing description and the visual observation is the difference between a promise and a specification. The marketing description tells you what the shirt is trying to do. The visual observation tells you what it actually does. Both are true, but only one is testable.
I keep coming back to the word periodically. In ordinary usage, it is a frequency claim: I wear this shirt from time to time. In the visual grammar, it is a method claim: I wear this shirt according to the periodic table. The shirt does not resolve the ambiguity. It leans into it. That is the joke, and it is a good joke, because it rewards the reader who notices the double reading. But it is also a reminder that ambiguity is cheap to produce and expensive to consume. The shirt costs you a second glance. An ambiguous API contract costs you a support ticket, a rollback, and a postmortem that begins with “we assumed.”
The useful heuristic here is what I call the legend test. Before you ship a notation — a status code, a pagination cursor, a retry header, a printed tile — ask whether the consumer can recover the intended meaning without external knowledge that you have not supplied. If the answer is no, you have two choices: supply the legend, or accept that some consumers will misread it. The shirt chooses the second option, and for a shirt that is fine. For a contract that other systems depend on, the first option is usually cheaper than the incident review.
There is a second heuristic, and it is about the difference between a slogan and a usable promise. A slogan is a sentence that sounds good and does not commit to anything. A usable promise is a sentence that tells the consumer what will happen next. The shirt’s sentence is a slogan in the best sense: it is compact, it rewards attention, and it does not pretend to be a specification. The tiles are the artifact that proves the joke happened. They are also the artifact that shows where the joke could fail. That is what makes the shirt worth writing about. It is a small, well-made notation with a deliberate gap, and the gap is the whole point.
Editorial note: This publication and Quirky Cotton Collective share an owner. This is not an independent review.
The shirt is available at the Amazon listing. If you are going to wear it, wear it periodically. If you are going to design a contract, supply the legend.
Editorial note: This publication and Quirky Cotton Collective share an owner. This is not an independent review.
The shirt prints a dashed empty circle at the top of a curved ramp and a solid ball resting at the bottom. The joke is not that the ball failed. The joke is that the ball still has potential energy — just less of it than the dashed outline implies. That distinction matters more than the punchline, because most slogans about potential treat it as a fixed quantity you either spend or waste. This diagram treats it as a state variable.
Here is the artwork as observed on the retail garment image: white capital letters reading I HAD POTENTIAL above a white curved descending ramp. A dashed empty circle sits at the upper left ledge. A solid white ball rests on the lower right flat ledge. The ramp is curved, not a straight diagonal. The dashed circle is the position the ball would occupy if it had stayed at the top. The solid ball is where it is now. The shirt does not show the ball falling, rolling, or being pushed. It shows the after.
That is a more precise joke than the phrase alone suggests. In physics, potential energy is not a moral reserve. It is a function of position in a field. A ball at the top of a ramp has gravitational potential energy relative to the bottom; a ball at the bottom has less. Nothing is destroyed. The energy went somewhere — into motion, friction, sound, heat — or it was never released and the ball simply sits lower. The shirt’s composition leaves both readings open. The dashed circle is empty, so the ball is not at the top. The ball is solid and present, so it is not gone. The phrase says had, past tense, but the drawing says still here, lower.
I keep coming back to that gap between the text and the diagram. The text is a self-deprecating verdict. The diagram is a state description. If you read only the words, you get the familiar joke about wasted talent. If you read the drawing, you get something closer to an energy audit: the ball is at rest on the lower ledge, and the dashed circle marks a position it no longer occupies. The shirt is funnier — and more useful — when the drawing wins.
This is where the design earns its place in a technical reader’s wardrobe, if it earns one at all. Most slogan shirts ask you to agree with a sentence. This one asks you to read a small diagram and notice that the sentence and the diagram are not saying quite the same thing. That is the same skill you use in a design review when the architecture diagram and the README disagree. The diagram is usually the more honest artifact. Here, the diagram is the honest one: the ball is on the lower ledge, the upper ledge is empty, and the ramp is curved because a straight diagonal would have made the fall look inevitable. A curve implies acceleration, a path, a shape to the loss. A straight line would have been a slide. The curve is a choice.
The minimalist execution matters too. The artwork is white on the garment, no border, no caption, no equation. There is no mgh or ½mv² to turn the joke into a physics lesson. The only labels are the words I HAD POTENTIAL, set in plain capitals above the ramp. That restraint keeps the shirt from becoming a costume. It reads as a diagram first and a joke second, which is the right order for anyone who has sat through a postmortem where the timeline told a different story than the summary.
I am not going to claim the shirt demonstrates a software engineering principle. It does not. It is a printed garment with a visual pun about stored energy and a dashed outline of a former position. But the pun is structurally sound, and that is rarer than it sounds. The dashed circle is not decoration; it is the counterfactual. The solid ball is not a punchline; it is the current state. The phrase I had potential is the incident summary, and the drawing is the timeline. The timeline is more informative.
If you are the kind of reader who keeps a copy of a postmortem template in your notes app, the shirt’s argument will land. It is not saying potential is gone. It is saying potential is positional. The ball at the bottom of the ramp still has potential relative to the floor. The dashed circle at the top is a reminder that the ball used to be somewhere else. That is a healthier way to think about a missed deadline, a deprecated endpoint, or a team that shipped the wrong abstraction — not as a verdict, but as a change in coordinates.
The shirt is available as a standard t-shirt through the listing: I Had Potential Funny Physics Pun Sarcastic Minimalist Quote. The retail title calls it a physics pun and a sarcastic minimalist quote. The visual observation supports the minimalist part: white capitals, a curved ramp, a dashed empty circle, a solid ball. The sarcasm is in the tense. The physics is in the position.
What I would do differently as a reader of this design is resist the urge to read the shirt as a statement about the wearer. The diagram is about a ball. The ball is not a person. The dashed circle is not a former self. It is a coordinate. That is the reusable heuristic I would take from this artifact: when a slogan and a diagram disagree, trust the diagram, and check whether the slogan is using the past tense to describe a change in position rather than a loss of substance. The ball is still on the ramp. The potential is still there. It is just lower, and the shirt is honest about that.
A p99 latency figure is a property of the measurement procedure that produced it, not a property of the service. Two teams can quote different p99 values for the same server on the same afternoon and both be arithmetically correct, because the load generator’s admission policy decides which requests exist to be counted at all.
That is the whole argument. Everything below is the mechanism, the arithmetic, and the reporting rule that follows from it.
There is a public demonstration repository by Judofyr that makes this concrete. The Go server does one thing: for eight seconds it behaves normally, then it takes a lock and sleeps for two seconds, during which every request blocks. The system is completely unresponsive for two seconds out of every ten. Twenty percent of wall-clock time is a stall.
Benchmarked with wrk at 10 connections, the reported distribution was:
Latency Distribution
50% 90.00us
75% 120.00us
90% 350.82ms
99% 1.83sThen the same server, same duration, measured with wrk2 at a fixed rate of 70k requests per second:
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 1.48s
75.000% 1.85s
90.000% 2.31s
99.000% 2.92sRead the medians, not just the tails. The closed-loop run says half your requests complete in 90 microseconds. The fixed-rate run says half your requests take 1.48 seconds. Those are not two estimates of the same quantity with different error bars. They are measurements of two different things, and only one of them resembles what a user experiences.
In wrk‘s execution model, each connection begins sending a request only after receiving the response to the previous one, so a high-latency response causes the generator to stop sending — and therefore stop sampling — precisely during the high-latency period. Percentiles are then computed over the requests that were sent, and because the vast majority of those requests were sent during healthy periods, the distribution is skewed toward the healthy period.
Gil Tene, who coined the term and wrote wrk2, states the mechanism in the tool’s README directly: “Since each connection will only begin to send a request after receiving a response, high latency responses result in the load generator coordinating with the server to avoid measurement during high latency periods.” The Judofyr README puts the arithmetic consequence plainly: “The percentiles are around the requests, not time spans.”
This is why the error is dangerous rather than merely annoying. It is not random noise that averages out. It is a one-directional bias: the reported number is always better than the experienced one, and it is better by an amount proportional to how bad the bad periods were. A system that never stalls is measured correctly. A system that stalls catastrophically is measured most wrongly. The methodology fails hardest exactly when you most need it to work.
The intuition most engineers carry is that coordinated omission inflates the tail and leaves the median alone. The Judofyr numbers refute that. Under wrk the p50 was 90 microseconds; under wrk2 at a comparable throughput it was 1.48 seconds. When a stall occupies a fifth of the timeline and the generator refuses to send during it, the requests that would have been slow are simply never created, and the surviving population is dominated by the fast periods.
This matters for how you argue about it internally. If someone proposes that the median is trustworthy and only the p99 is suspect, they have the model backwards. The median is trustworthy only if the generator’s send schedule is independent of the server’s response times. In a closed loop, it is not.
The first remedy is to decide when each request should be sent before the run starts, and to measure latency from that intended send time rather than from the moment the request actually left the client. wrk2 does exactly this. From its README: “Rather than measure response latency from the time that the actual transmission of a request occurred, wrk2 measures response latency from the time the transmission should have occurred according to the constant throughput configured for the run.”
The consequence is that when the server stalls, the requests that could not be sent on schedule are still counted, and their latency includes the time spent waiting for the generator to catch up. The README is explicit that this technique generalizes: it “can be applied to variable throughput loaders” provided you have “a ‘model’ or ‘plan’ that can provide the intended start time” for each request. Constant throughput just makes that plan trivial.
The README also documents the magnitude. In one example run, a single 1.4-second disruption introduced by suspending the Apache process produced a corrected 99th percentile roughly 200 times larger than the uncorrected one. That is one stall, in one run, on a local test server.
The second remedy is to keep your existing closed-loop sample set and reconstruct the missing samples. HdrHistogram supports this: the wrk2 README notes that “HdrHistogram includes a simple way to compensate for Coordinated Omission when a known expected interval between measurements exists.” The method is to take any observed sample larger than the expected interval and emit additional samples by repeatedly subtracting the interval until the remainder is non-positive.
Here is a labeled illustration of the arithmetic, not a measurement of any system: suppose your generator was configured for one request every 80 ms, and one observed sample came back at 2.0 seconds. Correction expands that single sample into a descending series — 1.92 s, 1.84 s, 1.76 s, and so on down to the remainder — because during those 2.0 seconds the generator should have issued roughly 25 requests, and the users behind those requests were waiting too. The original sample stays; the reconstructed ones are added.
This is a fallback, not an equivalent. It requires a defensible expected interval, and it fabricates samples that were never observed. If your generator’s rate drifted during the run, or if the workload was transactional rather than request-independent, the expected interval is a fiction and the correction inherits that fiction. Say so in the report.
Artillery’s engineering blog frames the boundary condition well: coordinated omission “is a measurement issue that can happen when an open system is tested with a closed workload generator,” and the tell is structural — “Any time you have a fixed number of connections, ‘threads’ or ‘iterations’, you will run into CO.”
But the same post makes the honest counterpoint that a pure open-loop generator only fits a narrow class of systems: “The only way to send requests at constant RPS is if each request is completely independent of other requests.” Real user journeys are sequential — load a page, click a repository, open the Issues tab — and imposing a constant request rate on that sequence is meaningless because each step depends on the previous response.
The resolution Artillery proposes is a hybrid: new users arrive according to a distribution (open loop), and each user then experiences back-pressure from the service (closed loop per user). That model is safe from coordinated omission because while user A waits, users B through Z are still arriving and still recording their own outsized response times.
So the test-design rule is not “always use an open-loop tool.” It is: decide the arrival model before you choose the tool, and write the model into the report. If the workload is genuinely request-independent, generate at a fixed rate and measure from intended send time. If it is transactional, model per-user closed loops inside an open arrival process, and state that you did.
Two protocol-level behaviors make the gap between the test number and the production number wider than the generator alone explains.
Timeouts and retries. AWS’s Builders’ Library documents the failure mode precisely: “Setting the timeout too low has two risks: Increased traffic on the backend and increased latency because too many requests are retried. Increased small backend latency leading to a complete outage, because all requests start being retried.” A closed-loop test that never exercises the retry path will report a p99 that production cannot reproduce, because production’s tail includes retried requests that the test never issued. The same article quantifies the amplification risk in layered systems: a five-deep call stack with three retries per layer multiplies database load by 243x. If your load test models one layer and production has five, the tail you measured is not the tail you will get.
Metric cardinality. OpenTelemetry’s metrics SDK enforces a default cardinality limit of 2000 unique attribute combinations per metric stream, and when the limit is reached, measurements are folded into a single overflow data point marked otel.metric.overflow=true. The documentation is careful about the consequence: “Once the stream overflows, a measurement for {url.path=/checkout, success=false} is folded into the single overflow data point {otel.metric.overflow=true}, dropping success along with url.path. A query for success=false then misses that measurement.” This is not a latency-underreporting mechanism, and it should not be described as one. But it is a real way that a production dashboard can undercount the error population whose latency you are trying to correlate against your test results. If your p99 chart and your error-rate chart are built on the same overflowing metric stream, they may not be describing the same requests.
A latency percentile without its workload model and expected interval is not a reproducible number. It is a claim about a procedure that the reader cannot reconstruct. The fix is cheap and it belongs in the template, not in someone’s memory:
The last point is the one that changes behavior. If your release gate says p99 < 200 ms and the number feeding it came from a closed-loop generator, then the gate passes whenever the generator was willing to wait. It fails to describe the service at all during the intervals that matter.
I would stop treating the load-test report as a measurement and start treating it as a procedure with an output. The procedure has three decisions — arrival model, send schedule, correction policy — and all three need to be visible to anyone who reads the number. The cost of writing them down is a paragraph. The cost of not writing them down is a release gate that has been quietly measuring the wrong thing for as long as anyone can remember.
I would also stop accepting “the p99 is fine” as an answer to “what did the generator do during the worst interval?” If nobody on the call can answer the second question, the first one is not yet evidence.
Schedule before you sample. Decide when each request should have been sent before the run starts, measure latency from that intended time, and write the schedule, the rate, and the correction policy into the report next to the percentile. If you cannot state the intended send time for the worst interval in the run, you do not have a latency measurement — you have a record of how long your generator was willing to wait.
The shirt reads NOT FRIENDLY DO NOT TOUCH in warning-sign lettering, with a yellow caution triangle and a crossed-out hand. The conclusion is that this is not a joke about being rude; it is a joke about the difference between a boundary and a warning, and most people who wear it are quietly asking for the first while being handed the second.
I want to be precise about what the artwork actually shows, because the retail title calls it a “funny warning sign introvert” shirt and that framing does some work the design does not. The lettering is set in the visual grammar of industrial caution: block capitals, a triangle, a prohibition mark. The triangle is yellow. The hand is crossed out. The words are imperative. Nothing in the printed design says “introvert.” That word is in the listing, not on the garment. What is on the garment is a sign that looks like it belongs on a machine, not a person.
That mismatch is the whole argument. A warning sign exists to protect the person approaching the hazard. A boundary exists to protect the person setting it. They look similar on the surface — both are terse, both are imperative, both use prohibition marks — but they point in opposite directions. The warning says you could get hurt. The boundary says I am not available for this. The shirt borrows the first grammar to express the second need, and that borrowing is either the joke or the problem, depending on who is reading it.
Look at the components. The caution triangle is the most standardized element in the design. In the visual vocabulary most readers will recognize, a yellow triangle means attention, hazard, proceed with care. It does not mean stop. The crossed-out hand is the stop element. So the design contains two instructions that are not quite the same: be careful and do not. The words NOT FRIENDLY DO NOT TOUCH resolve the ambiguity in favor of the second, but the triangle keeps whispering the first.
That is a small thing, and I think it is the most interesting thing about the shirt. A pure prohibition sign — a red circle with a slash — would be unambiguous and therefore less funny. A pure caution sign would be ambiguous in a different way. The design stacks them, and the stack is what makes it read as a person rather than a placard. Real boundaries are like that. They are not clean. They contain a hazard assessment and a refusal at the same time, and the person wearing them is usually aware that the two are not the same message.
I am interpreting the design here, not making a claim about signage standards or the history of the caution triangle. What I can say from looking at the artwork is that the triangle and the crossed-out hand are doing different jobs, and the words are doing a third. The shirt is a small exercise in reading three instructions at once and noticing that they do not fully agree.
This is where the shirt connects to something I think about a lot in technical work, and I want to be careful not to overclaim the connection. The shirt does not demonstrate anything about APIs or documentation. It is a piece of printed cotton. But the design raises a question that shows up constantly in contract design: what is the difference between a message that sounds clear and a message that actually tells the reader what to do?
A slogan is optimized for the person saying it. A usable promise is optimized for the person receiving it. NOT FRIENDLY DO NOT TOUCH is a great slogan. It is funny, it is legible across a room, and it signals a personality. As a usable promise, it is weaker. It does not tell you what friendly means, whether the prohibition is permanent or contextual, or what happens if you touch anyway. It is a boundary expressed as a warning, which means the person approaching has to guess whether they are being protected or rejected.
Most bad API documentation has the same shape. It tells you the endpoint is “secure” or the service is “reliable” without telling you what failure looks like, what the caller is expected to do, or where the boundary actually sits. The words are confident. The promise is underspecified. The reader is left to infer the contract from the tone, which is exactly the wrong way to infer a contract.
The shirt gets away with it because it is a shirt. A warning sign on a person is allowed to be a little ambiguous; that ambiguity is part of the social negotiation. A warning sign on an API is not allowed to be ambiguous, because the consumer cannot see your face and cannot ask you what you meant. The design is a useful reminder that terse and clear are not the same thing, and that the visual grammar of a warning can carry a boundary without ever specifying its terms.
The listing calls this an introvert shirt, and the search demand around the phrase “not friendly do not touch shirt” suggests people are looking for exactly that kind of object. I understand the appeal. But I think the introvert framing is the least interesting reading of the artwork, because it turns a boundary into a personality type. The shirt does not say I am tired or I need space or I will be friendly later. It says not friendly, full stop, in the imperative voice of a hazard sign. That is a stronger and stranger claim than introversion.
What the design actually depicts is a person who has decided to borrow the authority of public signage to enforce a private preference. That is a funny thing to do, and it is also a slightly aggressive thing to do, and the shirt works because it holds both. The crossed-out hand is not a request. It is a rule. The humor comes from the mismatch between the formality of the sign and the intimacy of the body wearing it.
If you are looking for the shirt itself, the Not Friendly Do Not Touch warning sign tee is the object I am describing. I am not going to tell you it is comfortable or that it fits well, because I have not worn it and I do not know. What I can tell you is what the artwork says and what it does not say, which is the only thing the design itself can prove.
Here is the heuristic I would take from this shirt into a design review, a docs sprint, or an incident call. I call it the boundary-versus-warning check. When you write a message that tells someone what not to do, ask two questions. First: does this message protect the reader or protect me? Second: if the reader follows it literally, do they end up where I intended?
A warning sign passes the first question when it protects the person approaching the hazard. A boundary passes the second question when it tells the person what to do instead. The shirt fails the second question on purpose, because it is a joke, and the failure is the point. Most of the messages we ship in technical work fail the second question by accident, and that is not funny at all.
The checklist is short. Name the reader. Name what they are about to do. Name what you want them to do instead. If the message does not survive those three sentences, it is a slogan, not a promise. The shirt is a very good slogan. It is a warning that has been repurposed into a boundary, and it works because the person wearing it is standing right there to enforce the ambiguity. Your API is not standing right there. Write the second sentence.
Editorial note: This publication and Quirky Cotton Collective share an owner.
Editorial note: This publication and Quirky Cotton Collective share an owner.
The shirt reads meh. in large, bold, white lowercase letters on a dark ground. The word is a shrug; the typography is a shout. That mismatch is the whole design, and it is worth taking seriously because it is the same mismatch that makes so many API error messages useless.
Look at the artifact first. The native garment preview shows the word set in a heavy sans-serif, lowercase, with a period. The letters are white against a dark shirt. There is no illustration, no animal, no secondary line of copy. The period is doing real work: it turns a hesitation sound into a complete sentence. The lowercase is doing the opposite: it refuses the authority that a capital M would claim. The bold weight is doing a third thing: it insists on being read from across a room. Three typographic decisions, three different registers, all compressed into four characters and a dot.
That is not a slogan. A slogan makes a promise. This makes a refusal. The distinction matters because technical readers spend a lot of their working lives writing messages that are supposed to do one thing and end up doing another. A deprecation notice that says Sunset: 2026-06-01 is a slogan if nobody has migrated. A health check that returns 200 OK while the database is down is a slogan. The meh. shirt is honest about being a refusal, which is more than most status pages manage.
I keep coming back to the period. In prose, a period closes a thought. On a shirt, it closes the conversation before it starts. The wearer has pre-empted the follow-up question. That is a specific social move, and it is the same move a well-designed 409 Conflict makes when it includes the conflicting resource ID: it does not just say no, it says no, and here is the boundary you crossed. The shirt does not include the resource ID. It just says no. That is the joke, and it is also the limitation.
The visual loudness is the argument. If the word were set in small gray type, the shirt would be a private joke. At this scale, in this weight, it is a public statement about not wanting to be asked. The dark ground makes the white letters read as a label rather than a decoration. I would not call it aggressive, but I would call it legible from the other side of a room, which is more than I can say for most incident postmortems I have read this year.
There is a temptation to turn this into a lesson about introversion or dry humor, because the retail title mentions both. I am not going to do that. The title is retail prose; the artwork is the evidence. The artwork shows a word and a period. What it demonstrates is a typographic strategy: take a low-energy word and give it high-energy treatment. Whether that strategy works for you depends on whether you want to be approached. The shirt is available at the Amazon listing if you want to inspect the preview yourself.
The reusable heuristic here is what I would call the register audit. Before you ship any message, ask three questions: What register is the content in? What register is the typography or formatting in? Do they agree? A meh. in 72-point bold is a register mismatch that works because it is intentional. A Success in green bold on a page that failed to save is a register mismatch that does not work, because it is accidental. The shirt is a reminder that the mismatch is a design decision, not a neutral fact. You can choose it. You just have to know you are choosing it.
The second heuristic is smaller: the period test. If your message ends with a period, does it read as final or as hostile? The shirt’s period reads as final. A support macro that ends with Please try again later. reads as hostile, because the reader knows there will be a later and the macro knows there will be a later and neither of you is allowed to say so. The shirt gets away with it because it is not pretending to help. That is the difference between a refusal and a failure.
I do not know who buys this shirt. I know what it looks like, and I know what it is doing typographically. It is a loud whisper, a bold lowercase shrug, a sentence that ends before it begins. If you are the kind of person who writes incident summaries for a living, you might recognize the impulse. The shirt is not a solution to anything. It is a well-set refusal, and that is enough.
Here is what the graph looks like. Queue depth climbs in a straight line. Consumer concurrency is pinned flat at its ceiling. The age of the oldest message rises with the depth, and the two lines are so parallel that someone in the incident channel says “it’s linear, so it’s fine” — which is the sentence that should page a second person.
AWS documents exactly this shape for an SQS-to-Lambda pipeline: when a producer consistently generates messages faster than the function can process them, backpressure occurs, and SQS monitoring shows the age of the oldest message growing linearly along with the approximate number of messages visible (AWS Lambda Developer Guide, “Troubleshoot event source mapping issues”).
The queue is not the problem. The absence of a refusal point upstream is. An unbounded queue is not a buffer; it is a decision to defer refusal until refusal is most expensive — after the work has been accepted, serialized, paid for in storage, and promised to a caller who has already stopped waiting.
The AWS event-source-mapping page separates two conditions that produce the same rising-age curve, and the distinction matters more than most dashboards admit.
Backlog from a slow or erroring consumer. The page describes a function that throws errors: Lambda returns messages to the SQS queue and, notably, prevents the function from scaling to avoid errors at scale. The observable signature is that the age of the oldest message and the number of visible messages both increase while no messages are deleted, the function’s error count is non-zero and growing, and concurrency has actually reduced while throttling stopped. The fix is in the function, not the queue.
Backpressure from a producer that outpaces the consumer. Here the function is healthy. It is simply slower than the arrival rate, and the age of the oldest message grows linearly alongside the visible message count. The fix is a throughput or admission decision, not a bug hunt.
If your only signal is queue depth, these two are indistinguishable, and you will spend the first twenty minutes of an incident arguing about which one you have. That is a metric design failure, not an incident-response failure.
AWS’s builders’ library describes queue-based systems as having two modes: with no backlog, latency is low and the system is in fast mode; once arrival rate exceeds processing rate, it flips into a mode where end-to-end latency grows and it can take a great deal of time to work through the backlog to return to fast mode (“Avoiding insurmountable queue backlogs,” AWS Builders’ Library).
The same article gives the arithmetic that should end most autoscaling arguments: recovering from an hour-long outage requires double the system’s capacity for another hour after recovery, absent other factors. And the compensating factors are not guaranteed — the article notes that other systems your consumer touches may not be prepared for the surge as you drain, which can extend recovery further.
So when someone says “just scale out the consumers,” the honest translation is: we are betting that our downstream dependencies can absorb a step change in throughput for as long as the backlog takes to drain, and that the work in the queue will still be worth doing when it gets there. Both halves of that bet are testable before the incident. Neither is tested by a queue-depth alarm.
Google’s SRE book describes client-side adaptive throttling in concrete terms. Each client task tracks, over the last two minutes, the number of requests attempted by the application layer and the number accepted by the backend. When the ratio of requests to accepts crosses a multiplier K, the client begins rejecting new requests locally, with a probability derived from that ratio — and those requests fail without reaching the network (“Handling Overload,” Site Reliability Engineering, Google).
The source is explicit about the tradeoff in choosing K: a smaller multiplier makes throttling more aggressive and wastes fewer backend resources on rejected requests, but slows the propagation of state from backend to clients. Google states a general preference for a 2x multiplier, and that is their example, not a prescription for your system.
The same chapter is candid about the limit: client-side throttling may not work well for clients that only very sporadically send requests, because each client’s view of backend state is drastically reduced, and approaches to increase that visibility tend to be expensive. If your traffic comes from cron jobs and webhooks that fire once an hour, adaptive throttling at the client is mostly theater. Know which kind of client fleet you have before you build it.
Deadlines are backpressure that the protocol already carries, and most services throw it away.
gRPC’s deadline guide is blunt about the server side: a server may receive RPCs with an unrealistically short deadline that would not give it enough time to ever respond, which wastes resources and in the worst case can crash the server. A gRPC server automatically cancels a call once the client’s deadline has passed — but the guide adds the sentence that separates a working system from a busy one: the server application is responsible for stopping any activity it has spawned to service the RPC, and long-running processes should periodically check whether the RPC was cancelled (gRPC documentation, “Deadlines”).
That is the whole argument in one line. The framework cancels the call; your code has to notice. A consumer that keeps computing a result nobody will read is not doing work, it is holding a database connection hostage.
Propagation is the other half. The guide notes that propagating a deadline as-is is problematic because clocks on two servers may not be synchronized, so gRPC converts the deadline to a timeout with elapsed time already deducted. If your service calls three dependencies in sequence and passes each one the original deadline, you have built a system that will happily spend three times the caller’s patience.
Retries are the most common way a struggling service gets kicked while it is down, and the gRPC retry design treats that as a protocol problem rather than a client-code problem.
Three details from the proposal (gRPC Proposal A6, “gRPC Retry Design”) are worth stealing even if you never touch gRPC:
grpc-retry-pushback-ms, a signed 32-bit integer of milliseconds to wait before retrying, where a negative or unparseable value means do not retry at all. The server gets a vote.The proposal also states the idempotency rule plainly: in general, only status codes indicating the service did not process the request should be retried, and a more aggressive set can be used when the service owner knows a method is idempotent. Retry policy is a statement about your method semantics. Putting it in each client’s code means it cannot be revised without a client release, cannot be throttled per server name, and cannot be audited when it goes wrong.
There is a queue inside your consumer that no dashboard shows: its own resource budget. PostgreSQL’s documentation on work_mem is a useful illustration of how a per-unit limit multiplies. A complex query may perform several sort and hash operations at the same time, each generally allowed to use as much memory as work_mem specifies before spilling to temporary files, and several running sessions may be doing this concurrently — so total memory used could be many times the value of work_mem (PostgreSQL 18 Documentation, §19.4 “Resource Consumption”).
Read that narrowly. It is not a claim that work_mem causes queue backlogs; it is a demonstration that “we cap it per query” and “we cap it per system” are different statements. The same gap appears in every consumer: a per-request timeout, a per-request memory cap, a per-request concurrency slot — each individually reasonable, collectively unbounded. When the consumer’s resource budget is the real queue, the refusal has to happen before the request is admitted, not after it has allocated.
This is my recommendation, not a finding from the sources. The design principle is that refusal should happen at the cheapest layer that can make an informed decision, and each layer must be independently observable — because a single queue-depth graph cannot tell you which layer is doing the work.
Each layer needs its own refusal metric: local rejections at the client, quota rejections at the boundary, abandoned work at the consumer. If you cannot name all three numbers, you do not know which layer is protecting you.
Queue depth tells you how much work exists. Queue age tells you whether the work is still worth doing. AWS’s Well-Architected guidance lists as an anti-pattern not measuring the age of messages in a queue, describing it as a measurement of latency that shows when consumers are falling behind or erroring out and causing retries.
The builders’ library goes further with a metric design worth copying: AgeOfFirstAttempt records now minus enqueue time only on the first delivery attempt, so that slow or offline devices do not pollute the signal, and a companion metric isolates the first subscriber to keep the number stable in a pub/sub fan-out. The reasoning is that retries and consumer-side slowness mask producer-side overload; separating first attempts from retries makes the producer’s behavior visible again.
Here is a clearly labeled hypothetical, arithmetic on stated parameters rather than a case record. A consumer fleet at 100 concurrent executions, 30-second invocations, batch size 1 drains roughly 3.3 messages per second. A producer at 10 messages per second builds a backlog at about 6.7 messages per second. Scaling to the concurrency quota does not change the sign of that difference; it only changes how long the queue takes to become the largest object in your account. The number that matters is not the depth — it is how many seconds of age you are willing to serve, and whether the producer can be told no.
Three things, in plain terms.
First, I would put the refusal metric in the same dashboard as the queue metric before the first incident, not after. The cost of not doing this is measured in incident minutes spent distinguishing two failure modes that the vendor documentation already separates.
Second, I would write the retry policy into the service contract on day one, with a shared deadline across attempts and a server-side pushback path. The cost of retrofitting it is a client release cycle per client, and the scar is every retry storm that happened in between.
Third, I would stop treating “the queue is bounded” as a safety property. A bound that is larger than the work anyone will still want is an unbounded queue with a smaller number in the config file.
Put the refusal where it is cheapest, and make the queue prove it was heard.
The operational test is one question per layer: can you name the metric that shows this layer refused work in the last hour? If the answer is no for any layer, that layer is not backpressure — it is hope with a retention policy.
The shirt does not show a notebook. It shows a picture of a notebook cover: a black-and-white speckled rectangle, a dark binding strip down the left edge, and a white ruled label headed COMPOSITION with an outlined ghost and pumpkin inside it. The conclusion follows in two sentences: this is a surface transfer, not a costume, and the distinction matters because a costume asks the wearer to become something while a printed cover asks the viewer to recognize a familiar object. The design works only if you read it as a flat, reproduced page — the same way a technical diagram works only if you read it as a diagram and not as the system itself.
Look closely at what is actually printed. The speckle is a texture, not a material. The binding strip is a dark vertical band, not a spine you can open. The label is white with ruled lines, and the word COMPOSITION sits at the top in a plain, slightly condensed face. Inside the ruled area, an outlined ghost and an outlined pumpkin share the space. Nothing about the print claims to be three-dimensional. There is no attempt at a trompe-l’oeil fold, no shadow under the binding, no page curl. It is a cover reproduced on cloth, and the ghost and pumpkin are drawn in the same outline weight as the label rules, which keeps the whole thing reading as one printed artifact rather than a collage of stickers.
That flatness is the argument. A composition notebook is already a cheap, standardized object — the marbled cover, the sewn binding, the wide-ruled pages, the label where you write your name and subject. It is the most legible school supply in the room. When you print its cover on a shirt, you are not wearing a notebook; you are wearing the idea of one, reduced to its most recognizable marks. The ghost and pumpkin are additions, but they are drawn in the notebook’s own visual grammar: outline, rule, label. The design does not ask the ghost to be scary or the pumpkin to be seasonal in any loud way. It asks them to sit inside the ruled box like a name and a subject would, which is a quieter joke than a slogan and a more durable one.
This is where the shirt differs from a costume in the ordinary sense. A costume usually adds something — a hat, a prop, a silhouette that changes the body. This shirt subtracts. It reduces a person to a flat printed rectangle and lets the viewer do the recognition. That is closer to how a good interface works than to how a Halloween store works: the surface carries the minimum marks needed for the consumer to reconstruct the object, and the consumer supplies the rest. The ghost and pumpkin are not decoration so much as a test of whether the reconstruction still holds when you add two small, seasonal marks inside the label. It does hold, because the label was always the place where you wrote what the notebook was for.
I keep coming back to the word COMPOSITION. On a real notebook, that word is a category — a kind of paper, a binding, a ruling. On the shirt, it is the only word, and it is doing the work of a title. That is a small but real design decision: the shirt does not say teacher, does not say Halloween, does not say group costume. Those words live in the retail title, not in the print. The print trusts the viewer to know what a composition notebook is and to find the ghost and pumpkin funny or fitting on their own. That trust is the same trust a well-written error message extends to its reader: it names the condition and stops, rather than explaining the whole system every time.
If you are looking at this as a composition notebook shirt for a teacher group or an off-duty October thing, the useful question is not whether it is spooky enough. It is whether the flatness reads at the distance you will actually be seen. The speckle and the binding strip are high-contrast and will hold at a few meters; the ghost and pumpkin are outline drawings inside a white label and will read as small marks, not as a scene. That is consistent with the design’s logic — the label is the focal point, and the seasonal marks are contents, not headline. If you want a shirt that announces Halloween from across a parking lot, this is not that. If you want a shirt that reads as a familiar surface with a small seasonal insertion, the print is doing exactly that.
The reusable heuristic here is what I would call the surface-transfer test: when a design reproduces a familiar object on cloth, check whether the reproduction keeps the object’s own visual grammar — its rules, its labels, its binding marks — or whether it borrows the object’s silhouette and adds unrelated decoration. This shirt passes because the ghost and pumpkin are drawn in the notebook’s grammar, inside the ruled label, at the same outline weight. A weaker version would have put a large cartoon ghost over the speckle and called it a costume. The difference is not craft for its own sake; it is whether the viewer can reconstruct the object from the marks alone. That is the same test I would apply to a diagram in a design review: can someone who was not in the room rebuild the system from what is drawn, or does the drawing only work because someone is standing next to it explaining?
Editorial note: this publication and Quirky Cotton Collective share an owner.