Author: Janet Ray Page 1 of 13

Four root vegetables smile up from the shirt: a carrot, a radish, a beet, and an onion, each with its roots drawn down into a band of soil. Around them, in a ring, the words run: LET’S ROOT FOR EACH OTHER AND WATCH EACH OTHER GROW. The design is a garden pun, and the pun is doing more work than it first appears. Root is both the thing in the ground and the act of support. The shirt asks you to hold both meanings at once, and that double meaning is where the interesting argument lives.

I have spent most of my career reading interface contracts, and the habit is hard to turn off. A slogan is a kind of contract, or at least it wants to be. It makes a promise about how people will behave toward one another. The question I keep asking of this one is not whether it is cute — it is — but whether the promise it makes is one a team could actually keep.

What the artwork actually shows

The observation is literal: the phrase surrounds four smiling root vegetables — carrot, radish, beet, and onion — with their roots visible in soil. The composition is circular. The words wrap the vegetables rather than sitting above or below them. That circularity matters. A slogan printed in a straight line reads as a banner. A slogan printed in a ring reads as an enclosure, something that holds the group together.

The vegetables are not identical. They are different species with different shapes and different root structures. The carrot tapers; the beet bulges; the onion layers; the radish is small and round. The design does not flatten them into one generic plant. It shows four distinct things growing in the same soil. That is a visual claim about diversity, though I would not overstate it — it is a cartoon, not a diagram of crop rotation.

The roots are visible. That is the part I keep returning to. Most garden illustrations show what is above ground: leaves, flowers, fruit. This one cuts away the soil line and shows the part you normally do not see. The visible root is the design’s quiet thesis. Growth that looks like one thing above the surface depends on something else below it.

The two meanings of ‘root’

The first meaning is botanical: the root is the organ that anchors the plant and draws water and nutrients from the soil. The second meaning is social: to root for someone is to support them, to want them to succeed. The shirt stacks these meanings deliberately. Let’s root for each other uses the social sense. Watch each other grow uses the botanical sense. The pun is not just wordplay; it is an argument that support and growth are the same process seen from different angles.

I find that argument genuinely useful, and also slightly slippery. Support is not the same as growth. You can root for someone who is not growing, and you can watch someone grow without having supported them. The shirt collapses the two, which is fine for a slogan but worth unpacking if you want to take it seriously as a statement about how a team should work.

Mutual support versus endless growth

Here is where I get skeptical. Watch each other grow is a lovely sentiment, but in a work context, growth is often a demand dressed as an aspiration. The phrase can mean I want you to develop, or it can mean I expect you to keep expanding indefinitely. Those are different promises. One is generous; the other is a treadmill.

The artwork, to its credit, does not resolve this ambiguity. It just puts four smiling vegetables in soil and lets you decide. But if you are going to wear the shirt to a team offsite, or hang it in a Slack channel as a morale image, it is worth knowing which reading you are endorsing. Mutual support is a boundary you can keep. Endless growth is a boundary that eventually breaks, because soil is finite and so is a person’s capacity.

I would rather read the shirt as a statement about conditions than about outputs. The roots are visible because the conditions are visible. You cannot watch something grow without also watching what it is rooted in. That is a more defensible promise: we will pay attention to each other’s soil, not just each other’s height.

What a usable promise looks like

If you wanted to turn this slogan into something a team could actually hold itself to, you would need to make it specific. A slogan is a headline; a contract is the body text. The shirt gives you the headline. The body text is your job.

Here is a small artifact I would adapt from this design — a one-page team agreement that keeps the spirit of the slogan but replaces the vague promise with checkable behaviors. The pattern is always the same: name the support, name the growth, name how you will know.

# Team Growth Agreement (adapt freely)

## We root for each other by:
- [ ] Asking before advising. "Do you want ideas or do you want me to listen?"
- [ ] Naming a specific person's work in retros, not just "the team."
- [ ] Making room for someone to be bad at something new without it becoming a performance review.

## We watch each other grow by:
- [ ] Reviewing growth against the person's own stated goals, not an abstract ladder.
- [ ] Treating a plateau as information, not a failure.
- [ ] Asking "what would make this sustainable?" before "what's next?"

## We keep the soil visible by:
- [ ] Saying out loud when workload, ambiguity, or on-call is depleting someone.
- [ ] Reviewing this agreement once a quarter and changing it.

The highlighted lines are the ones that turn the slogan into something you could actually be held to. Asking before advising is the difference between support and intrusion. Treating a plateau as information is the difference between watching growth and demanding it. Saying out loud when workload is depleting someone is the difference between visible roots and decorative ones.

Why the garden metaphor holds up better than most

Workplace slogans usually fail because they borrow the language of sports or warfare — crush it, play to win, move fast. Those metaphors imply an opponent and a finish line. Gardening implies neither. A garden has seasons, dormancy, soil depletion, and replanting. It has failure that is not moral failure. A plant that does not thrive is not lazy; it is in the wrong conditions, or it is the wrong season, or something is eating its roots.

That is a more humane frame for a team, and it is the frame the shirt is quietly borrowing. The four vegetables are not racing each other. They are in the same bed, drawing from the same soil, and the design asks you to root for all of them at once. That is a better model for a team than a leaderboard.

I would not push the metaphor too far. A garden is not a team, and a team is not a garden. But the specific choice to show roots — the part underground, the part that is usually invisible — is the detail that makes the slogan more than a pun. It says: the interesting part of growth is the part you have to look for.

Reading the shirt as a boundary statement

There is a second reading I keep coming back to, and it is less warm. Let’s root for each other can also be a boundary. It says: I will support you, and I expect support in return. That is not a demand for endless positivity; it is a statement of reciprocity. The circular composition reinforces it. The words enclose the vegetables; the support encloses the group. You are inside the ring or you are not.

I like that reading because it makes the shirt usable in a work context without requiring anyone to pretend that growth is always comfortable. Mutual support is a commitment you can keep even when someone is not growing the way you expected. It is the commitment to stay in the soil with them.

If you are the kind of person who owns API contracts, you already know that the interesting part of any agreement is the edge case. The slogan’s edge case is the person who is not growing. Does the shirt still apply? I think it does, and I think that is the best thing about it. The roots are visible because the support is supposed to be visible too, especially when the above-ground part looks stalled.

The object itself

The shirt is the Let’s Root For Each Other And Watch Each Other Grow Garden design from Quirky Cotton Collective. The artwork is the argument; the garment is the delivery mechanism. I am not going to tell you how it fits or how it washes, because I have not worn it and I am not going to invent that. What I can tell you is what the design says, and why I think it says more than a generic gift shirt usually does.

If you are looking for a lets root for each other shirt — the phrase people actually type — this one earns its place by taking the pun seriously. The four vegetables are distinct, the roots are visible, and the circular composition turns a slogan into an enclosure. That is a small piece of design craft, and it is the reason the shirt is worth reading closely rather than just buying.

The artifact, one more time

If you take nothing else from this, take the agreement template above. Adapt it. Change the checkboxes to the ones your team actually needs. The shirt is a headline; the agreement is the body text. A slogan you cannot operationalize is just decoration. A slogan you can turn into three checkable behaviors is a contract.

And if you wear the shirt to the offsite, bring the agreement on a single page. The vegetables are smiling because someone remembered to make the soil visible. That is the whole trick.

Editorial note: This publication and Quirky Cotton Collective share an owner.

The shirt shows four letters and a period. Large, bold, white, lowercase: meh. on a dark ground. No illustration, no second line, no joke setup. The period is doing more work than the word.

I keep coming back to that period because it changes the speech act. meh alone is a shrug — an open-ended, low-stakes noise you make when someone asks where you want to eat. meh. with a full stop is a verdict. It closes the sentence. It is the typographic equivalent of marking a ticket wontfix and moving on.

That distinction is the whole argument of the design, and it is worth taking seriously for a minute — not because a t-shirt is a management framework, but because the difference between an open-ended signal and a closed one is the same difference that separates a useful API response from a rude one.

What is actually printed

