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
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.
The shirt prints four letters and a period, centered, lowercase, at a scale that barely registers across a room. That tiny meh. is the entire design, and its restraint is the argument: a slogan announces, a whisper requires you to lean in.
I keep a folder of interface copy that fails the same way. The banner that shouts ERROR in forty-eight-point red when the user already knows something went wrong. The toast that says Success! with an exclamation mark nobody earned. Volume is not clarity. The meh shirt is interesting precisely because it refuses that move. The native garment preview shows very small, centered lowercase meh. lettering on a dark shirt, and no animal illustration is present. There is no mascot, no pride variant, no secondary graphic to soften the message. Just the word, the period, and a lot of dark fabric.
Read the punctuation literally. meh without a period is a shrug, an open-ended noise. meh. with a period is a closed statement. The period is the same character that ends a sentence in a runbook or a postmortem action item. It says the thought is complete. It does not invite debate. It does not escalate. It files the feeling and moves on.
That is a different speech act from sarcasm. Sarcasm usually wants an audience and a reaction. This design wants neither. The scale enforces the point: you have to be close to read it, which means the message is for the people already in your space, not for the room. I read that as a boundary drawn in typography rather than in words. The shirt does not say leave me alone; it says I have already assessed this and the assessment is final. Whether the wearer means either thing is not something the artwork can tell me, and I am not going to pretend it can.
Most printed slogans are written for the far field: legible from across a parking lot, optimized for the glance. This one is written for the near field. That is a design decision with consequences, and the consequences are the interesting part.
A far-field slogan makes a promise to strangers. It says: you will be able to read this and you will have a reaction, and that reaction is the product. A near-field slogan makes a promise to intimates. It says: if you are close enough to read this, you are close enough to already know what it means. The first is broadcast. The second is a shared channel. In API terms, one is a public endpoint with no auth; the other is a private one where the credential is proximity.
I have watched teams get this backwards in documentation. They write the landing page for the far field and the error messages for the near field, when the error messages are the ones a tired on-call engineer reads at 3 a.m. and the landing page is the one a stranger skims for four seconds. The meh. shirt gets the allocation right: the message is small because the audience is close, and the audience is close because the message is small. That loop is the whole design.
The observation is explicit that no animal illustration is present. That absence is worth naming because the default move for a shirt like this would be to add one. A grumpy cat. A sloth. Something to carry the meh so the word does not have to. The animal would be a hedge: it would soften the statement into a joke about a creature rather than a statement about a person.
Without the animal, the word has to do the work alone. That is harder and more honest. It also removes the escape hatch. You cannot say oh, it’s the sloth that’s meh, not me. The typography is the whole claim. I respect that, and I also notice the cost: a design this quiet will be misread by anyone who expects a punchline. Some people will look at it and see nothing. That is not a flaw in the shirt; it is the filter working.
Here is the distinction I keep coming back to. A slogan is optimized for the moment of encounter. A usable promise is optimized for the moment after, when someone has to act on it. Just do it is a slogan. Retries are safe; duplicates are not is a usable promise. The first makes you feel something; the second tells you what to do when the thing breaks.
The meh. shirt sits closer to the slogan end, and I do not think it is pretending otherwise. But the period pulls it one notch toward the promise end. It closes the statement. It does not leave you wondering whether the assessment is still in progress. In a work culture that runs on hedged language and let’s circle back, a four-letter word with a period is almost rude in its completeness. I mean that as praise. The most useful thing a colleague can sometimes say is a short, final sentence that does not require a meeting to interpret.
Not the word. The discipline. When I write a status update, an incident summary, or a deprecation notice, the question I now ask is: is this far-field or near-field? If the reader is a stranger skimming a changelog, I need the loud version, the one that survives a glance. If the reader is the person who owns the service, I need the small, final version, the one that respects their context and does not perform urgency it has not earned.
The shirt is a reminder that understatement is a load-bearing choice, not a lack of effort. The tiny lowercase letters and the period are doing more work than a banner would. I would rather read one closed sentence than a paragraph of maybe.
The near-field rule: before you write any message, name the distance between you and the reader. If they are close, be small and final. If they are far, be loud and complete. Do not write a far-field message for a near-field reader, and do not whisper at someone who has not walked over yet.
Editorial note: This publication and Quirky Cotton Collective share an owner.
Conclusion first: The shirt reads as a warm mutual-aid slogan, but its grammar quietly adds a condition: rooting is only half the promise, and the other half is growth. That clause is what makes it interesting to anyone who has written a team charter, a service-level objective, or a deprecation notice. The artwork is a ring of four smiling root vegetables — carrot, radish, beet, and onion — with their roots visible in soil, and the words LET’S ROOT FOR EACH OTHER AND WATCH EACH OTHER GROW wrapping around them. The pun works because root is doing two jobs at once, and the second job is the one with a deadline attached.
I want to be precise about what is actually printed, because the retail prose around gardening shirts tends to blur description into mood. The observation I am working from is the design itself: four root vegetables, each with a face, arranged around the lettering, roots drawn down into a band of soil. The carrot is orange, the radish red-pink, the beet a deeper magenta, the onion pale. The wording is set in a ring, not stacked in a block, so the sentence has no obvious beginning or end. You read it in a loop. That circular setting is not a neutral layout choice; it makes the slogan feel like a cycle rather than a one-way instruction. I am interpreting that effect, not claiming the designer wrote a specification for it.
The first meaning of root is encouragement — the sideline sense, the one you shout at a kid on a field. The second is the botanical sense, the underground structure that anchors the plant and draws up water. The shirt puts both meanings in the same sentence and then adds and watch each other grow. That conjunction is doing more work than it looks like. It converts a cheer into a two-part arrangement: I will support you, and I will also observe your development. Support plus observation is a different offer from support alone. It implies a relationship long enough for growth to be visible, and it implies that the growth is the point, not a side effect.
This is where the shirt becomes useful as a small piece of work-culture reading. Teams write slogans like this all the time, and the failure mode is almost always the same: the encouragement half gets printed, and the growth half gets forgotten. We support each other is easy to say and impossible to falsify. We watch each other grow is harder, because watching implies attention, and growth implies a baseline you can compare against. If you cannot describe what growth would look like for a colleague over the next year, the first half of the sentence is decoration. The shirt is not a management framework, and I am not going to pretend a cotton tee proves anything about team performance. But the wording is a decent prompt for a design review of a team charter: which clause in this document commits us to noticing change, and which clause only commits us to being nice?
The vegetables themselves carry a second, quieter argument. Carrot, radish, beet, and onion are all crops you pull up. Their value is underground, and you only see it at harvest. That is a different metaphor from the usual growth imagery — the sapling, the sunflower, the vine climbing a trellis. Those are about visible upward progress. Root vegetables are about invisible accumulation followed by a single revealing moment. If you take the artwork literally, the promise is not we will grow steadily and everyone will see it. It is the work happens out of sight, and eventually someone pulls it up. I find that more honest than most growth slogans, and I suspect it is accidental. The design needed four recognizable root vegetables with smiling faces, and the metaphor came along for free.
The smiling faces matter too. Root vegetables with faces are a children’s-book convention, and the shirt borrows that register deliberately. It is not a stern poster about professional development. It is a garden pun you can wear to a weekend plant swap. The tension between the cute drawing and the slightly demanding sentence is the whole object. If the vegetables frowned, the shirt would be a warning. If the sentence stopped at root for each other, it would be a greeting card. The combination — friendly faces, circular layout, growth clause — lands somewhere between a team value and a seed packet.
For readers who spend their days on contracts and interfaces, there is a familiar distinction hiding in the grammar. Root for each other is a best-effort commitment. Watch each other grow is closer to an observable outcome, though still vague enough to escape any real service-level definition. The shirt does not resolve that vagueness, and it should not have to. What it does is put the two halves in the same sentence so you cannot quote the warm half without also quoting the clause that asks something of you. That is a small editorial achievement in a genre — the inspirational slogan — that usually prefers to leave its obligations implicit.
The object itself is a standard t-shirt from Quirky Cotton Collective, listed as Let’s Root For Each Other And Watch Each Other Grow Garden. If you want the exact garment, it is the Quirky Cotton Collective listing on Amazon. I am describing the printed design as observed, not reviewing fit, fabric, or durability, because I have not worn or tested it and will not invent an experience to fill the gap.
Editorial note: this publication and Quirky Cotton Collective share an owner. This column is not an independent review.
What I would take from the shirt is a small reusable test for any mutual-support language, whether it appears on a team page, in a charter, or on a t-shirt. Call it the growth-clause check: read the sentence and ask whether it contains a second clause that commits anyone to noticing a change. If it does not, the sentence is encouragement only, and it should be labeled that way rather than presented as a promise. The shirt passes the check because the growth clause is printed in the same ring as the rooting clause. Most team values pages fail it, because they stop at we support each other and never say what support is supposed to produce. The vegetables, rooted and smiling and waiting to be pulled up, are a better diagram of that distinction than most of the documents I review.
The shirt prints a notification banner, not an alert: a white rounded rectangle with a bell icon and the sentence There is motion at your front door, and beneath it a circular, green-tinted doorbell-camera view of a wide-eyed orange tabby pressed close to the lens, porch siding and lights behind it. The joke works because the two halves disagree about urgency — the banner is calm, procedural, almost bureaucratic, while the image is a face that has arrived at the camera with no plan.
That disagreement is the whole design, and it is worth reading closely because it is the same disagreement that shows up in every notification system I have ever inherited. The banner is the promise. The cat is the experience. The gap between them is where the humor lives, and also where the support tickets live.
Two elements, stacked. The upper element is a notification: rounded white card, small bell glyph, one sentence in a plain sans. The lower element is a circular viewport, tinted green the way cheap night-vision or a compressed camera feed tends to look, containing an orange tabby at close range. The tabby’s eyes are wide. The porch behind it is ordinary — siding, a light. Nothing in the image is dramatic except the cat’s proximity to the lens.
I want to be careful about what I claim here. I am reading a printed graphic, not a product manual. The shirt does not document a real doorbell, a real cat, or a real event. What it documents is a recognizable visual grammar: the notification card and the camera thumbnail, arranged in the order a phone would arrange them. That grammar is the artifact. The joke is that the grammar is doing its job perfectly and the content is absurd.
Read the sentence again: There is motion at your front door. It is a statement of fact with no severity, no actor, no recommended action. It does not say someone is at your door. It does not say your package has arrived. It says motion exists. That is the minimum viable notification — technically true, operationally useless, and exactly the kind of message a system emits when the person who wrote the copy was optimizing for accuracy rather than for the reader’s next decision.
The thumbnail, by contrast, is all decision. A face fills the frame. The reader of the shirt — and the reader of the phone — now knows who, roughly, and can act. The banner told you something happened. The image tells you what to do about it. The shirt stacks them in that order because that is the order the real product stacks them, and the joke is that the second panel renders the first panel redundant in the most undignified way possible.
This is the pattern I keep finding in API design. A response says 200 OK and a body says {"status": "processed"}, and the consumer still has to open three other endpoints to learn whether anything they care about occurred. The status line is the banner. The payload is the thumbnail. When the payload is a cat, everyone laughs. When the payload is a null, everyone files a ticket.
A human at the door is a story with a social script. A cat at the door is a story with no script at all — the cat has no appointment, no package, no reason to be there, and no awareness that it is being observed. The wide eyes are not menace; they are the expression of a creature that has walked into a sensor’s field of view and is now, briefly, the most important event in the system.
That is the second thing the design gets right. The notification is about motion, which is a category so broad it includes leaves, rain, delivery drivers, raccoons, and the neighbor’s car. The camera view is about a specific face, which is a category of one. The shirt puts the broad category on top and the specific instance below, and the mismatch between their emotional registers — procedural above, startled below — is the entire comic engine. You cannot swap the cat for a person and keep the joke. The person would make the banner feel late. The cat makes the banner feel like a form letter.
The phrase there is motion at your front door is the kind of sentence that only exists because a product manager needed a string that would not be wrong. It is passive, it is vague, and it is grammatically incapable of assigning blame. The shirt does not improve the sentence. It illustrates the sentence’s cost: a calm, correct, unhelpful message sitting directly above the evidence that the message was never the point.
I have written strings like that. I have shipped strings like that. The reason is always the same — the system knows motion and does not know intent, so the copy retreats to what the system can defend. The shirt is a small, wearable postmortem for every one of those strings. It does not argue that the string is wrong. It argues that the string is insufficient, and it makes the argument with a face.
If you want the object itself, the listing is here: There Is Motion At Your Front Door Funny Cat Doorbell Meme. The design is the white notification card with the bell and the sentence, above the circular green-tinted camera view of the orange tabby. That is what is printed. Everything else in this piece is my reading of it.
The reusable heuristic is this: every notification should carry the thumbnail, not just the banner. If your system can only say motion detected, it has not finished the job — it has described its own sensor rather than the reader’s situation. The fix is not better adjectives. The fix is attaching the specific instance: the actor, the object, the frame. The shirt is funny because the thumbnail is a cat. The lesson is not funny at all: a notification without an instance is a banner with nothing underneath it, and the reader will supply their own cat, and it will be worse than yours.
Editorial note: this publication and Quirky Cotton Collective share an owner, so this is not an independent review.
Editorial note: This publication and Quirky Cotton Collective share an owner.
The shirt reads I WEAR THIS SHIRT PERIODICALLY, and beneath the sentence sit four periodic-table tiles: 53 I, 74 W, 22 Ti, 16 S. The tile symbols spell I W Ti S — not the word periodically, and not even a clean abbreviation of it. That mismatch is the whole design, and it is also the whole problem: the shirt is a promise that cannot be verified from the artifact it ships with.
I mean that as a compliment to the joke and a criticism of the contract. The visual observation is exact: four tiles, atomic numbers 53, 74, 22, and 16, symbols I, W, Ti, and S. The sentence above them says periodically. The tiles do not spell periodically. They spell a fragment that a reader has to reconstruct into a sentence using chemistry knowledge, English syntax, and a tolerance for missing letters. The shirt is not a pun that resolves cleanly. It is a pun that resolves only if you accept an implicit contract: the reader will do the assembly work.
That is a familiar contract in API design, and it is usually a bad one. When a response schema says status: "ok" but the payload contains a partial result, the consumer has to reconstruct intent from context. When a pagination cursor is opaque but the docs imply it is stable, the consumer has to guess. When a deprecation notice says sunset soon without a date, the consumer has to infer a deadline. In each case the producer has shipped a sentence that looks complete and a set of tiles that do not spell it. The shirt is a wearable version of that gap.
Look at the tiles more closely. 53 I is iodine. 74 W is tungsten. 22 Ti is titanium. 16 S is sulfur. Read as symbols, they give I W Ti S. Read as a sentence, they give I wear this — if you silently expand W to wear, Ti to this, and S to shirt. The word periodically is not in the tiles at all. It is in the sentence above them, doing the work of a comment that explains what the code was supposed to do. The design is funny because the tiles are technically correct as element symbols and semantically incomplete as a sentence. That is the same failure mode as a README that says see code for details.
The retail listing calls this a Funny Chemistry Science Pun, and I understand why. But the pun is not the interesting part. The interesting part is that the shirt asks the wearer to be the runtime that resolves the ambiguity. A periodic-table joke normally works by spelling a word with element symbols — Ba + Na + Na, or Co + W. This one does not spell the word. It spells a compressed instruction and leaves the expansion to the reader. The shirt is less a pun than a serialization format with a lossy schema.
I have spent enough time in design reviews to recognize the pattern. Someone proposes a field name that is obvious to the team. Someone else points out that the field name is not obvious to a new consumer. The team ships it anyway because the docs will explain it. The docs do not explain it, or they explain it in a place the consumer never looks. Six months later a support ticket arrives: what does this field mean? The answer is in a comment above the sentence, not in the tiles. The shirt is that ticket, printed on cotton.
The useful question is not whether the joke is funny. It is whether the artifact is self-describing. A good periodic-table pun is self-describing: the symbols spell the word, and the word is the joke. This shirt is not self-describing. It requires a decoder ring that the shirt does not ship with. That is fine for a t-shirt, where the decoder ring is a human with a chemistry class. It is not fine for an API, where the decoder ring is a consumer who will not read your docs.
If you want the shirt, it is listed here. I am not going to pretend it demonstrates anything about software. It is a shirt. But it is a useful shirt to think with, because it makes the gap between what the sentence says and what the tiles spell visible on a chest. Most of our contracts have that gap. We just do not print it.
The heuristic I would take from this: the tile test. Before you ship a schema, a status code, or a deprecation notice, ask whether the artifact spells the promise on its own. If a consumer has to reconstruct the sentence from context, you have shipped a shirt that says periodically above tiles that say I W Ti S. It may be funny. It is not a contract.
The shirt prints I HAD POTENTIAL in white capitals above a white curved ramp that descends from an upper-left ledge to a lower-right flat. A dashed empty circle sits on the upper ledge; a solid white ball rests on the lower flat. The joke is not that the ball fell. It is that the drawing shows exactly where it fell from and where it stopped, and the caption still calls the starting position “potential.”
That is a more precise joke than the usual sarcastic slogan, because the artwork does the work of a diagram: two states, one path, one caption. The dashed circle is the potential state — an outline, a position that could have been occupied. The solid ball is the actual state — a body at rest on the lower ledge. The curved ramp between them is the only thing that connects the two, and it is drawn as a smooth, inevitable descent. The shirt is not saying “I wasted my potential.” It is saying “here is the free-body diagram of what happened to it.”
I keep looking at the dashed circle. In physics, a dashed outline often marks a position that is not currently occupied — a ghost, a reference point, a thing that could be there. The shirt uses that convention without labeling it. The empty circle is the potential; the solid ball is the outcome. The caption sits above both, as if it were the title of a figure in a textbook. The whole design reads like a problem statement: Given a ball at rest on an upper ledge, a curved ramp, and a lower flat, describe the final state. The answer is printed on the shirt.
What makes the design hold up is that the ramp is curved, not a straight diagonal. A straight line would read as a slide, a chute, a deliberate drop. The curve reads as a path with acceleration — the ball would speed up as it descended, then come to rest on the flat. The curve also makes the drawing look like a potential-energy diagram rotated ninety degrees, which is probably not the intent but is hard to unsee once you notice it. The shirt is not a physics lesson. It is a visual pun that borrows the grammar of one.
The phrase “I had potential” is doing something subtler than self-deprecation. It is a statement about a closed system. The ball did not escape; it did not bounce back up; it did not get launched into a better trajectory. It rolled down a curved ramp and stopped. The shirt is funny because it treats a personal narrative as a solved problem with a diagram attached. The dashed circle is the only thing left of the potential, and it is empty.
If you want the object itself, the I Had Potential shirt is listed under the Quirky Cotton Collective brand. The design is minimal — white print on a white garment in the retail image, with no additional text or decoration beyond the caption and the diagram. The joke depends on that restraint. A busier design would turn the diagram into an illustration; this one leaves it as a figure.
Editorial note: This publication and Quirky Cotton Collective share an owner.
The reusable heuristic here is what I would call the closed-system check: when a slogan or a diagram claims to describe a trajectory, ask whether it shows the starting state, the path, and the final state — and whether the caption matches the drawing. This shirt passes that check. The dashed circle, the curved ramp, and the solid ball are all present, and the caption names the starting state without pretending the final state is a mystery. Most slogans fail the check because they show only the outcome or only the aspiration. This one shows both, and lets the empty circle do the talking.
Conclusion first: The shirt prints a personal boundary in the grammar of industrial safety signage, and that borrowed grammar is the whole argument. A warning triangle and a crossed-out hand promise enforcement; a person wearing them can only promise intent. The gap between those two promises is where the design gets interesting.
Editorial note: this publication and Quirky Cotton Collective share an owner. This is not an independent review.
The observed artwork is blunt: NOT FRIENDLY DO NOT TOUCH set in warning-sign lettering, a yellow caution triangle, and a crossed-out hand symbol. The retail listing is Not Friendly Do Not Touch Funny Warning Sign Introvert, sold under the Quirky Cotton Collective brand. That is the object. Everything below is a reading of the graphic, not a report on how it wears, who bought it, or how it performs.
Three visual decisions carry the meaning. First, the words are imperative and absolute: do not, not please don’t. Second, the triangle is the shape we teach people to obey before they can read the sentence inside it. Third, the crossed-out hand is a prohibition pictogram, the same family as no smoking or do not enter. None of these elements is decorative. Each one is a piece of a system that assumes someone has the authority to stop an action.
A caution triangle works because it is issued. It appears on a machine, a chemical container, a door, and the institution behind it has accepted responsibility for what happens next. The triangle is not a request from the machine. It is a claim by whoever controls the space.
When that triangle moves onto a shirt, the authority does not travel with it. The wearer has no enforcement mechanism, no policy, and no ability to make the pictogram true. What remains is the shape of a rule without the institution that backs it. That is not a flaw in the joke; it is the joke. The shirt is funny because it borrows the confidence of a safety label and spends it on something a safety label cannot deliver: a preference about conversation.
I would resist the temptation to call this a boundary. A boundary is something you can hold and negotiate. A warning label is something you are expected to obey without discussion. The shirt is closer to the second, which is why it reads as comic rather than therapeutic. It is a boundary drawn in the wrong genre.
The words alone would be a mood. The crossed-out hand makes a specific claim about physical contact. Prohibition pictograms are unusually efficient because they do not argue; they subtract. A hand with a slash through it says this action is not available here, and it says it in less space than any sentence could.
That efficiency is also the design’s weak point as a personal statement. A prohibition pictogram is designed for a space where the rule can be enforced by a lock, a guard, or a law. On a person, the slash is aspirational. The shirt can announce the rule; it cannot install the lock. Readers who have spent time in platform work will recognize the pattern immediately: a contract that describes an outcome the system has no mechanism to guarantee. The label is honest about the intent and silent about the enforcement.
This is the distinction I keep coming back to with objects like this. A slogan states a position. A usable promise states a position and the conditions under which it holds. Not friendly is a slogan. Do not touch is closer to a promise, but only if the wearer can actually prevent the touch, which no shirt can.
That does not make the shirt dishonest. It makes it a piece of public-sign language used for a private purpose, and the mismatch is the source of the humor. The design is not trying to be a functional boundary tool. It is trying to be legible at a distance, in the same way a real warning sign is legible at a distance, and it succeeds at that. The yellow triangle and the crossed-out hand do their job before the words are read.
As a piece of visual communication, the shirt is disciplined. It uses one color accent, one symbol, and one imperative. It does not stack jokes or add a second punchline. The lettering is set in the register of signage rather than the register of merchandise, which is why it reads as a warning first and a joke second. That ordering matters: if the joke arrived first, the triangle would feel like decoration. Because the warning arrives first, the joke lands as a recognition rather than a gag.
The introvert framing in the listing title is doing separate work from the artwork. The graphic itself does not say introvert; it says not friendly and do not touch. Those are not the same claim. Introversion is a preference about stimulation; unfriendliness is a claim about how one treats other people. The shirt collapses the two, which is part of its blunt charm and also part of what makes it a costume of a boundary rather than a description of one. I read the design as a joke about the fantasy of signage, not as a statement about any personality type.
When a design borrows the language of rules, run a quick enforcement audit before you decide what it means. Ask three questions in order:
Run that audit on this shirt and the result is clear: borrowed authority, no mechanism, no consequence. That is not a failure. It is the correct reading of a garment that uses the visual grammar of a safety sign to say something a safety sign was never built to say. The design is legible, disciplined, and honest about being a joke. The only thing it cannot do is enforce itself, and no shirt can.