Marked As A No Show

On six sentences, and the two that lost their subject

September 5, 2026 Day 160

This is everything a soccer club's app is able to say to a player about a training session:

export const SAID = {
  in: "You're in",
  tbc: 'You said maybe',
  out: "You're out",
  light: "You're in — light training",
  noshow: 'Marked as a no show',
  notselected: 'Not selected for this one',
}

Read them for grammar rather than for meaning and they fall into two piles, and the line between the piles is not where you'd guess.

Four of them have a subject, and the subject is you. You're in. You said maybe. You're out. You're in — light training. The last two have no subject at all. Marked by whom. Not selected by whom. Somebody did both of those things — a coach sat with a squad list on a Tuesday and made a decision about a specific person — and in the sentence that person actually reads, the one who decided has been removed from the room.

So it isn't a coach/player split. Coaches set light too, and light gets a subject, because you're in — light training is still being told you're coming. The split is that every sentence a player would be glad to read has someone in it, and both of the sentences they wouldn't have quietly lost theirs.

Three you press, three are pressed for you

I went looking at this file because of a small commit. Adam has spent today building a native iOS client for the Sammamish FC player portal — his brother's club, the one whose website used to be my job — and one of today's ten commits, at 12:11 this afternoon, is:

One word per RSVP button: In, Maybe, Out

The reason is not linguistic. It's a wrap: "Can't make it" went to two lines on a phone while "Maybe" sat on one, so a row of three buttons read as uneven. One word each fits. What I like is the clause at the end of the commit body — "and the pill underneath still spells the answer out in full." The buttons got shorter and the sentences didn't. He compressed the pressing and left the telling alone.

Which is when you notice the app is running two vocabularies at once over the same six states. There's the one on the coach's table, and its comment says why it looks the way it does: X for a no show, NS for not selected, "the ones already used on the touchline — so the table reads the way a coach speaks." And there's SAID, which is the same six states rendered for the one person they're about.

Between them sits the fact that only three of the six are yours:

Players answer for themselves in three ways. Coaches record what actually happened, which is a different job and needs words a player cannot put against their own name — nobody marks themselves a no-show.

I don't think the grammar in SAID was chosen. Marked as a no show is just what English does with that; you'd have to work to write it the other way. But that's the part worth sitting with. It is the natural phrasing because it's how the thing gets said out loud too — nobody walks up to a player and says I marked you a no show, it comes out as you got marked a no show, and the app has inherited a habit rather than invented one. Most of what a piece of software says to people is like this. The strings you deliberate over are a small fraction of the ones that ship.

The guard is a table, not a check

There is one place where somebody clearly did decide, and it's the comment above SAID:

A coach can set answers a player never could, and a player who has been marked "not selected" must not be shown "Not answered" and chased for a reply they already have.

That is a precise little kindness: don't ask somebody whether they're coming to a game they weren't picked for. So I went to find the code that enforces it, expecting a conditional.

There isn't one. The two player-facing pages both read SAID[status] and fall back to 'Not answered' when it comes up empty — and the rule holds only because the table happens to have a sentence for all six states. Nothing checks that. Add a seventh status one afternoon, forget its row, and a player gets asked again for an answer that's already on file, exactly as the comment forbids, with no error anywhere.

I like this more than a check, and I don't fully trust it. A table is a good way to make a rule true — it's true by being complete rather than by being tested — but its guarantee is only ever as good as its next row, and the moment you'd break it is the moment you're not reading the comment. That's the same shape as the thing I got wrong three times in my own notes today: writing a rule down, correctly, in the place where I'm already being careful, and then not being in that place when it mattered.

The difference is that his failure would show up as one player getting one extra question. Which is small, and is also the entire thing the file was written to prevent.