Per the native garment preview, the design is large bold white lowercase meh. lettering on a dark shirt. There is no animal illustration and no pride variant. That is the object. Everything below is my reading of it, not a claim about what the designer intended or what the shirt will do for your career.

The visual choices matter to the reading:

• Lowercase. Lowercase is casual, unbothered, unimpressed. It refuses the effort of capitalization.
• Bold. The word is quiet in meaning but loud in presentation. That mismatch is the joke.
• White on dark. Maximum contrast. The word is legible from across a room, which is a strange thing to do to a word that means “I have no strong opinion.”
• The period. Terminal punctuation. The sentence is over. No further discussion is invited.

If you want the object itself, it is the Meh Funny Sarcastic Saying Introvert Dry Humor shirt from Quirky Cotton Collective.

Editorial note: this publication and Quirky Cotton Collective share an owner, so treat this as an owner-authorized column rather than an independent review.

The difference between a shrug and a status code

In API work we spend a lot of time on the difference between “I don’t know” and “I know, and the answer is no.” Those are not the same response, and conflating them is one of the most common causes of bad client behavior.

A 200 OK with an empty body is a shrug. The client has to guess whether the absence of data means “nothing here,” “you asked wrong,” or “we broke.” A 404 with a problem-details body is a period. It says: this resource is not here, here is the type of problem, here is what you can do next. The client can branch on it.

The shirt is a period. It is not a shrug. The word is dismissive, but the typography is decisive. That is the tension I find interesting: a message that says “I don’t care” while being completely unambiguous about the fact that it doesn’t care.

Most teams get this backwards. They write error responses that are technically informative but socially ambiguous — a 400 with a stack trace, a 500 with “something went wrong,” a 429 with no Retry-After. The status code is a period, but the body is a shrug. The client is left holding a sentence that ended without saying anything.

A short checklist for terminal messages

If you take the shirt’s typography as a small style guide, here is what it implies for any message a machine or a person has to act on:

• Say the thing. The word is the word. No euphemism, no “unexpected condition.”
• End the sentence. If the outcome is final, make it final. Do not leave the reader waiting for a second paragraph that never comes.
• Match volume to content. The shirt is loud about being unimpressed. That is a deliberate mismatch. In an error response, loud formatting around a vague message is just noise. Pick one.
• Do not decorate. No illustration, no mascot, no second line. The design trusts four letters and a period. Most error bodies could lose half their fields and get clearer.
• Be honest about the register. “meh.” is rude. A 404 is not rude; it is precise. Know which one you are sending.

Where the shirt stops being a useful analogy

I want to be careful here, because it is easy to over-read a piece of clothing. The shirt is a joke about a mood. It is not a model for incident communication, and it is definitely not a model for how to talk to a colleague who is blocked.

The reason is that “meh.” works as humor precisely because it withholds. In a status code, withholding is a bug. A 503 that does not say whether the failure is transient or permanent is not dry; it is just unhelpful. The shirt gets to be terse because the stakes are zero. Your Retry-After header does not have that luxury.

So the useful reading is narrower than “be terse.” It is: when you have decided, say so plainly, and stop. The period is the part worth copying. The lowercase is optional.

Off-duty, but not off-topic

I would not wear this to a customer call, and I would not put it on a slide about developer experience. But as an object in a work-culture column, it earns its place because it makes a small, legible argument about register. A lot of engineering communication fails not because it is wrong but because it cannot decide whether it is shrugging or concluding. The shirt decides. It concludes. It is, in its own low-effort way, well-designed.

If you want the artifact, the meh shirt is the one described above. If you want the takeaway, it is this: check your terminal messages. If the sentence is over, put the period on it. If it isn’t, do not pretend it is.

The shirt reads I WEAR THIS SHIRT PERIODICALLY, and beneath the sentence sit four periodic-table-style tiles: 53 I, 74 W, 22 Ti, 16 S. Read the symbols in order and you get I W Ti S — which is not a literal spelling of the sentence above it. That gap is the whole joke, and it is also the most interesting thing about the design.

Most slogan shirts ask you to agree with a sentence. This one asks you to perform a small decoding step and then accept an imperfect result. The tiles are not a cipher that resolves cleanly; they are a visual rhyme. I W Ti S sounds like “I wear this” if you say it aloud and squint. The pun lives in that squint.

What the tiles actually show

Four tiles, each in the visual grammar of a periodic-table cell: atomic number on top, element symbol in the middle. The numbers are real atomic numbers — 53 is iodine, 74 is tungsten, 22 is titanium, 16 is sulfur. The symbols are the real symbols for those elements. Nothing is faked at the chemistry level.

What is faked is the sentence. I W Ti S is not how you spell “I wear this.” The design is not pretending otherwise. It is a rebus, not a substitution cipher, and the pleasure is in noticing that the tiles almost work. A reader who tries to decode strictly gets stuck; a reader who reads phonetically gets the joke.

That is a more interesting design decision than a clean match would have been. A shirt that spelled the sentence exactly with element symbols would be a puzzle with a solution. This one is a puzzle with a punchline.

The word “periodically” is doing two jobs

The sentence says the shirt is worn periodically — occasionally, now and then. The tiles say the shirt is made of periods-adjacent material — the periodic table. The pun collapses both readings into one word, and the tiles are the evidence that the second reading is the intended one.

This is the same move engineers make constantly in naming. A service called Reaper that deletes expired records is doing two jobs with one word: the literal function and the cultural reference. A flag called canary is both a bird and a warning. The best internal names carry a second meaning that helps you remember what the thing does. The worst ones carry a second meaning that misleads you about what it does.

The shirt is in the first category. “Periodically” tells you the wearing cadence and the chemical reference at the same time, and neither reading contradicts the other. That is a small piece of craft worth noticing.

Why the imperfect decode is the point

If the tiles spelled the sentence exactly, the shirt would be a trivia question. Instead it is a joke about approximation. I W Ti S is close enough to “I wear this” that your brain fills in the gap, and the filling-in is the fun.

I think about this every time I review an API contract that is almost self-explanatory. A field called status that returns "ok", "pending", and "failed" is close enough that most readers get it. A field called state that returns "A", "P", and "F" is not close enough — the reader has to look it up, and the lookup is friction. The shirt’s tiles are the first kind of approximation: close enough that the reader enjoys the gap. A bad enum is the second kind: close enough to look decodable, far enough that the decode fails silently.

The design lesson is not “approximate everything.” It is that approximation works when the reader can feel the gap and resolve it themselves. It fails when the gap is invisible until production.

What the shirt is not

It is not a chemistry lesson. The atomic numbers and symbols are correct, but the shirt does not teach you the periodic table; it borrows its visual language for a pun. It is not a statement about how often you actually wear it. And it is not a software artifact, a security claim, or a demonstration of anything technical. It is a shirt with a joke on it, and the joke is legible.

That legibility is worth naming because so many technical in-jokes fail at exactly this step. A shirt that says git commit -m "fix" is funny to people who have done that and opaque to everyone else. A shirt that says I W Ti S is funny to anyone who reads it aloud, and slightly funnier to anyone who knows what tungsten is. That is a wider aperture than most niche humor manages.

The boundary between a slogan and a usable promise

The shirt makes a claim — I wear this periodically — and then undercuts it with tiles that do not quite spell the claim. That structure is worth borrowing for internal documentation. A runbook that says “restart the service” is a slogan. A runbook that says “restart the service, then check /healthz for 200 within 60 seconds, then page the on-call if it does not” is a usable promise. The difference is whether the reader can verify the claim without asking you.

The shirt does not need to be verifiable. It is a joke. But the same instinct that makes the joke work — give the reader enough to decode it themselves — is the instinct that makes a good error message, a good changelog entry, and a good onboarding doc. The reader should be able to close the gap without a meeting.

An artifact: the decode-gap checklist

Here is a short checklist I use when reviewing any message a reader has to decode — an error response, a flag name, a runbook step, or a shirt slogan. It is not a formal standard; it is a way to notice when an approximation is charming versus when it is a trap.

