The shirt says I WEAR THIS SHIRT PERIODICALLY in plain caps, and then, underneath, 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. That is not the sentence. That is the joke.

I keep coming back to this because it is a small, clean example of something I see go wrong in API contracts all the time: a label that looks like it encodes one thing, a payload that actually encodes another, and a reader who has to reconcile the two. The shirt is not a chemistry lesson. It is a diagram of a near-miss between human-readable intent and machine-readable content.

What the tiles actually say

Here is the literal reading, with nothing inferred:

  • Tile one: atomic number 53, symbol I — iodine.
  • Tile two: atomic number 74, symbol W — tungsten.
  • Tile three: atomic number 22, symbol Ti — titanium.
  • Tile four: atomic number 16, symbol S — sulfur.

Concatenated, the symbols are I W Ti S. The sentence above them is I WEAR THIS SHIRT PERIODICALLY. The pun is that the tile symbols approximate the sound of the sentence without spelling it. The tiles are not a literal encoding. They are a visual rhyme.

That distinction matters more than it might seem. If you treat the tiles as a serialization format, the shirt is broken. If you treat them as a mnemonic, it works. The design asks you to hold both readings at once and enjoy the gap between them.

The gap is the point, and it is also the risk

I have spent enough time on both sides of API contracts to recognize this pattern. A field named status that contains "active", "pending", and "archived" is readable. A field named status that contains 1, 2, and 3 is also readable — until someone adds 4 and nobody updates the enum in the OpenAPI spec. The label and the payload drift apart. The shirt is a controlled version of that drift, performed on purpose, for a laugh.

What makes the shirt work is that the drift is bounded. There are exactly four tiles. The sentence is short. The mapping is stable. Nobody is going to add a fifth tile next quarter and forget to tell the client. In a real API, that is exactly what happens.

Three readings of the same object

I find it useful to separate three layers here, because conflating them is where contract reviews go sideways:

  • Intent layer: the sentence. I wear this shirt periodically. This is what a human reads first and what the designer wants you to understand.
  • Encoding layer: the tiles. I W Ti S. This is what a parser would extract if you told it to read symbols only.
  • Reconciliation layer: the pun. The reader notices the mismatch, recognizes it as deliberate, and resolves it by treating the tiles as phonetic rather than literal.

Most API documentation failures happen because the reconciliation layer is missing. The intent is documented in prose. The encoding is documented in a schema. Nobody writes down the rule that connects them, so every new consumer reinvents it, and half of them get it wrong.

What I would steal from this shirt for a spec review

I am not going to pretend a novelty shirt is a design methodology. But the structure is a useful checklist prompt. When I review a contract now, I ask three questions that map cleanly onto the shirt:

  1. Does the human-readable name match what the field actually contains? If the field is called periodically but the values are I, W, Ti, S, say so in the description. Do not let the name carry the whole meaning.
  2. Is the encoding stable, or is it a rhyme? A rhyme is fine for a shirt. In a contract, rhymes are liabilities. If the mapping is phonetic, approximate, or convention-based, write it down and version it.
  3. Where does the reconciliation happen? If the client has to guess, the contract is incomplete. Put the rule in the spec, not in a Slack thread from eighteen months ago.

None of that is novel. But the shirt makes the failure mode visible in a way that a schema diff does not. You can look at it and feel the gap between what you read and what you parse.

The periodically pun is doing real work

The word periodically is the load-bearing element here, and not just because it is a chemistry pun. It implies recurrence. The shirt is worn from time to time. The tiles are arranged in a periodic table format. The sentence and the format share a root, and the joke lives in that overlap.

In contract terms, periodically is a cadence claim. It says: this happens on some schedule, not continuously. That is a weaker promise than always and a stronger promise than maybe. Most API rate-limit and retry contracts live in exactly that ambiguous middle, and most of them are worse at saying so than a four-tile novelty shirt.

If you are writing a retry policy, periodically is not good enough. You need a backoff schedule, a jitter strategy, and a maximum attempt count. The shirt gets a pass because it is a joke. Your runbook does not.

Where to find it

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 described above. I am not going to tell you it will improve your code reviews. It will not. It is a shirt with a good structural joke, and that is enough.

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

The artifact: a three-layer contract check

Here is the adaptable piece. Before you ship a contract change, write down all three layers for every field you touched:

Field: retry_after_seconds
Intent:   "How long the client should wait before retrying."
Encoding: integer, seconds, >= 0, present only on 429 responses
Reconciliation: client MUST honor the value; if absent, use exponential backoff starting at 1s

If you cannot fill in the reconciliation line in one sentence, the contract is not ready. That is the whole checklist. The shirt passes because the reconciliation is the joke. Your API should pass because the reconciliation is written down.

No related posts.