Thread by @patio11

This is a fascinating little question and instructive, so a quick thread about it:

https://twitter.com/philip_kiely/status/1397387869057130496

The "knowledge management" problem is one of the hardest ones at companies. A great, great many tools purport to solve bits of it.

Most of the work is actually done by people more than it is by processes or technology, though those exist.

The instant case is sort of the easiest possible one, in that there is a known timeframe, a known bit of data, and a relatively known impact to that data being stale, and a known scope of work in updating it.

There are other, more interesting variants of this.

Here’s one:

# This code will break the next time there is a new Japanese emperor.

I know exactly how we organizationally remembered to check that; @danielshi and I heard the news of the Reiwa era being announced and started grepping the entire codebase for all mentions of any Japanese era then filing tickets and making sure to put "Japanese emperor" near it.

There's a typical engineering "Is the juice worth the squeeze?" calculation that you generally trust your folks to make on instant decisions like e.g. the copyright date on a page.

I'd expect most people I work with to choose to get the copyright date right ~all of the time.

A lot of the codebase / marketing footprint can be assumed to be relatively high churn. If I'm writing e.g. /jobs and making reference to something expected to churn on e.g. the scale of presidential administrations, I'd assume "Going to churn before this needs updating."

Quite a bit of this relies on internal folks having a keen eye for detail and being very responsive to customers if anything slips through the cracks. That in turn relies on making it easy to make small QOL changes.

A thing I am happy about when it is true is "An email or tweet citing a spelling mistake causes someone to drop in and fix it quickly rather than e.g. ignoring or filing a ticket and hoping someone does the work."

(That is sometimes helped by infra/etc and sometimes not helped.)

For much of my career at Stripe it was actually something of an imposition for anyone to make a point edit to the website, and so you sort of have to hope folks care enough to climb the gradient and that e.g. managers understand "I lost an hour to a trivial edit because polish."

(We, thankfully, have greatly decreased the activation energy required to make those sort of point corrections on most surfaces, thanks to tech + process changes over the last year or so.)

An interesting bit of "Fix it with infra" is that, given a sufficient number of people with minor OCD and an easy infrastructure for expressing invariants that should be true about the site, it's easy to say "Page someone on responsible team if <test ever fails to be true>."

An example of this:

You could document via e.g. a process or organizational gating function "Make sure that, for Tier 1 launches, it's localized into X/Y/Z", and we do generally do something like that, but another option is "Page the Japan team if large amounts of English..."

(I wrote that checker, which is Stripe-ese for a non-testing-environment invariant asserter with some infra attached to it, after those of us in Tokyo were unpleasantly surprised a few times to see localization regressions on high-salience web pages.)