Onboard new teammates with a 90-day plan

My new boss had written up a 90-day plan for me the week before I started. This was perfect timing. I was already starting to put a bow on my current work and my focus was wandering. Now my brain could start working on ideas for the next gig. Plus, I had a much better idea of what I’d start working on and how to make an impact than I did coming out of my interviews. It was one of the better emails I’ve ever received.

Use factories to create jumbo object graphs

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(
  name: "Acme, Inc",
  user: build(
    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
let(:alice) { company.users.find_by(name: "Alice Smith") }
let(:posts) { alice.posts }

Failure = entropy due to adding humans

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.


Writing is thinking, so write about code

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!


Bradford Fults on feedback and human bias

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


The project management corollary to Hofstadter’s Law

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Corollary: It always takes more repetitions to tell people what you’re doing, how you’re going to do it, why you’re doing it, how much progress you’ve made, that you finished doing it, etc. even when you take into account the corollary to Hofstadter’s Law.

Towards smaller JavaScript

The JavaScript ecosystem’s gone to a strange place where dense frameworks and complex tooling are the status quo. But, there are data-points suggesting the pendulum could swing back sooner than later:

  • Snowpack 2.0 – download all your deps, import them as modules. Snappy development experience ensues.
  • lit-html – generate DOM without going through React/Vue/etc. intricacies
  • Alpine.js – attach dynamic interactions to elements with data elements describing DOM manipulations
  • htmx – attach dynamic networking to elements with data elements describing AJAX/Websocket/SSE events

Caveat: I haven’t tried any of these. But, the trend-line is promising. JavaScript the language, while not perfect, is Pretty Good now. Perhaps the next few years will see the great ideas of the frameworks squeezed into more accessible, less sprawling expressions of those ideas.