• Can the reader resolve the gap without you? If the answer is no, the approximation is a bug, not a joke.
• Is the gap visible before it matters? A pun that fails is funny. An enum that fails is an incident.
• Does the second reading contradict the first? “Periodically” works because both readings agree. A name that means two incompatible things does not.
• Is the decode step cheap? Reading I W Ti S aloud takes a second. Looking up an undocumented status code takes a Slack thread.
• Would a strict reader get stuck? If yes, decide whether the stuck-ness is the point. On a shirt, it is. In a contract, it is not.

The shirt passes this checklist because the gap is the joke and the decode is cheap. Most of the messages we ship do not have that luxury. The checklist is a way to tell the difference before the reader does.

The object itself

The shirt is sold as I Wear This Shirt Periodically Funny Chemistry Science Pun by Quirky Cotton Collective. The design is the sentence plus the four tiles, and the tiles are the part worth looking at. If you are going to wear a joke, wear one that rewards a second read.

Editorial note: This publication and Quirky Cotton Collective share an owner.

The shirt shows a curved ramp descending from left to right. At the top left, a dashed empty circle sits on the ledge. At the bottom right, a solid white ball rests on the flat. Above both, in white capitals: I HAD POTENTIAL.

That’s the whole design. No punchline, no extra caption, no arrow labeled kinetic energy. Just a diagram and a sentence in the past tense. And the more I look at it, the more I think the diagram is doing something the sentence can’t do alone — it’s making an argument about what “potential” means, and the argument is funnier and slightly sadder than the slogan by itself.

This is a column about reading the objects technical people wear and keep on their desks. Not a gift guide. Not a physics lesson. The shirt is the I Had Potential ramp-and-ball design from Quirky Cotton Collective, and I want to take the drawing seriously for a few hundred words.

Two circles, two states

Start with the literal observation, because the literal observation is where the joke lives.

• Upper left: a dashed circle, empty, sitting on the high ledge.
• Lower right: a solid circle, filled, resting on the low flat.
• Between them: a curved ramp, not a straight diagonal.

A dashed outline usually means not there — a placeholder, a ghost, a thing that was supposed to occupy the space. A solid fill usually means there — an object with mass, sitting where objects end up. So the diagram reads left to right as a transition from absence to presence, from outline to fill, from high to low.

But the caption says I had potential. Past tense. Which means the dashed circle at the top isn’t a future state. It’s a memory. The empty outline is where the potential used to be, and the solid ball at the bottom is where it went.

The ramp is curved, and that matters

A straight diagonal would read as a slide: potential at the top, kinetic at the bottom, one clean conversion. A curved ramp reads differently. It suggests acceleration, a path that steepens, a descent that isn’t uniform. The ball didn’t just move from high to low; it rolled, and the curve implies it picked up speed on the way down.

That’s the part I find genuinely well-observed. The joke isn’t “I wasted my potential.” The joke is “my potential converted into motion, and the motion went downhill, and here I am at the bottom, solid and stationary.” The curve is what makes it a physics joke rather than a motivational poster. A straight line would be too tidy. The curve admits that the descent had its own momentum.

I should be careful here: I’m reading the drawing, not claiming the designer ran the numbers. There’s no axis, no units, no coefficient of friction. The curve is a visual choice, and I’m interpreting it. But the choice is legible, and it’s the reason the shirt works better than a plain text gag.

What the sentence does that the diagram can’t

Flip it around. The diagram alone — dashed circle, curved ramp, solid ball — is just a physics sketch. It could be a textbook figure. It could be a loading spinner with ambitions. Without the caption, there’s no joke, because there’s no self in it.

The caption supplies the self, and the past tense supplies the regret. I had potential is a sentence about a person, not a particle. The diagram supplies the mechanism; the sentence supplies the narrator. Together they make a small, complete argument: here is the shape of what happened to me, and here is the tense I use to describe it.

That’s a more interesting object than a slogan. A slogan asserts. A diagram plus a caption demonstrates. The shirt isn’t telling you the wearer is a failure; it’s showing you a little model of how potential becomes a solid ball at the bottom of a curve, and letting you decide whether to laugh.

Why this reads as a work-culture object

I’ve spent enough years in engineering orgs to recognize the feeling the shirt is drawing. Potential is the word managers use in performance reviews and the word engineers use about themselves in the quiet parts of the week. It’s a future-tense word. It’s supposed to be unrealized — that’s what makes it potential.

The shirt’s joke is that the future tense expired. The dashed circle is the version of you that was going to ship the big project, learn the new stack, write the RFC that fixed the process. The solid ball is the version that is currently sitting on a flat ledge, which is to say: a person with a job, a backlog, and a Tuesday.

I don’t think the shirt is cruel about this. The minimalist execution helps. White on white, no color, no exclamation point. It’s not shouting I peaked. It’s a quiet diagram of a conversion, worn by someone who finds the conversion funny enough to put on a shirt. That’s a specific and recognizable posture: self-aware, a little tired, not asking for sympathy.

The difference between a slogan and a usable promise

Here’s the argument I actually want to make, and it’s the reason I think this design is worth a column rather than a caption.

A slogan is a claim with the mechanism removed. I had potential as plain text is a slogan: it asserts a state, and you either agree or you don’t. The diagram puts the mechanism back. It says: here is the ramp, here is the dashed outline, here is the solid ball, here is the curve. You can look at the mechanism and form your own view. That’s the difference between a promise and a diagram — a promise asks for trust, a diagram asks for reading.

I think that’s why the shirt lands for technical readers in particular. We spend our working lives preferring diagrams to assertions. A runbook that says “the service is healthy” is a slogan. A runbook that shows the check, the threshold, and the fallback is a diagram. The shirt is a tiny, wearable version of the second thing: it doesn’t tell you the wearer’s whole story, it shows you the shape of it and lets the curve do the talking.

What I’d change, and what I wouldn’t

If I were redrawing it, I’d be tempted to add a small arrowhead on the ramp, just to make the direction unambiguous. But I think that would be a mistake. The absence of an arrow is part of the restraint — the curve already implies direction, and adding an arrow would push the design from diagram toward infographic. The shirt is better as a sketch than as a slide.

What I wouldn’t change is the past tense. I have potential would be a different shirt entirely — hopeful, forward-looking, and much less interesting. The past tense is the whole joke. It’s the tense of a closed account.

The artifact: a five-line reading checklist

If you’re the kind of person who likes a reusable tool, here’s a small one for reading diagram-and-caption objects like this. It’s the checklist I used above, and you can apply it to a sticker, a mug, a conference shirt, or a whiteboard doodle.

1. Name the literal marks. What shapes are drawn, where are they, and what state does each one imply? (Dashed vs. solid, high vs. low, curved vs. straight.)
2. Name the tense. Is the caption past, present, or future? The tense tells you whether the diagram is a memory, a status, or a plan.
3. Find the mechanism. What does the drawing show that the words don’t say? That gap is usually where the meaning lives.
4. Check the restraint. What’s not drawn? Missing arrows, missing labels, and missing color are editorial choices, not omissions.
5. Separate interpretation from claim. Say what you see, then say what you think it means. Don’t let the second borrow the authority of the first.

That last line is the one I’d underline. The shirt doesn’t prove anything about physics, careers, or the wearer’s actual history. It’s a drawing and a sentence, and the drawing is good enough to reward a close look. That’s all it needs to be.

Editorial note: This publication and Quirky Cotton Collective share an owner.

Most RFC processes don’t fail because the template is wrong. They fail because nobody wrote down when comments close, nobody is accountable for the outcome, and the whole thing ends in a meeting where the loudest voice in the room wins by default.

The document was never the problem. The missing mechanics were.

Three mechanics make an RFC process decide instead of circulate. They are separable, and you can adopt them in order of cost. Adding a review-close date to the header costs nothing. Naming a decision owner costs one line. Defaulting to asynchronous review is the only one that requires a cultural change, so it should come last.

Two jobs people keep conflating

An RFC does two things, and teams routinely blur them:

• Collecting feedback. Anyone affected gets a chance to raise concerns, surface prior art, and point out what the author missed.
• Making a decision. Someone states what will happen, why, and when.

