Adam Keys is Thinking

Annabel Scheme and the Adventure of the New Golden Gate - a short story by Robin Sloan. Fantastic world building for a short story. Highly recommended.

Nostalgia and the “this city used to be cooler” sentiment comes up (and is rejected). Funny that the sentiment in the story is about San Francisco, where many Austinites came from and was allegedly cooler when it had fewer former-San Franciscans.

Maybe cities are like Saturday Night Live: there are very few real stinkers, just casts or episodes or locales for which one isn’t nostalgic.

How Product Hunt does asynchronous work: everyone in their own swimlane, unblocked. I really dig how they haven’t siloed work between front-end/back-end developers.

Collaborative Single Player Mode:

A developer should be able to execute a feature from start to finish – from the database to the backend, API, frontend, and CSS. The goal is never to get blocked.

• If you are missing a design, mock the UI, designers can fill this in later
• If you don’t know how to do something technically, hack it or fake it
• If a product decision is missing, try to make this decision yourself - it’s better to ask for forgiveness rather than permission

Sounds like they use feature flags so they can move quickly and decisively, but safely. And of course, plenty of testing and code review automation.

The entire time I’ve been using FactoryBot, several years at this point, I’ve used it one factory at a time:

company = create(:company, name: "Acme, Inc.")
alice = create(:user, name: "Alice Smith")
posts = create_list(:post, 3, user: alice)

Do you see the mistake I make all the dang time? Spoiler alert, I forgot the company relation on Alice’s user, so she is either orphaned (unfortunate) or created on an entirely unrelated company. That’s gonna make my test fail in weird ways!

Lately, I’ve been trying something different: create the whole object graph I want to test on in one fell swoop:

company = create(
  :company,
  name: "Acme, Inc",
  user: build(
    :user,
    name: "Alice Smith",
    posts: build_list(:post, 3)
  )
)

The entire intent of the test scenario is made clear right here. And, the error I so often make is solved structurally rather than by vigilance.

Granted, that’s pretty chunky and way more lines. I feel like it’s a worthy tradeoff!

When I need to reference the models created by my jumbo object graph, I use RSpec let and ActiveRecord finders with a mind towards consistently finding the right thing:

let(:company) do
  create(...) # the whole company bit from above
end
let(:alice) { company.users.find_by(name: "Alice Smith") }
let(:posts) { alice.posts }

“Perfect is the enemy of shipped” - Simon Willison

15 rules for blogging - Matt Webb

Lists, emoji, and consistency are totally working for Duncan Davidson

Here’s a real dinger of a sentence from Michael Lopp’s latest, The Art of Leadership: Small Things, Done Well:

Failure is created by the increasing entropy of a growing number of humans running around the building, good intentions in hand, breaking things.

Growing an organization requires rethinking trust, coordination, and collaboration. The breakpoints where things go from working pretty well to an absolute shamble come faster than we think. They don’t even occur at nice, round numbers like base–2 or base–10 orders of magnitude.

Figuring out how this works for teams, companies, social networks, and whole countries feels like one of the big unsolved problems of the knowledge/attention-era.

Two iOS wishlist items:

1. Any app that can send & receive messages (emails, direct messages, photos, chats, tweets, etc.) should require a narrow, write-only affordance for sending a one-off message without distracting yourself in all the engagement loops.
2. “Smoke-break”, an extension of the current screen time affordance. Only allow yourself access to e.g. Facebook, Twitter, TikTok, etc. for seven minutes of the hour. The easy part is integrating this into the operating system. The hard and most impactful part is keeping the Smoke-break name and all its negative connotations.

The best way to achieve these outcomes now is to delete the app from your device and only dip into the web interface when you absolutely must. That’s contrary to Apple’s goals. It’s not bad for the web platform, though🤔.

In short: nerf the engagement loops at the operating system level.

Writing clarifies thinking. Therefore, writing design docs clarifies one’s thinking about code. Design Docs at Google and an example/meta design doc from the same author are great places to start!

I found that writing prose until I run out of clarity and then switching to proof-of-concept code is even better. The constraint of making an ambitious design work with a minimal change-set is a nice way to work for a day or so.

Lots of features or fixes don’t require in-depth thinking to get started. But when they do, sorting out the ideas and tradeoffs in writing helps a lot.

Write until I run out of ideas, flesh those ideas out, write about the nuances I found. It’s a nice feedback loop!

A Better Approach to 360° Feedback: Bradford Fults shares ways to route around fallible human memory and gather useful information when it comes to review season.

Humans also have a recency bias and suffer from long-term memory distortions that change to fit their current opinions of other people. This means that “observations” from months ago often aren’t so much observations as they are current opinions and emotions repackaged as fixed stories about the past. Most people don’t even intend to distort the truth like this: it’s just the way the human brain works.

Instead, ask questions in the context of how the reviewer works with the reviewed, particularly in the last 90 days or so. Paraphrasing Janet Jackson: “What Have You Done For Me Lately?”