Adam Keys is Thinking

Austin Kleon - A working from home manual in disguise:

1. Make lists.
2. You can be woke without waking to the news.
3. Airplane mode can be a way of life.
4. Naps are a secret weapon.

David Perell - Beer Mode and Coffee Mode:

Creatives have two ways of working: beer mode and coffee mode.

Beer mode is a state of unfocused play where you discover new ideas. In contrast, coffee mode is a state of focus where you work towards a specific outcome.

The see-saw of beer and coffee mode is like breathing. Your best ideas emerge when you balance the inhale of beer mode with the exhale of coffee mode. Coffee mode rewards action, while beer mode rewards laughter. Coffee mode rewards focus, while beer mode rewards conversation. And while coffee mode rewards clarity, beer mode rewards serendipity.

What way of working is thinking big thoughts in the shower?

Mike Perham: Grouping Events for Later Processing:

But we see enough traffic that we don’t want to turn every single click into a background job. We want to aggregate the clicks and process them regularly. There’s several ways to do this; I’m going to show you how to implement it using a cron job running every minute.

Redis and some creativity scales really well. In other words: you may not need microservices, part 34.

Christof Damian, My thoughts on meetings:

I used to really hate meetings. As a developer they seem to just get into the way of doing real work…But at some point you specialise, teams grow and you need some way to sync up.

I’ve learned in the work-at-home times that it’s definitely possible to have too few meetings. After passing that threshold, the cart to play is creating better meetings. Lots of good ideas and guidelines in this article.

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!