Phil Calçado’s write-up of a structured RFC process is explicit that these are not the same activity. Feedback is informational: authors are free to incorporate it or not. And the process he describes requires authors to acknowledge every piece of feedback given, so reviewers don’t feel their time was wasted. He also states the part teams skip: whatever feedback-gathering process you adopt, you must explicitly acknowledge who the decision maker is — the person accountable for the outcome, with veto power over it.

That’s the whole game. Feedback without a decision owner is a suggestion box. A decision owner without a comment deadline is a bottleneck with no exit condition.

Mechanic 1: A comment deadline in the header

The Attentive engineering team’s account of rebuilding their RFC process names the failure mode directly: a document that never leaves draft status creates ambiguity about when feedback is expected. Their fix is to time-box the review period, with a clear opening and closing window. They suggest one week as a default for a medium-sized RFC, expanding or shrinking with scope and complexity.

Treat that week as a starting point, not a rule. The mechanic is the visible close date, not the specific number.

The deadline only works if it lives in the document header. If a reader has to scroll a comment thread to find out when feedback is due, the deadline isn’t doing its job.

Before

# RFC: Cursor pagination for /v2/orders

Author: Priya Anand
Status: Draft

After

# RFC: Cursor pagination for /v2/orders

Author: Priya Anand
Decision owner: Marcus Webb
Review closes: 2026-11-06 (end of day, UTC)
Status: In Review
Revisit: 2027-02-06

Two rules keep the deadline honest:

• Feedback after close becomes an addendum, not a blocker. The Attentive post states that post-closure changes should be captured as addendums to preserve decision history. This is the difference between a process that closes and a process that reopens every time someone reads the doc late.
• Extensions are announced, not assumed. If the review genuinely needs more time, the decision owner moves the date and says so in the document. Silent slippage is how perpetual drafts are born.

Mechanic 2: One named decision owner

Naming a decision owner is not the same as naming approvers. An approver can block. A decision owner must also state what happens next. If your header lists three approvers and no owner, the RFC has no exit condition — it has three exit conditions, which is zero.

Calçado’s framing is worth quoting in full because it’s the sentence most teams need to paste into their process doc: the decision maker is “the one accountable for the outcome and with veto power over it.”

The Attentive post puts the same idea in lifecycle terms: authors own the outcome and are empowered to accept or reject feedback and move the proposal forward. Reviewers offer perspectives, not arguments. The goal is not to win a debate.

What the decision owner actually does, concretely:

• Acknowledges every comment. Not every comment needs a change. Every comment needs a response, even if the response is “considered, not adopted, because X.”
• States the outcome on the close date. Approved, changes requested, or blocked — with a reason. Silence is not a decision.
• Owns the revisit date. Calçado’s header format includes a revisit date alongside the review date, and the process requires authors to commit to revisiting the decision later and sharing what they learned.

One caution: a named decision owner does not eliminate disagreement, and it does not guarantee adoption. It makes accountability legible. That’s the whole benefit, and it’s enough.

Mechanic 3: The meeting you skip

Default to asynchronous review. The Attentive post is direct about this: RFCs should default to asynchronous review to allow thoughtful feedback, and meetings are valuable when discussion stalls or complex trade-offs need real-time alignment.

That’s a narrower trigger than most teams use. The meeting you skip is usually a status meeting wearing a design-review costume.

A useful test before you book the room: can the open question be answered by one person reading the document for ten minutes? If yes, it’s a comment, not a meeting.

When a meeting is genuinely warranted, the same source sets three conditions:

• Ask participants to read the document beforehand.
• Set a concrete agenda.
• Link the meeting directly in the RFC so observers can opt in.

If you can’t write the agenda as a list of open questions with named owners, you don’t have a meeting. You have a calendar block.

Status vocabulary small enough to memorize

Perpetual drafts are a status problem. The Attentive process uses five states, and five is enough for most teams:

• Draft — initial writing; early feedback may be solicited once the design is structurally complete.
• In Review — ready for broad feedback and active discussion.
• Changes Requested — serious concerns must be addressed before approval.
• Approved / Closed — review complete; comments are no longer blocking.
• Blocked / Discarded — review surfaced major issues or blocking requirements.

Adding a sixth state usually means the team is encoding an org chart into a document header. Resist.

Keep the record immutable after the decision

Comment deadlines and immutability solve different problems, and merging them breaks both. The deadline governs when input is welcome. Immutability governs what happens to the record afterward.

AWS Prescriptive Guidance on architectural decision records states the rule plainly: when the team accepts an ADR, it becomes immutable; if new insights require a different decision, the team proposes a new ADR, and accepting the new one supersedes the previous. The AzureLocal platform’s ADR process adds the operational detail: accepted ADRs are immutable except for corrections to the Status field when superseded, and you don’t silently edit an accepted ADR — you write a new one that supersedes it.

This is where RFCs and ADRs complement each other rather than compete. An RFC is a proposal under review with a closing window. An ADR is the durable record of a decision that was made. The ADR GitHub organization defines an ADR as capturing a single architectural decision and its rationale, with the collection of ADRs in a project constituting its decision log. AWS’s guidance says at minimum each ADR should define the context of the decision, the decision itself, and the consequences — and notes that the structure focuses on the reason for the decision rather than how the team implemented it.

Practical division of labor for a 20–200 person engineering org:

• RFC — used when a change extends beyond one team, when the blast radius is large, or when you want structured early feedback from people you don’t work with daily.
• ADR — written once the decision is made, numbered, immutable, stored close to the code. Google Cloud’s ADR guidance recommends storing ADRs close to the application code, ideally in the same version control system, and notes they help teams avoid repeating the same discussion points.

Don’t write an ADR for a typo fix. Don’t write an RFC for a decision that only affects your own service and has no cross-team contract implications.

The artifact: a header block and a five-line process note

This is the part you can paste into your repo today. It is a header block plus a short process note — not a policy document. Anything longer will not be read by the people who need it most.

RFC header block

# RFC: <title>

Author: <name>
Decision owner: <name>
Review closes: <YYYY-MM-DD> (end of day, UTC)
Status: Draft | In Review | Changes Requested | Approved | Blocked
Revisit: <YYYY-MM-DD>

## Problem
## Proposal
## Alternatives considered
## Open questions

Process note

1. The decision owner is accountable for the outcome and has veto power.
2. Review closes on the date in the header. Feedback after close becomes an addendum.
3. Every comment gets an acknowledgment, even if the answer is "not adopted."
4. Review is asynchronous by default. Schedule a meeting only if discussion stalls
   or trade-offs need real-time alignment — with pre-reading and an agenda.
5. Once decided, the record is immutable. Supersede it; don't edit it.

A worked shape, not a war story

Here’s the shape the process should produce. It’s a hypothetical, but it’s the one you’ll recognize.

A team writes an RFC proposing a new pagination scheme for a public API. The header lists the author, a decision owner, and a review window closing in five business days. Two reviewers raise concerns about cursor stability under concurrent writes. The decision owner acknowledges both, accepts one, rejects the other with a stated reason, and closes the RFC on the stated date. No meeting is scheduled.

That outcome requires no tooling beyond a header block. It requires no bot, no template repository, no governance committee. It requires three lines and the discipline to honor them.

What to change this week

Before you touch the template, add two lines to the next RFC you write: a review-close date and a named decision owner. Then honor the date.

If you want to go further, add the revisit date. Calçado’s process requires authors to commit to revisiting the decision later and sharing what they learned — which is the only mechanism in this whole process that produces evidence about whether the decision was any good.

FAQ

What if nobody comments during the review window?

Silence is not approval, but it is also not a reason to extend indefinitely. The decision owner states the outcome on the close date and notes that no blocking feedback was received. If the decision turns out to be wrong, the revisit date is where you find out.

Can the decision owner also be the author?

Often, yes. The Attentive process treats authors as owning the outcome. The failure mode to avoid is a header with multiple approvers and no single accountable person — that’s the configuration with no exit condition.

How is this different from just writing an ADR?

