Adam Keys is Thinking

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:

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:

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:

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

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.

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.

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?”