article {
  max-width: 60ch;
}
  • I’m the “unscientific testing” guy. Here’s my thoughts on the steam machine after 9 days: The steam machine is pretty great. The reviews on youtube talking about cost and performance are not speaking to anything I care about …

  • Mastodon, The Only Good Choice: I agree with this sentiment but some people I follow are only using Bluesky. I never use twitter anymore.

  • None Yet. What does incident management look like on day 1: Brilliant. Small, simple process that makes for a good starting point for a company.
    • Declare
      • Call the incident
      • Call it when you need more eyes (not severity)
      • Waiting means you might start working the problem later than you could have
    • Stop regular work
      • People working an incident need to focus on recovery
    • Who
      • One person at a time for however long the team agrees
    • Comms
      • One person makes the company aware of what is known, what we’re doing and when to expect another update
    • After
      • Learning
        • What happened
        • What was learned
        • What will change to avoid or help recover from this kind of incident
      • Write down action items and add to the backlog
    • Reporting
      • Spreadsheet
        • Date
        • Duration
        • What broke
        • What fixed it
    • Later
      • Severity
      • Commander
      • Blameless
  • Rewriting Bun in Rust: Big port of bun from zig to rust implementation languages at incredible expense by Anthropic. Makes for an exciting case study, but many questions remain: how many bugs are in the new millions of lines codebase? What’s the quality of the resulting rust code? What about safety? It doesn’t seem like this kind of usage is going to be accessible for people not-Anthropic or with massive amounts of money to burn on an experiment like this. $160,000 in api use. In other news, open weight models are apparently 6-12 months behind frontier models and also improving, so there will be alternatives to openai and anthropic in the future for this kind of tool it seems like …
  • Transforming How We Run Kafka at Honeycomb: Considerations for a large migration of kafka from ec2 to eks in aws. Considerations:
    • Practiced migration plan
    • Collaborative activity across teams
    • Informed by recent outages
    • Start by understanding historical context like “how we got here”
    • Migration plan is a living document that is updated after every phase
  • Fascinating Photos Show How Canada Looked When It Was Created 159 Years Ago: Gorgeous photography of Canada around 1867.

Embracing the Code Review Bottleneck:

A team @ Honeycomb tries to shift work from code review to agent prompt review. Rather than reading code (as thoroughly? but also much more monitoring …), review by humans focused on the initial prompt and plan analysis. The experiment wasn’t all bad. They found learning was still happening around bad plan steps. They eventually backed off from it but still use the new practice for smaller, well-defined tasks. This thought I liked: “Every change became a small rfc.”

What if the bottleneck exists because this stuff matters? What would happen if we were to decide our job isn’t producing and running code, but owning the system? After all, knowing what changes are happening, keeping up with the structure of our systems, discussing the changes we want to see happen, staying aligned on plans and asking for each other’s input are all critically important. If code takes almost no time to write anymore, what if we instead could use all the freed-up time to do more of everything else?

An agent triggered by a review of yesterday’s bugs in a loop

Reasonable idea for the start of an agent loop. I wouldn’t let the clanker go all the way through task creation to deployment in production. There are steps in there to review the issue (what if the error message is bad, or the exception is “normal” behaviour for certain workflow terminations?) and review the proposed change for me.

Make better documents

A post by Anil Dash from 2024.

  • Know your audience and goals
  • Don’t overformat
  • Whitespace
  • Sequencing and order (the most important stuff first)
  • Clear conclusion (it’s not a murder mystery)
  • Ask questions that are answerable (Do we go with A or B? Here’s what’s different about them. Get to constructive conversations …)
  • Close with a reminder about goals