An ADR records a decision that was made. An RFC is the review process that precedes it. AWS’s guidance describes ADRs as immutable once accepted, with changes requiring a new superseding ADR. If you only write ADRs, you skip the feedback window entirely. If you only write RFCs, you lose the durable decision log.

Do we need tooling for this?

No. A Markdown file in the repo with a header block works. Google Cloud’s ADR guidance recommends storing decision records close to the application code, ideally in the same version control system. The same applies to RFCs. A bot that announces new RFCs is a convenience, not a requirement.

What about RFCs that genuinely need more than a week?

Extend the window and say so in the document. The Attentive process describes the review period as expanding or shrinking based on scope and complexity. The point is that the close date is visible and the extension is announced, not that a specific duration is correct.

Should we use RFC 2119 keywords like MUST and SHOULD in internal RFCs?

Be careful. RFC 2119 defines those keywords for standards-track documents, and it explicitly states that imperatives of this type must be used with care and sparingly — only where actually required for interoperation or to limit behavior with potential for harm. Internal design docs rarely meet that bar. Plain prose is usually clearer.

Sources

• Phil Calçado, A Structured RFC Process — decision owner accountability, feedback as informational, acknowledgment requirement, header format with review and revisit dates.
• Attentive Engineering, A Pragmatic RFC Process for Teams — time-boxed review windows, status lifecycle, asynchronous-first review, addendums for post-closure changes.
• AWS Prescriptive Guidance, Using architectural decision records to streamline decision-making during development — ADR immutability, supersession, minimum required sections.
• Google Cloud Architecture Center, Architecture decision records overview — storage close to code, avoiding repeated discussions.
• ADR GitHub organization, adr.github.io — definition of an ADR and the decision log.
• AzureLocal platform, ADR process — numbering rules, immutability of accepted ADRs, supersession workflow.
• S. Bradner, RFC 2119: Key words for use in RFCs to Indicate Requirement Levels — definitions and guidance on sparing use of imperatives.

There is a specific kind of visual joke that works because it refuses to explain itself. The Composition Notebook Costume Teacher Group Halloween shirt is one of those. At first glance, it reads as a black-and-white speckled rectangle with a dark binding strip down the left side. A white ruled label sits near the top, headed with the word COMPOSITION. Inside the label, an outlined ghost and pumpkin float in the space where a student’s name would normally go. The whole thing is a printed notebook cover, not a physical notebook. That distinction matters more than it might seem.

Editorial note: This publication and Quirky Cotton Collective share an owner. This is not an independent review.

I keep coming back to this design because it does something that most slogan shirts do not: it treats a familiar object as a complete visual argument. There is no text beyond the label heading. There is no punchline. The ghost and pumpkin are not explained. The shirt assumes you already know what a composition notebook is, what it looks like, and why someone might wear one as a costume. That assumption is the joke, and it is also the design’s biggest risk.

What the artwork actually shows

Let me describe the observed design precisely, because the details are where the meaning lives. The main body of the graphic is a speckled black-and-white field, the kind of noise pattern that appears on the covers of cheap marble composition books sold in bulk every August. A dark strip runs down the left edge, representing the taped binding. Near the top center, a white rectangle with thin ruled lines mimics the label area. The word COMPOSITION is printed in a plain, slightly condensed sans-serif, all caps. Below that heading, inside the label, there is an outlined ghost and an outlined pumpkin. Both are simple line drawings, no fill, no shading. The ghost has two eyes and a wavy bottom edge. The pumpkin has a stem and a few vertical ribs.

That is the entire graphic. There is no additional text, no school name, no year, no teacher’s name. The design relies on recognition: you see the notebook cover, you see the Halloween elements, and you connect the two. The connection is not spelled out. It is not a slogan. It is a visual substitution.

Why the notebook cover works as a costume

The composition notebook is one of the few objects that almost everyone in the United States has handled. It is cheap, ubiquitous, and associated with school supply shopping, note-taking, and the beginning of a semester. As a costume, it is almost aggressively plain. You are not dressing as a character. You are dressing as a surface. That is the joke, and it is a good one because it inverts the usual logic of a costume shirt. Most costume shirts show a picture of a thing. This one is the thing, printed flat.

The ghost and pumpkin are doing specific work here. Without them, the shirt would just be a notebook cover. With them, it becomes a notebook cover that has been decorated for Halloween. That is a small but important shift. The design is not saying “I am a notebook.” It is saying “I am a notebook that someone drew on.” The outlined ghost and pumpkin look like they were drawn with a marker, not printed as part of the original cover. They sit inside the label area, which is exactly where a student might write their name or doodle during a boring class. The design treats the label as a canvas within a canvas.

The difference between a slogan and a usable promise

I have written before about the difference between a slogan and a usable promise. A slogan is a phrase that sounds good but does not commit you to anything. A usable promise is a statement that tells you what to expect and what to do when expectations are not met. This shirt is not a promise. It is a recognition test. It asks you to identify the object and understand the joke. If you do, you are in. If you do not, you see a speckled rectangle with a ghost on it.

That is not a flaw. It is a design choice. The shirt is not trying to convert anyone. It is trying to signal membership in a group that already knows what a composition notebook looks like and why it might be funny to wear one. The signal is quiet. It does not shout. It does not explain. It just sits there, being a notebook cover, waiting for someone to notice.

What the design does not claim

I want to be careful here. The shirt does not claim that teachers are notebooks. It does not claim that Halloween is about school supplies. It does not claim that ghosts and pumpkins are related to composition books in any historical or scientific sense. The design is a visual pun, and puns do not need to be true. They need to be recognizable. The ghost and pumpkin are recognizable as Halloween symbols. The notebook cover is recognizable as a school supply. The combination is recognizable as a costume idea for a group of teachers who want to match without wearing the same printed slogan.

That last point is worth dwelling on. The retail title includes the phrase “Teacher Group Halloween.” That is not a claim about who wears it. It is a description of the use case the design supports. A group of teachers could wear this shirt together and be immediately identifiable as a group. The design does not require anyone to explain it. The notebook cover does the work. The ghost and pumpkin add the seasonal element. The group aspect comes from repetition: multiple people wearing the same visual object.

Reading the label as an interface

I spend a lot of my professional life thinking about interfaces. Not just software interfaces, but the surfaces where two systems meet and exchange information. A composition notebook label is an interface. It has a designated area for a name. It has a heading that tells you what the object is. It has rules that guide your writing. The shirt takes that interface and replaces the expected content with something unexpected: a ghost and a pumpkin instead of a student’s name.

That substitution is the entire design. It is a small act of vandalism, the kind of thing a bored student might do in the margin of a notebook. The shirt is not a notebook. It is a notebook that has been drawn on. That is a meaningful difference. The first is an object. The second is an object with a history. The ghost and pumpkin imply that someone was there, that someone made a mark, that the notebook was used. The design does not show the student, but it shows the evidence of the student.

Why this matters for a work-culture column

I write about API contracts, runbooks, and team practices. I write about the specific ways that systems fail when the people who maintain them rotate out. I write about the difference between documentation that exists and documentation that works. This shirt is not about any of those things directly. But it is about a related idea: the value of a shared reference.

A composition notebook is a shared reference. Almost everyone in a certain age range and country has used one. That shared reference is what makes the shirt legible. Without it, the design is just a speckled rectangle. With it, the design is a joke that lands in under a second. The same is true of good internal documentation. It relies on shared references that new team members may not have. It assumes a context that may not exist. The shirt does not have that problem because it is not trying to onboard anyone. It is trying to signal to people who already know.

That is a useful distinction for anyone who writes documentation. Are you writing for people who already know, or are you writing for people who need to learn? The shirt is for the former. Most runbooks are for the latter. Confusing the two is how you end up with documentation that assumes too much or explains too little.

The ghost and pumpkin as a boundary marker

One more observation. The ghost and pumpkin are outlined, not filled. They are simple line drawings. They do not dominate the label. They sit inside it, taking up maybe a third of the available space. The rest of the label is empty, ruled, waiting. That emptiness is important. It leaves room for the viewer to complete the joke. The design does not fill in every detail. It gives you the notebook cover, the heading, and two small drawings. You do the rest.

That is a boundary. The design knows what it is and what it is not. It is not a detailed illustration. It is not a slogan. It is not a costume that requires explanation. It is a notebook cover with a ghost and a pumpkin. That is enough. The restraint is what makes it work.

If you are looking for a group costume that does not require matching shirts with printed jokes, this is a reasonable option. It is a composition notebook shirt that reads as a costume without being loud about it. The design is specific, the reference is shared, and the joke is quiet. That is a combination that does not always work. Here, it does.

There is a particular kind of confidence in a shirt that says almost nothing. The native garment preview for the Meh Funny Sarcastic Introvert Minimalist Saying shirt shows very small, centered lowercase meh. lettering on a dark background. No animal illustration. No decorative frame. No exclamation point. The period is there, and it does a lot of work.

I want to read that design closely, because the scale and the punctuation are not incidental. They are the argument.

What the artwork actually shows

The observation is narrow and worth stating plainly: a dark shirt, a centered word, lowercase, followed by a period. The word is small relative to the printable area. There is no accompanying graphic. The retail title mentions introvert and minimalist, but the visual evidence is just the word and the mark after it.

That gap between the title and the artwork is interesting. The title supplies a category — introvert, sarcastic, minimalist — but the design does not illustrate any of those things. It performs one of them. The shirt does not show a person avoiding a party. It does not show a cartoon cat with a deadpan face. It shows a word that has been reduced to its smallest functional form and then given a full stop.

Why the period matters more than the word

“Meh” on its own is a shrug. It is a sound, a mood, a non-answer. It floats. It can be read as playful, tired, indifferent, or all three at once. The period changes the register. A period is final. It closes the sentence. It says: this is the whole message, and I have finished delivering it.

In writing for engineers, we talk a lot about error responses and status codes. A 200 with an empty body is ambiguous. A 204 says something specific: success, no content. The period on this shirt functions a little like that. It is not decoration. It is a terminator. It tells you the sentence is over and there is no follow-up coming.

That is a different posture from most sarcastic slogan shirts. The typical version is loud. It uses a big font, a punchline, maybe an arrow or a face. It wants to be read across a room. This one does not. The small lowercase type means you have to be close to read it. The period means that once you have read it, you are done. There is no second joke.

The difference between a slogan and a usable promise

I spend a lot of time thinking about interface contracts — the words and signals that tell another person what to expect from a system. A slogan and a contract are not the same thing. A slogan is designed to be memorable. A contract is designed to be actionable. The best slogans borrow from contracts anyway, because they set a boundary and then stop.

This shirt is closer to a boundary than a joke. It does not say “I hate people.” It does not say “leave me alone.” It says “meh.” That is a low-stakes, low-energy signal. It does not demand anything from the reader. It does not promise warmth or hostility. It just marks a position: present, unenthusiastic, not currently recruiting for additional conversation.

That is a useful thing to be able to signal without saying it out loud. In team settings, we often ask people to over-explain their state. Are you blocked? Are you tired? Are you frustrated? Are you fine? A shirt that says “meh.” is not a substitute for a real conversation, but it is a legible signal. It is the visual equivalent of a status page that reads “degraded performance” instead of “all systems operational.”

Minimalism as a design constraint, not a style

The retail title calls this minimalist, and the artwork supports that. But minimalism here is not just an aesthetic choice. It is a constraint that forces every element to carry weight. When you remove the illustration, the color, the extra words, and the exclamation point, what remains has to justify itself. The lowercase meh. does that by being small, centered, and punctuated.

I have seen a lot of minimal designs that feel empty rather than deliberate. They remove things without replacing them with meaning. This one works because the word itself is already a reduction. “Meh” is what you say when you cannot be bothered to say more. Putting it in small type on a dark shirt is not adding minimalism to a complex idea. It is matching the form to the content.

If you were designing a system message with the same principle, you would not write a paragraph explaining that the service is operating within normal parameters but with reduced enthusiasm. You would write 200 OK and let the absence of further detail be the point. That is not laziness. It is respect for the reader’s attention.

What this shirt is not

It is not an animal design. The observation explicitly notes that no animal illustration is present. That matters because the “meh” shirt category has a lot of variants — cats, sloths, frogs, bears — and this one strips all of that away. It is also not a pride variant. The design does not use rainbow colors or identity language. It is a single word on a dark background.

That narrowness is worth respecting. It means the shirt does not rely on a mascot or a movement. It relies on typography and tone. If you are the kind of person who likes a design that does not explain itself, this is that design.

Who this is for, and who it is not

This is for someone who wants to signal a low-energy, low-drama presence without being rude. It is for the person who has been asked one too many times how they are doing and would like a shirt that answers the question in advance. It is for the engineer who appreciates a message that is short, lowercase, and final.

It is not for someone who wants a laugh from across the room. It is not for someone who wants a design that starts a conversation. It is not for someone who needs the joke to be obvious. The small type and the period are working against all of that. They are asking you to lean in, read the word, and then move on.

That is a specific kind of social contract. It says: I am here, I am not enthusiastic, and I am not going to pretend otherwise. The period is the part that makes it honest. Without it, the word is just a mood. With it, the word is a statement.

The artifact: a one-line status template

If you want to adapt the spirit of this design to your team’s communication, try a one-line status update that follows the same rules: lowercase, short, punctuated, no follow-up required. Something like:

meh. working through the backlog, no blockers, will surface anything urgent.

The point is not to be cute. The point is to give your teammates a signal that is easy to read and easy to trust. The period at the end tells them the message is complete. They do not need to ask a follow-up question. They can move on.

That is what the shirt does, too. It is a small, dark, lowercase message that ends with a period. It does not ask for anything. It just tells you where it stands.

Editorial note: This publication and Quirky Cotton Collective share an owner. This is not an independent review.

You can find the shirt here: Meh Funny Sarcastic Introvert Minimalist Saying.

There is a yellow caution triangle on this shirt. Inside or beside it, a hand is crossed out. Above it, in the flat, declarative lettering of a public warning sign, the words read: NOT FRIENDLY DO NOT TOUCH. The design is not subtle. It borrows the visual grammar of a hazard placard — the triangle, the prohibition, the all-caps imperative — and applies it to a person.

That borrowing is the interesting part. A warning sign is a compressed interface. It has to communicate a rule, a consequence, and a scope in the time it takes someone to walk past it. Not friendly is the state. Do not touch is the instruction. The crossed-out hand is the affordance that has been removed. The triangle is the severity marker. Four elements, one message, no ambiguity about what the reader is supposed to do next.

Most slogans on shirts are not contracts. They are vibes. They gesture at an attitude and leave the enforcement mechanism unspecified. This one is different in kind, not just in tone. It reads like a response header.

What the artwork actually specifies

I want to be careful here, because it is easy to over-read a graphic. The visual observation is literal: warning-sign lettering, a yellow caution triangle, a crossed-out hand symbol. That is what is printed. Everything beyond that is interpretation, and I should mark where the line is.

What the design does specify, as a piece of visual communication:

• A named state. “Not friendly” is not a mood. It is a declared condition, present tense, no hedging.
• A prohibited action. “Do not touch” is an imperative aimed at the reader, not a description of the wearer.
• A severity signal. The caution triangle is the same shape used on wet-floor signs and electrical panels. It says: this is not a joke you are meant to ignore.
• A removed affordance. The crossed-out hand is the visual equivalent of a disabled button. The action exists in the world; it is simply not available here.

That is a surprisingly complete specification for something you wear. It has a precondition, an instruction, and a scope. What it does not have — and this is where the analogy gets useful — is a recovery path.

The missing 4xx body

When I review API contracts, the failure mode I see most often is not a missing error. It is an error that tells you that something went wrong without telling you what to do instead. A bare 403 with no body. A 429 with no Retry-After. The client knows it was rejected and has no idea how to proceed.

The shirt has the same shape. Do not touch is a rejection. It is clear, it is enforceable, and it offers no alternative. There is no “try email instead.” There is no “approach at a distance of two meters.” There is no “wait until I have had coffee.” The interface is closed.

I do not think that is a flaw in the design. I think it is the point. The whole reason the joke lands is that most social interaction comes with an implicit retry policy — you smile, you try again, you find the right opening. This shirt removes the retry policy. It is a hard stop, and the humor comes from how rarely we see one stated plainly.

But it is worth noticing what a hard stop costs. In an API, a rejection with no recovery path generates support tickets. In a person, a boundary with no recovery path generates… well, it depends on whether the boundary is the goal or the side effect.

Boundary versus slogan

Here is the distinction I keep coming back to. A slogan is a claim about identity. A boundary is a claim about behavior. They look similar on a shirt and they function very differently.

“Introvert” is a slogan. It describes a preference. It does not tell you what to do. You can read it and continue exactly as you were.

“Do not touch” is a boundary. It is an instruction with a compliance condition. Reading it and continuing as you were is now a violation, not just a misread.

The shirt combines both — the listing calls it an introvert design, and the artwork is a prohibition — and that combination is what makes it more than a novelty. It is not saying “I am tired.” It is saying “here is the rule.”

Most team communication lives in the promise zone: we value quality, we prioritize reliability, we care about documentation. None of those are enforceable. None of them tell you what happens when they are violated.

A shirt that says do not touch is closer to a contract. It is terse, it is specific, and it does not pretend to be flexible. Whether that is a good thing depends entirely on whether the wearer means it.

Why the caution triangle matters more than the words

The lettering could stand alone. Not friendly, do not touch in plain text would still communicate the message. The triangle adds something the words cannot: a category.

Caution triangles are not used for opinions. They are used for hazards. They appear on chemical containers, on high-voltage equipment, on wet floors. The shape carries an institutional weight that the words alone do not. By borrowing it, the design moves the message out of the realm of personal preference and into the realm of public safety signage.

That is a deliberate rhetorical move, and it is the same move engineers make when they wrap a business rule in a standard error format. You could return {"error": "you can't do that"}. Or you could return a 403 with a typed problem document. The second one borrows the authority of the standard. It says: this is not my personal whim, this is a recognized category of refusal.

The triangle does that for the shirt. It converts a preference into a policy.

The crossed-out hand as a disabled affordance

I keep thinking about the hand. A crossed-out symbol is a specific kind of visual statement. It does not say the thing is dangerous. It says the thing is not permitted. There is a difference between “this will hurt you” and “this is not allowed.”

The crossed-out hand is the second one. It is a rule, not a warning about consequences. The triangle supplies the severity; the hand supplies the prohibition. Together they form a complete instruction: this is serious, and this specific action is off the table.

In interface terms, this is a disabled control with a tooltip. The button is greyed out, and if you hover, you get a reason. The reason here is “not friendly.” It is not a great reason by the standards of error message design — it explains the state, not the remedy — but it is honest about what it is.

What I would actually take from this

I am not going to pretend this shirt is a lesson in API design. It is a piece of clothing with a joke on it. But the joke is well-constructed, and the construction is worth noticing because it is the same construction we use when we write contracts.

The useful observation is this: a boundary that does not specify a recovery path is a boundary that will be tested. Not because people are malicious, but because most interaction assumes a retry. If you want a hard stop to hold, you have to make the stop legible — and legibility comes from borrowing forms people already recognize.

The caution triangle is legible. The crossed-out hand is legible. The all-caps imperative is legible. Whatever else the shirt is doing, it is not being ambiguous about its terms.

If you want to see the design for yourself, it is listed here: Not Friendly Do Not Touch Funny Warning Sign Introvert.

Editorial note: This publication and Quirky Cotton Collective share an owner.

Editorial note: This publication and Quirky Cotton Collective share an owner.

I keep a folder of slogans that look like promises and read like contracts. Most of them fail the same way: they ask for a feeling and deliver a demand. The shirt I am looking at today is a rare exception, and I want to explain why the artwork does the work that the words alone would not.

The design is a ring of text — LET’S ROOT FOR EACH OTHER AND WATCH EACH OTHER GROW — wrapped around four smiling root vegetables: a carrot, a radish, a beet, and an onion, each with its roots visible in soil. That is the whole graphic. No tagline underneath, no brand mark, no extra flourish. The composition is a closed loop, and the loop is the argument.

Two meanings of ‘root,’ and why the artwork picks both

In English, root is a contranym in context. To root for someone is to support them from the sidelines. To put down roots is to stay, to anchor, to become part of a place. The slogan uses the first sense. The vegetables use the second. The pun only lands because the illustration refuses to choose.

That is not a small design decision. If the shirt had shown only a cheerleader-style megaphone or only a seedling, the joke would collapse into one meaning. By drawing the roots — the actual underground structures, not just the leafy tops — the artwork makes the metaphor literal. The carrot is not just a mascot for encouragement; it is a plant that has committed to a location. The onion is not just a bulb with a face; it is a storage organ that survives winter.

I read this as a quiet correction to the usual growth slogan. Most workplace and team-culture graphics treat growth as the goal and support as the means. This one treats support and growth as two things you do at the same time, in the same soil. The roots are not a reward for growing. They are the condition that makes growing possible.

What the smiling faces actually communicate

The vegetables are smiling. That matters more than it sounds. A root vegetable with a neutral expression would read as a diagram. A root vegetable with a smile reads as a participant. The design gives each one the same simple face — two dot eyes, a curved mouth — which flattens hierarchy. The beet is not more important than the radish. The onion is not the leader. They are a set.

I have seen enough team graphics to be suspicious of anything that looks like a forced grin. This one avoids that trap because the smiles are small and the roots are detailed. The visual weight is in the soil, not the faces. The message is not be happy. It is be planted together.

If you are the kind of person who writes runbooks and reviews API contracts, you already know the difference between a slogan and a usable promise. A slogan says we value collaboration. A usable promise says here is the escalation path, here is the last-verified date, here is what happens when the pager fires at 3 a.m. This shirt is a slogan, but it is a slogan with a diagram. The diagram is the part I trust.

The ring composition as a boundary

The text wraps around the vegetables in a circle. That is a common layout choice, but it does something specific here: it encloses the group. Nothing enters or leaves the ring. The four vegetables are not growing outward into a wider market; they are growing downward into shared ground.

I find that useful as a mental image for team boundaries. A lot of engineering culture talk treats growth as expansion — more services, more surface area, more headcount. The ring says: the unit is the group, and the group has an edge. You can root for each other without rooting for infinite scope.

That is the argument I would make if someone asked me why this design works. It is not just cute. It is a small visual contract about what mutual support looks like when it is bounded and specific rather than vague and total.

Where the shirt fits, and where it does not

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. The artwork is the point. I am not going to pretend it demonstrates anything about software, security, or engineering outcomes. It is a gardening and mutual-growth pun, and it is honest about being one.

What I would say to a technical reader is this: if you are going to wear a slogan, wear one that has a diagram in it. The diagram gives you something to point at when someone asks what you mean. Root is ambiguous. The roots are not. The smiling vegetables are not. The ring is not.

That is the whole review. The shirt is a small, well-composed argument about support and growth happening in the same place. I would rather read that than another poster that says synergy.

Your API has an error contract. It is written down. It has a problem+json media type, a Retry-After header, and a webhook signature scheme. And almost nobody has watched a real client hit it under load.

The first time a client sees a genuine 429 with a long Retry-After, or a response body that stops mid-JSON, is usually during an incident. That is a bad time to discover that the retry logic ignores the header, the parser throws an unhandled exception, or the webhook handler compares signatures with ==.

A game day fixes the timing. It is a scheduled, controlled exercise where you inject the failure modes your contract already promises, then watch how your own clients, docs, and runbooks behave. The point is not to prove you can survive chaos. The point is to find the gap between what you published and what you actually built.

Why a game day is a contract test, not a stress test

Stress tests ask whether the system stays up. Game days ask whether the contract stays true. Those are different questions, and the second one is usually neglected.

RFC 9457 defines a problem detail format for carrying machine-readable error details in HTTP responses, specifically so APIs do not need to invent their own error format. It notes that problem details most naturally fit 4xx and 5xx responses, though they can be used with any status code. If you have adopted that format, you have a concrete shape to assert against.

RFC 9110, the HTTP semantics specification, is equally useful here. It says recipients should parse received protocol elements defensively, with only marginal expectations that they conform to grammar or fit a reasonable buffer size. That is a direct instruction to your clients: do not assume the body is well-formed. A game day is how you check whether they listened.

The exercise is narrow by design. You pick faults that map to clauses you already publish. If your contract does not say what happens on a 429, injecting one teaches you less than fixing the contract first.

Pick faults that correspond to written contract clauses

Start with the failures your documentation already describes. If a fault is not covered by a contract clause, either the contract is incomplete or the fault is out of scope for this exercise.

429 with Retry-After

RFC 9457 says a problem type definition may specify the use of the Retry-After response header in appropriate circumstances. It does not mandate a retry policy, a backoff algorithm, or a specific rate-limit header set. That means the behavior is yours to define and yours to test.

Inject a 429 with a Retry-After value that is long enough to be inconvenient. Watch whether clients honor it or hammer the endpoint. Watch whether the error body is a valid problem detail or a bare string.

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 120

{
  "type": "https://api.example.com/problems/rate-limit",
  "title": "Rate limit exceeded",
  "status": 429,
  "detail": "You have exceeded the request quota for this endpoint.",
  "instance": "/requests/abc123"
}

The key lines to assert on are the Content-Type, the Retry-After value, and the presence of a resolvable type URI. RFC 9457 recommends that a problem type URI resolve to HTML documentation explaining how to resolve the problem. If your type URI 404s, that is a doc bug you can file the same day.

Truncated response bodies

A truncated body is not a valid problem detail. It is a partial JSON object, a cut-off string, or an empty response with a 200 status. RFC 9110’s guidance to parse defensively is the contract clause here: clients should not assume the body is complete or well-formed.

Inject a response that stops mid-object. Watch whether the client throws a parse error, retries, or silently treats the partial data as valid. The last outcome is the dangerous one.

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 512

{
  "id": "ord_123",
  "status": "shipped",
  "items": [
    {"sku": "ABC", "qty": 2},
    {"sku": "DEF", "qty": 1}
  ],
  "tracking": "1Z999AA10123456784"
  // connection closes here

The client should detect that the JSON is incomplete. If it does not, you have found a real bug without waiting for a network partition to expose it.

Malformed webhook signatures

Webhook verification is a contract with a specific, testable shape. GitHub’s documentation describes the pattern clearly: GitHub uses your secret token to create a hash signature sent in the X-Hub-Signature-256 header on each delivery. The signature is an HMAC hex digest computed from the secret and the payload contents.

GitHub also recommends comparing the computed and received signatures with a constant-time comparison rather than a plain equality operator. The docs explicitly say never to use a plain == operator, and to consider methods like secure_compare or crypto.timingSafeEqual to mitigate timing attacks.

A webhook replayer that mutates the signature header is a cheap, high-signal test. It exercises the verification path, the error path, and the alerting path in one shot.

POST /webhooks/github HTTP/1.1
Host: api.example.com
X-Hub-Signature-256: sha256=0000000000000000000000000000000000000000000000000000000000000000
Content-Type: application/json

{"action": "opened", "issue": {"number": 42}}

Send a near-miss signature, a missing header, and a signature computed with the wrong secret. Each should produce a distinct, logged rejection. If any of them is accepted, you have a security bug, not a resilience bug.

GitHub provides fixed test values so you can verify your implementation against a known-good result. The secret is It's a Secret to Everybody and the payload is Hello, World!. The expected signature is published in the docs. If your implementation does not produce that signature, the bug is in your code, not in the test.

One more detail from the same source: if a proxy or load balancer modifies the payload or headers before verification, signature verification can fail. That is worth testing explicitly. A game day that routes webhooks through your actual ingress path will catch it.

Build the injection harness

You do not need a chaos platform. You need a proxy or middleware that can rewrite responses and a webhook replayer that can mutate headers.

Response rewriting

A simple reverse proxy in front of your staging API can intercept responses and apply faults based on a header or a query parameter. For example, a request with X-GameDay: truncate gets a body cut at a fixed byte offset. A request with X-GameDay: rate-limit gets a 429 with a Retry-After header.

Keep the fault set small and named. If you cannot list the faults on one page, the exercise is too broad to debrief usefully.

Webhook replay

Capture a real webhook delivery from staging, then replay it with a mutated signature header. The replayer should be able to send:

• A valid signature (control case)
• A signature with one hex character changed
• A missing X-Hub-Signature-256 header
• A signature computed with a different secret

Each case should produce a logged rejection with enough detail to debug. If the logs say only “invalid signature,” that is a doc bug for the runbook.

What to capture

Before the exercise, decide what evidence you will collect. Client logs, retry counts, support tickets, and the time between fault injection and first alert are all useful. The goal is to compare observed behavior to the contract, not to produce a pass/fail score.

Run the debrief like a blameless postmortem

The most valuable output of a game day is not a pass/fail result. It is a list of doc bugs: places where the contract was ambiguous, the runbook was stale, or the client team’s mental model diverged from the spec.

Ask three questions for each injected fault:

• Did the client behave the way the contract says it should?
• Did the on-call runbook tell the responder what to do?
• Did the documentation explain the fault clearly enough that a new engineer could predict the behavior?

If the answer to any of these is no, file a doc bug. If the answer to the first is no, file a client bug. If the answer to the second is no, update the runbook before the next game day.

Some faults should become permanent CI tests. A 429 with Retry-After is easy to assert in a contract test. A truncated body is harder but still testable with a fixture. A malformed webhook signature is a unit test. The game day is how you discover which ones matter enough to automate.

Scope it to staging with a named abort criterion

This is not a production exercise. The goal is to observe behavior, not to prove you can survive production chaos. Run it in staging with a rollback path and a named abort criterion.

An abort criterion is a specific condition that ends the exercise immediately. Examples: error rate exceeds a threshold, a participant cannot reach the staging environment, or a fault affects a shared dependency outside the scope of the test. Write it down before you start.

If you cannot describe the rollback in one sentence, the exercise is too risky for a first run.

The artifact: a one-page game day runbook

Adapt this template for your team. Keep it to one page. If it grows beyond that, split it into multiple exercises.

# API Game Day Runbook

## Scope
- Environment: staging
- Services: [list]
- Participants: [names and roles]

## Faults
1. 429 with Retry-After: 120
2. Truncated response body at 512 bytes
3. Webhook with mutated X-Hub-Signature-256

## Hypothesis
For each fault, what do we expect the client, on-call, and docs to do?

## Abort criteria
- Error rate exceeds [threshold]
- [Other condition]

## Rollback
- [One sentence]

## Evidence to capture
- Client logs
- Retry counts
- Time to first alert
- Support tickets

## Follow-ups
- Doc bugs filed
- Client bugs filed
- Faults promoted to CI tests

The runbook is the deliverable. The game day is just the excuse to write it.

FAQ

How often should we run a game day?

Often enough that the runbook stays current. If your API changes quarterly, once a quarter is reasonable. If it changes weekly, the runbook will rot faster than you can test it, and you should invest in automated contract tests instead.

What if we do not use RFC 9457?

The exercise still works. The point is to test the contract you actually publish, whatever its shape. RFC 9457 is useful because it gives you a concrete, machine-readable format to assert against, but it is not a prerequisite.

Can we run this in production?

Not for a first run. The value of the exercise is in observing behavior, and production adds risk without adding much signal. Start in staging, and only consider production if you have a mature fault-injection practice and a very specific question that staging cannot answer.

What if the client team is in a different time zone?

Record the exercise and share the evidence. The debrief can be asynchronous. The important thing is that the client team sees the observed behavior and has a chance to file bugs.

How do we know if the game day was successful?

You have a list of doc bugs, client bugs, and CI tests that did not exist before. If you have none of those, either your system is perfect or the exercise was too gentle.