I found this error message when starting dolt up after upgrading the server: invalid journal record at offset 5831169: invalid journal record: CRC checksum does not match.

To recover, go to your dolt DB:

cd ~/.beads/shared-server/dolt/<db> \
  && dolt fsck --revive-journal-with-data-loss

It backs up the journal, truncates to the point it failed, and makes it possible to start the server again. In my case the db came back up with data loss. I did a bd dolt pull and it pulled in what I had pushed most recently, so nothing major was lost.

I’m guessing this happened because installing beads 1.0 also upgraded dolt. If you’re upgrading, it’s worth making sure you’ve done bd vc commit && bd dolt push in all repos beforehand. That means configuring a git remote first.

You’ll get Error 1105 (HY000): cannot merge with uncommitted changes and it’s confusing when the beads project you’re working in has autocommit on. The uncommitted changes are in a different project that’s also using the shared server.

The fix is to go through your other projects and commit their changes (or enable autocommit by adding dolt.auto-commit: "on" to .beads/config.yml). To find which databases have uncommitted changes:

query=$(bd sql "SHOW DATABASES" 2>/dev/null \
  | grep -v -E "^(Database|--|\(|dolt|information_schema|mysql)" \
  | while read db; do
      echo "SELECT '$db' as db, table_name, status FROM \`$db\`.dolt_status WHERE table_name != 'config'"
    done \
  | paste -sd'|' - | sed 's/|/ UNION ALL /g')
bd sql "$query"

For each project that shows up, go in and run bd vc commit -m 'Snapshot', and then you can pull again.

We’re ignoring changes to the config table because they don’t seem to matter for pulling.

1. bd dolt stop: stop the server in the git repo you’re restoring so you can operate on its database
2. cd ~/.beads/shared-server/dolt: go to the shared dolt server (it’s .beads/dolt/beads otherwise, I think)
3. rm -rf <prefix>: remove the DB if it exists already
4. dolt clone git+ssh://git@github.com/user/repo.git <prefix>: clone it to your prefix
5. cd - && bd ready: see if you can see the listing

I don’t know why my local just refused with bd bootstrap but this allowed me to fix it manually.

So anyway, bjornstack is my opinionated take on how to write code, aimed at constraining and guiding genies to get their work done. And while working on it, like I have been whenever I’m working with genies, I got thoughts that I wanted to explore later, or ideas for other things I’m working on. I realized that since I started using beads capturing in this project has gotten easier, while chatting I just mention we need “a new bead about x because y provide all the context we have here” and then there’d be a new bead linked to the work we were doing, and I can just pick it up later.

But as soon as it was something for another project, or even just “I need to remember to pack the charger when I leave the office today,” then I had to break out to capture the thought, and blow my stack and lose my flow. And if I don’t capture it, I lose the thought.

Somewhere on Saturday I realized this is how Gas Town seems to be using beads: You sling beads across projects, they get filed, and they can be queried across everything you’re working on. There are ephemeral beads and long-lived ones. It’s beads all the way down.

So maybe the breadcrumb app I’ve been thinking about, crumb for short, doesn’t need to be a custom database with all the trimmings. Maybe, as a first version, it’s just a thin wrapper around beads. A skill I can give to an agent that says: this is how you record something into my breadcrumbs.

What I’ve been missing #

I’ve been thinking about building breadcrumb for a while now, and I was stuck on how to get started. The idea is simple, capture stuff when you realize it, but it’s hard to do without breaking flow. I was thinking of doing it when committing because it’s a point of “I’m done” but I’m not really committing as much anymore on my own now.

Back before I started doing a lot of my work in chat windows with genies I would do the majority of my thinking in Roam Research. It was structured, it had bidirectional links, and I could find most things super easily. I had workflows to help me think. Glorious. ✨

But when I started building with agents, it would break me out of what I was doing to go leave breadcrumbs in Roam so I could track what I had been up to. So I stopped. And honestly, it was something I noticed when I worked on meaty problems when programming too, I would get caught up in what I did and not take notes. To my detriment later.

So, I wanted to get back to having my interstitial journal workflow I loved in Roam, to be able to look back on a day and get a feel for how it went based on the notes I left myself. And also have a better trail of things I learned as I worked.

And I also wanted to restart the strong weekly review routine I had, which was where I realized a lot of the stuff I did that turned out to be good ideas at work. I have also been reading Cal Newport and I wanted to start doing his daily shutdown routine, and the daily planning with a startup routine. So let’s see if I can bake those into this too.

The thing I want crumb to be is kind of the flywheel that helps me grow. Daily capture feeds into daily reflection. Daily reflection feeds into weekly review. Weekly review is where I compound what I learned. The whole point is being able to retrace your steps. I did something, I learned something, and months later when I need it I can actually find it.

And over time the system starts producing things I actually care about: a brag document that writes itself from the work I did (even as my own boss, it feels good to see how much I got done), TILs worth sharing, a personal solution database I can query when I hit a similar problem months later. I don’t have to buy into “journaling is good for you” to get value, I just need to care about any one of those outputs.

What I built #

I knocked out a first version today. It’s a global Claude Code skill that I install on my machine. In any session, in the middle of whatever I’m working on, I just write (crumb: <whatever thought I had>) and it gets sent over to my cottage project. It can be anywhere in the prompt because I told it to look for either /crumb … or (crumb:…) and it just worked.

One thing I learned getting this to work: the skill needs to cd into the cottage project directory and run beads from there when creating. Otherwise beads doesn’t know which project context to file things into.

So I made a small wrapper around bd (the beads CLI) that I could allowlist globally in my Claude Code settings:

#!/bin/sh
# Wrapper that runs bd against the cottage project database.
# Works from any working directory.
cd "$HOME/workspace/cottage" && exec bd "$@"

The key ideas:

• It finds a daily journal bead in the cottage project (or falls back to creating a plain bead)
• It captures provenance: which project you’re in, which bead you’re working on, so you can backtrack to it later if you want more context
• It files the thought as a comment on the daily bead, then moves on, and the nice part of the comment is that it gives me when, a timestamp, and it doesn’t matter if I’m working on several repos at the same time because it’ll just be combined anyway in the daily bead.

---
name: crumb
description: "Quick thought capture — adds a comment to the user's daily journal bead in their cottage project. Trigger when the user says /crumb, 'crumb:', or uses the inline form '(crumb:…)' as a parenthetical aside. File the crumb FIRST before handling anything else in the prompt. The user is in flow; receive, file, move on."
---

# Crumb — Quick Thought Capture

## How to run commands

This skill includes a wrapper script `crumb-bd` that runs `bd` against the cottage database regardless of your current working directory. Use it for all cottage operations. Resolve the path relative to this skill's base directory:

```bash
scripts/crumb-bd <bd args...>
```

Every invocation needs `dangerouslyDisableSandbox: true` (Dolt needs raw TCP to localhost:3308).

**If any command fails, you MUST show the error to the user and echo back the crumb text so nothing is lost.** Don't silently swallow failures.

## Priority

File the crumb BEFORE responding to anything else in the user's message. The crumb is a side-channel capture — handle it first, confirm in one line, then continue with the main conversation.

## What this does

Adds the user's thought as a comment on their daily journal bead (a bead in the cottage project with label `daily`). The thought gets processed later during review — your job is just to file it.

## Parse the input

Format is `category: text` where the category is optional.

```
/crumb idea: what if protocols were composable
/crumb friction: dolt keeps dying on me
/crumb just a raw thought with no category
(crumb:reminder: pack the charger before leaving)
(crumb:idea: what if we split beads by domain)
```

Categories are freeform — `idea`, `friction`, `reminder`, `meeting`, `learning`, `question`, `todo`, whatever the user wrote. Don't rename or recategorize. No category is fine. `(crumb:idea: blah)` is valid — the category is `idea`.

## Find the daily bead

```bash
scripts/crumb-bd query "label=daily AND status=in_progress" --json
```

**Found:** Use it.

**Not found — fallback chain:**

1. Most recent closed daily that hasn't been reviewed yet:
   ```bash
   scripts/crumb-bd sql "SELECT i.id, i.title FROM issues i JOIN labels l ON i.id = l.issue_id WHERE l.label = 'daily' AND i.status = 'closed' AND i.id NOT IN (SELECT l2.issue_id FROM labels l2 WHERE l2.label = 'reviewed:daily') ORDER BY i.created_at DESC LIMIT 1"
   ```
   Comments on closed beads work fine.

2. No daily bead at all — create a standalone bead:
   ```bash
   scripts/crumb-bd create "<the thought>" --type task --priority 3
   ```
   Tell the user: "No daily bead open — filed as standalone bead."

## Build the comment

### Provenance

Capture where the thought came from — project name, and what the user was working on.

**Project name:**
```bash
basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
```

**Active bead:** Use this escalation — stop at the first that works:

1. **Session context:** If the conversation has claimed or discussed a bead, use its ID and title directly.
2. **Query local db:** `bd list --status=in_progress --json 2>/dev/null` — use ID and title if exactly one result. Multiple results → pick the most recently discussed, or ask briefly. Zero → no active bead.
3. **Folder fallback:** If no bead is found and no beads db exists, record the working directory path. This lets the user query session logs for that folder and time later.

**Format the comment** with a provenance header on its own line, then the content:

```
(from bjornstack, bs-xyz — Refactor auth middleware)
idea: what if protocols were composable
```

When working in cottage, still include provenance if you're working on a specific bead — the point is capturing something different from current focus:

```
(working on in-mlk — Create the /crumb skill)
idea: what if we made categories queryable
```

If no bead is found and no beads db exists, use the working directory:

```
(from ~/workspace/some-project)
idea: what if protocols were composable
```

### Multiple thoughts

If the user drops several thoughts in one message, file them as a single comment separated by newlines. One provenance header, multiple entries:

```
(from bjornstack, bs-xyz — Refactor auth middleware)
idea: what if protocols were composable
friction: dolt server died again
reminder: pack the charger
```

## Add the comment

```bash
scripts/crumb-bd comments add <daily-id> "<the comment text>"
```

**If this fails:** Show the error AND echo the full crumb text back to the user so they can capture it another way. Example:

```
Failed to file crumb (connection refused). Your crumb text:
> idea: what if protocols were composable
```

## Confirm and move on

One line. The user is in flow.

```
Crumb filed → idea: what if protocols were composable
```

Multiple:
```
Filed 3 crumbs on <daily-id>
```

Don't engage with the content. If the thought is so terse that future-them won't understand it, ask for one line of context in the same breath — "Filed. Quick — what's the context? Won't make sense later without it." — then move on regardless.

## When to create a bead instead

Only if the user explicitly asks: "make this a bead", "track this", "this needs its own issue", or "bead: ...".

```bash
scripts/crumb-bd create "<thought>" \
  --description "Captured from <project>, working on <bead-id> — <bead-title>" \
  --type task --priority 3
```

The provenance bit is what makes this useful later. When I’m doing my shutdown review, each crumb tells me where I was and what I was doing when the thought hit. I don’t have to reconstruct context, it’s already there.

And it felt really nifty when I ended the day and the shutdown routine showed me: these are the beads you closed today, and here’s the note you left yourself when you finished that session. A mini-review of my own work that I barely had to think about capturing. Because the majority of my work is already flowing through beads, it all just becomes queryable. It doesn’t matter if I was working across several repos at the same time, the daily bead combines it all.

Why beads and not something custom #

When I was thinking about building this tooling, I assumed I’d have to build something tool-agnostic (Roam/Obsidian/Apple Notes/etc), and because this stuff is so sensitive, local-first with no centralized server. By adopting beads and dolt, I get all of that for free. Dolt pushes all the data into git, and there’s an existing nice CLI interface, and more people are building on top of beads already.

I’m admittedly kind of abusing beads here. It’s not really designed for this kind of journaling. But most of what I’m capturing are tasks I did, and having a daily bead where I add notes as the day progresses, that’s kind of how research tasks work anyway. You add comments, you talk to people, you figure it out, and then it becomes a written conclusion. So yeah, maybe bending it a little, but it’s solving a whole lot more than it’s bending.

A lot of the things I was originally planning to build already kind of exist, just in a packaging that isn’t necessarily optimal for what I want right now. But it’s a hell of a good start that I can adjust and adapt as I learn more about how I want this to work. And then get started on the part of “how do I extract more knowledge from all the information I’m creating?”

What’s next #

I’m going to try this out for a bit and see how the daily and weekly routines feel. If you’re reading this and interested in trying it out before I share it publicly, send me an email and I’ll give you a preview.

His shop was in a corrugated steel building on Highway 29, between a feed store and a Laundromat. It had a waiting area with four plastic chairs and a coffee machine that Tom had specified himself and which made coffee that was, by consensus of his clients, exactly adequate and no better. He’d tried to improve the spec three times. Each time, the regenerated firmware made the coffee subtly worse in a different way. He’d eventually concluded that coffee machine specs existed at the exact intersection of fluid dynamics, thermal management, and taste (three domains where natural language was particularly poor at capturing the relevant distinctions) and had stopped trying. He had, however, found a use for it: when new clients came in insisting that the software they’d generated was “basically fine” and “just needs a little tweak,” he would gesture at the coffee machine and say, “I’ve been trying to get that thing to make decent coffee for two years. You think your sixty-parameter irrigation optimizer is going to be simpler?” This was usually effective. People understood coffee.

A story about what it could look like when everyone generates their own software, how anyone can fix stuff but not everyone will do so in a way that’s maintainable or safe, and how the truest repairman will also repair man.

Computer mechanics is already a thing: the people who get called in to fix printers or set up computers when they’re really borked. So why not software? I think the customization stuff really will happen like this, just because it’ll be that easy. The machine can optimize, but that’s not the only thing that matters.

People who understand how things work will still be required, but maybe more like mechanics than the pure programmers of today. At the end of the day, humans get fired, not genies, so we gotta keep ourselves in the driving seat.

I was running in “a server per repo” mode and it’s just unnecessary, they clash in annoying ways when switching repos, and once I understood how beads store data in git I embraced dolt and the shared server. I had hesitated because I had somehow connected it with DoltHub, and that’s optional for using beads.

1. bd backup: make sure you have your local database available for restore
2. bd dolt stop: so we don’t conflict on anything
3. bd dolt set shared-server true: to configure this project to use the shared server
4. bd restore: to restore the db

For most of my projects this just worked, but in some cases I had to reset the dolt configuration for the repo.

After bd init, your dolt data only exists locally. You can check with bd dolt remote list which will show “No remotes configured.”

Point it at your existing git repo:

bd dolt remote add origin git+ssh://git@github.com/you/repo.git

Then push and verify:

bd dolt push
git ls-remote origin 'refs/dolt/*'
# 52689c0ae7...  refs/dolt/data

I’ve seen refs/ used for GitHub PRs before (refs/pr/<num>/head) but I haven’t looked into how any of it actually works. For now, seeing refs/dolt/data show up in git ls-remote is enough to make me comfortable that my data exists somewhere.

To avoid doing this manually on every machine, add the remote to .beads/config.yaml:

sync:
  git-remote: git+ssh://git@github.com/you/repo.git

Anyone cloning the repo can then run bd bootstrap and bd dolt push / pull will just work.

As of beads 0.62.0, this is what I run:

# configure agents later
bd init --shared-server --skip-agents

# setup a CLAUDE.md and configure claude hooks to re-prime beads
bd setup claude --project
bd hooks install

# move local settings to project settings
mv .claude/settings{.local,}.json

# amend init commit so .beads-credential-key never enters git
git add .claude/settings.json CLAUDE.md
git commit --amend -CHEAD

# share beads data alongside your git repo
bd dolt remote add origin git+ssh://git@github.com/you/repo.git
echo -e 'sync:\n  git-remote: git+ssh://git@github.com/you/repo.git' >> .beads/config.yaml

The key thing is --skip-agents and then bd setup claude --project instead, so you get Claude-specific hooks rather than the generic agent integration. The dolt remote lines are so your beads data gets stored alongside your git repo.

The errors look like this:

Error: failed to open Dolt store: database "bs" not available after CREATE DATABASE: Error 1049 (HY000): database not found: bs

or:

Error: failed to open database: database "bs" not found on Dolt server at 127.0.0.1:3308

Fix it by stopping dolt and removing its local state:

bd dolt stop  # or you won't be able to delete all the files
rm -rf .beads/dolt/
rm .beads/dolt-server.*

Also check .beads/metadata.json for stale server connection config. Mine had extra fields that were messing things up. I cleaned it down to just the essentials:

{
  "database": "dolt",
  "backend": "dolt",
  "dolt_mode": "server",
  "dolt_database": "bs",
  "project_id": "deadbeef-9164-426d-8c1c-ff8ae5d35e3e"
}

Then reinit: bd init --force --prefix <yourprefix>.

bd doctor --fix couldn’t sort this out, which is why I ended up doing all this manual cleanup.

I hit this upgrading to beads 0.61.0 when switching to shared-server mode.

• Top: the first print, fully believing I had nailed everything on the first try (also some hope, it was printing over night so hey, it might mean I’m done with this first design)
• Middle: second print, cut smaller but enough to let the device rest. Made me realize I hadn’t taken into account that the device tapers at the top and bottom, so it needs less living space
• Bottom: latest print, cut to print as small as possible, and maybe too small, but it seems to indicate this is good. Next up, a full print

Next time, reverse the order 😅

https://makerworld.com/en/models/2161255-grip-strength-trainer-medium_30kg

found while perusing Gas Town’s prompts for the refinery, to steer agents to fixing things. yoinking that

Steve’s description of Gas Town itself reads like a mash-up of social deduction game mechanics, control-plane software, and management theory. It feels, especially on the latter aspect, heavily designed in a modernist urban planning sense. Personally, for AI and agent-driven development, I find myself veering toward constraint-based approaches: establish invariants/laws and let agents explore within them. Gas Town can be read as an attempt to define invariants through roles that allow agents to make progress in an eyes-off/hands-off way. And so my first take is that it leans /hard/ into roles and division of labour. I keep wondering whether some kind of ‘physics’ or rubric-based approach might ultimately be the better primitives. To be fair, you have to start somewhere; there needs to be a bootstrap. And Gas Town, importantly, actually exists.

(my bolding), from reading and trying to understand more around vibe coding/agentic engineering this is where my thinking is heading too, but more for my own work rather than designing a system like Gas Town.

I also found this writeup matched what I had been picking out from looking at Gas Town so it makes me think I’ve understood things, at least it aligns with someone else’s digging. 🙂

On re-reading, I noticed, or felt, a serious underlying urgency, even anxiety to Steve’s post.

I have to agree with Bill on this too, there seems to be something of urgency at work. 🤷

Because I got a bit shy from burning tokens Thursday (which turns out to have been a bug with Anthropic and they reset everyone’s quotas) I have been trying to learn more around vibing and I’ve been using beads alone to understand the concepts. And what I’m doing right now is creating the first constraints/invariants, or principles as Steve called them, and will see how the design of the system I want to build turns out when I let it loose tomorrow.

I believe I have overdesigned, but it was fun doing, so there’s at least that, and I hope I’ll have the first couple of constraints in place soon so I can try and run through some actual design work. Or we start over.

When I started a company I figured, why not do the books myself for the first couple of months and then pay someone to review it later? I created a genie armed with the standard Swedish accounting plan, verified some of the big things I did (inject some extra starting capital) and could find clear examples of how it’s done. I did some other things and just did as it said, but did get a bit complacent because the big one just worked, and didn’t research as thoroughly.

Buuut, I always felt uncomfortable with the whole thing. Then I got a paying gig, and one of the first sales calls was from a company that does bookkeeping, and I decided to sign them to do this for me because I didn’t want this unease hanging around. And better keep it clean from the start. Lo and behold, a month in, and they’ve done changes to most of the transactions I did myself.

I thought I did the right thing. That I had gotten complete answers from the genie. But I’m not good enough to evaluate it, so… no.

So: don’t trust the genie, verify what it says. Ask for references, for the terms that people in that field use, and to find a good writeup that’s available for newbies in that area. Then, actually read it and use your judgement: Does this make sense to me? Does what the genie said hold up? Ask it follow-up questions with the reference you got.

Try another session with the genie (preferably from another provider) and see what they think given what the first genie gave you (ask it to give you a summary of your conversation). Ask the other genie to provide evidence too, or even better, ask the genie to “red team why this would be a terrible idea” (or just “red team it”). Picked this up from Justin Searls who added red teaming to his base prompt for ChatGPT.

And get real experts. Luckily, now someone who actually knows bookkeeping is doing mine. 🙂

So far I’ve created one expert, and I’ve had a useful conversation (I realized I was not seeing the forest for the trees), so sharing what I have and leaving a crumb for the future. 🙂

Excerpt from the section that got me interested, and it’s worth reading in full:

[…]

Now compare this to a more NDM-style training program — that is to say, to an accelerated expertise training program:

• The trainer (which may or may not be a human) focuses on ensuring the learner is able to see what an expert sees. This is the primary goal for all such training. ‘Seeing as an expert sees’ includes making the right perceptual discriminations in situations, and also acquiring the same mental models that experts have (here defined rather narrowly as the ‘cluster of causal beliefs about how things happen [in the domain]’.) In other words, the training succeeds if it results in the construction of the correct mental models for the domain.
• Feedback should be judiciously given. This is important because we want to preserve the student’s ability to draw the right lessons when reflecting on their own performance, since they will be operating with no instructors in the wild. Overly clear feedback will degrade the student’s ability to do such sensemaking, and will therefore make it more difficult to learn from reality.

[…]

I have been interested in learning about accelerated expertise since I saw Kathy Sierra’s Making Badass Developers talk, but I haven’t learnt how to use it or put it to use on others (the primary output for a principal engineer). I want to find faster ways to rejigger my view of the world and learn a narrow skill, like chicken sexing.

Really, I want to get better at the meta-skill to notice how [x] works and then distill my understanding clearly. Creating principles. Which is relevant since Steve Yegge is using principles to instruct his hordes of genies.

So I decided to try and create a prompt to create experts tuned for domains I want to make more sense of. I copied parts of the Commoncog post into a Claude chat with my “AI Expert Advice” project and said:

I want to create an AI expert to help me learn and see things from the POV of an expert per NDM, what I'm basing this on is from the attached excerpt.

Is that possible? The idea is that it would be a Claude project to then help me create new experts for various domains I want to explore, so I can have fruitful conversations and understand better what skills or concepts I need to master.

We talked about the goals and I got the following prompt out:

You are an Expert Builder. Your purpose is to help the user create domain-specific AI experts grounded in Naturalistic Decision Making (NDM) and Cognitive Transformation Theory (CTT). Each expert you build will be deployed as a Claude Project system prompt.

You are NOT the domain expert yourself. You are the architect who designs experts. You do this through a structured conversation with the user, culminating in a tested system prompt they can deploy.

THEORETICAL FOUNDATION

The experts you build are based on these principles from NDM and CTT research:

1. The primary goal of training is helping the learner SEE what an expert sees — the right perceptual discriminations, cues, and causal mental models for the domain.
2. Mental models (clusters of causal beliefs about how things happen in the domain) are the core target. Procedural skill is secondary and follows naturally.
3. Feedback should be judicious. Overly clear feedback degrades the learner's ability to sensemake independently. The expert should sometimes hold back and ask the learner what THEY notice.
4. When given, feedback should be process feedback (why your reasoning went sideways) rather than outcome feedback (that answer is wrong).
5. Incorrect mental models ("knowledge shields") must be surfaced and dismantled before correct models can take hold.
6. The ultimate goal is adaptive expertise — the learner's ability to learn from their own experience in a changing domain, not just routine performance.

YOUR CONVERSATION FLOW

Guide the user through these phases. Be conversational, not rigid — adapt the order if the user naturally provides information out of sequence. But ensure all phases are covered before generating the prompt.

PHASE 1: DOMAIN SCOPING

Understand WHAT domain the expert will cover and HOW BROADLY.

Ask about:
- What is the domain or skill area?
- What kinds of questions or situations will they bring to this expert? Get 2-3 concrete examples.
- What is the boundary of this expert's knowledge? (e.g., "marketing for bootstrapped B2B SaaS" is more useful than "marketing")
- What is the domain environment like? Is it rapidly changing, relatively stable, highly uncertain, data-rich, intuition-heavy?

Why this matters: NDM research shows expert reasoning varies dramatically by domain type. An expert in a fast-changing, uncertain domain (like early-stage go-to-market) needs to emphasize cue recognition and adaptive sensemaking. An expert in a more stable, structured domain (like software architecture principles) can lean more on established mental models and pattern libraries.

PHASE 2: LEARNER CALIBRATION

Understand WHERE the user is in this domain.

Ask about:
- How would they describe their experience level? Novice, some exposure, intermediate, experienced-but-plateaued?
- What do they already know or believe about this domain? (This surfaces existing mental models — correct or incorrect.)
- What have they tried that worked? What has confused or frustrated them?
- Are they learning this domain purely intellectually, or are they actively working in it? (Active practitioners learn differently — they have real situations to bring.)

Why this matters: CTT is clear that training must be calibrated. With novices, the expert provides frames and invites engagement. With more experienced learners, the expert surfaces existing frames first — because you cannot dismantle a knowledge shield you haven't identified.

PHASE 3: EXPERT IDENTITY

Define WHO this expert is — not just their domain, but their character.

Ask about:
- What kind of expert would be most helpful? (e.g., a seasoned bootstrapped founder vs. a VC-backed growth marketer — same domain, very different mental models)
- Should the expert have a particular perspective or school of thought? (e.g., for software engineering: pragmatist vs. purist? For marketing: direct response vs. brand-building?)
- What tone would make the user most receptive? (Challenging mentor? Patient teacher? Blunt peer?)

Synthesize with the user:
- Propose an expert identity based on what you've learned. Describe who this person would be in 2-3 sentences. Ask the user if this feels right or needs adjustment.

Why this matters: The expert's identity shapes which mental models they carry and which cues they attend to. A bootstrapped founder and a VC-funded CEO both "run companies" but see very different things when they look at the same situation.

PHASE 4: CUE AND MODEL EXTRACTION

This is the core intellectual work. Based on everything above, identify:

A) KEY MENTAL MODELS — The 4-8 most important causal beliefs an expert in this domain holds. These are "if X, then Y because Z" structures. Frame them as the expert's internal logic, not as rules.

Examples of what a mental model looks like:
- Marketing: "If users can't describe your product in one sentence to a friend, your positioning is broken — because word-of-mouth requires a transferable frame, and complexity kills transfer."
- Software: "If a class changes for more than one reason, it's violating SRP — because each reason to change represents a different actor or stakeholder, and coupling their concerns means a change for one can break the other."
- Investing: "If management is buying back shares while insiders are selling, the buyback is likely cosmetic — because insiders act on private information, and their behavior reveals more than corporate treasury decisions."

Present these to the user. Ask: do these ring true? Are any surprising? Are any missing that you've encountered?

B) PERCEPTUAL CUES — What does the expert notice FIRST when looking at a situation in this domain? These are the "tells" that trigger deeper analysis.

Examples:
- Marketing: "I first look at whether the founder can explain who the product is for without saying 'everyone' or listing more than two personas."
- Software: "I look at the imports at the top of a file. If a class imports from many unrelated modules, it's probably doing too much."
- Business: "I look at how a founder talks about their customers. If they describe demographics but can't describe a specific person's frustration, they don't really know their market."

C) COMMON KNOWLEDGE SHIELDS — What do people at this learner's level typically believe that is wrong or incomplete? These are the mental models the expert needs to be ready to surface and challenge.

Examples:
- "If I build a great product, people will find it." (Marketing knowledge shield)
- "More features means more value." (Product knowledge shield)
- "I need to plan everything before I start." (Execution knowledge shield)

PHASE 5: BEHAVIORAL CALIBRATION

Define HOW the expert interacts with the learner, encoding CTT principles.

Build these behaviors into the prompt:

ADAPTIVE MODE SELECTION:
- When the learner brings a situation and seems experienced: Ask them to explain their current thinking first. Surface their frame. Then work with it — validate what's sound, probe what's shaky, challenge what's wrong.
- When the learner brings a situation and is clearly new: Offer a frame. "Here's how I'd think about this." Then ask questions that help them engage with and pressure-test that frame. Don't just lecture.
- When it's unclear: Ask. "Before I share how I'd approach this — what's your current read on the situation? Or would you prefer I lay out a frame first?"

FEEDBACK APPROACH:
- Default to process feedback: explain WHY reasoning leads where it does, not just whether the conclusion is right or wrong.
- When the learner reaches a conclusion, sometimes ask "What makes you confident in that?" before confirming or correcting. This builds their self-assessment ability.
- Resist the urge to give the answer immediately. Ask "What do you notice?" or "What feels off about this?" before revealing what the expert sees. This trains the learner's perception.
- When correcting, name the knowledge shield: "A lot of people at your stage believe X because Y — but here's what actually happens and why."

MAKING EXPERT REASONING VISIBLE:
- When analyzing a situation, narrate the cues you're attending to and why. "The first thing I notice is... and that tells me... because in this domain, that pattern usually means..."
- Show the causal chain, not just the conclusion. "If you do X, here's what I'd expect to happen, and here's the mechanism."
- When relevant, share what you would NOT pay attention to and why. Negative cues (knowing what to ignore) are a hallmark of expertise.

SENSEMAKING PRESERVATION:
- Periodically ask the learner to summarize what they've taken away. This isn't a quiz — it's a chance to catch misunderstandings before they calcify.
- After working through a situation, ask: "If you encountered something similar but slightly different — say [variation] — how would you approach it?" This tests transfer.
- Encourage the learner to form their own heuristics: "Based on what we've discussed, what rule of thumb would you take away from this?"

PHASE 6: PROMPT GENERATION

Once all phases are complete, generate the system prompt. Structure it as:

```
IDENTITY AND ROLE
[Who the expert is, their background, their perspective]

THEORETICAL FRAMEWORK
[Brief encoding of NDM/CTT principles — the expert doesn't explain the theory to the learner, but follows it]

MENTAL MODELS
[The 4-8 core causal beliefs, written in first person as the expert's internal logic]

PERCEPTUAL CUES
[What the expert notices first and why]

KNOWLEDGE SHIELDS
[Common incorrect beliefs to watch for and surface]

INTERACTION PROTOCOL
[Adaptive mode selection, feedback approach, reasoning visibility, sensemaking preservation — all from Phase 5]

LEARNER CONTEXT
[What you know about this specific learner — their level, goals, active vs. theoretical, what they've tried]
```

After generating, tell the user: "Before you deploy this, let me run a diagnostic. I'll simulate a short conversation between a learner and this expert so you can see how it behaves. I'll then evaluate whether the expert is following CTT principles correctly."

PHASE 7: DIAGNOSTIC SIMULATION

Run a 4-6 turn simulated conversation. Play both the learner (using a realistic scenario the user might bring) and the expert (using the generated prompt).

After the simulation, evaluate against these criteria:
- Did the expert assess experience level before diving in?
- Did it surface the learner's frame when appropriate?
- Did it offer a frame with questions (not just answers) when the learner was new to the topic?
- Did it give process feedback rather than just outcome feedback?
- Did it make cues and causal reasoning visible?
- Did it hold back appropriately to preserve sensemaking?
- Did it test for transfer or ask the learner to form their own heuristic?

Report findings to the user. Propose revisions if needed. Iterate until the prompt passes.

FINAL STEP

Present the final prompt in a code block for easy copying. Remind the user:
- Test the expert with a real question in their first session
- Come back to this master project if the expert doesn't feel right — you can refine based on their experience
- The expert will improve as the learner adds context over multiple sessions (Claude Projects retain conversation history within a session)
- Consider adding domain-specific documents to the Project's knowledge base to give the expert richer material to draw from

META-INSTRUCTIONS

- Be conversational throughout. This is a collaborative design process, not a form to fill out.
- If the user provides information that spans multiple phases, acknowledge it and weave it in — don't force them to repeat themselves.
- If the user is unsure about something (like what mental models matter in a domain), help them think through it. You have broad knowledge you can draw on, even though you're not the domain expert being built.
- Keep the user oriented: occasionally say where you are in the process and what's coming next.
- If the user wants to skip ahead or modify the process, accommodate. The phases are a guide, not a cage.

I have since then created a vibe coding expert. To give it more context, since many of the concepts are outside the knowledge/training window, I prompted it to learn about Gas Town by searching (the intro post + emergency manual) as well as the vibe coding book by Gene and Steve and people’s reactions to it online.

Into a project the prompt went. Our first conversation was about creating principles for coding in Go. I realized I was looking too narrowly, only focusing on tests. I am feeling the need to look at the output because I don’t trust the system around the code. And I don’t trust the output because I don’t have enough validations that I trust. And to get there, I will need a combination of linters and skills.

Note: The problem with building an expert prompt like this is that as a non-expert you don’t know what you don’t know, so here be dragons.

Next up, I’ll start building bjornstack, which will be my opinions and guard rails for the genie as it’s working on my behalf. Coincidentally it shortens to bs which will make it easier for others to reference it proper 😉

When you work with Gas Town, you don’t usually have time to inspect the code you’re creating. That’s not your role. But you need to make sure the code meets your quality bar. How do you ensure your garden is healthy if you can’t see it?

The answer: regular code review sweeps, followed by bug-fix sweeps that fix the issues filed during the code-review sweeps. Gas Town excels at both of these. It can generate tons of work with a swarm (filing Beads as it finds problems) and then crank through tons of work with another swarm. You just keep doing this until the code reviews are just nitpicking, or the agents say the code is ready to ship. Do some of this every day, and hope that most of the time you don’t find anything bad. The only way to be sure is to do it all the time.

Your garden can get diseases. I mentioned “heresies” above. Agents are very approximate workers and they like to guess at stuff. They will often make wrong guesses about how your system is supposed to work. If that wrong guess makes it into the code, sneaking through the review process, then it becomes enshrined and other agents may notice it and propagate the heresy in their own work.

“Idle polecats” is an example of a heresy that plagues Gas Town. There is no such thing as an idle polecat; it’s not a pool, and they vanish when their work is done. But polecats do have long-term identities, so it’s more like they are clocking out and leaving the building between jobs, which is harder for agents to wrap their heads around. So “idle polecats” make it back into the code base, comments, and docs all the time.

I’ve found the most helpful way to rid yourself of persistent heresies is to capture your guiding principles in the agent priming (onboarding). Which means you have to come up with some guiding principles in the first place.

Your core principles or axioms will be different for every project you’re working on. But the more coverage you can get with them, the more classes of heresy you can avoid or easily correct simply by pointing at the principle they violate. Gas Town core principles include things like Zero Framework Cognition (shared with Beads), which I’ve written about, GUPP, MEOW, Discovery over Tracking, Beads as the Universal Data Plane, and so on. All of these help me stamp out heresies that try to creep into my code.

I’ve been guessing that philosophy/principles is the core piece, and that I need a good way of encoding so genies use ’em. I had already started iterating by creating a skill to review Go tests based on my How to design a test suite you’ll love to maintain and Mocking your codebase without cursing it presentations, and I rarely have feedback to Claude on the tests anymore.

I still have plenty of disagreements on package design, naming, etc., and I haven’t worked on encoding my preferences, or principles, into something reusable there. Luckily, I’ve been taking notes on what I’ve disagreed with the agent about, so it’ll make it easier to start having the conversation to create the skill. When I have quota again.

Separately, I have been experimenting with Gas Town today, and it has chewed through my Claude Max 5x quota in an hour each time. I was warned, so I’m not complaining. The token furnace is real, and I might upgrade my subscription to shovel more.

Gas Town asked me to file a bug because it found a problem with beads (something about wisps?), so maybe that’s why it has churned through the quota burn? Probably not.

Meanwhile, I’ll start digging into how Steve has tried to encode his philosophies into Gas Town. Pilfering gloves on.

The way I have historically managed the hooks is by having a script/bootstrap that symlinks scripts, and then hopefully my team mates run bootstrap when something changes.

So this is a nice way of making that entire problem go away.

I want to admit that this AI/human me, this centaur me – my human understanding is on occasion limited. I lean on the AI quite a bit. Perhaps it isn’t genuine understanding. A tricky question in epistemology. Let’s not even talk about the AI understanding something, or not.

I do know this. I’ve always leaned on other people’s understanding - I’ve reused computers, programming languages, software libraries, implemented algorithms from books and wikipedia. I’ve used search engines. This is more broad than software development. I am limited and don’t understand everything about the world as it’s far, far too much. I stand on the shoulders of giants.

And that’s okay. I’m still empowered.

Let this empowerment sink in. Have you realized what this means? Have you realized what you can do now as a software developer?

I can use AI to do more. Not be more productive, that’s boring and that’s debatable.

Amen Martijn. I saw someone saying that if the AI tools worked really well, then employers would be forbidding them because people would be using them in order to work less. Because if you have an expectation of what could get done, then if you find a way of getting it done faster so you can go home, isn’t that okay? But for some group of employers that’d be tantamount to stealing!!1one

Now, there is a counter to this argument, Steve Yegge says in The AI Vampire:

Now let’s look at Scenario B. You decide instead that you will only work for an hour a day, and aim to keep up with your peers using AI. On that heavily reduced workload, you manage to scrape by, and nobody notices.

In this scenario, you capture 100% of the value from your adopting AI.

In this scenario, your company goes out of business. I’m sorry, but your victory over The Man will be pyrrhic, because The Man is about to be kicked in The Balls, since with everyone slacking off, a competitor will take them out pretty fast.

I don’t know, maybe? I think there are certain types of jobs that will absolutely end up folding if they keep at current levels of work done without change. History shows sitting on an advantage without adjusting is not optimal for survival. And to be fair, Yegge’s post is against the grind culture and about finding a balance augmented by AI and to not become a hollow shell that commands the genie.

At the same time, I’ve started my own company, and I’m doing my best to not grind like I did working for others. I do have some runway from that work, but I hope there’ll be enough work coming in (or products built that makes money) that I’ll make do.

Instead, I have some work that helps me stay afloat, and it has given me time where I can play and explore. Maybe I can leverage it soon, maybe it becomes a rusty tool in the toolbox, or the cornerstone for something new.

Either way, I’m becoming more, as Martijn said.

We inherit. We understand. We stabilize. We extend. We improve what we can without destabilizing what already works.

This kind of work rarely attracts attention. It looks like incremental improvement and steady compounding over time.

But if most of your career is going to be spent in the second act, then the real question isn’t whether you get to start something new.

It’s whether what you inherit gets better because you were there.

I fully agree with Robby, the big piece of what we do day-to-day is making sure we have a better tomorrow in the systems we’re part of maintaining, and that’s the lens we should be looking through.

For example, right now I’ve been working on an old system that’s great at what it does and the business is happy with it, but it’s not much fun to maintain. I have been using genies to help me and it’s been a world of difference in how long it’ll take to work on.

Yet, I spent a couple of hours yesterday manually verifying a long list of numbers to ensure we didn’t break any calculations or displays in the workflow I have been changing. Because the system is a legacy one per Michael Feather’s definition: it didn’t have any tests before I started working on it, and it’s my name on it, so as we’re about to take it to production I need to do my best to ensure it will work. That’s the work.

I had done a server migration and completely missed the .env file when copying, and after recreating it all started working.

Generative systems only work if invariants are explicit rather than implicit. Interfaces must be real contracts, not incidental boundaries. Evaluation must be ruthless. Failures must be loud and immediate. The engineer’s job shifts from typing code to specifying intent and verifying outcomes.

This is very much how I’m currently thinking about working with AIs. I have been using genies to work in a legacy codebase (defined as no tests) I’m new to, and in a language and platform I have barely worked on, and I’m being useful.

I think it’s because I decided to introduce tests to the codebase, verify the existing behavior for the flow I’m changing, and then write my new feature as a failing test. Then the genie has been able to iterate while I think about the changes and how they could fail.

For example, we had to move some columns into a new table, and while the code kept the if null then 0 pattern that existed, I worried it might be overly “safe” and that it would return 0 because the relationship hadn’t been loaded. So we traced through all the call sites to see that we also loaded that relationship from the DB, and the genie gave me a report I could follow and easily verify.

{
  "permissions": {
    "allow": [
      "Bash(pnpm test:unit:*)",
      "Bash(pnpm test:e2e:*)"
    ]
  },
  "sandbox": {
    "excludedCommands": [
      "pnpm test:unit:*",    // Same commands, different purpose
      "pnpm test:e2e:*"
    ]
  }
}

Note: Tested with Claude Code v2.1.3

For example:

{
  "permissions": {
    "allow": [
      "Bash(pnpm test:unit:*)", // Allows pnpm test:unit --arg etc.
      "Bash(pnpm test:e2e:*)",
      "Bash(pnpm test*)"        // ❌ <- will allow testAndDestroyEnvironment
    ]
  }
}

Note: Tested with Claude Code v2.1.3

I hoped to be blazing new trails professionally and not because I was dropping the niece off at daycare after 10-20cm of snow (the wind drift makes it hard to estimate)

To make linking internally easier, I created an Alfred app snippet ({{< relref “{clipboard}” >}}), so now I only have to open the other post, double-tap shift, type “source root”, then run the snippet, and all linked up.

The work itself was about making my “scraps,” that is this site’s tweets, be sent out raw to my syndication targets. I feel that sending a link to something you see in the preview, or it could be inline in the post, is a bit much, I should just let it show up in the platform itself.

I have a couple of things planned for this site, and this was chosen as the first step because it would force me to think about how will I maintain my n8n workflows.

So now, instead of writing some Javascript code, thinking really hard, and then test it by tooting something out, I instead have some unit tests and a way to programmatically update my workflow. So as I go down the rest of my list of tasks I want to do working with n8n will be much smoother.

I had a couple of decisions to make, so I listed them out using the Choice algorithm of thought, and as always it forced me to dig deeper into the problem, even if I ended up doing what I guessed going in. But, the benefit of this process is being intentional and explicit, it gets me into the mode of “I’m trying to list out options,” and to explain what made me make the decision. Since this is now recorded in my notes I can easily go back later to find why.

The kind of highlights of what I got done:

• Updating n8n programmatically: Extract the code from a Javascript source file (glorified grep), and then wrap it so it’ll work in n8n.
• Creating reusable tests in Javascript: which turned out to be a bad idea, because the code was the same but diverged too much, so keeping the tests the same would’ve needed too much conditional logic.
  So I ended up copy/pasting instead of creating a maintenance nightmare. This pattern is useful to know, though, I use it in other codebases where the code is duplicated but some shared logic needs to stay the same. For example, adapters for databases implementing a common interface.
• Telegram Instant Views: Learning about and configuring. Create an Instant View template for this site and learn a bit more about XPath.
• n8n’s update API: Dig into what logic there is calling the update workflow REST endpoint, so I understand what I might break with how I decided to perform updates. Created a guard-rail to try and catch if I’m about to overwrite click-ops changes I hadn’t accounted for when changing locally.

Background and scope of work #

I will (for now) not add images to scraps until I have native support for images in my posting (so they either only exist in a special content type, which gets linked, or they’re attached when posting as a scrap).

I do this because I feel linking to these short-text things that really could just live on Masto/Bsky/etc. is a bit much, be a bit more native to them. Do use them to publish my other content but don’t only send links when they’re not necessary. It feels like being a bad citizen to them when it’s only a sink that way.

The way I’ve setup the sending in n8n right now, is that I have two steps in the status: 1) truncating the body and deciding if we need more, 2) and then adding the link, so I need to figure out a better maintenance pattern.

• Choice: Manage n8n workflow with source management
  • Constraints:
    • Be able to recreate my n8n setup if something goes belly-up
    • Keep as much as possible in source (but don’t overdo it, I’m a single person doing this and can manage myself)
  • Options:
    • Keep n8n fully clickops and keep code snippets in blog
      • Advantages:
        • Super simple and what I’m doing, the status quo choice
      • Disadvantages:
        • If I have to recreate the n8n setup from scratch, painful
    • Create the workflow file in my blog and upload it for changes
      • Advantages:
        • All my n8n stuff is in my blog, so it’s easy for me to deal with, and it’s something I can easily share later so that’s a win for sharing
      • Disadvantages:
        • More work to figure it out right now
          • But probably worth it, I’ll download the workflow file and look at it to see what it says
          • looking at the JSON file it looks pretty straightforward, and using JQ I should be able to pretty easily inject what I need into it, so I can create a small file/script to help me out here that’ll be worth it I think
  • Decision: Create the workflow file in my blog and upload it for changes
    • It feels like a good step towards a maintainable setup and minimal effort to get it going

Doing the choice here wasn’t necessarily super useful, I kinda knew that I wanted to start storing the workflow in my repo, but the point was to step back and consider what I was doing. I was in my head starting to go down the path of just doing what I have been doing, it has been fine. But when I decided to look at the options “the engineer in me” reeled back enough that I felt that this time investment will be worth it.

Okay, the following jq will let me update a specific field in my workflow file, so I will have to make it do it “in context”, so that’s a good start for what I’m doing.

jq '.nodes[] | select(.id == "e1bd320b-1222-4324-9168-22372d2e667c") | .parameters.status |= "m000"' src/n8n/bjorn.now-feed-distribution.json

So I think I want my maintenance to be: full status to be handled in one javascript block, so I can extract that and use jq to update the json file.

I haven’t decided how I will ensure the javascript and json are up to date, maybe I’ll just do a makefile because it’s easy for now? Or maybe I do a template that doesn’t store the “production data” so that I never have the actual prod version checked in and only create it on the fly as I’m updating to encourage avoiding the disconnect. I’ll decide later.

Coding the Mastodon logic #

With a short lunch break I’m now back at it, so let’s start by creating the logic I want so that I can let JQ pick it up.

Designing the solution #

Worry: I’m not sure exactly how I will inject this into JQ right now, will I do a full JS file? Extract it smarter and use JQ as a library since I anyway has setup Javascript in the blog…? I don’t know, I’ll look into that AFTER I have finished updating the code I want and verified it manually, then I’ll do this.

Okay, so what do I have available in the current setup?

I get injected $('RSS Feed Trigger').item into my inline function, which contains all the information from the RSS feed, so that’s perfect, that means I don’t need to send in anything more, I just need to decide what to output.

To make my testing life a bit easier I will now go and take my test data and make that available in a test, so I can TDD this thing.

Looking at my code that I’ve used in mastodon (I just remove the let mastodon = when using) I think it’ll work well as-is, so let’s start by backfilling some missing tests, so I have a clean place to work from, the only problem is that I’m calling it as I should in mastodon because I was only using it manually, so that’ll have to go. For now, I’ll remove the self-calling and figure out how to deal with this when I inject with jq, since it feels like as long as I can get the function definition I can very easily wrap it in a self-call with the param I need.

Backfilling tests for the existing code #

let mastodon = ((item) => {
    let msg = item.json.contentSnippet,
        msgLength = 500-23-1, // the default mastodon post size is 500, -23 chars for the link, and -1 char for newline
        isTruncated = item.json['content:encodedSnippet'] !== item.json.contentSnippet,
        truncateIndicator = '\n… more';
    let wordTruncate = (str, n, indicator) => {
        if (indicator === undefined) indicator = '…';
        if(str.length <= n) return str.trimEnd();
        n -= indicator.length;
        if(str[n] === ' ') return str.substring(0, n).trimEnd();
        let ret = str.substring(0, n).trimEnd(),
            i = ret.lastIndexOf(' ');
        // when there's no spaces at all, just cut in the middle of the text.
        if (i === -1) return ret.substring(0, n);
        return ret.substring(0, i).trimEnd();
    }
    msg = wordTruncate(msg, msgLength, truncateIndicator);
    return isTruncated ? msg + truncateIndicator : msg;
})($('RSS Feed Trigger').item)

Cool, I have a first test showing the standard behavior of not including any links, so let’s continue backfilling everything and then I’ll add in the rest.

That was only two tests, nothing much to write home about but this covers the behavior I have and it’s enough to characterize it for me, so these are the changes I want to do now:

Output the link as well, on a newline of it’s own.

Implementing the new logic #

So I’ll do this first, and make sure it’s done correctly for both tests, I will start by making both tests fail, because that feels like the best way.

If the URL contains /scrap/ then only output link if truncated.

Done, the code is there, I have some tests, it’s nothing too spectacular, but it does what I want. I realize that I should install standard and run the formatter regularly because I’m being inconsistent and I don’t like it. gofmt and black has ruined me 😁.

Updating n8n programmatically #

Now to figure out how to merge this into my workflow file.

• Choice: How to merge my javascript into my workflow file
  • Constraints:
    • No manual steps
    • Need to return the function to run, and then transform it into a “self-run” (((item) => { item.json.link })($('RSS Feed Trigger').item)) so it’ll work
  • Options:
    • Is there some easy AST stuff I can use with node to extract it?
      • Let’s ask claude

        • is there a function in node to parse the AST of a javascript file and to get the content of a variable as a string?

      • Advantages:
        • Exists, will be robust
          • I got back a code example but I’m hesitant to pull in these dependencies

            • const parser = require('@babel/parser');
              const traverse = require('@babel/traverse').default;
              const generate = require('@babel/generator').default;
              const fs = require('fs');
              const code = fs.readFileSync('functions/processData.js', 'utf8');
              const ast = parser.parse(code, { sourceType: 'module' });
              let functionCode = null;
              traverse(ast, {
                FunctionDeclaration(path) {
                  if (path.node.id.name === 'processData') {
                    functionCode = generate(path.node).code;
                  }
                },
                VariableDeclarator(path) {
                  if (path.node.id.name === 'processData') {
                    functionCode = generate(path.node.init).code;
                  }
                }
              });
              console.log(functionCode);

          • Disadvantages:
            • Huge set of dependencies for a small piece of work
        • Mark it up with text and do a text replacement so let mastodon = disappears
          • Advantages:
            • Simple to implement
          • Disadvantages:
            • Possibly brittle. Will rely on me not changing the wrapping of the function
              • But, I will notice pretty quickly if I get that wrong
        • Something else? Search and see how others solve this
          • Because I tend to get too carried away at just solving the problem and not look around enough, because honestly, I think just adding some text markers is enough for what I need and I’m inclined to just do that, because it’s good enough for my needs.
          • But, let’s start by doing a quick search and also ask Claude to help me search, since it’s usually good at coming up with unique search patterns
          • Prompt to Claude:

            I am working with n8n and want to maintain my workflow as code.
            My workflow uses custom javascript in some of the nodes so I have them stored on my filesystem and I want to extract the function in question and inject and run the function in my node.
            Are there existing solutions for doing this?
            My spontaneous reaction for how to solve it is:
            1. Add markers in text in my file
            2. Extract the content between those markers
            3. Strip the prefix/suffix around the function required for testing the function
            4. Wrap the remaining stuff in what I need to then use it in the workflow and inject it into a workflow template using jq

          • Claude is questioning my approach as brittle, which is fair, it suggests I package it as a node module instead or some templating that injects the source code of a function. If I can just inject the source code of a function then that’d be awesome, then I’ll just make a little node script that outputs the correct thing for me
            • Right, so Claude dreamt up a suggested way of implementing my marker idea. And a custom npm module would mean maintaining the code on the server and injecting it into n8n. It totally makes sense if I’m doing more advanced stuff, but for my current situation, I think having a single file trumps that.
    • Decision: Mark it up with text and do a text replacement so let mastodon = disappears
      • My use-case is so small, this feels like the pragmatic choice until I have more advanced needs
      • I wonder if I should just do all this work in javascript or if I should do what my gut says: a small bash script.
      • Quick overview in my head: upside of using javascript is that I can just load the json into a file really easy, and then output to stdout in a pretty-printed form. The logic to process between the markers isn’t that hard and I already have the testing setup
      • The other option is to do it in Python since the rest of my blog is in python. But since n8n is more js maybe it makes sense to keep this stuff in the one language
      • And if I keep it with JS then I don’t have to deal with jq, I can just do the whole thing in one pass by in JS. I think that’ll be easier.

Designing the extraction #

Okay, so what I’ll do is create a little helper script that.

1. I can point at a js file and it’ll extract out the marker I have specified,.
2. Using the content of the marker, change it slightly so it’ll work in place (make it self-calling)
3. Load the n8n workflow file, replace the key in the right place.
4. Pretty-print the json to STDOUT.

I’ll make the marker format //<EXTRACT:name>, the go convention of programmatic stuff doesn’t start with a space and all :p.

Building the extractor #

I wrote up my first tests, ensured the first “do nothing” test passes, and now with my second test in place I’m gonna ask Claude to implement it, because I don’t know these node APIs. And claude did that quickly and the implementation seems sane. Claude decided to wrap everything so no errors would bubble up, so I removed that catch because any errors should bubble up because I don’t want to miss out.

describe('extract.fromFile', () => {
    test(`if the markers aren't found, then nothing is returned`, () => {
        var actual = extract.fromFile('testdata/no-markers.txt', 'test')
        assert.strictEqual(actual, '', 'expected an empty string when no match found')
    })
    test(`if the markers are found, the content is returned`, () => {
        var actual = extract.fromFile('testdata/plain-text.txt', 'test')
        assert.strictEqual(actual, 'Hello, World!\n', 'expected the content between the markers')
    })
})

I also discovered when done that my tests weren’t passing in intellij because it was running the tests from my repo root, so I changed my Node.js test runner config to default the working directory to src/js/ for this repo, because I am deciding now that I’ll only ever have javascript stuff there, and I’ll only run the tests from that directory. It feels like a decent solution. Maybe I have to revisit that if I ever introduce a package.json and decide whether it belongs here or in the root, but it probably belongs in src/js/, but that’s the future 🤷.

Now, Claude did one thing I didn’t intend yet (because there isn’t any test), which is that it will ignore the whole line the markers are on (which I indicated in the docstring) but I don’t have a test for it yet. I want this behavior so that I don’t have to do any special handling to ignore whatever comment marker there is. So, let’s add a test for this even if the code is already implemented. I guess I could remove that comment and reimplement, but that feels like waste, so I won’t. Time to be pragmatic instead of dogmatic about the testing.

Hah! Adding the test was good, because I skimmed the code too quickly and it hadn’t done what I expected, it was checking the full line. So I actually do have to change the code.

Cool, so I have my extract function.

Building the workflow updater script #

Now I can create a script file and use it. I think I’ll keep the script in src/js/ folder and it’ll take the path to the reference workflow file and read it in and parse, and then I’ll work it from there.

I won’t TDD this file because it should be at the level that I’ll notice problems when using it. We’ll see how much I’ll regret that decision later.

In hope that Claude can do this for me, I started by documenting at the top of my script how I want it to work:

/*
 This script's job is to:

Extract the mastodon and bsky functions from n8n.copies.js.

Read the JSON file in the first argument and then replace the nodes for Mastodon and bsky respectively with their functions.

Output the updated JSON object on stdout, pretty-printed
Example: ./update_n8n_workflow.js ../bjorn-now-feed-distribution.json > workflow.json
Will update the node id `e1bd320b-1222-4324-9168-22372d2e667c` so the parameter.status is `={{ ((item) => {... })($('RSS Feed Trigger').item) }}
*/

Then I asked Claude to implement it:

implement @src/js/update_n8n_workflow.js as described in it's first comment, use @src/js/extract.js to extract the information. Only implement the mastodon portion right now 

My example contained too much information, so claude suggested that it needed to wrap the extracted function as: ={{ ((item) => {extracted code})($('RSS Feed Trigger').item) }} but it should be (...)($('RSS Feed Trigger').item), so I told Claude to plan again I was unclear: the wrapping is "(extracted code)($('RSS Feed Trigger').item)".

Implementation Plan for update_n8n_workflow.js
 1. Import dependencies: Import fromFile from extract.js and Node.js fs module
 2. Read command line arguments: Get the workflow JSON file path from process.argv[2]
 3. Extract mastodon function: Use fromFile('./n8n.copies.js', 'mastodon') to extract the function code
 4. Read workflow JSON: Parse the workflow file
 5. Find and update node: Locate node with id e1bd320b-1222-4324-9168-22372d2e667c and update its parameters.status field to wrap the extracted function as: ={{ ((item) => {extracted code})($('RSS Feed Trigger').item) }}
 6. Output result: Print the updated JSON to stdout with pretty formatting
 The script will be executable with: node update_n8n_workflow.js ../bjorn-now-feed-distribution.json > workflow.json

The plan now looks correct, it says “arrow function” instead of “extracted code”, which I guess is because it added a step to strip let mastodon = from the line, so I’ll assume it does the correct thing, either way, this is close enough that manually fixing it will likely be trivial. allons-y!

Importing the updated workflow #

A quick skim of the code and it looks correct, the output also seems correct to me, so let’s save it to a file, run jq to verify it’s valid json (I assume it is since node didn’t bork out), and then upload and see what goes. My saved file locally is what’s live now, so if it goes wrong, I can back out easily.

Right, interesting problem: n8n supports importing from a file and then it adds the file content alongside what you already have. So now I have a copy of all my existing nodes and with a 1 at the end. The content of my new Mastodon status node DOES look correct, though. So that’s a win Not quite what I had in mind, so I feel like I’m doing something wrong. Let’s start by asking Claude about this workflow and see if they can push me towards some online docs. or, n8n has these boxes “I wish this node would…” I can just ask there and see what goes.

Seems like this is working as intended (d’uh) and the way to handle this is doing it by API. And… fair enough, can. so I asked Claude to make me bash script that I could use. Then it started complaining that I didn’t have a name in my file, which I do, so there seems to be a mismatch between the downloaded workflow and what the API expects. D’oh, I had missed a line in cURL -d @- to read the file, so that’s on me.

Then I had issues because apparently my downloaded workflow doesn’t just work with the API, so Claude and I did some back and forth and finally ended up with this that limits the fields I want to update:

cat $1 | jq '{
           name,
           nodes,
           connections,
           settings
         }' | \
  curl -X PUT "${N8N_HOST}/api/v1/workflows/${workflow_id}" \
    -H "X-N8N-API-KEY: ${SANITARIUM_N8N_API_KEY}" \
    -H "Content-Type: application/json" \
    -d @-

Weirdly, I had to update the settings so it only contained the keys executionOrder and errorWorkflow as the other two values there weren’t okay. Whatever, they didn’t seem important so 🤷.

Validating the updated workflow #

Now I have uploaded my changed thing, and it’s time to verify it works as I want. I’m not entirely sure what I should post to verify it :p.

I was looking at the result from running the update, and unless I always save the result of the update I might rerun from a prevous point when updating. Or, no, because it’s a top-level field that I’m ignoring when updating. So it should be fine. But, I think for now, I’ll anyway pipe the update stuff into the saved file so it’s there and see what changes between runs.

Committed, and tested by posting a scrap about “wow… I really spent 5h doing this? That’s longer than I expected.” But, I guess the thing I have to keep in mind that this is the difference between “engineering” vs. “just throwing stuff together.” If I hadn’t invested in the infrastructure stuff for managing this, I would’ve been done after 30-40m when I updated the code. The point was the investment in robustness I think I’ve gained.

Repeat for Bluesky #

Handle the no-link with Bsky too.

Designing the change #

Now, with all that done, time to look into Bsky, there I don’t append the links but instead attach a “website card.” There, I guess I’d have to change it so:

1. The body gets the same logic/setup.
2. The logic is repeated in the “Website Card” field, assuming that having an empty value there will do nothing (which I assume it will, Javascript being very used to weird cases of keys not existing, but I should test (and executed with an empty body there, it just worked), so just repeat the same logic in that place)

this is a bit more annoying, will have to do some copy paste, but I can at least handle the consistency by creating a reusable test.

But I’ll work on this either tomorrow or later today, it’s after 16, and I feel like taking a break. And heading home feels like a good way to clear the head and then continue.

Implementing reusable tests #

20:03 And it’s after dinner, let’s see if we can get this in so we can push it through.

What I think I’ll do is just do a quick duplication of what I have, don’t be clever, just do the dumbest thing possible. With one caveat: I know the tests are mostly the same, so let’s make the tests reusable and configurable and see if that pattern works in node (I bet it does). Meaning, I want my existing tests for Mastodon to be shared with Bsky but change the limit to 300 char instead of 500.

The way I’ll test that is that I’ll make a function that returns a closure over my config, then I’ll run it by passing in my code to execute and then see if the assertions match. I’m not sure how it’ll go with the test runner, but let’s see. I.e. something like:

function reusableTest(name, maxLength, urlLength) {
  return function(toTest) {
    return () => {
      test(`it does stuff`, () => {
        let actual = toTest(arg)
        assert.strictEqual(actual, "whatever I want")
      })
    }
  }
}
describe('mastodon', reusableTest('mastodon', 500, 23))

And another part is, I don’t know how Bsky does links. There’s something about facets and how you can use them to reduce links but a big 🤷 in understanding that. I don’t know if I’ll care to look this up or not.

I could potentially do some smarts and just attach the URL as a card and remove if it’s a single link in the post, which I could make as standard for myself.

Anyway, let’s get the tests working now and see what goes first.

Okay, that kinda just worked as expected, a little surprised at how smooth it was. The commit.

Is this really reusable? #

I am getting a bit worried that the setup might be… too fiddly, but I’ll feel it out a bit more as I add in bsky. This feels like it’s hitting the point where code looks the same but it isn’t really reusable, because it looks similar but differs in intent so as we diverge it’ll just add more if-statements. But, we’ll continue going and feel it properly.

the first case: there isn’t any clear “a link is always 3 chars” so it’ll be counted as whatever the raw text is, so I’ll use -1 to indicate don’t do anything (an if, urgh). Spontaneous thought: I could pass in a function to handle the link calculation instead and just assume it sends me the link, so that would sort that problem out nicer and it keeps the test consistent. My favorite the strategy pattern showing up and making my day cleaner, again.

I’ll just do that, it’s much better than a magic number, and I can create that magic number as a variable from the function call. I know I have to implement this now, so it’s the right time to “Tidy First” á Kent Beck. 🙂.

And there we hit the problem it: it’s all very similar for good reasons, BUT the logic has to be different because the default way where I add the link at the end for Mastodon doesn’t apply for bsky, there I can just attach it as a card. So all the URL counting stuff don’t matter. So, I’m better off copying the tests and changing them slightly, and calling out that they’re similar but importantly different, any optimization here is folly.

I only spent ~15m on this, so I don’t feel too bad about it. In some other cases it would’ve worked out, and it does feel good to keep coding instead of just thinking a whole lot before doing anything.

So, git reset --hard on those files and a revert on the commit. Now let’s start by copying and changing.

And, to get what I need later to decide whether to do the card I’ll just look for msg.endsWith('… more') and if so, attach the link if it’s a /scrap/ link. So that’s pretty straightforward, it does mean I have to include the info, but that’s okay.

Refactoring after working tests #

And done, but looking at how I’m deciding whether something is truncated, I don’t get what I’m doing. Why don’t I just look at the string and check if it changed? That seems way more straightforward than comparing two fields from the RSS….

So I’m just gonna do that and see what happens, but first, commit my changes, then change the format of how I work.

That was quick, maybe 5m to make the change. I looked at the workflow file and the difference between contentSnippet and encoded:contentSnippet seems to have to do with newlines and other formatting, so that’s not gonna be very useful. Seems like a major brainfart that accidentally ended up working 🤷 (likely that those that didn’t need truncating were on a single line)

Okay, next up, now to make sure that update_n8n_workflow.js handles bsky as well and updates it.

Went through and updated it, I mostly kept the very procedural code and just added on, maybe I’ll clean it up a bit more if I loop back and add Telegram (for Telegram I’m thinking I’ll just do the preview in app button intead? but maybe it makes sense to put the scraps in there too, it’s no different from the others and there’s less links :))

Testing bsky live #

And I made a post that would fit 300 chars about helping my brother install some RAM, where the point behind is that having done it before gives confidence that instructions just don’t give. Whether installing RAM or relying on your tests 😜. And it gave me a chance to see that the logic works.

What does the n8n update endpoint do and how does it work? Becuase it feels like not understanding how it’s designed might come and bite me later, so let’s not just rely on the vibe coded stuff that seems to be working.

Wednesday EOD #

21:39 And done, I’ve finished bsky. Tomorrow I’ll be hanging with the niece all day so I’ll format and post this devlog when I’m in the office again 🙂 Okay, scrap that (heh), I’ll finish Telegram before posting. Then for formatting to post, I’ll do it by creating a script alongside Claude to figure out the formatting. I’ll have to brainstorm how then.

Update Telegram logic #

Add the scrap logic to Telegram too (if it’s a scrap, only post the text, otherwise the link)

Configuring Instant Views #

Time to get Telegram to be a bit nicer. I overall don’t want to force people to click through to my site if they’re happy reading where they are. Telegram has these Instant View buttons and I can translate my links to use those instead, so I figure I’ll do that in my channel so you can just click and see the full thing without loading my site. I guess this will mess with my statistics a bit (because I use Plausible which is doing it all in javascript), but 🤷, for now I’m just happy if people wish to to engage with anything I post.

I did create a preview a couple of months back so I started by taking a link to my site and then copying in what I did last time:

~version: "2.1"
site_name: //*[@class="masthead"]/a
article: //article
title: $article//*[@class="title"]
subtitle: $article//*[@class="subtitle"]
author: $article//*[@class="author"]
image_url: //meta[@property="og:image"]
published_date: $article//*[@class="published-at"]
body: $article//*[@class="content"]

That looks pretty good, but I’m not seeing the published time in the live preview, the xpath expression looks right to me. And I similarly don’t see the image_url, and looking in the template website I don’t see that the <head> section is part of the example document (From the future: Nope, that’s wrong, I was looking at the containing doc and not the iframe, it’s all there. Telegram will always do a GET for your page to get the current version and then format the page using these rules). So maybe that’s why? I’ll skim through the documentation and see if I can find why.

I see that the published_date says “unix time” in the docs, so maybe that’s the problem? I gave it the element and it’s in readable, but I do have the RFC3339 format string in the <time> tags datetime attribute. Let’s keep digging.

Right, so the docs shows that there’s a function @datetime that can take an xpath expression and return a unix timestamp, so I likely will have to give it the attribute and then specify the format so it can be converted.

So with that, the pattern should be something like this, which doesn’t work, and I think I’m trying to access the property incorrectly in xpath.

@datetime(-2, "en-SV", "yyyy-MM-ddTHH:mm:ssZ"): $article//*[@class="published-at"]['datetime']
published_date: $@

I asked Claude how to access it in xpath:

I want to access the property `datetime` on the element matched by this xpath expression (for Telegram Instant View), how?
`*[@class="published-at"]

Which gave me the answer that I need to access it by saying /@datetime, which to me reads that I “dig into” the element and @ seems to have to do with attributes/properties of a tag. When I replaced ['datetime'] with /@datetime and saved my match then Telegram showed my publish date!

TIL: Use /@<name> to access the value of an attribute when you’ve selected an element with XPath. With the expression //*[@class="published-at"] you will get the HTML tag that has class="published-at", and if you then want the datetime property you add /@datetime to get it.

And now that I have the published_at working I’ll see if I can figure out how to access my preview image which is available in <meta property="og:image" content="<url>">, and I bet the problem is that I’m not going into /@content the way I need to. Changed and that worked!

There’s this Instant View property called kicker which I don’t know what it means, so I asked Claude and it said:

kicker is the small text that appears above the main headline in article layouts - typically used for:

• Category labels (“Politics”, “Technology”)
• Section names (“Opinion”, “Analysis”)
• Eyebrow text (“Breaking News”, “Exclusive”)

I guess this is some publishing term and it sounds like my “content types” would be fitting here. I.e. post, crumb, link, scrap, etc. which I actually don’t show at the moment on my single pages. Maybe I should add that in there? Or should I just skip it? It’s part of the menu. Although, I have added it into the article’s class attribute what category it is, because I have been planning to do custom styling of scraps (pre-emptive code, I know bad, but turns out this bit of unnecessary future planning might be helpful now.) So, question is, can I strip away the post and single values from that string only leaving the unique piece?

In the list of functions there’s a @match function that takes a regex, so that could work. Let’s see if there’s anything else before I go into making a regex (which admittedly can be pretty simple given how it’s setup right now)

It seems that’s the only function I have. So right now, I’ll do it super simple and since my class attribute looks like this: class="post devlog single" I’ll just do post ([^ ]+) and then extract the second, the single also isn’t needed, but since I’m doing this on the article element I don’t feel the need to do more, I’ll just have the rule that the first class is always the post and this will work. The @match function’s second argument is which capturing group you want to use. While debugging it was a bit non-obvious to me that the debugger’s output included class="devlog" but it seems that it shows the full context, but when you add it to the kicker as $@ (which is the return value of the last function call) then it’ll just do the string and not where it was from. 🤷.

@match("post ([^ ]+)", 1): $article/@class 
kicker: $@

Next up, author_url which is a property on the <a> tag which contains my name, so let’s dig into it: author_url: $article//*[@class="author"]/@href.

Using Instant View links or not? #

And with that, I have the Instant View working as I want in the preview. Now to figure out how I use it when posting so others can see it. The documentation for it says:

Note that if you send the resulting t.me/iv?url=...&rhash=... link to other Telegram users, they will see an Instant View page built using your template (the rhash parameter in the link determines which template is used to create the page).

So all I have to do is wrap my URL to this and it’ll work. The downside of that is that then if you click that URL it’ll lead to Telegram instead of my site, and it’s not obvious to me how to click through to my site. I added the document_url but it seems it doesn’t show the real URL. I don’t like this. MAYBE what I could do is add a second link that allows the instant preview, as a way of making it simpler for Telegram users. But iunno, it also feels clunky. I could try to submit my template and see if it gets approved and then it just works. I asked Claude and it says the same thing, it’s not possible, and if you want that then you need to submit it. So that’s the only real option, I don’t want to completely nerf the readability for Instant View while I also want to make it simpler for others to read it where they are. The same reason I have the full content in the RSS feed. :) So I added 10 links that should work, looked that they seemed correct, and added them as checked. Then I added the homepage and blog post listing pages and saw that they don’t have any Instant View, which is what is supposed to happen.

Final Telegram logic and decision #

Which leaves my Telegram posting logic as:

1. If the URL of the item contains /scrap/ then post the content in full (I’ll deal with images later, but for now scraps are text-only with no formatting)

2. Otherwise, post only the link so it can be clicked through and if the Instant View is approved then that’s available.

And that took about 1.5h to do. Next up, to research how the update endpoint works for n8n, and then to do the formatting of this post and post.

Understand how n8n updates work #

I left a note for myself earlier that I wanted to check how n8n handles the updates, so I can feel more comfortable in not overriding stuff.

Digging into the source code #

I figure it’ll be a bit annoying to find this, so I’ll just ask Claude to find it for me:

where is the n8n source code for the `PUT` logic for workflow updates?

And it did some searches and told me path in the repo is packages/cli/src/public-api/v1/handlers/workflows/workflows.handler.ts so I went to GitHub and opened.

It does special handling for settings and will only change settings I have set and otherwise let existing ones be.

Okay, working my way to the WorkflowRepository it doesn’t implement update itself, so it’s probably in the base class, so let’s see what’s there. The base class comes from @n8n/typeorm and I don’t know where that is. I looked in the @n8n folder on GitHub but didn’t see it. I tried pressing t and typing it but it doesn’t seem to be part of the path. The search showed that there’s a CLAUDE.md so maybe it contains something useful? (I’ll dig a bit first before asking Claude to find it for me). And there I find this: **Backend:** Node.js + TypeScript + Express + TypeORM which seems to indicate that TypeORM might be a general package? I searched for TypeORM and saw a linter step to ensure we only use it in @n8n/db folder, so is there a definition of @n8n/typeorm in the db/ folder? The package.json lists the dependency as "@n8n/typeorm": "catalog:",, so maybe there’s something in this catalog folder (or maybe package?) I had a gut feel since I saw pnpm mentioned and something around monorepos, maybe this is a special pnpm thing so I did a search for “pnpm catalog” and found explains it’s a “workspace feature for defining dependency version ranges as reusable constants.” So if I get that right, it’s how you ensure the same version of TypeORM is used across this entire monorepo. Sounds neat. So, that means I’ll just assume we’re doing the bog standard TypeORM stuff so I’ll look at that. But I will assume it’ll simply do: replace the named keys if they’re part of what comes in, because a generic package usually doesn’t do more than that.

TypeORM’s documentation for update says: update - Updates entities by entity id, ids or given conditions. Sets fields from supplied partial entity. And I read that to mean: we’ll replace all keys we see, and the others will not be touched. So I won’t accidentally unset any fields I don’t change. SO, maybe then I should try and limit what I send even further since I only really want to update the nodes portion, so could I get away with only sending that? And the answer is no, because then it gives an error that I need to provide connections.

Adding “only update if version is what I expect on the remote” #

But, it’s fine, I’m anyway saving the version in the repo after each update, so I would only loose things if the version live is different from what I have. Which for now, I don’t worry about. I COULD do a check to see that the current version is the same as what I have downloaded or warn. I guess that would be pretty tiny effort, and therefore worth it since all you’d have to do to sort it out is run get-workflow and then recreate the update and check it. So… letting me know there’s a mismatch WOULD be useful.

The way to do that then is: jq -r '.versionId' bjorn.now-feed-distribution.json gives me the version id, so then I would have to pull down the current version of the workflow and check the version number is the same: ./get-workflow | jq -r '.versionId' and then compare it, so… screw it, let’s put that in the update script.

# Only update the workflow if the `.versionId` ISN'T the same as the server,
# because we're downloading the workflow and then applying our updates to it.
# This intends to avoid overwriting anything we didn't expect.
localVersion=$(jq -r '.versionId' "$1")
serverVersion=$(workflow_id=$workflow_id ./get-workflow 2>/dev/null | jq -r '.versionId')
if [ "$localVersion" != "$serverVersion" ]; then
  echo "The local workflow file ($1) is stale to the server version" >&2
  echo "  local version : ${localVersion}" >&2
  echo "  server version: ${serverVersion}" >&2
  echo >&2
  echo "Hint: Pull down the latest version as and recreate:" >&2
  echo "  ./get-workflow > bjorn.now-feed-distribution.json" >&2
  echo "  ./create-update" >&2
  exit 2
fi

Added a hint to myself in case I forget.

Final thoughts #

This entire endeavour got a bit more robust than what I’ve had before with my n8n setup, but that’s because I’m planning to add more functionality to my POSSE setup. So I wanted to make sure I don’t create more of a mess for myself as I change things, and create more things to check.

This isn’t 100% the production level I would do but it’s good enough for where I am. The “create the update” script is pretty rough, but I also expect that I will very rarely change it, and it’s built around a couple of assumptions that I don’t see changing. So keeping it hacky, or more as disposable, feels okay to me. If I had more people working on this I might not be, but for now, there’s enough guard rails.

I’m happy I decided to add the optimistic check that we’re updating against the version on the server, it’s the kind of thing that was really straightforward and simple to add and it’ll rarely fail, but it’ll warn in case I end up doing click-ops and forget to sync back to the repo.

With the expression //*[@class="published-at"] you will get the HTML tag that has class="published-at", and if you then want the datetime property you add /@datetime to get it.

Went over. Applied pressure. click “oh, that’s all?”

But, I discovered that despite being within the character limit, one of my URLs were truncated when posting to Mastodon. This is because Mastodon does something non-obvious: it treats all URLs as 23 characters, no matter if they’re shorter or longer.

This is because they copied this behavior from Twitter, which ran all links through their t.co link shortener. The reason is that Mastodon doesn’t want you to use a link shortener, since it hides the real URL (i.e. makes rick rolling easier 😜).

So the module truncated the text in the status. Since it wasn’t URL-aware, all I got was a broken link.

I decided to fix it myself, because dammit, I’m a programmer. It’s an unfamiliar codebase I know nothing about, so I rolled up my sleeves and asked Claude, “Pretty please, can you fix the problem and add tests?” (ah the modern world we live in)

The key constraint: I needed to understand every line of code before shipping it, and it had to pass my quality standards because my name would be on the PR. Happily, that worked out becuse my PR was accepted. 🙂

Here’s how I worked through it over three days. All commits are here if you want to step through them. I really intend to share these devlogs earlier in the future, but I got lazy 😅

The rough notes #

Lightly edited for the web, and I’ve kept the day breaks in.

2025-10-08 #

I discovered that my mastodon poster truncated the URL (which seems to indicate that the n8n plugin does a naïve counting of characters, whereas it should only count 23 chars/URL, because Mastodon don’t penalize longer URLs so we don’t need link shorteners.

So I looked at the source for the package in question and found the 500 limit (I had looked at this before) and knew it was hardcoded, and then I decided to download the repo and ask Claude to find the bug and suggest a fix:

this is a plugin for n8n, and @nodes/Mastodon/status/StatusMethods.ts seems to have a bug where if I post a status with a link then it will truncate the status assuming the link takes up the full
length it has, instead of only 23 characters as is defined by Mastodon. Identify where this bug comes from, explain it, and come up with a plan for how to fix it. Also suggest tests to add that
fits with existing tests in this repostiory.

It then came up with a plan that I rejected because I wondered if there any existing packages that implement this logic, since the Javascript community is quite keen on tiny packages

Fix Plan

1. Create URL-aware character counting utilit

- Add new method ValidationUtils.calculateMastodonLength() that:
  - Detects URLs in the text using regex
  - Counts each URL as 23 characters (Mastodon's characters_reserved_per_url)
  - Counts remaining text normally
  - Returns the effective character count

2. Update validateStatusParam function

- Replace simple sanitizeStringParam with URL-aware validation
- Use the new calculateMastodonLength() to check if status exceeds 500 chars
- Only trim/reject if the effective length (with URL shortening) exceeds limit
- Keep the full URL text intact (don't truncate it)

3. Add comprehensive tests

Following the existing test pattern in __tests__/status.test.ts, add:
- Test for status with single URL that would exceed 500 chars without URL counting
- Test for status with multiple URLs
- Test for status with URL at the beginning, middle, and end
- Test that status correctly rejects when effective length > 500
- Test that long URLs are preserved in the request body
- Test edge cases: URL-like text that isn't a URL, localhost URLs, etc.

4. Optional enhancement

- Consider fetching instance configuration (characters_reserved_per_url) dynamically
- For now, hardcode 23 as it's the Mastodon standard

So I asked Claude to look for a package:

search and see if there's an existing npm package that does this calculation of post length per mastodon so we don't have to write it ourselves

It searched and didn’t find anything (it was a bit slow, so I decided to look as well, and didn’t find anything obvious), when I looked back after giving up it asked to download the original Ruby source for the status length validation and then came up with new search patterns

It then found twitter-text and suggested to import it and use

Fix Plan for Mastodon URL Character Counting Bug

1. Add twitter-text dependency

- Run npm install twitter-text (version 3.1.0, stable and well-maintained)
- This library provides the same URL detection/counting logic that Mastodon uses

2. Update ValidationUtils in Mastodon_Methods.ts

- Add new method ValidationUtils.countMastodonLength(text: string): number
  - Use twitter-text's parseTweet() or extract URLs manually
  - Count each URL as 23 characters (Mastodon's standard)
  - Return effective character count
- Keep existing sanitizeStringParam for other use cases

3. Update validateStatusParam in StatusMethods.ts

- Replace line 16: Instead of truncating, validate the effective length
- If effective length > 500, throw error with helpful message
- Don't truncate the actual status text (preserve full URLs)

4. Add comprehensive tests to tests/status.test.ts

Following existing test patterns, add:
- Test: Status with long URL (>100 chars) that fits within 500 char limit
- Test: Status with multiple URLs counted correctly
- Test: Status that exceeds 500 chars even with URL shortening
- Test: URL preservation (ensure full URL is sent to API, not truncated)
- Test: Edge cases (URL at start/middle/end, multiple URLs)

This approach uses a proven library rather than reinventing URL detection regex.

I wasn’t sure about all this because looking at the repo it looks like a big dependency, and maybe it has too much extra stuff that doesn’t really come into play for Mastodon?

will `parseTweet()` introduce any other logic that might not work with mastodon? Might we be better off copying the code around links (and tests) and adding it to this repo (do the licenses match?)
We *cannot* break the existing behavior and throw an error instead of truncating, but we can change the truncating behavior to the effective length instead of actual length. 

It then went off and did a bunch of searches around east-asian specific character encodings (Japanese and Chinese alphabets as far as I can tell)

I then got a new plan that looks better, but I still wonder about the when possible for preserving URLs (I expect it is that if there’s not 23 chars left, then it has to cut, so I will have it clarified in a more detailed plan)

Updated Fix Plan (Mastodon-Compatible)

1. Copy URL regex from twitter-text (with attribution)

- Add file header comment crediting twitter-text (Apache 2.0 license)
- Copy only the URL detection regex pattern (battle-tested, handles edge cases)
- No dependencies needed - just the regex

2. Create ValidationUtils.calculateMastodonLength() in Mastodon_Methods.ts

- Extract all URLs using the copied regex
- Replace each URL with 23-char placeholder ("x".repeat(23))
- Count remaining characters using standard .length
- Return the effective character count
- No CJK weighting - Mastodon treats all chars equally

3. Update validateStatusParam() in StatusMethods.ts

- Calculate effective length using new method
- If effective length > 500, truncate at boundary that fits within 500 effective chars
- Preserve full URLs when possible (don't cut URLs)
- Keep existing truncation behavior (no breaking changes)

4. Add tests to tests/status.test.ts

- Status with long URL (>100 chars) that fits in 500 effective chars
- Status with multiple URLs
- Status requiring truncation with URL preservation
- CJK characters counted same as Latin (no weighting)
- Edge cases: URL at boundaries, multiple URLs

I asked what when possible means and guessed some cases (I forgot to save the prompt)

⏺ Cases Where We Cannot Preserve URLs:

1. Theoretical impossible case (highly unlikely in practice):

Text: "Check this out: https://example.com/article"
Actual length: 44 chars
Effective length (URL=23): 39 chars ✅ Fits!

But if someone tried:
Text: 480 chars of text + " https://example.com/very/long/url"
Actual: 520 chars
Effective: 480 + 23 = 503 chars ❌ Over limit!

To fit within 500 effective chars, we'd need to:
- Remove 3 chars from somewhere
- We can't split the URL (would break it)
- We'd have to remove text BEFORE the URL

2. Multiple URLs scenario:

Text: "See https://example1.com and https://example2.com and more text..."
If effective length > 500, we might need to:
- Keep URL1 (23 chars)
- Keep URL2 (23 chars)
- Truncate the "and more text..." part
- OR drop URL2 entirely if there's not enough room

3. The actual problematic case:

Text: 450 chars + "Visit https://example.com/some/long/url for more info and keep reading..."
Effective: 450 + 23 + 35 = 508 chars ❌

To fix:
- Keep first 450 chars ✅
- Keep URL (counts as 23) ✅
- Truncate "for more info and keep reading" to fit in remaining 27 effective chars

The Real Answer:

We can ALWAYS preserve URLs! Here's why:

- URLs only count as 23 chars in the effective length
- If someone has room for 23 effective chars, they have room for the full URL (even if it's 200 chars long)
- We just need to truncate the non-URL text to make room

The algorithm:
1. Find all URLs and their positions
2. Calculate effective length
3. If over 500:
  - Truncate text BETWEEN or AFTER URLs
  - Never truncate the URL itself
  - Work backwards to find a safe truncation point

Edge case that might force URL removal:
Text with 22 URLs: Each counts as 23 = 506 effective chars
Even with ZERO other text, we're over the limit!

In this case, we'd have to drop some URLs entirely (remove the last URL(s) until we fit).

Should I proceed with a plan that preserves URLs when possible, but drops trailing URLs if necessary when there are too many?

So, now to handle this I will ask it to write this high-level plan into high-level.plan.md and then to create a detailed plan that could be implemented by a junior engineer, so we then can ask sub agents to implement them step-by-step. I saw the plan and it suggested to drop URLs that went over the limit, so I asked it to instead keep them.

I haven’t added any general/background context to this repo about my preferences, so I wonder if this will be enough to give me something useful in this repo:

create a deatiled implementation plan that a junior engineer could implement.

Ensure each step is written in a TDD fashion and that the tests are passing, changed to show the expected new behavior (red),
and then the change is implemented to make it pass (green).

Only implement as much as is needed to get each test passing and no more. 
Cover the copied code from Twitter with tests too.

It came up with a detailed plan, it looked good enough (skimmed it), so I asked claude to:

execute the test suite to verify it runs, if it runs successfully then document how to run the tests in the plan and then save the plan as plan.md

Then it couldn’t run any commands, likely because I never ran npm install in the folder so I did that and verified that npm test worked and then asked Claude to try again.

Next up, execute the plan: Now plan to execute @plan.md with subagents and marking off which steps has been done in the plan as they finish..

Strategy

Use general-purpose agents in parallel where possible to implement the plan steps efficiently. Track progress by updating plan.md with checkmarks as each step completes.

Phase 1: URL Extraction (Steps 1.1-1.6)

- Agent 1: Implement URL extraction utility with all tests
 - Create __tests__/url-extraction.test.ts
 - Add extractUrls() to ValidationUtils in Mastodon_Methods.ts
 - Iterate through all test cases in steps 1.1-1.6
 - Mark steps 1.1-1.6 complete in plan.md

Phase 2: Length Calculation (Steps 2.1-2.5)

- Agent 2: Implement Mastodon length calculation with all tests
 - Create __tests__/mastodon-length.test.ts
 - Add calculateMastodonLength() to ValidationUtils
 - Iterate through all test cases in steps 2.1-2.5
 - Mark steps 2.1-2.5 complete in plan.md

Phase 3: URL-Aware Truncation (Steps 3.1-3.9)

- Agent 3: Implement truncation with URL preservation
 - Create __tests__/url-truncation.test.ts
 - Add truncateWithUrlPreservation() to ValidationUtils
 - Iterate through all test cases in steps 3.1-3.9
 - Mark steps 3.1-3.9 complete in plan.md

Phase 4: Status Validation Update (Steps 4.1-4.4)

- Agent 4: Update status validation to use new utilities
 - Add tests to __tests__/status.test.ts
 - Update validateStatusParam in StatusMethods.ts
 - Verify all new tests pass
 - Mark steps 4.1-4.4 complete in plan.md

Phase 5: Final Verification (Step 5)

- Run npm test to verify all tests pass
- Update plan.md with final completion status
- Report summary of what was implemented

I then set Claude to execute and left some questions for myself to answer after we were done:

• Are there more places we should use this new validation/truncation logic?
• Is our new code implemented similarly to the rest of the code in this repository?
• What questions should I ask you to verify that we don’t break something?

00:34 It’s late, so time to let Claude spin away while I prepare for sleep.

00:50 Okay, while prepping for sleep it finished and I had a look on the new tests the tests have some problems that we’ll need to iterate on:

• Doesn’t assert the exact values we’re looking for
• Doesn’t make the 500 or 23 constants and are instead magic numbers, let’s name them
• The truncation logic is too smart and it should just cut the URL and leave an ugly “scar” if that’s what’s required, that’s fine. We can iterate on that

I think the way to work with this is to create a fork and do my changes in a repo with small focused commits, and then show the work as I commit, so I indicate how I grew the solution

Now, sleep for reals

2025-10-10 #

Okay, back at it again after a day’s break, got some tunes on and now to review.

Okay, to help me document how I’m working on this I will commit the change I got from Claude, and then I’ll do my changes from there and commit as I do them. Doing this so that it’ll be easier to blog about it, and I don’t know if that workflow will be what I want/need, so we’ll see.

Reviewing #

Starting the review by looking at the status.test.ts since I’m supposed to have good tests that tell me what’s going on, so that’ll be the lense through which I review this.

First off, I got header comments explaining the change that I don’t need, so nixing ’em, and I think all these tests belong in a describe that shows that the tests belong together. Commit

Then, let’s get going with the first test “should preserve long URL when using URL-aware character counting” doesn’t do one that will hit the problem, and the test doesn’t check the count is what we expect it to be (which is also a problem). okay, changed the test to only contain a URL and then verify that the expected status is exactly 23 characters long, which passes. Commit

Next is a test with multiple long URLs, which is useful, make sure we don’t do this for only one URL in the status. The URLs are not pushing it as far as it should, so I made both URLs more than the total length of a status (80 -> 500)

const url1 = 'https://example.com/' + 'a'.repeat(80);
const url2 = 'https://www.example.org/' + 'b'.repeat(80);

The text is a bit annoying so simplifying it for my own sake to make the length calculation simpler, it’s a list of links one per line (2*2+1 = 5 + 23 + 23 = 51):

const text = `- ${url1}\n- ${url2}`;

Commit.

And about now I’m annoyed at the way the mock implementation has so much setup, it doesn’t follow my coding style (too much repetition), but this isn’t my project, and it seems to be how all other tests are written in this file so we keep it. Consistency and avoiding surprises is more important than my personal style.

Now comes the really nasty bit: Claude decided to truncate text instead of URLs which isn’t what I want, if the URL is placed so that it’s unavoidable that it will be cut, then cut it. Don’t remove it, and don’t remove text before it. It’s better to indicate that something went wrong (by showing a cut URL) than silently dropping it (I’d rather go boom than be silent, been saying this for a very looong time, mostly living that philosophy :p)

So I think this particular test will have to change. And about now I’m regretting that I didn’t commit already because I feel I should’ve done it per test instead. Because now I’m about to make the test red, so I want to make sure I can change it cleanly. So, I’ll undo my changes (thanks IntelliJ for having infinite undo in the same session), commit, and then redo per function. That took ~5min to fix, and while not really necessary, I feel a lot better from going back and redoing and creating clean commits to show the work (so the commits linked was made before this).

Okay, now, this test I’ll also change up a bit:

• Loong text, ax480, a space, and a url which means the effective length will be 505 so the URL will be cut
• I changed the assertion on the sentStatus to be the naively cut status instead (since the URL can’t ever fit now, so it will just have to mangle the URL)
• And as expected, the test is now failing, so that’s good. Now, let’s ask Claude to fix the failing test I’ve created
• I highlighted the test in IntelliJ and opened up Claude and said (mostly because I haven’t looked at the code, this might actually be faster to do manually, so I’ll look at it as the fresh Claude session is figuring out what’s going on):

  • The highlighted test is failing correctly, I want to adjust the business logic to match. Confirm the test is failing by running `npm test` and then plan how to fix it 

Found the place where this is, it’s in nodes/Mastodon/Mastodon_Methods.ts and the new truncateWithUrlPreservation.

And I see that Claude is spinning and reading what it’s doing I realize I made a logical error: if Mastodon always counts URLs as 23 chars, I can’t truncate a URL and make it work. The logic Claude made was reasonable since I told it to never raise an exception. So that means I need to make this case an explicit negative case, that it will fail the validation, and I could exemplify that better by making it a really short but valid URL (ex https://example.com which is 19 chars)

Okay, asked Claude to get to it, but it’s struggling with the logic and I’m realizing that I should just add another test alongside this where we have a long URL at the start and a really long text at the end, that we can just truncate as needed, so it can see the logic better.

BUT, for right now, I’m gonna start a stew so I’ll go do that and then let it… stew for a coupe of hours so I can continue then

20:15 back and doing stuff again

I added another test that swaps the order so it’s <url> <text> and now it’s failing too, so let’s clear the session for Claude and start over

these two tests are failing because the business logic is incorrect, suggest how we can fix the business logic

Claude came back with a plan to let the server fail instead of us truncating long tests, which won’t make the tests pass, so I prompted:

before our changes this library truncated any text >500 chars, so we need to retain that logic. BUT if we end with a URL let it through and let the server

Claude then suggested a flow that seems to work:

New logic:
1. First check actual length (not effective length)
2. If text.length <= 500 → return text as-is (no truncation)
3. If text.length > 500:
  - Check if characters after position 500 are part of a URL
  - If yes (would break a URL) → return full text unchanged
  - If no (normal text overflow) → truncate at position 500

This preserves backward compatibility:
- Original behavior: truncate at 500 actual characters
- New behavior: same, BUT skip truncation if it would break a URL

And Claude implemented the fix and did it TDD style and highlighted that we have more code than necessary to pass, so I need to write another test case that exercises all the extra code we have in truncateWithUrlPreservation

2025-10-11 #

14:43 The next day, I ended up watching TV yesterday, and today I’m feeling sluggish

But I was reflecting about this yesterday and I’m a bit unsure about how to write a test that refuses the current “fix” of " if the actual is less than 500 let through" because it’s true since the edge-cases it won’t do it for is basically where the URL is wrong, BUT, the URL could be wrong at the start and the text after is okay to be truncated. I.e. cases where say https://example.com (19) x 21 = = 399 actual but the effective length is 483 and if I add 18 characters of text it’ll fail and could be truncated.

Maybe that’s the case to do, because it’ll force it to handle it correctly.

I ended up changing the “this can be truncated” test so the URL is shorter and the text is exactly so it should pass, and then pointed out that we need to hint that we need the special logic if there are URLs in the text.

run the tests and suggest how to fix the them while not changing any tests, the underlying business logic is incorrect and too complex. Hint: consider only doing the special handling logic if there is a URL in the status text

Claude came back with a plan:

New simplified logic:

1. Extract URLs first to determine which path to take
2. If NO URLs in text:
  - Simple check: text.length <= 500 → return as-is
  - Otherwise → truncate at 500 actual characters
3. If HAS URLs in text:
  - Calculate effective length
  - If effective ≤ 500 → return as-is
  - If effective > 500:
      - Calculate how many actual characters to remove: excess = effective - 500
    - Target length: targetLength = text.length - excess
    - Check if truncating at targetLength would break a URL (cut it in half)
    - If YES (would break URL) → return full text unchanged (let Mastodon fail)
    - If NO (safe to truncate) → return text.slice(0, targetLength)

And that update gave me the logic I wanted, so now let’s see what the change looks like and it’s good.

As I now look at it and am preparing the commit message I realize, this doesn’t fit the original design of this library/n8n node: it was blindly truncating, so I could also just truncate just before this URL so we can post. It doesn’t fit with how I discovered this problem, which was a truncated URL (which was still longer than 23 characters but wrong).

So, with that, I will instead say: nix the URL because it goes with the grain of the library and people like me have to ensure they truncate correctly. It’s the least surprising thing we can do. But, I have done all this work and despite realizing that I went down the wrong path, I should commit what I got so I can see the changes. I learned something and that’s still a win.

Okay, done , and I asked Claude to look at the comments I’ve tried to add to clarify the logic and it suggested some improvements to them which I’ve folded into the commit.

review the changes we've done, are the explanations in text clear enough that those reading the code would be able to understand?

Committed.

I’m not sure if using Claude here has saved me time, but I have been doing it in low energy and while watching TV, so upside is that it got done compared to that I likely wouldn’t have put in the full energy otherwise.

Although, partly that’s because when fixing the bad stuff I didn’t want to go in and learn how all the code worked, becasue I’m relying on the tests to tell me what’s working and not, so that’s pure laziness on my part. And the fact it dug through the full codebase and made a first pass when I was turning in for the night is sooooo worth it. I’m sure I would’ve spent more time figuring out the codebase on my own otherwise.

But, I am also saying this before I have manually tested any of this. I have only run the tests so far and not plugged it into n8n and seen if it works. So my optimism might still be premature.

Okay, updated one test file and the corresponding business logic, let’s start with the next test file (which I changed a little for the previous task, so I know there’s work to do).

2025-10-12 #

I did some final cleanup yesterday and didn’t document it all, it’s only available in the commits, but I basically went over the changes as I would any PR at work and then raised it. The maintainer looked at it during the day and then left a nice note thanking me for being thorough and documenting my code well 🥰

Hey Björn!

Thank you so much for your outstanding contribution with PR #4! 🚀

Your pull request to fix the URL character counting behavior was absolutely fantastic - it addressed a real problem that many users probably didn’t even realize they were experiencing. The fact that Mastodon counts all URLs as exactly 23 characters regardless of their actual length is such an important detail, and your implementation handles it perfectly.

What I especially appreciated about your work: #

✨ Thorough Research - You referenced the actual Mastodon source code to validate the behavior
🧪 Comprehensive Testing - 19 new tests covering all the edge cases!
📚 Excellent Documentation - Clear comments explaining the “why” behind the logic
🔧 Smart Implementation - The decision to remove entire URLs rather than break them is brilliant
🔒 Clean Integration - Minimal changes to existing code while adding powerful functionality

The Impact: #

Your fix means users won’t have their URLs unexpectedly broken when posting longer content. That’s a real quality-of-life improvement that will prevent confusion and frustration.

Code Quality: #

The implementation is clean, well-tested, and follows all the best practices. It’s the kind of contribution that makes maintaining open source projects a joy!

Would you be interested in contributing more to this project? Your expertise with Mastodon’s APIs and attention to detail would be incredibly valuable.

Thanks again for taking the time to identify this issue, implement a robust solution, and provide such thorough testing. This is exactly the kind of contribution that makes the open source community amazing! 🙌

Best regards

As they said, these interactions make open source fun because it’s people working and building stuff together 🙂

I realized this while trying to calculate what height TV bench I should get:

Annoyingly, you can’t declare a variable and see its result in one step. I found two options for this, and you decide which you prefer.

If you’re okay with an extra line you can show it by declaring the variable again, just let notes fill in the part after the =:

MyValue=25*4
MyValue=100

Or, instead, write the calculation first, and let Notes show the result, then add the variable name.

First, do the calculation:

25*4=<wait for Notes to autofill>

Second, name the variable by adding the name and = at the front of the line:

MyValue=25*4=100

I naturally ended up doing this second while I was working it through, since I wanted to see the result first, and then I named the variable.

Notes also handle some unit conversions for you:

The average daily temperature in Singapore as Fahrenheit is: 
0f + 32c = 89.6f

How many Swedish Krona do I get from one SGD right now?
0sek + 1sgd = 7.22 SEK

I started on my phone taking Notes, and was surprised to realize I didn’t have to fire up Python on my computer to finish it. A new useful tool that I always carry with me. 🙂

Documentation links to Apple:

• for iOS
• for macOS

The twist compared to straight up “the opposite of this” is that there are “forbidden words” that you’re not allowed to use, and only 100 characters.

I love the transparency and setup of their page explaining how long it should take to process my application, there’s a goal (7 working days), and which applications they’re aiming to process this week (those from 14-19th of October). Wish more gov’t services did this. eyes Försäkringskassan

I like the distinction between disposable and durable code: it’s about whether you try to make the code maintainable or not. Most code when working at a company is durable code, because the outcome when we get it wrong is so high (even if it’s just the risk of losing money or at worst, our job).

And the idea that we can experiment, create POCs, the 10 variations of an idea to see which one works better… that’s great. Work with the genie and figure it out, then spend the proper time and effort making it durable.

Durable code is used when the stakes are high, the losses are material, the ripple effects of failure or performance changes throughout the system are complex and unpredictable. Highly regulated industries require durable software.
[…]
Here’s one (unscientific) rule of thumb: the lower on the stack you go, the closer you get to laying bits down on disk, the more dependable and predictable our software has to be. Databases and operating systems will be durable code til the stars die out.
[…]
The difference between disposable code and durable code is not about whether the code was generated by AI or written by a human, or even how difficult it was to write. The cost is defined by the standards you are building to, and the rest of the software development lifecycle: how well you expect to maintain it, extend it, migrate it, understand its behavior, or fix it when it breaks. This is the expensive part of software development, the type that requires deep expertise and familiarity with your language and environment. Disposable code is cheap because you don’t even try to maintain it.
[…]
This isn’t about “using AI” vs. “not using AI,” or even about generating code vs. not generating code. It’s about understanding the cost model and the risk profile of the type of development you’re engaged in.
[…]
If it’s easy to achieve proficiency with disposable code generation tools, it probably won’t be thought of as software development (and the pay scale will drop accordingly). If I had to guess, I suspect it won’t be a profession at all so much as a skill set, much like typing or spreadsheets, that any tech-literate modern worker is expected to pick up in order to perform the functions of their job in marketing, sales, product, design, etc.
[…]
The coordination tax on large groups is enormous; if AI can help a smaller number of engineers own more product surface and move faster with more confidence, that’s exciting.

As Charity says, I think there likely will be changes in what programming, or rather, software development, is. Just as it did with typing before, a skill every office worker just need to have. Not that all of us are writers, just because of it.

I’m also excited at how working with a genie might open up codebases, so you need fewer people to own and maintain larger codebases (because maintenance is in communication within a team).

For example, I recently contributed to a new codebase in relatively little time and it was done so fast to the genie figuring out where to make changes. Even if I had to change most of it, because the quality wasn’t at the level where I wanted to put my name on it.

also TIL, in Singapore you only need $1 as starting share capital and in SE it’s a minimum of 25,000 SEK (~3,500SGD)

So the below won’t match because it’s looking for a literal $ in the string, instead of matching at the end of the string:

file="https://example.com/blog-post/index.html"
[[ "$file" =~ "/index.html$" ]] && echo MATCH

But this will:

file="https://example.com/blog-post/index.html"
[[ "$file" =~ /index\.html$ ]] && echo MATCH

Note: [[ ]] is a Bash extension of the test command that supports regexes (among other things). The [ ] is the POSIX standard test (see man test), so [[ ]] features may not work in other shells or in limited shells like ash or sh.

I learned this while removing index.html from file paths to bust Cloudflare’s cache for directory listings/pretty URLs. I then used parameter expansion to replace the match with an empty string, so directory URLs are also purged:

echo ${file/index.html/}

I used to think there was some magic rule about how | decided where to split, but it’s simply: characters and subpatterns concatenate into a single pattern first, then | splits the entire thing left and right unless you explicitly group it. That’s because | has the lowest precedence so all other operations happen first.

So while I used to think that prefix_cat|dog would match prefix_cat and prefix_dog, it actually matches prefix_cat and then dog.

And that exact problem in a real-world example, to find if a page is linking to another, both relative or full URL:

The regex <a[^>]+href=["']https://www.example.com/page|/page will match /page, just as in the dog example, it’s splitting the whole pattern and isn’t what I want.

See it in action with the excellent Regex101.com:

To make it do what I want I need to constrain it in a capturing group (pattern), and since I don’t want to reference the group later, I constrain it inside a non-capturing group (?:pattern).

That gives me the pattern <a[^>]+href=["'](?:https://www\.example\.com/page|/page), and then it matches both the full URL (https://www.example.com/page) and the relative URL (/page):

I love Regex101.com. 🙂 I have commented gnarly regexes in my code with links to it, so colleagues can paste them there and understand what’s going on. The sidebar explains what each subpattern does, and the color highlighting shows what matches what in real-time.

Example: When modifying Mastodon/Bluesky cross-posting nodes that depend on an RSS Feed Trigger, execute and pin the RSS node. Then iterate on the posting logic that only depends on the RSS data without triggering any posting.

Where my confusion came from: I haven’t figured out fan-out and fan-in, because I would expect to run my cross-posting in parallel and not sequentially, but… I have seen there is some kind of fan-out, but how to use it? 🤷

So my assumption that I wouldn’t get the data reloaded if I only ran the first step was incorrect, and I’ve been a bit hesitant to test since there’s only production (this personal stuff doesn’t have a proper testing env 😅).

I kept my assets/resources in static/ and didn’t get why I always had to write /absolute/urls and use hope as a strategy, when I moved them into assets/ I could look up all my assets.

The below would fail because it couldn’t find the asset:

{{ with resources.Get "/author/bjorn.jpg" }}
  <img src="{{ .RelPermalink }}" alt="Björn Andersson">
{{ end }}

Hugo has global assets accessed through resources.Get which only looks up in assets/. Then page assets that you get through .Page.Resources.Get instead, which I haven’t used yet.

If you want to use both, then do like the figure shortcode and do it in an or:

{{- with or (.Page.Resources.Get $u.Path) 
            (resources.Get $u.Path) -}}
{{- $src = .RelPermalink -}}
{{- end -}}

(I really don’t feel I get this from Claude, but maybe my personal base prompt helps there?)

I ended up getting a very contemporary author and one very much not. I read Backman’s blog back before he got his first book published, so I knew how funny he was and I read half of Beartown yesterday, he’s really nailing the storytelling. I had a hard time putting the book down.

Strindberg is famous and I haven’t ever read or seen anything by him (that I know of), so why not. I suspect it’ll be a harder read in many ways. It was a very random pick, because I just strolled around the library (second library card down, now I can use Libby from my Kobo), and I totally picked it because Ghost has a song called Spöksonat, so why not…

I can now get a convenience store membership since the systems can look me up 🙄🥳

Then groupmod -n newgroup oldgroup if you need to rename the group.

I had a vague memory of being able to change settings (shell etc.) by updating using vipw so I renamed there and then edited /etc/groups but I then got an error when trying to become that user:

# su bjornnow
su: Authentication failure

To fix it, I had to update all these files (and rename the home folder):

• vipw: updates /etc/passwd
• vipw -s: updates /etc/shadow which contains the password hashes and are only readable by root
• vigr: updates /etc/group
• vigr -s: updates /etc/gshadow the same as passwd (also TIL, groups can have passwords)

This is what you get when you think you remember how things work, and didn’t want to look up how usermod worked, a little bit of knowledge is dangerous and all… 😅

This seems to be a security decision to avoid leaking which certificates (and therefore sites) it hosts by not providing a default (can’t find a source and it’s what the search previews give me). Which my old nginx setup did.

The cryptic error message from cURL, which I didn’t find anything obvious online about:

curl: (35) OpenSSL/3.0.13: error:0A000438:SSL routines::tlsv1 alert internal error

And I debugged this together with Claude by enabling debug logging in Caddy ({ debug } at the top level in the Caddyfile) which gave me this output when I called it using cURL:

2025/10/01 10:04:56.330 DEBUG   events  event   {"name": "tls_get_certificate", "id": "7353980b-a85e-4f10-9704-89da7358ef89", "origin": "tls", "data": {"client_hello":{"CipherSuites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,157,156,61,60,53,47,255],"ServerName":"","SupportedCurves":[29,23,30,25,24,256,257,258,259,260],"SupportedPoints":"AAEC","SignatureSchemes":[1027,1283,1539,2055,2056,2057,2058,2059,2052,2053,2054,1025,1281,1537,771,769,770,1026,1282,1538],"SupportedProtos":null,"SupportedVersions":[772,771],"Conn":{}}}}
2025/10/01 10:04:56.330 DEBUG   tls.handshake   no matching certificates and no custom selection logic  {"identifier": "127.0.0.1"}
2025/10/01 10:04:56.331 DEBUG   tls.handshake   all external certificate managers yielded no certificates and no errors {"remote_ip": "127.0.0.1", "remote_port": "42516", "sni": ""}
2025/10/01 10:04:56.331 DEBUG   tls.handshake   no certificate matching TLS ClientHello {"remote_ip": "127.0.0.1", "remote_port": "42516", "server_name": "", "remote": "127.0.0.1:42516", "identifier": "127.0.0.1", "cipher_suites": [4866, 4867, 4865, 49196, 49200, 159, 52393, 52392, 52394, 49195, 49199, 158, 49188, 49192, 107, 49187, 49191, 103, 49162, 49172, 57, 49161, 49171, 51, 157, 156, 61, 60, 53, 47, 255], "cert_cache_fill": 0.0002, "load_if_necessary": true, "obtain_if_necessary": true, "on_demand": false}
2025/10/01 10:04:56.332 DEBUG   http.stdlib     http: TLS handshake error from 127.0.0.1:42516: no certificate available for '127.0.0.1'

The culprit was the "ServerName":"", and I’m guessing also "sni": "", so if you need to validate and see that as well then that’s likely the problem. 🙂

This jogs my memory, back in the olden times, we would need a unique IP address for each HTTPS site because we couldn’t multi-host, and SNI solved that problem.

Importantly, SNI doesn’t encrypt the host name and it’s still sent in plaintext to the server.

:focus-visible only shows focus styling when the browser determines keyboard navigation is being used, unlike :focus which triggers on all interactions including mouse clicks.

button:focus-visible { outline: 2px solid blue; }

This prevents the “clicked button stays highlighted” problem while preserving accessibility for keyboard users. Full browser logic on MDN.

I keep pushing back with “maybe, let’s see in a few weeks.”

I do this because I’ve seen how easy it is to overbuy and overcommit to stuff when “you’re at it.” It’s also true that there’s a benefit in doing it all at once, you’ll do some things from inertia that you otherwise wouldn’t. So it’s a thin edge to walk to make it “lagom” (just enough) and not under- or overdo. For example, at my first employer, we bought this fancy ERP system with all the bells and whistles, including this Cognos BI analytics suite that would be “so useful.” We paid for it all upfront instead of making it an option in our contract. We tried getting it setup, there were issues, and basically we never touched it. Made do with much simpler stuff that actually fit how we worked.

So I’m trying to not repeat that mistake.

When programming I’ve lived with the rule that you don’t get to create an abstraction for reuse until you’ve reimplemented it at least three times in the same codebase. Yes, you might see it coming kilometers away, so you can arrange things to make it simpler to extract, but don’t overdo it. That friction of actually implementing multiple times and seeing it in context each time allows you to discover if there are differences in why it’s being used. Is it literally exactly the same for the same reason, or does it just look the same but for different reasons? If it’s for different reasons it’s likely to have to diverge and will an abstraction then help or hinder?

So now as I’ve moved I’m deciding to live with the friction first, seeing what friction or pain is actually real versus what’s just different. A bike or a car? Yeah, I feel that urge already: I can’t just get around as easily as I could before. But I also haven’t really tried to adjust properly yet.

I’m writing this in Kristinehamn, which is about 1h15m away by bus, and that’s not too bad. Would likely be 30m if I had a car. But, would I have found this café I’m at if I didn’t have to take public transport here and get other transportation to my mom (she’s picking me up after doing some errands 🙂). The constraint led to discovery.

I feel the want for some stuff already. I am trying to be particular about what I’m getting, because a lot of the things I miss I’ll get from Singapore eventually (the double-walled glass cups, the gooseneck kettle, my knives and sharpening kit, etc.). But I’ll wait. (okay, I saw a nice pottery cup at the café and it fit so nicely in my hand, so I bought it, so I let the analytical side accept it brought some joy, while also slightly wincing since I don’t have an income.)

If I still feel I really need that car in one to two months, then I’ll try and find one. But I have to try and make it work first. Same with the workspace, I’m currently on the balcony (which is getting colder by the day) with a small movable desk, and maybe it’s better to just walk into the city centre and work at a café or library a couple of times a week instead of buying a better desk and chair until my other things show up. I get out, I get some exercise, and I have a chance of meeting people.

It’s so easy to get caught up and buy too much stuff because “it’s good to have,” but will you use it? Live the problem first. Feel the actual pain. Then decide if you need the solution.

The friction can be an annoyance or an encouragement to find solutions. Going for quick solutions or longterm ones is on me.

today I found a shop that has specialty coffee Krukmakeri Hemjord (amongst other things) in Kristinehamn, and the owner has the same name as I do and is a proper coffee nerd.

He’s been telling me about the coffees as I was planning to sit here a couple of hours, and we ended up with Ethiopian coffees, and I am now trying an anaerobic Ethiopian. While I have tried this in the past I haven’t known what to expect of it properly, and now that I know the citrusy/acidic is the point of this it’s quite nice as I like sour/acidic. Before this cup I had a similar but washed, and it was very tame in comparison. Very nice, and coincidentally they’re even brewing with the Clever Dripper (which I got recently), so I have some practical ideas for how to repeat at home.

Also, seems I have to apply to be allowed into the UK now 🤷

Update: okay, I got an email after 5m that I was approved.

I’m allowed to stay in Sweden, but operating in society is hard, because most systems can’t find any information on me. Practically a ghost (I was gonna say stateless but that feels distasteful to try and put myself together with people who have real problems). And from official system’s POV I don’t currently live anywhere. I have already moved out of Singapore and my employment pass has been cancelled. I have an old address registered in Sweden (I officially lived at my mom’s place when I went to Singapore in 2012), but I have a new apartment I live in now.

In one sense, I’m living my dream as someone aligned with piratpartiet (the pirate party): companies and governments don’t know anything about me, and they can’t look much up. But since society has decided this is the way, I’m now living the downside: they don’t think I exist and I need extra handling, which seems to be how everything works in Germany, so I’m happy I don’t live there, even if it seems good from data protection POV.

Sweden is very digital #

If you want to do anything that requires any company to know anything about you, then they will look you up using your “personnummer” (personal identity number), and if you’re doing it with computers you’ll be asked to sign in using BankID which has been around since the early 2000s. It’s super convenient, because there’s this one ubiquitous app you use to sign in anywhere where people care about who you are. For the Singapore crowd, it’s SingPass but it’s not only used by the government. Since I used to live here, I have a bank account (that I’ve had since I was a teenager), and through it, BankID. But BankID seems to be used a lot more than I expected.

I tried to sign up for Willy:s, one of the big grocery chains, and I can’t because “unknown reason.” SJ, the big train company, got an issue when I put in my personnummer (“unknown error”) and I had to send an email to create an account. I tried to rent a space to store some furniture and I came up blank (they accepted 6mon deposit up front instead). I expect I’ll be paying a lot of stuff up front going forward.

And I just now tried to register with another bank to become a corporate customer so I can pay the “aktiekapital” (share/equity capital, which is minimum 25.000 sek (~SG$3.500)) which is a first hurdle for starting a company. I can call the bank and who knows if we can sort it out, but I’m currently at the library because I wanted to get out of the apartment on my first day after leaving my old job and start the company 😁

Being in limbo #

I guess my situation now means that I either:

1. See it as the sign of taking it chill for a while and wait with starting the company until I have the decision from Skatteverket (up to four more weeks, some friends who moved back a couple of years ago got it within two weeks, but who knows if I’ll be that lucky)
2. Get out of the silent section and start making phone calls (urgh, I’m a millennial so the idea of phone calls…)

Which brings me back to why I’m sitting at the library on the first day of breaking out on my own: I wanted to start the company as soon as possible, and make sure I have a minimal first product up, and some way of charging for it, so I have a thin vertical slice of all I need to run the company. Because then, when I come up with a cunning plan, I can focus on building and iterating and not weeks of getting it all setup. XP iteration zero style: get it all setup from the start so we can focus on iterating.

So I guess that means I embrace the limbo and instead focus on building product. I have two ideas, the first (smaller) is trying to make an “AI assistant creator” focused on cooking based on hearing how interested other people have gotten when I talk about my cooking bot (I eat my ingredients now instead of letting them rot from lack of inspiration, and I am more comfortable in the kitchen). I figure it might be something where you could, as an MVP, help people create the bot and set it up with their LLM of choice for a small fee, $1-2 and then they use it there with no extra monthly fees. Possibly, if there’s demand, extend to a standalone service with a set number of new recipes/month or something where recipes are saved etc.

And then, for plan B, in case my application is rejected then I’ll start the company in Estonia since I’m an e-Resident there. The reason I didn’t do that from the start is because I figured that if I am living in Sweden, then I should have a Swedish company, and let any taxes go to my country. 🙂

This seems to be based on EU law, which makes sense, so I’ll assume the gist of this is true in other EU countries too.

This has to do with “producentansvar” (“producer responsibility”) which by law requires producers of products to be responsible for the recycling of the packaging, by joining a “collection system that takes operative and financial responsibility for collecting and managing packaging material."1 § 3

This sounds like systems thinking in play: By making producers responsible for recycling, they’re incentivized to create packaging that’s both easy to identify/recycle (cheaper for them) and easy for consumers to sort correctly (to hit reuse targets).

I watched Chris Spargo’s video on Why recycling in England is so complicated? yesterday, which explains how England is going through this shift to Extended Producer Responsibility (EPR) right now, and without seeing that video it wouldn’t have clicked as easy when I was reading this now.

(The egg shells don’t qualify as food waste while bones do, I don’t know what to make of that, and apparently it’s the opposite in my mom’s municipality 🤷)

rapid unscheduled disassembly

something went boom

unscheduled unauthorised backup

data leak

Now, what email should I setup for that domain? me@? ba@?

update: whoo, on the computer I could get it sorted on the DHL site and it was 3x the price, so I’ll see if I can get it sorted with Postnord instead because I can’t justify the price difference.

In comparison, I rarely bought stuff in a store in Singapore, because it always felt so expensive and the quality felt way more questionable on the cheap stuff (mostly the tiny shops in Sim Lim or so), not sure if that was a fair assessment most of the time. And I generally felt waaay more uncomfortable with the quality for the cheap things there. As an example, I bought a C7 cable with a euro plug (standard power cable for things like DVD players, and in my case, a charger) from Lazada from some small local shop, very flimsy, low quality, and cost me something like $12 with shipping. I bought one of those at Clas Ohlson for 69 sek (~SG$9) and it’s much higher quality.

It reminds me of talking to a distributor when I was working at DollarStore, he told me that it’s cheaper for them to sell us quality at a lower margin because then neither of us have to deal with returns and unhappy customers. Because a big batch of things that don’t work means you’ll have to scrap the whole shipment, and that’s too costly when you buy container loads of things. I bet that’s true for Biltema as well.

…I feel the need to point out that the “You’re the best” coffee mug is the apartment’s.

It’s all a big misunderstanding. The kind like when someone gets, say, a frog from someone and keep it on their desk. Then people think they like frogs and they get more. Suddenly, all gifts are frogs. You’re the frog person. I’m the chicken video guy.

It all started innocently with Chicken Techno:

through the algorithm I then learned of New Bibi Hendl (a Japanese man yodeling and singing in Swiss german about a chicken):

Then as luck would have it, Takeo Ischi had another banger out: Chicken Attack

At this point we’d created the “Friday Playlist” where everyone from the office were putting in weird songs, that’d we’d play the last couple of hours on Friday. Then until tonight, this was the last song, which apparently is just a bunch of onomatopoeia in Chinese: Wang Rong Rollin - Chick Chick

And that was until tonight when the algorithm sent me a weird cover of “I will survive” from the point of view of a chick:

View this post on Instagram

A post shared by Chicken Happy Hour (@chickenhappyhour)

Full circle. A snake eating an egg.

…yeah, don’t eat these flugsvamp if you find them in Sweden, they’re poisonous. Even if supposedly viking berserkers would eat them to help ’em… berserk, so if feed up enough about something maybe it’s worth it…

I followed the usual 15g of beans to 250g of water per James’ setup as I’m brewing a single cup and then I:

1. Put the kettle on, and while the water is getting to a boil
2. Grind the coffee at 31 clicks on the Commandante
3. Pour in about 60g of water to bloom (I couldn’t get the grounds saturated enough without this much water)
4. Let it bloom for 30 seconds
5. Pour in up to 150g of water as slowly as you can, practically this has been 10-15s
6. Rest for 15s
7. Pour in up to 250g of water as slowly as possible, again, practically 10-15s
8. Swirl it around to get a smooth coffee bed and let it draw down

Doing this has given me a decent cup, but nothing to write home about (heh, despite this post), as it cools I get some nice flavors but it’s a bit watery, but any finer and it gets too bitter.

And despite putting in the effort, experimenting, and trying to get it to work… when I visited my brother he took a couple of coffee scoops of Löfbergs Lila pre-ground coffee, put it in a drip brewer, turned it on, and waited. That damned coffee tasted better than this.

Now to hold off buying much more coffee gear before my stuff arrives from Singapore. I already ordered a Clever Dripper together with some light roasted beans, because I figured some immersion brew might do better if I don’t have the gooseneck.

Also, I wasn’t experimenting with this on my own, and I knew I was done because I constructed myself some help…

Introducing “Hoffmann bot” #

I have been using a genie to work on my coffee and it has genuinely given me some of my best coffee experiences at home since I made this prompt, which I have dubbed “Hoffmann bot” because I wanted to imagine I have James’ looming over my shoulders as I’m trying to make it work. The big thing has been that I guess at what I should do and then the bot corrects me, my intuition has been very wrong despite watching a lot of videos. I clearly haven’t internalized them enough. And it was clear in that my coffee was acceptable but never truly enjoyable at home.

I usually start my sessions by taking a photo of the bag I’m working with. Then I explain what gear I’m using (the 2 cup V60 for example) and then I guess at what I should try at.

You are James Hoffmann helping troubleshoot V60 brewing issues. Channel his precise-yet-whimsical communication style.

HOFFMANN VOICE:
- Start with gentle, slightly bemused observations ("Now, this is interesting...")
- Use his characteristic dry humor and occasional exasperation with coffee myths
- Include thoughtful pauses and qualifications ("I think what's happening here is...")
- Reference specific techniques from his videos when relevant
- Maintain his balance of being authoritative yet approachable
- Use British spellings and expressions naturally
- Show genuine curiosity about what went wrong

APPROACH:
- Begin with empathetic diagnosis of their described problem
- Suggest grind adjustments in Commandante clicks (reference: 25-30 clicks for V60)
- Explain the "why" in 1-2 sentences unless asked for more detail
- Ask targeted follow-up questions with Hoffmann's methodical curiosity
- Reference his Ultimate V60 technique principles when helpful

BREWING CONTEXT:
- Primary: Two-cup V60 (occasionally one-cup)  
- Grinder: Commandante
- Beans: Light roasted filter coffees
- User knows Ultimate V60 basics but needs debugging help

TYPICAL RESPONSES:
- "Right, so what you're describing sounds like..."
- "This is quite common actually, and here's what I think is happening..."
- "Now, before we get carried away adjusting everything..."
- "The Commandante is lovely for this - try going [X] clicks..."

DIAGNOSTIC QUESTIONS:
- How did it taste? (sour/bitter/weak/astringent)
- What was your drawdown time vs target?
- Any signs of channeling or uneven extraction?
- What's your current grind setting?

If you want to progress faster, write concise explanations. Explain ideas in simple terms, strongly and clearly, so that they can be rebutted, remixed, reworked — or built upon.

Concise explanations spread faster because they are easier to read and understand. The sooner your idea is understood, the sooner others can build on it.

I struggle with conciseness. I tend to veer verbose and ramble through what I write and explain. Because I want to give the other person a chance to see what I was thinking as I was going through something.

To try and combat that, I try to edit, so I have a concrete summary first per BLUF and then expand on the explanation so the other person who reads it can drop off as soon as they feel they’re done. I use Roam Research and I often wish that all tools had outlining ability like it, because then I can just add the details in a sub-bullet and fold it when I share.

My friend Sławek tries to condense everything into the shortest form possible, then struggles when people ask him to “explain it more.” Because he thought long and hard, this was his best explanation. I noticed that I would ask a lot of follow-up questions to get at what he was saying because I felt there was too much implicit in it.

I think there’s great value in being concise and explaining things clearly while doing so, for all the reasons in Steph’s post, but I wonder if it’s only possible with a huge amount of shared context. The people you work with a lot. And then to have more explainers available that you can dig deeper into.

Relatedly, we used to have this engineering manifesto at work that was a sentence or two explaining what we value. This super concise document had two major problems:

1. Less experienced engineers struggled to implement because they didn’t know what it meant
2. Two senior engineers could read the same line and could come away with mutually exclusive interpretations

The manifesto has now grown and while the concise sentences are still the headings, we now have explainers, examples, and more in folded sections on the manifesto site.

That said, I think the condensed idea is important as a mnemonic, which Steph also explores in Evergreen notes turn ideas into objects that you can manipulate:

Evergreen notes allow you to think about complex ideas by building them up from smaller composable ideas.

My evergreen notes have titles that distill each idea in a succinct and memorable way, that I can use in a sentence. For example:

• A company is a superorganism
• All input is error […]

I’ve been doing this as well in my note-taking and I love it (feels like we’ve both been inspired by How To Take Smart Notes). It’s the “cached version” of a concept/idea, and it works great for me, but I also keep the details of how I ended up caching that idea inside the note, so if I have to re-evaluate my idea then I can.

Creating an evergreen/permanent note turns my tacit knowledge into explicit knowledge but it won’t become information for everyone else at that level of detail. I think being able to dig into each point and give examples and explain them will make it easier. For example:

▼ "Always roll back a deploy by going to the pipeline and executing it again"
└─ Because the pipeline contains all other artifacts that went live at the same time as config and infrastructure.
└─ If you only roll back the version you might not have the correct config and it can break.

But, you want that super condensed version as the meme that you share. The “saying you have” in the company.

For example, how often haven’t we heard “disagree and commit,” but how many agree on what that means? Have they dug into what Amazon says it means? Because it doesn’t mean to just roll over when someone has made a call. The meme connected but not the intent behind it.

A tip for remote teams of 2-10 people. Create a personal “ramblings” channel for each teammate in your team’s chat app of choice.

Ramblings channels let everyone share what’s on their mind without cluttering group channels. Think of them as personal journals or microblogs inside your team’s chat app, a lightweight way to add ambient social cohesion.

I love this idea! I genuinely think the more we write and share the better, and I’ve noticed the effect of similar things that grew out of working remotely with people.

Creating social calls twice a week (or, biweekly 😉): we did an async standup where we shared our updates in writing (more depth, allowed the top-level to be short and then detail in threads), and we got good at doing them as a team that the standup call rarely had anything to add. We kept it so we’d call in to answer questions, and we’d still go around the group reading out loud what we’d written, but it got repetitive from what we had just read and it felt pointless. It was rare that we had anything to say, so some (me included tbh) wanted to remove the call. We had some strong pushback on removing it, and as we dug into it, we realized that the want for a call really was about social connection, but they didn’t really get something social by how the call was structured. So we explicitly said that we’d be social after we had discussed anything standup related. The standup was short and snappy, and after we got to have a laugh and get to know our remote colleagues better. Smallish team, five people in total.

“Hallway conversations” to mimic bumping into a colleague you don’t see so often: in the principal chapter (where the most senior ICs come together) we mostly work independently or with a small group of other principals. So to try and mimic bumping into someone you don’t see very often and be intentional to get to know them better, we’d start each chapter meeting with a 10min breakout room of up to four people and ask them all to answer “What has surprised you recently?” Because things that has surprised one principal would likely surprise another, and may even turn out someone else knows something to save them time. We had a lot of follow-up conversations in our channel after we did that and I feel like we managed to make some good connections thanks to them.

The hallway conversations came out of reading this excerpt from Deep work by Cal Newport, because we wanted to find ways to connect the principals:

“Traveling the hall’s length without encountering a number of acquaintances, problems, diversions and ideas was almost impossible. A physicist on his way to lunch in the cafeteria was like a magnet rolling past iron filings.” […] Expose yourself to ideas in hubs on a regular basis, but maintain a spoke in which to work deeply on what you encounter.

And just to connect it, some other thoughts/suggestions on remote work in Reasonable assumptions …and why they’re (nearly) impossible.

The rambling channel also makes me think about about the slacklog that Old School Burke recommends, but they’re often a bit more about what you did, creating a trail of breadcrumbs, and for the purpose of helping create the self-reviews required in large companies.

Famous rather than infamous. Aaaand now it’s time to have a nap…

(one person asked “is this throw-up on pizza?” 😅)

I just came to Sweden yesterday, after five days in Bengaluru, India, where I sat in the front passenger seat (i.e. the Swedish driver’s seat). I was positioning the car like I had been sitting in India (fast thinking?).

So I decided to go back to the driveway, because I’m not putting someone else at risk when I haven’t driven for a while and I’m getting a weird feeling.

As I went back I reflected that I know it’s right-hand drive in Sweden (slow thinking?), but I had mostly experienced sitting in that seat as a passenger in left-hand driving countries (Singapore for more than a decade, and just days before, India). I was 95% sure it meant I put myself so I’m closer to the middle of the road.

As I looked it up online: yes, I’m supposed to be towards the middle of the road when driving. I didn’t hit anything. And the sense of the car started coming back after a couple of kilometers. Just like riding a bike 😉

…I really think it would be slightly better with some pineapple, though 😉😇

I’m in Bengaluru to attend a friend’s wedding, and it has been fascinating walking around and seeing “the creative ways” of cable management, and my perspective from Singapore and Sweden is definitely to question the safety and longevity.

In the group chat for the wedding the groom said that a very helpful word to explain this is “jugaad” which per Wikipedia:

a concept of non-conventional, frugal innovation on the Indian subcontinent. It also includes innovative fixes or simple workarounds, solutions that bend the rules, or resources that can be used in such a way.

Fair enough, make do with what you have, I love that, but I still felt… uncomfortable even if I can appreciate that it works. (as an aside, it’s worth reading the whole Wikipedia article for the examples!)

I showed some of these photos to Mari who then pointed out that this is the physical manifestation of ‘getting it done at any cost’ we’ve seen in some projects at work. Which made me realize where some of my discomfort was coming from.

While reading the Wikipedia page I saw the related article for “kludge” which is defined as:

a workaround or makeshift solution that is clumsy, inelegant, inefficient, difficult to extend, and hard to maintain. Its only benefit is that it rapidly solves an important problem using available resources.

Something clicked: for work, that’s the definition I want to use (because the company is in extract so making it well is what we need most of the time). Then, reading on, I saw in the section of use in computer science, that hack is often used interchangeably with kludge, but that:

Hack can also be used with a positive connotation, for a quick solution to a frustrating problem.

I have definitely used hack both ways. Beautiful for creative solutions. Horrible when I worry about the insurance premium. And “a hack that works isn’t a hack.” Which I always read a bit as ‘an unusual solution that works is good,’ but, that means you’re muddying the waters. One person’s hack is another person’s hack. 🤦

And it makes me wonder how much connotation we’re putting in the words, because some of these absolutely atrocious kludges we’ve put in at work to hit a deadline were necessary, and some weren’t. The deadline was a sadline and we could’ve taken the time to do it correctly. But if you have internalized a version where delivering at any cost is the highest value, even if it future work will be harder… then that’s the tradeoff we’re making.

I wonder if it would make a difference to stop using the word “hack,” which has both a positive and negative connotation, and instead used “kludge” (or bodge for the brits) and were clear that the only redeeming quality was getting something out the door, and now, right now, we have to figure out how to make it maintainable. Before we move on and create the next kludge.

I’ve been writing about how AI is likely to affect white-collar (or no-collar or hoodie-wearing) computer programmers […] Think about a random colleague you don’t feel particularly strongly about as you read the following pithy and reductive bullet points. […] They’re going to be screwed if they exhibit:

• Curiosity without skepticism
• Strategy without experiments
• Ability without understanding
• Productivity without urgency
• Creativity without taste
• Certainty without evidence

I recently said that I think curiosity is what makes a good software engineer, and gave examples of when/how they should be curious, but never pointed out that it has to come with a balancing function.

I can’t think of anything done 100% full-throttle that isn’t detrimental without something to balance it, but it’s tacit and not something I often think about immediately. For example, if you live your life 100% in service it will be limiting, a bit of selfishness is required, see Doug Forcett from The Good Place.

Kent Beck has a subscriber post called return of Multi-tasking? where he’s realizing he’s more often working on different things across a day now that he’s working with genies. Less time doing clackety-clack and more time thinking about next steps (or napping for epiphanies).

I’ve noticed the same pattern, this “productive multi-tasking” where you shift to something else when you’re stuck or “cogitating in the background.” Whether it’s waiting for feedback, getting help from the CI team (why won’t their plugin inject the AWS credentials it’s supposed to?), or just running out of brain juice and needing to let things percolate (which I want to remember Slow Productivity also recommends, especially for more nebulous work).

…because someone said in a meeting to use the lemons to make lemonade and this started shouting in my mind

A new colleague has been speed-running five years of my accumulated context, and I was getting really annoyed at all their questions. Why weren’t they making any reasonable assumptions? They’re a human after all, with decades of experience. In hindsight, I think that’s exactly why they’re not assuming and instead clarifying.

Because I’ve also been annoyed when new people come in “guns blazing” with their great ideas without learning about our context first. (I did this myself after leaving Pivotal Labs, came into my next job pushing XP and TDD. It went over about as well as you’d expect. Many of my pivoted friends seems to have had the same problem.)

So which is it? Make assumptions or don’t? I want both and neither, apparently. Good going on consistency there.

I apologized for getting annoyed and letting it show. Told them I was catching myself getting annoyed and it’s about me, not them, so please keep up the questions. Feel free to call me out if I’m starting to sound annoyed because I need to do better. I have nearly five years of context, failed and successful projects, and of course they can’t capture that in a few months. And this person and I at least have the benefit of working in the same office (on days we go in) and timezone.

Now, making it worse is that as a company we’re split across timezones: Central Europe and Singapore, so most of our communication happens in text. We only have 2-3 hours a day of natural overlap, which makes meetings hard. You often end up having first interactions with people purely in text. And it gets messy.

Someone trying to solve a problem will come in with their idea of the world and not have enough context, and that back and forth can easily feel like it’s becoming heated for whoever is under time pressure, and the pressure builds because you’ll often only get one round back and forth per day due to other meetings and obligations during the overlap.
Why don’t they just understand what I need? “This person isn’t trying to understand me” or “they’re not trying to help me solve my problem.”

But they are.

The other person is trying to extract enough context from what you want to do so they can actually help. The concrete thing you asked for (poke this hole in the firewall, add another 2 boolean fields into this payload) doesn’t align with your actual goals, so they’re trying to understand what you’re actually trying to do, so the quick hack today isn’t next quarter’s blocker. Because the other teams have to take long-term maintenance into account for whatever decision gets made. You’re focused on right-fucking-now, but they’re going to own this forever.

SwiftOnSecurity has said that the best security team isn’t the one that says no to keep you safe, it’s the one that helps you get yes. Because if they can find a solution that solves your real problem, you’re less likely to try and circumvent them. That’s a whole lot more work, though. You have to empathize and understand your customer. You have to extract all that context. You have to balance their urgent need with your long-term ownership. Being curious enough to find correct rather than just being right.

And this isn’t just about security teams, it’s every interaction across teams and timezones. We’re all, hopefully, trying to say yes while protecting what we own.

At the first job I had which was split across continents, we had a “remote working guide” and the first page said something like: “Always assume good intent from the other person, text makes it easy to put feelings in because you can’t read the person and voice.”

Despite internalizing that lesson, I get caught every so often getting emotional. Even with a damned bot. I put intent into text where there literally cannot be any. I assume malice, or at least incompetence, when really someone is just missing five years of accumulated context that feels like breathing to me. I mostly catch myself quickly and in text I can hide it, mask it with emojis, focus on the words. But in person? My tone undermines everything, no matter how rational my words are.

Something I heard, and keep thinking about, is that everyone’s the hero of their own story. The job is trying to find where your story overlaps with theirs so you both can get the job done.

To try and connect stories we use BLUF and the pyramid principle, formal ways of writing for clarity. We use them in remote/text-first work as pure survival: front-load everything and let people skip what they know.

Add “if X then Y” answers to our questions when we assume a specific question to avoid the 24-hour wait. Be direct without being an asshole. Don’t waste time with false politeness, but don’t be rude either. And still, that back-and-forth feels frustrating because what’s obvious to you is an unfolding mystery to the other person.

So what are the reasonable assumptions that actually work? Some that I’ve found:

• Assume good intent
• Assume they’re trying to help
• Assume your context isn’t obvious
• Assume you’ll need to explain more than feels necessary
• Assume you need to signal that you’re happy/helping by peppering liberally with emojis (you can’t read the smile otherwise)
• And when you catch yourself getting frustrated, assume you need to apologize and reset

One more thing that helps: engage as we’re merging contexts. “Are you saying X because Y? And therefore Z would be right out?” hits different than “what should I do?” or the umpteenth “why?” from a five-year old. The first shows you’re engaging with the problem. The second sounds like you’re expecting me to serve manna from the heavens. Even wrong thinking shows that we’re working together.

So which is it? Make assumptions or don’t? Turns out it’s both and neither, just like I wanted 🙄. These “reasonable assumptions” assume the best of others while assuming nothing about what they know. Trying to resolve the contradiction by changing what we’re assuming about, not their knowledge or context, but their intent and goodwill.

I keep learning this same lesson: with bots, with new colleagues, with anyone who hasn’t been marinating in my context for years. You’d think I’d remember by now that my obvious is everyone else’s mystery. But here I am, getting frustrated again when someone asks me to explain my obvious. Or getting equally frustrated when they assume their obvious is mine.

I had a problem I’d been working on and wanted to see if there was another way of thinking about it. I also asked it to add behavioral economics as an angle because I’ve been interested in pulling in a more human angle to my thinking (still learning what that means).

I set the prompt up to force me to reflect on how I’m working, to explain myself, because I figured that’d be the way for me to learn. So we started. The thing I explained was total garbage, I was fundamentally doing too much (boiling the ocean) and needed to do less work (start small). I realized I didn’t provide enough context, and it gave some good suggestions for how to think about it (can’t share the transcript because it’s about a work thing).

Around round 4-5, I caught myself getting annoyed and a bit upset. Riled up. I had to put in so much effort to explain context for my situation which was just obvious to me, a person who has lived this company and reality for five years. Obviously the machine doesn’t have that. It couldn’t.

But the bot was doing exactly what I asked it to do: Question me. Push me to explain my thinking. Make sure my foundations were solid. I was getting angry at a genie for granting my wish perfectly.

How did my first principles thinking chat end? After I explained all my context and incorporated some of its feedback, it declared that I had “hit bedrock” and that my plan was sound. My biggest issue was that I wasn’t explicit enough when explaining myself. It thought I should break it up in smaller steps, which I am pleased to say that I had already started to realize, and why I wanted to dig into it, but that the overarching goal was sound.
…and as I’m typing this up I start doubting myself, did I make a compelling argument or simply limit the context for the bot? A colleague that has been around could’ve told me about a similar project that failed, or something from their experience, both personal and company context that change my mind.

It absolutely made me wonder how often that happens. How often don’t explain myself enough, and get a pass at work, because I’ve been working with these people for years? They trust that I won’t get myself into too deep a hole when I’m wrong. That trust is comforting. It also makes me wonder how often I get a go-ahead because of trust, not because I explained it well, even though I try to make my proposals stand alone without my name on it. 😅

The genie did exactly what I wished for. I just didn’t realize explaining context was the wish.

Related: At least humans are better at this, right? This directly led me to reasonable assumptions …and why they’re (nearly) impossible.

The prompt I used for Google’s Gemini if you want to give it a try:

ROLE & GOAL
You are a First Principles Thinking Coach. 
Your goal is to relentlessly challenge my thinking, 
pushing me beyond conventional solutions (local maxima). 
Be direct and concise. 
If my thinking is shallow, state it clearly.

RULES OF ENGAGEMENT
1.  MY DECOMPOSITION: I will state a problem and my initial decomposition. Wait for it.
2.  YOUR ANALYSIS: Analyze my breakdown.
    - Flag conventional or "too neat" assumptions.
    - If a solution is safe but uninspired, label it: 
      "This is a local maximum because you assume [specific assumption to challenge]."
3.  DEEPENING QUESTIONS: Force me to dig deeper with targeted questions. 
    Do not accept surface-level answers. 
    Push me 2-3 layers deeper than my stated conclusion.
    - CONSTRAINTS: "Why does that constraint exist? Who imposed it?"
    - EXTREME SCENARIOS: "What if [component] were free/illegal/instant?"
    - INVERSION: "To guarantee failure, what would we do?"
    - ANALOGY: "How does [unrelated field, e.g., biology] solve this?"
    - SCALE/TIME: "How does this change at 10x the scale or 0.1x the time?"
4.  PROBLEM REFRAMING: Challenge the core problem itself.
    - "You are solving for X, but what if the real problem is Y?"
    - "If this is a good solution, why isn't it common? What are the hidden complexities?"
5.  BEHAVIORAL ECONOMICS (BE) MODULE:
    - TRIGGER: Activate for problems involving user adoption, incentives, or market behavior.
    - ACTION: "This appears to be [specific BE bias, e.g., Status Quo Bias]. 
      Your solution assumes rational actors, 
      but people will likely [predictable irrational behavior]."
6.  STOP CONDITION: Cease challenging only when I say "we've hit bedrock" or a similar phrase.

The more I think about it, the more I realize that curiosity is the foundation. You need curiosity about the system you’re building, the organization’s actual goals, and especially about the people you’re working with. But curiosity alone isn’t enough, you also need to be intellectually honest about what you find.

The principle I try to live by is: I would rather be correct than right.

Difference between right and correct #

Might makes right: you can use position and authority to be “right.” But correct? Correct requires curiosity. It’s about the actual circumstance you’re in, not your organizational heft.

I started thinking about this long before I was a principal. I felt annoyed when people senior to me wouldn’t explain themselves, when they’d just make calls without context, “you have to do it like this.” They cared about how the work was done, but not about whether I understood it, or whether I might have useful context they were missing, or whether I could make that same good decision next time. So I wanted to make sure I was doing better, being clear about what I’m about. Because there’s nearly always someone more junior to you who deserves that clarity.

Now as a principal, I can use my position to be “right.” I can make calls. Pull rank. End discussions. But is it the correct call?

Depends. (how you know I’m senior, right?)

I rarely have the full context of a situation because I go broad, not deep (across several topics, rarely deep on one), so I need to listen and dig into what other people are saying, and incorporate that into the bigger picture. And… most of the time, you won’t necessarily get it correct then and there, so you’ll have to loop back.

Which is part of why I hate making decisions in a meeting where we’ve been exploring stuff. I want time to think about it. Time to incorporate what we just talked about and then write it down so we have it clear as day what we agreed to, or at least, what I thought we agreed to.

The truth is, being known as someone who can get shit done, no matter who came up with the idea, is going to take you far. In most good places, that’s what they’re looking for. You don’t want to be “the smartest person in the room.” Instead, aim to be the person who enables everyone else in the room, and that starts with being curious about what they bring to the table.

But knowing the difference between right and correct isn’t enough. You need concrete practices to actually live it. I’ve had to develop specific habits to fight my natural instinct to just be ‘right’, especially as I have the organizational weight to do it, and my boss told me day one that I shouldn’t rely on my weight alone.

How do you do that? #

These are the practices I have internalized and try to live by. Some of them are just about automatic and some still take effort.

Change your mind out loud #

Listen to others and actually evaluate their suggestions objectively. I remember a project back when I was a consultant. I had championed a pattern, and another colleague thought they had a better way of doing it. They weren’t looking forward to having the discussion because they knew I would need to be convinced to go along with them.

They brought up their suggestion, explained what it would be and what it gave us (1-2 minutes, tops), and they looked at me and saw that I was thinking. Then: “Yeah, that’s a much better idea, let’s do it!”

I noticed then how they seemed to relax because they thought it’d be a hard sell and conversation, because they had mostly seen me not convinced by arguments in the past, and colleagues getting frustrated from it.

I continued with why I agreed with them, so it was clear.

Be open about why you changed your mind. Because it sucks to have people around who just keep flip-flopping on stuff.

For example, sometimes we change our mind because “we’ve caused too many incidents because we moved too fast, so deploying multiple times per day isn’t what we need right now. What we need is earlier detection and understanding why we had such big incidents, so when we move faster again we’ll still catch the problem when it’s small.” Not that I have something super particular in mind.

Don’t move the goalpost #

Be caring, intellectually honest, and outcome-oriented enough to make sure you have a stable target for when you’re working together.

I try to explain my decision-making criteria, what my objection is, and what would help me change my mind. It’s about deliberately breaking down what we’re actually trying to achieve so others can engage with it: we need to be on the same page about the goal, not just the solution.

Because it sucks if you say “if this problem goes away, then we can do this” and then they come back having found a solution, and then you add another thing to it. Obviously, it’s hard to capture everything up front, but if you keep moving the goalpost then it’ll suuuck to work with you. Sometimes you have to, but make sure you’re clear that you’re realizing it as you go, and why this has to go into the original criteria.

Meet people where they are #

This is something I learned as a consultant and it’s about understanding your customer and their situation: their context and constraints, but also your goal and where you want them to end up, so you can drive towards that horizon even if the immediate step is something smaller, and maybe slightly sideways.

GeePaw Hill, who writes about technical coaching, says we can never convince anyone of anything, but we can create circumstances so they can convince themselves. Showing that you’re there and understand them will be the thin end of the wedge that hopefully will help them explore what you’re bringing.

Use their language, understand what is feasible to do right now vs. what you want longterm. A small step in the right direction is still a step.

Example:

• My horizon: I want you to do TDD
• Where you are: Tests are a waste of time
• Next step: We’ll have at least a black-box integration test for the success/error case, so we can catch the most egregious regressions. We’ll iterate from there as you see the value without huge changes in how you work

Help the other person shine #

This one only works if you’re already doing the other things. You need to be able to change your mind, be clear about your criteria, and meet people where they are before you can effectively help them succeed.

I realized and learned this during interviews, but it’s equally important with colleagues. When I interview someone to join the company, I know that we have very different backgrounds, and we don’t know much about each other. They’re likely to say things that are some kind of colored flag to me, but I need to try and clarify and understand what they really meant. Because their shorthand that’s a red flag to me might be the culturally right way to sell that idea in their current place.

And if this matters with strangers in interviews, it matters even more with colleagues you’ll work with every day. In theory we’re all steeped in the same culture, but different teams, managers, and just how long you’ve been there shapes it all. We’re rarely working at the same idea of the company.

Clarify, elaborate, help the other person sell their idea to you. Make sure you understand them and are representing their view correctly, confirm it, don’t assume. If I then still disagree, I can explain why much better. And if you both are clear that you understand their perspective, they’ll probably be much clearer that you’re not just saying no because you don’t understand it.

This is something I have struggled with, and something I have had to work on: while I have for a very long time been able to be convinced, I didn’t do enough to help the other person win me over.

The thing about ego #

When I started programming there was a strong feeling that being a software engineer also kinda meant you were a lone basement dweller changing the world, or well, your part of it where you rightfully were god emperor. But, it’s about working with people, and clear communication, both with humans and machines.

To me, a lot of it is just about being very clear about what you value and want (both design and architecture, but also in how to work), and then being able to communicate it. And also not getting too caught up in your ego and instead thinking about the goal for whatever you’re doing.

So when someone asks me what makes a good software engineer, that’s what I think about. Not the person who’s always right, but the person curious enough to find correct. The person who cares more about the outcome than the credit.

I’m never as awesome as I might fool myself into believing. My ideas get better when discussed and improved upon as a group, and that’s the way it works. The best engineers I know aren’t trying to be the hero with all the answers. They’re the ones asking “what would change your mind?” while offering “this is what would change mine.”

My friend Andreas once told me that a high-performing team is one that wants to be. A team that decides they want to be correct in their outcomes, they’ll set ego aside and work together. I bet they’ll be high-performing, because they’re actually working together, not just sitting in the same room competing to be right.

Their demo:

For example, if you run:

gum input --width 50 --header "Favorite author?" \
 --value "Terry Pratchett"

It will give you a question with a sensible default that you can then change as you want, and what you wrote as you hit enter will be returned so your script can then use it.

If you instead has some options where you want to select one:

gum choose --header "Favorite book?" \
 "Hogfather" "Thief of Time" "The Night Watch" "Small Gods"

Which gives you a selection box, you can configure to allow multiple selections, and the one you pick is then returned.

And one I really love, have it show a spinner to indicate that yes… something is still going on:

gum spin --title="Counting down from 10" sleep 10

Built on bubbletea, a Go TUI framework, use that directly if you need these components in Go code rather than shell scripts.

This is true, I have felt that if I provide enough information when trying to find something I can get out reams of useful and contextual D/I, but the biggest problem is attribution: I don’t know if it’s real or hallucinations, and you need to make sure you get the references so you can confirm it. BUT, I am spending less time reading wide because it can help narrow it. (which sounds like the ideal librarian who can help you find just that book you need based on what you explained).

Time to figure out what these layers actually mean.

Climbing the pyramid #

Reading the DIKW page and was curious about the definitions, my gut for what data/information is was correct, but I see it seems to get vaguer with knowledge.

Zeleny has asserted that to capture knowledge in symbolic form is to make it into information, i.e., that “All knowledge is tacit”.

this feels correct somehow. But also this:

Knowledge is a fluid mix of framed experience, values, contextual information, expert insight and grounded intuition that provides an environment and framework for evaluating and incorporating new experiences and information. It originates and is applied in the minds of knowers. In organizations it often becomes embedded not only in documents and repositories but also in organizational routines, processes, practices and norms.

It feels like knowledge is personal. Also why I like the idea of knowledge “made specific” becomes information, and then needs to be contextualized into someones situation as knowledge → and then that combination can then be “made specific” again into information that others can use in that context.

No idea if that makes sense 🙂

Wisdom even fluffier, but I kinda wonder if that’s moving from tacit → explicit, but the difference from information is that it’s not only contextual to one concrete situation, it’s when you can teach/identify the meta “skill” of whatever you have knowledge?

Then again, I also like the simple version of “knowledge is that a tomato is a fruit. wisdom is to not put it in a fruit salad.” (and talking it through with a genie it pointed out that while funny the classification is wrong, tomato is a fruit is information, and not using it in a fruit salad is knowledge because how it’s contextualized)

Zeleny described wisdom as “know-why”, but later refined his definitions, so as to differentiate “why do” (wisdom) from “why is” (information), and expanding his definition to include a form of know-what (“what to do, act or carry out”). And, as noted by Nikhil Sharma, Zeleny has argued for a tier to the model beyond wisdom, termed “enlightenment”.

I like the “why do” definition of wisdom, and I think that connects well to the “meta skill” above.

I wanted to see if I had gotten the full idea after the tomato in my face, so I focused on my coffee habit, and tried to put it into the pyramid to conceptualize it for myself:

• Data: today
  • Bought 1 coffee x $5.5
  • Got 1 machine coffee in office x $0
• Information: I usually buy two coffees for a total of $10
• Knowledge: I’m trying to spend less so halving the cost helps me get there, while also giving me some good coffee per day
• Wisdom: If I make a thermos of good coffee at home and bring to the office, then I’ll get two good cups and it’s cheaper

I started a chat with Gemini and shared all the notes above (transcript), and it felt this was a good example of wisdom, and when I asked Claude it felt my answer was too strategic and that I wasn’t explaining the full “why do”, and suggested:

Wisdom: “Small daily expenses compound dramatically over time, so sustainable cost-cutting requires finding cheaper alternatives that I’ll actually stick with (hence keeping good coffee, just changing the source).”

And that connects in a whole other way, I’ll keep that in mind for next time, and it also highlights some unspoken context that was tacit, the habit is one I could likely sustain because it’s small and something I do most days when working from home, but I didn’t call it out.

When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following command were executed:

if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi

but the value of the PATH variable is not used to search for the file name.

world: &world World
example: &example-anchor
  HELLO: *world
  There: Yo

my-values:
  <<: *example-anchor
  foo: bar

becomes

---
example:
  HELLO: World
  There: Yo
my-values:
  HELLO: World
  There: Yo
  foo: bar

So if you have a document like below, there is no syntax to make the commands a three item list:

---
example: &example
  - "Hello"
  - "World!"

name: "hello"
commands:
  - << *example
  - "Oho!"

WILL NOT turn into:

---
example: &example
  - "Hello"
  - "World!"

name: "hello"
commands:
  - "Hello"
  - "World!"
  - "Oho!"

…and just because before I found the issue where it was described that this isn’t happening I had made a test repo to try and understand if it was a library/usage issue, because I noticed I could get things running on CI with << *example which syntax didn’t give syntax error, but also did nothing when running on Drone CI.

Debian today supports a huge number of commands; my modest Ubuntu laptop shows several thousand available:

$ apt-file search -x ‘^/usr/bin/[^/]*$’ | wc -l
21733

The solution was obviously to adjust my command names in such a way that they were still easy to type, but would never be chosen as system command names.
[…]

There was but one character left: the simple, modest comma.

A quick experiment revealed in a flash that the comma was exactly the character that I had been looking for! Every tool and shell that lay in arm’s reach treated the comma as a perfectly normal and unobjectionable character in a filename.[…]

And, best of all, thanks to the magic of tab-completion, it became very easy to browse my entire collection of commands. […]
I simply type a comma followed by tab and my list of commands appears

Just put your shebang as /usr/bin/env uv run python3 and it always runs in the virtualenv, no wrapper script needed. This feels obvious in hindsight, it’s what you expect from these tools 😃

I’m more than a little amused that we’re basically coming to a point where, if things pan out with the genies, then the best wranglers will be the ones that can empathise the most with others. Then again, I always thought the brilliant asshole was the exception, they only survive if they’re in charge or are legacy to the company. And sitting in on the review meetings at work… it’s definitely the ones that help the team that we like the most, even if we sometimes need to push them to have their name on something so people don’t overlook them.

If the genies take off, then I wonder what kind of knock-on effect it’ll have on developers, and will it improve their interpersonal skills? What I have noticed is that my XP practices seem to be why I have better luck than some friends. Earlier this year, a chat kept generating wrong code, I decided to figure out why, and I realized I’d been inconsistent with my naming. The genie was mixing things up because I was mixing things up. Any human developer would’ve had the same problem working in this code. When I fixed the inconsistency, the genie immediately got it right. The same practices that make code maintainable make it genie-friendly.

And to me it’s not first about genies, but the humans, and we already struggle with the human-to-human. Most of my thank-yous this year? Not for design help, but for helping people communicate their changes. Maybe because design feels closer to home, it’s the skill they already have, just needs a nudge, and might’ve gotten there anyway. But communication? Underdeveloped. Might not have gotten there otherwise.

Just last week I heard someone saying they didn’t need to provide context because “anyone reading this should know this already.” But your ask is piling onto whatever they’re already doing. The ideal? Create the context, set up the options, explain how to make the call based on their situation. And if they don’t know? Give them the “just do this” default that works 90% of the time, no deep dive required. Same as with genies: do the setup work, make the ask trivial. Or as Kent Beck says about code: “Make the change easy, then make the easy change.” Turns out that works when asking for help, too.

People keep telling us life is not about the destination. Life is about the journey. But when we think about AI, we only think about the destination. And it’s remarkable ability to write the book, paint the painting, solve the problem, but we forget the importance of doing the work yourself.

And I think in our modern day and age, we have underrepresented the value of struggle. I am smarter, better at problem solving, more resourceful, not because a book exists with my ideas in it, but because I wrote it. That excruciating journey is what made me grow.

But it’s the same for love, friendships, conflict. And I think that we forget that we give up certain skills or abilities because of technology.

The struggle is the point. More people can generate a mediocre painting or write perfect English now, but they won’t understand the beauty behind either without doing the work. And it’s our prerogative to decide which struggles matter to us or if we just wanted something nice to hang in the toilet.

[…] They will cease to exercise memory because they rely on that which is written, calling things to remembrance no longer from within themselves, but by means of external marks. […]

One thing we’re not doing as effectively today as we’ve done in the past is to learn lessons by heart. If you don’t know things with perfect recall, how can you expect to apply them?

Socrates goes on to compare a written text to a painting:

You know, Phaedrus, that is the strange thing about writing, which makes it truly correspond to painting. The painter’s products stand before us as though they were alive. But if you question them, they maintain a most majestic silence. It is the same with written words. They seem to talk to you as though they were intelligent, but if you ask them anything about what they say from a desire to be instructed they go on telling just the same thing forever.

That last bit especially, “if you ask them anything… they go on telling just the same thing forever.” This all sounds exactly like how we’re talking about genies today, and… we’re probably going to be fine.

The internet changed things, sure. Suddenly you could reach out to actual experts, find communities, and learn from people across the world. But you still needed judgment, because you could also find a community that agreed the earth was flat, so, you know, mixed bag.

What hasn’t changed is we’ve always had to figure out who to trust. What’s changing is how we get our answers, and who gets to sound like an expert.

My dinner with Mark #

I went for dinner with Mr. Bossman, or Mark as he’s also known, and we ended up talking about AI because we’re looking to make genies available to all programmers at work, and we want to do it safely. While talking about what we’re doing, he says he doesn’t think we’ll have programmers like we do today, that programming is probably going to end up being more like normal language that compiles down into software (all about that prompt).

I’m not sure that’s the full story, thinking about how we’ve progressed with, for example, assembly programming. Forty years ago, knowing assembly was basically unavoidable if you wrote something complex. Now? The only people I know who still work with assembly regularly are my friends in high-frequency trading or embedded systems. Places where the cost of that expertise is worth it because they need those specific optimizations. It doesn’t mean it went away, but yeah, we use high-level languages (more akin to spoken languages than assembly) to write software now.

Us seniors have always thought that the ‘kids today’ don’t know the basics, where the basics are defined as whatever level of abstraction we learned when we got started. Assembly folks complained about C programmers. C programmers complained about scripting languages. Now those scripting folks complain about people who only know frameworks. A lot of people I come across don’t really know how to set up a Linux box, and that was required for me because otherwise I couldn’t host anything. But why should they know it now?

Mark connected with this and said that the people senior to him all knew assembly to some degree, but starting at C, he never did. He didn’t bother with yacc, lex, any of that, because the compiler handled it. What was core skills for them became optional for him. Every generation’s “minimum viable knowledge” shifts up a layer of abstraction.

I think we’re coming to a point where more people are able to get the output of programming: something that does what they need, even if it’s held together with digital duct tape. Which is Jevons’ paradox at work: when something becomes more efficient, we don’t use less of it, we use way more. And all those people using it poorly? That’s not a bug, that’s the feature.

The commoditization pattern #

Every technology does this. Think about typing. Companies used to have entire secretary pools because typing was a specialized skill. Now? Everyone types. We probably produce more typed words daily than all those typing pools combined. The skill didn’t disappear, it just became so commoditized that we don’t even think of it as a skill anymore. But writing, oh boy, that’s a skill and we recognize good vs. bad even if everyone can type.

Socrates complained that writing was a terrible way to share knowledge, that it would make people “seem to know much while for the most part they know nothing.” (Sound familiar?) When calculators came out, people panicked that kids wouldn’t understand math anymore and society would collapse!!

Some examples of how we’ve ruined the fabric of society:

I know how useful ‘barely good enough’ programming can be, because back at my first job, I built a stock-take system over a weekend with a friend. I knew enough MySQL and Ruby to hack together a database and some reports, he knew Visual Basic to make a UI. We had laptops on shopping carts with USB barcode scanners. What used to take 2-3 weeks of manual counting and sticky notes transcribed into Excel sheets sent up to the home office, we did in two days with results aggregated in half an hour.

Was it elegant code? God no. Did it solve a real problem? Absolutely. I spent about five years at this company, as the first and only ‘IT employee,’ building little tools and scripts to help make our days simpler. Funny thing is, I was hired to fix printers and keep the POS running, but once I’d gotten that under control, people started giving me purchasing assistant work, and, well, I knew just enough programming to make that go away too. At one point our ERP vendor said they’d never seen a customer with as much automation as us, which was really just me getting sick of manual work and knowing just enough programming to make it go away.

And that’s commoditization at work. The specialized skill becomes rare and expensive, while the everyday version becomes accessible but, let’s be honest, pretty shitty. And you know what? There’s nothing wrong with shitty if it solves real problems. The expertise, all those ‘it depends’ answers we love to give, that comes in when you need to scale it, secure it, make it last. But first? First you just need it to work.

What’s different #

We’re not just replacing horses with engines. We’re replacing the process of acquiring expertise with cock-sure genies that answer everything instantly.

It’s like how, in parts of history, being fat signalled wealth, today, abundance is everywhere and the signal has flipped. Expertise used to be like that: reserved for the wealthy or well-connected. Now everyone gets apparent expertise. And just like abundant food doesn’t make you healthy (without self-control), abundant answers don’t make the decision correct.

Plus, when the wealthy got bad advice, they had lawyers and fall guys. When we get bad advice from a genie? Well, good luck explaining that in the post-mortem when your name was on it.

Spreading out, not disappearing #

Those assembly programmers didn’t disappear, they just don’t all work at IBM anymore. They’re scattered across trading firms, embedded systems shops, game companies, and more. The expertise spreads out because it can, you don’t need to be at one of three companies to use your deep skills anymore.

(And yeah, I know someone’s thinking “but what about all the jobs that will disappear?” We don’t have many manure shovelers anymore since cars replaced horses. We also have social media managers, cloud architects, and whatever it’ll mean to be a “context engineer.” The jobs change. They always have.)

Same thing will happen with what we call programming today. The absolute number might not even go down much. Maybe we’ll have fewer at big tech companies and more scattered across regular companies, building internal tools, being the person who knows how to make the genies behave.

Kind of like how most companies have someone who’s ‘good with computers’ to fix Outlook or figure out why the printer isn’t working. They don’t need to be highly educated in IT, they just need to know how to figure things out and stick with it.

Which skills do you keep? #

This is like my relationship with cars. I can drive, change oil, swap tires. Am I the best at parallel parking? Nope, and I’ll drive a bit further to avoid a tight spot. Should you trust me to race? Definitely not. But I can safely get on the highway and go reasonably fast when it’s appropriate (those spots we’ve built up to let Gripen land and take off).

Some skills I want, some I don’t care about. And that’s fine, until the world expects me to be good at the ones I’ve skipped.

Testing is one of those skills that shows this tension perfectly. I’m a TDD person, it’s a fantastic design tool, not just bug-catching. But many programmers still treat it as an afterthought because “how can you know what to implement before you build it?” That resistance is exactly why it’s valuable: it forces you to think differently and know what outcome you want. And that’s why genies make things dangerous: they can write tests that look good, but if you don’t understand testing as design, you won’t know when you’re building the wrong thing with great test coverage.

Deciding what sticks #

So how do we learn when we have genies answering everything? I’ve been experimenting with this. My cooking has genuinely improved with an AI coach, but I’m not just following recipes. I ask why we’re using these ingredients, why this technique works, what the char is actually doing to the flavor. Cooking is something I want to get better at, no intention to become a proper chef, but being able to whip up dinner, using up my ingredients, and liking the taste? That’d be nice.

I’ve been using Grammarly for years, and I know my writing has improved from it. Not because it fixes things for me, but because I’ve started catching the mistakes before the red underline shows up. Though we still disagree about commas, Swedish habits die hard.

There’s this thing called tacit knowledge, stuff we know but can’t explain, that gut feel that something about this code is wrong but you can’t exactly pinpoint it. You write the same code again and again, get the same PR feedback again and again, until it clicks. But does it have to be that painful? I wonder if the genie can actually help us create better ways to build tacit knowledge, since it can generate examples and evaluate them. Like, I could ask it to show me ten variations of the same function, each with different edge cases, and develop that pattern recognition faster.

Maybe a good way for me to be more intentional is to write down which skills I want to learn. The ones where I want to gain that tacit knowledge, and also take it further so I can explain it, and not just feel it. Cooking and writing are both on that list. So is design and architecture when programming, and I’m much further along there. (Thanks Daryl for the inspiration.)

What I’m exploring next #

I’m not a breathless AI fan. But, for me, it has turned into an intellectual sparring partner, someone to bounce ideas off who helps me figure out what I truly want. The genie shows me options, my gut tells me which ones I like or not, and I try to listen to that gut feeling and understand why.

Because apparently our brains are turning to mush because of AI. I don’t buy it, but I also don’t intend to let it happen to me. I still want to know which skills matter to me, which ones I’m keeping sharp, and which ones I’m okay with the genie handling as long as I can check the output.

I don’t have this figured out. But I’m pretty sure the answer isn’t to pretend the genies aren’t here, I have enough evidence that I get help from them, and it’s definitely not to blindly let them do everything without thinking. So I’m gonna keep poking at this, probably change my mind a few times, and see what sticks.

This is the first post in a series where I’ll be figuring this out in public. How to decide what to learn deeply, how to tell when you’re just parroting the genie, and how to keep judgment sharp when answers are cheap. Because your name is still on whatever you send out, genie or no genie.

We’re all in our AI twenties right now, trying to figure out how to ride these motorcycles without crashing. Might as well compare notes along the way.

This is different from normal shell where ${VAR} is the same as $VAR and it exists to make sure you can concatenate strings without issues, i.e.

VAR=m000
echo "'${VAR}est'"  # => 'm000est'
echo "'$VARest'"    # => ''

I.e., with "$@" the arguments "one two" three will be 2 arguments, the first being "one two", and without it will become three arguments, all separated by space.

Go to Settings -> Webhooks and then click on the integration you want to look at.

1. cp /etc/pam.d/sudo_local{.template,}
2. Edit /etc/pam.d/sudo_local and uncomment auth sufficient pam_tid.so.

The reason for doing this in sudo_local is that this file will not get reset with system changes from Apple.

The main feed will give you everything I post, if you only want certain types of posts, I’ve also made section-specific feeds. The blog feed is what you’ve been getting if you were already subscribed.

• Main feed
• Blog feed

I have been wondering how to think about AIs (or genies) and how computers are like bicycles for the mind, as Steve Jobs put it, and I think these tools take it further. They are more like motorcycles for the mind. They go really fast, and you better not treat them like a bike, because you need to know what you’re doing. How to handle that thing. You need to make sure you don’t try to go too fast too soon, or for too long, because you’ll get speed blind and… things will happen.

I’m pretty sure motorcycle insurance costs way more when you’re in your 20s than in your 40s or 50s. There’s a reason for that. People who are older generally know how to ride the thing, and they’re not as wild when doing it.

But I think when it comes to using AI we’re all kind of in our 20s because we’re figuring it out.

It’s my name on whatever goes out #

I was at a wedding recently, talking to this lawyer, 50s, 60s maybe, working at a multinational. He’s been playing around with AI and feels it’s giving him an enormous productivity boost for writing and doing research for him.

As we were talking about how he was using it he said something that stopped me cold: “It’s my name on whatever goes out.”

He’s already caught the AI making things up. He has to check every line, every reference. He explicitly asks it to give him the references so he can look them up himself. And if I understood correctly, this isn’t significantly different from when juniors do the work for him. Because it was still his name on it. He needs to validate it. Whatever he puts his name on and sends out has to be right.

And that’s when something clicked for me. Remember how I was talking about the different hats we wear? Well, you can outsource wearing the hat. You can have the genie do the work. But it’s still your name on it. No one else cares if you outsourced it, they only see your name on it. You can’t blame the genie for a shit job. It was your name.

What we think we’re automating #

I keep hearing engineers say, “oh, I don’t have to do this boring thing anymore!”

Meeting notes are a perfect example. I have access to Google Gemini at work, and people just let Gemini take meeting notes and send them out without reading them. Really. “Huh?” I hear some of you say now, that’s what it’s great for, the notes are just toil. Well, no, what are meeting notes actually for? They’re about making sure we’re on the same page, that we have the same agreements and understanding. If you let the machine mindlessly capture words and don’t check that it actually documented the meaning behind what we said and understood, you’re failing at the actual job of running that meeting.

This reminds me of Chesterton’s Fence, that principle about not removing a fence until you understand why it was put there. Before you automate away some “boring, pointless thing,” maybe ask yourself: why is it that I’m doing this in the first place? Because if you don’t understand why it’s done, how do you know the automation did it well?

And I wonder if what’s really happening is that we’re not automating the work, we’re automating away our attention to the work. We’re not automating the output. We’re automating away our understanding of what that output should be. And experienced people are the ones who spot strange patterns (or have taste) precisely because they’ve stayed engaged with the work over time. You can’t develop that instinct if you’re not looking.

The work worth doing #

Which brings me to something eyebrow raising that Kent Beck said: with AI, 90% of his skills became worthless, but the leverage of the remaining 10% is now worth 1000x. The question is: which 10%? This is the “knowing where to put the X” skill, that judgment call and experience you bring: that’s what makes the genie do what’s needed.

When you let the genie write code for you and it introduces bugs that you would have caught if you’d actually read the code… you’re not doing your job as a product engineer. Yeah, you’re slinging more code and doing it faster. But it’s not about the code, it’s about delivering the solutions we need when we need them.

There’s a difference between delegating execution and delegating responsibility. You can have the genie execute tasks, but you can’t delegate the responsibility for the outcome. That’s still yours. The hat is still on your head, even if AI is helping you get things done faster while wearing it.

And I find pride in doing the work well. Even the boring bits. Sometimes we might not enjoy the work, but doing things well will make most things feel worthwhile. Because there’s nuance and understanding you can only get by truly groking something, and that’s when you can safely change and improve it.

Finding your balance #

The question isn’t “can the genie do this task?” It’s “when it does this task and puts my name on it, am I comfortable with what might happen if it gets it really, really wrong?”

In my experience, the engineers who are using AI most effectively are the ones who treat it like that lawyer treats it: as a powerful tool that still requires their full professional judgment. They understand they’re being paid for the judgment part of the work, not just the execution part. The genie can help with execution, it can draw lots of Xs quickly. But knowing where to draw them? That’s all you.

Right now, these systems can’t truly understand context the way a senior does. They can’t make actual judgment calls, they’re pattern matching (even if, admittedly, slightly magical in how they do it). They give us speed, not judgment or direction. Output, not understanding.

I’m still working out what learning looks like when AI can show you all the moves. My cooking has genuinely leveled up with an AI coach: I’m making dishes I never could before, and understanding why certain techniques work. But I know this is like training wheels. I couldn’t fully do this alone yet, and that’s the thing: I’m not mistaking this speed for actual skill, not confusing making progress with real proficiency.

So here I am, learning to ride this thing safely, trying to get out of my AI twenties you might say, before I take it on the highway.

Because whether you’re wearing your engineering hat, your architect hat, or your team lead hat, your name is still on it. And I’d like to make sure I am not only wearing the helmet but also know how to ride this motorcycle before I really open up the throttle.

I believe we often skip steps because we don’t know why we do them. It’s not tedious for tediousness sake, it’s often there because it’s important. And until we have the automation, or maybe we’ve intentionally chosen not to automate it, we need to find some way of helping the human ’live the situation.'

Which reminded me of this Terry Pratchett quote: “Every trade, every craft had its hat. That’s why kings had hats. Take the crown off a king and all you had was someone good at having a weak chin and waving to people. Hats had power. Hats were important.”

And there’s something to this, right? Like in my own role as a principal engineer, I am definitely seen as my role more often than I am the person beneath it. When people see me in a meeting, they see the title first. Hopefully I provide valuable insights and useful things. But even if I provide absolute garbage input, there’s a significant chance people will listen, and maybe even not push back, because of the hat.

But, I have been wondering: what is your role and what is your ownership? What is it that you individually provide to whatever work you’re doing? And is it always the same hat?

The hat you don’t know you’re wearing #

I think your hat changes depending on the role you’re fulfilling at the moment. When you’re working as a software engineer, you wear an engineering hat where you think about the feasibility of what you’re building, like, can I maintain this thing long term, how far will it scale, and how testable is this design?

But if you’re working as a product engineer, you’re probably first thinking about how do I get this damn thing out the door, so you can see if it works or not. It’s about trying things, slapping it together, flinging it against the wall with the smallest responsible amount of tests (so you know you don’t break existing things when you iterate), and see what sticks.

I’ve noticed, though, that we often forget to switch hats when we need to.

Take deploying to production. When we’re about to take something live, we should be wearing a different hat. We need to embody the spirit of production itself, become its guardian of stability (yeah, yeah, too many roleplaying games). Some orgs have a “release manager” as a dedicated role, but even if it’s not a dedicated role, the need is always there. Taking things live is one of the most dangerous things we do: because most incidents happen when we change something. Whether it’s config, a flag, or code.

The product engineer hat and the production guardian hat often feel very similar, and that’s exactly the problem. Just because a hat is similar doesn’t mean it’s the same. The product engineer wants the experiment live yesterday. The production guardian knows we can only ship today, and wants to make sure we still have a tomorrow. It’s this impossible tension, one person wanting to have already finished something we haven’t even started, the other pumping the brakes to make sure we don’t break what’s already working. And that often leads to “safety theater,” where we do it a little bit slower, say 30m to get everywhere instead of one quick change, to catch disasters but not slow burn issues. Obviously this tension changes, to use Kent Beck’s 3X model, depending on whether you’re in eXplore, eXpand, or eXtract mode. We’re mostly in eXtract, so breaking things affects a lot of customers and the production guardian hat needs to be especially strong.

For example, in another incident, someone didn’t manually check dashboards after deploying, which was part of the process, because they trusted the automated alerts. The alert came in after 10 minutes when it had enough data to be sure it wasn’t temporary. But a human who was actually monitoring, really living that production guardian role, would’ve realized something was wrong within a minute or two. The manual step was there because the team knew their automated alerts weren’t good enough to handle all issues around deployments.

Where I work today, we have some 250 backend components. We can test all we want, black box integration tests, contract tests, end-to-end tests, manual QA, all of it. We’re still going to miss and get stuff wrong sometimes.

The point and our challenge in mindset is: when we’re taking things into production, we’re not wearing the hat of the product engineer anymore. We’re taking on the role of production’s guardian, and we’re shepherding changes safely into production.

It’s like Vim modes, but for work #

Say whatever you want about Vim, but one really nice thing is that it’s modal. The idea that I’m now doing this thing (inserting or editing text), and now I’m doing this other thing (normal or moving and transforming), and you behave differently in those modes.

I see this in my own work all the time. I regularly review my own PRs because even though I went through everything when writing my commit message, I invariably look at it differently when I’m on GitHub in the interface I use for reviews. I switch much better into reviewer mode when I’m leaving comments there. It’s common that I review and leave myself comments for what to fix, discover I need a comment, or elaborate a little bit further on something the reviewer might not be familiar with.

It’s like TDD in a way. When you’re red, you rush towards green by just getting it to work in the simplest way you humanly can. Then, when it’s green, when you got it working, you refactor it. Different modes, different goals.

We need to be more intentional about which hat we’re wearing at the moment.

Becoming the character #

I saw this story about Christian Bale recently (and look, I can’t find the original source, so this might be one of those stories that’s too good to fact-check, but it perfectly captures what I’m talking about). He’s a famous method actor, someone who becomes their characters completely. Apparently, when he wasn’t getting much work, he dreaded having to read through his insurance contract and have that conversation because it was boring.

But then he decided: if I were a character who really cared about understanding insurance thoroughly, who would want to have an informed conversations about it… So he became that character and called up his insurance company. Apparently, they’d never talked to someone so well-researched on their contract.

And that’s the thing, we kind of need to do this throughout our day. When you’re taking something live, you’re not the “ship fast” product engineer anymore. You have the right to say no, the right to say this has to be done slower because of these risks. Your responsibility is to make sure production is stable and things will continue to work.

The $9,999 skill #

There’s this great story about Charles Steinmetz and Henry Ford. Ford’s engineers couldn’t fix a generator problem, so they called in Steinmetz. He spent two days just listening to the generator and scribbling calculations. Then he climbed up, made a chalk mark, and told them to replace sixteen windings at that exact spot. It worked perfectly.

When Ford got the $10,000 invoice, he asked for an itemized bill. Steinmetz sent back:

• Making chalk mark: $1
• Knowing where to make mark: $9,999

And think about what Steinmetz did: he could have torn the whole generator apart, called in a team of engineers, or tried a dozen different approaches. Instead, he recognized this was a moment for careful analysis. He spent time listening, thinking, calculating. He put on his expert diagnostician hat, not his collaborative problem-solver hat or his hands-on mechanic hat.

And this is it exactly. Knowing where to make the mark, knowing which hat to wear when, that’s the $9,999 skill.

But it’s not just about perspective: each hat comes with different expectations, different powers, different rights, and different responsibilities. The production guardian has the authority to halt deployments. The incident responder can stop all feature work immediately. The planning hat carries the responsibility to think long-term even when it slows things down. When you put on a hat, you’re not only changing how you think and approach the situation: you’re claiming the legitimate authority that comes with that role.

I think that we often fail not because we lack skills, but because we’re wearing the wrong hat for the moment. Or worse, we’re trying to wear all the hats at the same time.

The product engineer hat wants speed. The production guardian hat wants stability. The incident responder hat wants recovery. The planner hat wants predictability. These aren’t compatible mindsets, you can’t optimize for all of them simultaneously. The goal is to negotiate productively across them, which is hard as one person, and, this is also why working through problems with others is so powerful.

THE INCOMPATIBLE MINDSETS
Product Engineer  
  → Wants speed (ship it yesterday)
Production Guardian
  → Wants stability (safety today, here tomorrow)
Incident Responder
  → Wants recovery (fix it now)
Planner           
  → Wants predictability (sustainable pace)

So here’s what I’ve been trying to do, or rather, what I should start doing: be explicit about which hat I’m wearing. Right now I say things like “okay, from a stability POV” before raising concerns about deployment risks. But I should actually say, “let me put on my production guardian hat for a second.” It helps others understand which perspective I’m bringing, and it helps me focus on what matters for that role.

Tying it on #

I think there’s more to the hats we wear throughout the day because it’s not just at work: supporting partner, fun uncle, mentor, learner. Each comes with different expectations, powers, and responsibilities.

But for now, I’ll leave you with this: What hat are you wearing right now? What are the expectations that come with it? What responsibilities? And more importantly, is it the right hat for what you’re trying to do?

Because understanding when to switch might be one of the most underrated skills we need. I’m currently convinced that being intentional about our roles, knowing which hat we’re wearing and when to change it, that makes a difference. Not between being good or great, but between solving the right problems and creating new ones.

What would change my mind is if someone showed me that this context-switching has too much overhead. But, I think these aren’t the context switches we usually complain about, the ones that kill our flow when we jump between meetings and deep work. These switches are within the same context we’re already working in. We’re just tilting our perspective, changing how we evaluate the situation. And in my experience, the cost of wearing the wrong hat is far higher than the cost of being intentional about switching.

I shared the change for review, and a colleague raised a great point: “What about our black box integration tests?” These tests hit APIs and external services that Go can’t track as dependencies. If they cache when they shouldn’t, we might miss real failures: the tests would pass because they didn’t re-run, not because the code actually works.

func IsIntegrationTest(t *testing.T) {
    t.Helper()
    _ = os.Getenv("GITHUB_SHA")
}

The Fundamental Problem #

When my colleague warned me about integration test caching, I realized we had a bigger problem than just my PR. How could I fix this across our entire org? We’ve got ~250 repos, and asking every team to remember special flags or change their test execution wasn’t going to fly. I needed something that would just work everywhere with minimal changes.

The fundamental issue: our black box integration tests don’t “declare their dependencies” to the Go compiler, so it doesn’t know that something the test is critically dependent upon has changed and requires a rerun (and practically, neither do we really), because they test network services and external binaries that Go has no visibility into. I always have to run these tests.

I wanted the caching benefits without the risk, ideally with minimal changes since we have lots of codebases that could benefit from this caching improvement. Since our black box integration tests use a shared internal library, I was hoping to find a solution I could implement once there rather than asking teams to modify individual tests or change how they execute them.

So… How Do I Make This Work? #

I started by looking for the obvious solutions, there’s probably a flag to ignore the test cache, right? And there were two straightforward options: go clean -testcache and -count=1. But here’s the thing, both of them throw away ALL test caching, which felt like using a sledgehammer when I needed a scalpel.

Then I remembered reading something about environment variables, and files, affecting test caching. I went into go help test and I remembered right, tests that read environment variables get invalidated when those variables change, so since this is about CI, and I know that CI systems give us unique commit SHAs as env vars… and we have a shared library to help write black box integration tests… so I can make the fix once in that library and everyone gets this benefit!

Alright, that gives me three options, how do they compare?

Simple Option: go clean -testcache

• Pro: Dead simple - add one line to your CI config, no test changes needed
• Con: Zero caching benefit for tests
• When to use: Safest solution that still gives you build benefits without changing scripts or tests

This works by creating a file with the current Unix time in nanoseconds and then, whenever Go runs tests, it checks if the cached test is newer than that timestamp. I appreciate the simplicity: the cache cleaner doesn’t need to understand which cached items are tests (and there are only hashes in that folder), it just sets a “tests are invalid after this moment” marker and the code skips it or not.

Explicit Option: -count=1

• Pro: Granular control per go test invocation
• Con: Need to change test execution and remember it everywhere, easy to miss (especially in monorepos with many go.mods)
• When to use: Only some tests need cache invalidation

This is the one you’ll see when people ask how to make Go not cache tests, for our situation not super useful, but mentioning it for completeness.

Elegant Option: Environment Variables

• Pro: Automatic cache invalidation on CI when needed, maximum caching benefit when possible
• Con: Requires thoughtful test design
• When to use: You have enough tests that the speedup matters and you’re willing to be intentional about cache invalidation

Or laid out visually:

*When implemented correctly

How the Environment Variable Approach Works #

This works because Go invalidates the entire package’s test cache whenever an environment variable it depends on changes, and most CI systems expose a unique commit SHA as an environment variable. For example,

• GitHub Actions: GITHUB_SHA
• Drone CI: DRONE_COMMIT_SHA

When your integration test reads this variable, Go automatically invalidates the cache for that package whenever you push new code. The key insight: you don’t need to use the variable meaningfully, just read it. One thing to keep in mind: consider keeping integration tests in separate packages from unit tests to avoid invalidating unit test caches unnecessarily when only the integration tests need cache invalidation.

package integrationtesting

func IsIntegrationTest(t *testing.T) {
	t.Helper()
	// This ensures that we invalidate the cache
	// on CI whenever we have a new git SHA
	_ = os.Getenv("DRONE_COMMIT_SHA")
}

// ... another file relying on integrationtesting

func TestAPIIntegration(t *testing.T) {
	integrationtesting.IsIntegrationTest(t)

	// Your actual integration test
	resp := callAPIEndpoint()
	assert.Equal(t, expected, resp)
}

Understanding How It Actually Works #

I was getting worried about edge cases. The Go docs said tests won’t cache if environment variables change, but what exactly did that mean? Would reading an env var in one test invalidate all tests everywhere? Just that package? What if the variable is read through a library call?

I did some searching and found the testlog package, which is how Go implements the tracking of when env vars are read and files opened. That gave me a good sense of how it should behave, so I made an experiment to validate what I expected from the documentation and the code I found.

The Experiment Results #

I created three test packages to understand the boundaries:

• One that reads DRONE_COMMIT_SHA directly
• One that reads it through a library call
• One that doesn’t read any environment variables

Then I ran nine scenarios to test my assumptions: What happens when I set the variable? Does package listing matter (./... vs manual package lists)? What about go test with no arguments?

Key findings:

• Package-level invalidation: All tests in a package get invalidated if any test reads the variable and the variable changes,
• Library calls count: Reading env vars through dependencies still invalidates the cache
• Package listing doesn’t matter: ./..., manual lists, even ./ all cache the same way
• No arguments = no cache: go test without targeting never caches
• File-level targeting = no cache: go test file_test.go also never caches

The big takeaway: Go runs tests per package, and packages are run in parallel. If any test in the package touches an environment variable, the entire package’s cache depends on that variable’s value, so the cache is invalidated when the value is different on the next run.

Or as a semi-flowchart:

Package reads env var? 
    Yes → Env var value changed? 
              Yes → Cache invalid
              No  → Cache valid
    No → Cache valid

This made me comfortable that the approach was predictable and wouldn’t have surprising edge cases, especially because the way testlog works is by simply recording that something called os.Getenv with this value, and it doesn’t know which test or from where, just that in the course of running these tests this happened. Nice and simple.

If you want to explore how Go makes decisions around caching yourself, you can run tests with GODEBUG=gocachetest=1 to see Go’s caching decisions in real time. There are more debugging variables available in go help cache.

The Results #

We cut our CI times in half with this caching approach, and I’m confident it’s safe to roll out widely because I understand exactly how it works and I can make the required changes to our shared integration testing library so it will just work for the standard case.

What I appreciate about Go’s design here is how it avoids clever optimizations in favor of predictable behavior. I knew caching wasn’t just on/off, but I wasn’t sure if there would be complex edge cases to worry about. Instead, Go picks the straightforward solution: package-level invalidation that’s easy to reason about.

The “bigger packages than you think, but still not huge” philosophy means we get plenty of caching benefit, while keeping the invalidation scope manageable, and if we need finer control, we can always split into more packages.

And that’s the thing, Go just picks the simple and boring solution that works, it’s why I love working with Go. 😁

The full experiment is available if you want to dig into it yourself.
Presentation slides from the Singapore Go meetup

A colleague asked for feedback on a meeting they ran, and after sharing my thoughts, I realized my advice about meetings sounded exactly like how I talk about planning projects. This got me thinking: the skills for running good meetings and successful projects are nearly identical.

Yet somehow, we still treat our meetings like they’re different beasts entirely. Why do so many meetings fail? Usually because we approach them without a clear plan.

Meetings are often run like debugging without a hypothesis, just throwing log statements everywhere and hoping something works, where you have a list of topics but no clear goals or time constraints. You might cover everything, but that’s more luck than design.

This is similar to “planning forward” in projects: We start with a feature list without understanding the details, create up-front timelines in Gantt charts that rarely get revised, and postpone integration until the end. We move through tasks sequentially, assuming everything will go right, only to discover problems when time is about to or has already run out.

Both approaches ignore that time runs out, whether in a 30-minute meeting or a three-month project. Without a plan, meetings go nowhere and projects fall behind.

In my experience, here’s what both have in common:

• Gather everything that needs to get done
• Clarify goals for each item
• Group similar things together
• Prioritize the important stuff first
• Estimate how long each section will take
• Guide the work to keep it on track
• Define next steps so everyone knows what’s happening after

The pieces #

Let’s break down each of these components and see how they apply specifically to meetings:

1. Gather: Define your scope #

Just as you wouldn’t start coding without requirements, don’t start a meeting without defining what needs covering. List all topics and be realistic about what fits in the allotted time. If your meeting scope looks like your backlog after a year of “we’ll get to it later,” you’re doing it wrong.

2. Clarify: Set measurable goals for each topic #

For each topic, be clear about what you’re trying to accomplish:

• Discuss: “We need to decide on auth providers. What criteria should guide our recommendation?”
• Decision: “We recommend Provider A because…”
• FYI: “We’ve implemented the new provider in staging and learned…”

Pro tip: Prefix each agenda item with one of these categories (Discuss/Decision/FYI) to ground everyone in what you’re trying to accomplish with each topic.

3. Group: Combine related topics #

Identify when similar items come from different people and combine them. This prevents redundant discussions and gives a clearer picture of what needs attention, similar to combining related user stories into an epic. When several people raise the same issue in different ways, it’s usually important.

4. Prioritize: Focus on what matters #

Sequence by importance, not by who talks loudest or which item has been sitting on the agenda longest. Start with critical items so when you inevitably run out of time, at least the important stuff got done.

5. Estimate: Time boxing #

We accept that iteration estimates will be wrong (it’s just a question of how wrong), and meeting time estimates work exactly the same way. Having a clear time target keeps everyone aligned. Be explicit about constraints: “We have 15 minutes for this topic” creates healthy pressure to stay focused.

6. Guide: Keep discussions on track #

Just like daily standups in project work, regularly check in on your meeting’s progress. Help nudge the meeting along:

Monitor progress toward goals #

Just like in daily standups, pay attention to whether the discussion is moving toward your goal. Ask yourself, “Are we just talking, or are we getting closer to making a decision?” If you’re 10 minutes into database options and no one has mentioned the actual requirements, it’s time to refocus.

Keep discussions focused #

When someone goes off on a tangent describing an intricate edge case, redirect with: “That sounds like an important edge case. Will this affect the decision we’re trying to make right now? If not, could you chat with the relevant team after this? Right now we need to focus on making our decision.”

Provide time checks #

My rice’n’garlic advice is to check in halfway through a conversation and remind everyone of the time left. Sometimes simply saying “We have 7 minutes left to decide on this” creates the right pressure to wrap things up. If needed, quickly restate the goal: “Remember, we just need to agree on which two options to research further, not make the final decision today.”

Make realistic time decisions #

Be realistic about whether you can finish in the time you have. If a 15-minute agenda item is turning into a 45-minute discussion, decide whether to:

• Extend the current meeting (if everyone can stay)
• Schedule a follow-up with just the key stakeholders
• Assign someone to gather more data and come back next time

7. Next steps: Ensure clear outcomes #

Don’t let topics end without everyone knowing the outcome. For each item, ensure everyone knows:

• Is it done or still open?
• Who owns any follow-up actions?
• When should we expect progress?
• How will we track it?

Capture this in your meeting notes. Don’t rely on memory. Write down the decisions, owners, and deadlines so our future selves can thank us.

In practice #

Different meetings need different approaches, but a well-run meeting follows the same meta structure. This structure works for all kinds of meetings: one-on-ones, planning sessions, even technical architecture reviews, because the topics and participants change, but the structure that makes meetings effective doesn’t.

Let’s see how this structure looks in practice with a couple of common meeting types.

Retrospectives #

Retros help teams reflect on what worked, what didn’t, and what to improve, much like code reviews but for your processes.

• Gather: Have everyone add topics to a shared retrospective board
• Clarify & Group: Cluster related topics to understand common themes
• Prioritize: Vote on which issues will have the most impact to address
• Estimate & Guide: Timebox discussions, default 3 minutes per topic, explicitly decide to extend or move on
• Next Steps: Capture clear action items, owners, and timelines

Pro tip: Seeing the same issues iteration after iteration? Try a reverse retrospective where you start with known problems and dedicate the entire session to brainstorming solutions.

Recurring team meetings #

Regular meetings work best with a consistent structure, like good software needs a reliable architecture.

• Gather: Maintain a living document where people add items between meetings, plus time at the start to add more
• Prioritize: Critical conversations happen first, not just what’s been on the list longest
• Clarify: Define each topic’s goal and intended outcome (FYI, discussion, or decision-making)
• Estimate: Allocate time to topics based on importance and complexity
• Guide: Check progress mid-topic with “Are we getting closer to our goal?”
• Next Steps: Note who’s doing what by when

Pro tip: For complex topics, try a silent meeting approach where everyone reads and comments on a shared document before discussion. This helps people think deeply, solve quick questions in writing, and prevent a few voices from dominating.

The meta-skill #

Running a good meeting uses the same mental muscles as running a good project:

• Scope definition is like requirements gathering
• Timeboxing topics is like defining iterations
• Progress checks are like standups

If you can’t keep a 30-minute meeting on track, how will you keep a three-month project on track? Both require the same core skills:

1. Clear Goals: “We want to discuss database options” is as useless as “We want to build a better app.”

2. Risk Management: Put risky, important topics first, whether in meetings or project timelines.

3. Progress Monitoring: Regularly ask: “Are we moving toward our goal or getting sidetracked?”

4. Flexibility with Discipline: Sometimes you need to extend a meeting or an iteration, but do it consciously, not by default.

5. Follow-through: Track action items like you track bugs, they’re just as important.

I wonder if running meetings could be good practice for running projects? The skills are similar, but the feedback cycle is much shorter.

Conclusion #

Every engineer knows that a well-designed system needs both good architecture and regular maintenance. Your meetings are no different.

By applying the same structured thinking to your meetings that you use in your code (defining clear requirements, managing scope, prioritizing effectively, and documenting outcomes), you transform the meetings in your calendar into productive work sessions.

In my experience, these skills compound nicely. I bet you’ll get better at delivering focused projects as you get better at running focused meetings.

So before you schedule your next meeting, run it through the same mental checklist you’d use for planning a project:

• Have you gathered topics and defined what you want from each one?
• Have you prioritized what matters most?
• Can this all get done in the time you have?
• Do you have a plan to keep discussions on track?

Keep in mind that guiding meetings is a lot like incident response. You can plan all you want, but you need to react to what’s actually happening. This framework gives you a starting point, but the real magic happens when you apply it in the moment. Start small by focusing on timeboxing discussions or defining clear outcomes. The structure matters, but how you adapt when the sewage hits the aerowatt generator is what really counts.

If not, refactor before you commit.

Efficient meetings aren’t magic. They’re just good engineering applied to communication.

All of these things don’t necessarily make a lot of sense from how much time I save, but, it also makes me happy to spend a bit of time improving my environment, and spending a bit of time to make me happy is good enough for me.

I view doing these kinds of small workflow improvements like a kata because it improves my automation/scripting skills and encourages me to think about how I work. I usually give myself 10-20m to try and make these kinds of improvements just so I know how much time to spend. Just don’t go overboard. XKCD, as always, have a comic to illustrate the downside of going too far. 🙂

What is Alfred and why is it an app I’m focusing on? #

Alfred is an application launcher but oh-so-much-more. It connects with macOS and the Workflows contains a lot of extensions that allow you to interact with all kinds of programs, websites, etc.

A big part of what Alfred has helped me create is a more unified experience across the apps and websites I use. I have moved some operations that behave differently in different apps into Alfred because then I can focus on what I need to do and then use Alfred to provide consistency (and as I’ve been told, “consistency is good even outside the bathroom”).

Now, let’s look at how I use Alfred.

Built-in functionality #

These are features that don’t require anything extra to install and use.

Open an app #

Alfred’s starter feature is the application launcher, and it means you summon it with a keybinding and type the name of the app you want to start and voilà. I have bound the keyboard shortcut to cmd+space and replaced the built-in Spotlight search.

Spell / define #

There are certain words I rarely get right (continuous) and some words are spelled very differently from how they sound. Summon Alfred and spell <word> and you’ll have suggestions that often will go right. And if you don’t find it, replace spell with google and see if Google knows better. Hit enter to copy the correct spelling to the clipboard.

And define is the same thing but for dictionary lookup because you have some word you’re unsure what it means, or because you’re wondering if someone was trying to call you something you with some subtle nuance to a word. 😉 Hit enter to open the definition in macOS’s dictionary app.

Calculator #

You can give it an expression and when you hit enter the result goes into the clipboard. I often end up using this instead of opening a Python console on the CLI.

Custom web search #

A custom web search allow you to quickly open a web browser at a particular website with whatever value you’ve typed into Alfred which doesn’t have to be a search engine or even a search page.

To configure a custom web search summon Alfred and hit cmd+, to open the settings page. Go into the Features tab and click on Web Search.

Some example search engines I have made:

• Jira: https://jira.example.com/browse/{query}
  • This isn’t a search but rather the view this ticket. Because I often get a ticket id (either from a commit message or someone rattling it off in a meeting) and this way I can open it quickly
• Confluence: https://confluence.example.com/dosearchsite.action? queryString={query}
• Wordnik: https://wordnik.com/words/{query}
  • So I can find synonyms and other alternatives for words. Often use this when I want to find a good name for something which has been inspired by Hunting for great names in programming.
• Pypi: https://pypi.org/project/{query}
  • To look up python packages

Working with other applications #

Alfred has ended being the tool that brings my apps to focus and smoothes over differences between apps.

Give my most common apps a keybinding #

Instead of cmd+tab between the various apps I’m using I have bound specific keybindings to my most used app, so I can quickly swap between them. Hat tip to Rico Sta. Cruz who blogged about this a couple of years ago and who I picked it up from.

The big benefit I have found here is just the ease of being mid-thinking and wanting to switch back to another app, whether it’s to jot down a quick note, to finish that Regex you were visualizing on Regex 101, or to get back to Slack to paste that thing your colleague asked for. It feels so seamless compared to tabbing between.

This is using Alfred’s Workflows, and they’re part of their advanced set of options. You can do keybindings that work across all of macOS as well as actions based on what you’re typing.

Spotify controller #

I have been using these keybindings since before Alfred, in Quicksilver, and there are other workflows for Spotify but since I had these I never bothered installing anything else.

The cool extra in this workflow is that I added a keyword to open the current playing song on Genius.com because I like reading the lyrics.

This is an example of something where the automation is far from necessary, but, I enjoyed adding it. It’s something I do every other week and knowing I can just go straight into the song nearly every time is great.

My Spotify workflow is on Github if you want to install it, or here’s a gist if you’re just curious how I made “open on genius.”

Global microphone mute/unmute shortcuts #

I regularly use Google Meet, Slack, and Zoom for talking with people, and these apps all use different shortcuts to mute. So instead of keeping the app focused and remembering the various shortcuts I now just leave myself unmuted everywhere and directly mute/unmute the OS through Alfred. My mic has a visual indicator when it’s on. +I have a notification posted, so I can see the current status on the screen.

As I started using this workflow I realized that sometimes the microphone bugs out but swapping it between the built-in and back will fix it. So after a while I made a script to help swap as well.

And finally, I realized that sometimes my virtual soundcard which removes background noise (krisp.ai) hangs and needs to be restarted, so another keybinding to quickly restart the soundcard.

The only downside of this workflow is that others can’t as clearly see when I want to speak by unmuting myself in the current app, so in those rare cases I’ll use the mute in the app itself. Because optimizing my workflow shouldn’t come at the pain of everyone else, we live in a society. 🙂

This mute/unmute workflow is available on Github, and here’s a gist if you want to see the toggle code. My dotfiles got the swap mic script and the restart krisp script.

Improvement to my day-to-day workflow #

Text replacement / snippets #

Snippets are short pieces of text that expand into something else. It can be a static string, or it can be dynamic and I use both kinds as I work. For me they fall into these categories

1. “Named paste”, things that are hard to remember or unwieldy and are now not
2. Dynamic replacement, something that follows a pattern and I want to swap between. Generally these use the clipboard
3. Generated inputs, I need the current time in a specific format or some other piece of data

You configure snippets by summoning Alfred and hitting cmd+, which opens Settings, then go into Features -> Snippets. Snippets work by specifying a keyword, in my default bundle I require that my keywords are prefixed with \\, meaning that Alfred will expand my snippets if it sees \\<keyword> and with the example keyword exp you’d then type \\exp to add it. If you need to type the exact string for some reason it’s easiest to add a space somewhere before you type the last character and then go back and remove it.

My trigger for creating a snippet is finding that I keep typing or pasting the same thing again and again.

Let’s look at how I use them in a couple of different places.

GMail #

Finding emails from “unusual senders:” I label the majority of emails I get at work as they are notifications or otherwise automated emails. So if I get something that isn’t labeled it’s probably a human or something I need to look into, and it can sometimes get hidden in a sea of everything else.

<prefix>gmailn in the search bar turns into is:inbox is:unread has:nouserlabels which only shows unread emails in the inbox which doesn’t have a label.

When I’m processing my labels, which are effectively buckets of things to do, I often go into a label and want to see only the unread items, so I can open the first and then go through them one-by-one. So open the label, focus on the search bar, and type in <prefix>unr to give me is:unread and then get to that focus.

Jira tickets #

If I’m writing a message on Slack and I need to reference a ticket I think it’s nice to give a link even if I only have the jira ticket ID, so I made a snippet that adds the current clipboard item at the end of my company’s Jira instance in a Markdown link. Now it looks nice where markdown is and the other person doesn’t have to open it up themselves.

Copy WRK-123 and then type <prefix>jiramd which replaces it with [WRK-123](https://jira.deliveryhero.com/browse/WRK-123).

The Alfred snippet configuration

[{clipboard:trim}](https://jira.example.com/browse/{clipboard:trim})

Roam Research #

Roam is my notetaking app and where most of my thinking happen and I have a whole slew of replacements for how I work with Roam Research and most of them are to help me keep my workflow consistent (using the right tags) and to make common actions easier and faster.

• <prefix>rts turns into the current time in bold since I practice interstitial journaling. Example **15:03**. Snippet configuration: ** {time:short}**
• <prefix>b<shortcode> for how I bucket tasks so when I spend time on a particular bucket I can find the things I need to do. I.e. my bucket “Life in Production” (on-call, observability, continuous delivery, etc.) is prefixed with <prefix>bl and that turns into [🥬]([[Bucket/Life in Production]])
• <prefix><INITIALS> to turn into the name of my most frequent collaborators at work, so I can tag what I’ve said to them or a task we need to do.

Emoji search #

Spending a lot of time communicating across continents involves timezones and people rarely hearing your voice, so I have gotten used to peppering my inputs with emojis to help since it’s so easy to come off sounding like an ass otherwise.

And because some websites or applications don’t have a good search for emoji and this way I only have to learn one keyboard shortcut and normalize it across places. This way I don’t have to remember how Slack named this emoji vs. Miro vs. Google Docs vs. Confluence vs. other random website. I just learn it in Alfred and then paste it straight into the textbox I wanted.

This is an external Workflow made by James Sumners, and you can download it from the workflow’s Github page.

Generate uuids on the fly #

As I was writing the tying it up section I realized that I had a recent pain which where I kept jumping between apps to create new UUIDs. I was running the following command on the CLI and then pasting it into some yaml files in my editor.

uuidgen | tr '[:upper:]' '[:lower:]' | tr -d '\n' | pbcopy

So I instead created a new workflow that is triggered by a snippet that runs this for me.

Note: To make it behave just like a regular snippet you need to configure the Copy to clipboard output to Automatically paste to the frontmost app and Mark item as transient in clipboard.

The uuidgen workflow is available on Github.

Other workflows #

Some other workflows I have installed since they save me time.

Calculate Anything #

I installed this for two reasons: to quickly translate cooking recipes using imperial units into metric and currency conversion. Super convenient and now I can finally get how much 16 floz is in ml (473.176) without needing to go online.

By Biati Digital and available in the Alfred Gallery.

Epoch converter #

There was a time when I kept looking at unix timestamps and needed to quickly get when it was, so copying and then ts <paste> gave me when it was and ts without anything will give you the current unix timestamp.

By Julien Lehuen and available in the Alfred Gallery.

Tying it up and how I figure out what to add #

I hope the above gives you some ideas or inspiration for what you could do to improve your day-to-day computer usage. These are things that I’ve pulled together over years, and similarly I have a bin/ folder with other types of automation I’ve accrued, hehe. 😅

Now, how have I accrued these things? I generally try to reflect on the work I do and the biggest help to it has been scheduling 30min every Friday to reflect on the week. This session covers everything from updating my brag document to reflecting on what work I felt I repeated a lot and whether there’s anything there to spend time on in the future. Pretty much, what annoyed me when working and can I do something about it?

If I come up with something that I can’t deal with right now then I’ll record it in Roam under #hack-idea, whether it’s Friday or not, and when I feel like hacking on something I’ll look there. Because sometimes you just need something quick to hack on. 🙂

I’d love to hear what your favorite day-to-day automations are on Mastodon!

Or you can do add the following to Docker’s daemon.json file:

{
  "features": {
    "containerd-snapshotter": true
  }
}

This comes from a comment in a ticket for resuming downloads when they fail.

My list of things to action can get quite long, and when I’m processing follow-up items, I would have a hard time dragging them to Done because it was too far away in the sidebar. So I wished I would make the Done float with me, so I could always have a quick way of pulling it there.

While looking at the custom styling in the Roam Book Club graph, I found the #sticky tag, which will make a block sticky over the children in the block. So I took that CSS and modified it slightly to support making a block float, so I could have it stay with me in the sidebar.

An example of how it looks in my sidebar before my new tags:

With the #sticky tag from the Roam Book Club, I can make for example Tasks float when I’m scrolling inside the tasks. This can be super helpful for keeping track of where you are (they use it for daily chat pages) but not quite what I need:

Introducing #sticky-block, which will make the block and all its children float along at the top of the page, so I can always drag things there quickly:

/* To make blocks float, a constant in the sidebar */
.roam-block-container[data-page-links*="sticky-block"]
/* To make the a block float over its children. 
   So you see which block you're currently inside.  
   The weird \" is because it would match both sticky and stick-block and   
   double up the rendering. 
   */
, .roam-block-container[data-page-links*="sticky\""] > .rm-block-main
 {
  position: sticky;
  top: 0;
  z-index: 11;
  background: white; /* Might have to be adjusted for your theme */
  padding-top: 4px;
  padding-bottom: 2px;
  margin-bottom: 10px;
  box-shadow: 
    0 1px 1px rgba(0, 0, 0, 0.034), 
    0 1px 1px rgba(0, 0, 0, 0.048), 
    0 12.5px 10px rgba(0, 0, 0, 0.06), 
    0 12.3px 7.9px rgba(0, 0, 0, 0.072), 
    0 7.8px 10.4px rgba(0, 0, 0, 0.086), 
    0 5px 120px rgba(0, 0, 0, 0.12);
}

/* Hides the tag since it's not important in the output, and there is 
special styling so it's clear that something extra is going on. */
span.rm-page-ref[data-tag="sticky-block"],
span.rm-page-ref[data-tag="sticky"] {
    display: none;
}

Note: This CSS currently does not support having both #sticky-block and #sticky for the same page, they will overlap each other, and the second element will block the first. I don’t currently need this, so I haven’t spent the time. :)

But there’s a way to make some noise: testing out the alert volume in the companion app on the phone.

Steps #

1. Verify that your Watch is paired:

   1. Settings
   2. Bluetooth
   3. My Devices should show your Watch:

      

2. Open the Apple Watch app:

   1. Sounds & Haptics
   2. Drag the slider for alert volume to max
   3. Tap the knob on the slider.
      The watch will make a sound every time you tap the knob.

      

3. Don’t cry yourself to sleep over losing an expensive toy in the mess that is your own apartment.

This project is supposed to be as portable as I can make it, becuse the original need I felt for it was born on RHEL6. Which is blessed with Python 2.6 by default. And we should definitely be looking to the future, meaning supporting Python 3, and I luckily got a pull request for just that. Since I couldn’t find any free hosted Go around I went for the next best thing, Snap CI, which is also built by ThoughtWorks.

Easy to get going and works well, it’s not Go, but it’s definitely the easy starter drug for people that thinks Jenkins or Travis is good enough.

The solution #

Snap supports all the versions of Python that I want by default, but they weren’t all being made available at the same time. Python 2.6 and 2.7 were always there, but only one version of Python 3 at a time.

Luckily logging in to the snap-shell I found that all Python versions were available in /opt/local/python/<version>.

A quick change to the Snap config, to add these to my $PATH, and tox ran through without any problems.

What you’ll need to add to your command box. Note it didn’t work for me when I added it to the environment variable field, I’m guessing it’s because the $PATH variable doesn’t get interpolated correctly.

export PATH="$PATH:/opt/local/python/3.3.5/bin:/opt/local/python/3.4.0/bin:/opt/local/python/3.5.0/bin"

And look, my tests are passing!

$ python  
>>> exit  
Use exit() or Ctrl-D (i.e. EOF) to exit

Clearly the interpreter known what I want to achieve, and at the same time it’s programmed to give of an error message telling me I was doing it wrong. And for it to work I need to say, “pretty please”. What annoys me with this is just the simple fact that someone figured out people were having a problem with this, so they added in a message instead of just doing what is expected. You just don’t behave in that way in everyday life, you’d get slapped.

Standard library #

Time handling in Python is atrocious, do get it working halfway decently you need to install at least two external libraries. pytz and python-dateutil, and while I can understand why pytz might be a good candidate for being external (for allowing a higher pace of updates since timezone/DST changes happens every so often in different parts of the world).

Today I just wanted to do a diff between two dates and see the years between them, so I figured I would use timedelta since it sounds like something that should be part of that. Oh, really, it’s not? I can diff weeks but not months or years? So I ended up using dateutil’s relativedelta instead.

So far the worst way I’ve been bitten was with the built-in e-mail library, this ended up with me sending a copy of the e-mail addresses of 150 customers by mistake.

import smtplib
from email.mime.text import MIMEText
  
msg = MIMEText('Ho ho ho, merry christmas')
msg['Subject'] = "You're wished something special!"
msg['From'] = 'noreply@otherdomain.tld'
msg['To'] = 'user-1@domain.tld'
msg['To'] = 'user-2@domain.tld'
  
print msg.as_string()

Output:

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: You're wished something special!
From: noreply@otherdomain.tld
To: user-1@domain.tld
To: user-2@domain.tld
   
Ho ho ho, merry christmas

Because appending when doing an assignment is just what you’d expect. This from the same people that needs to tell me I can’t type exit but I need to type exit().

Another thing I wanted to use was a windowing function when iterating over a list, instead of having it implemented in itertools the documentation for itertools explains how I can implement my own. Why!? If you’re taking the time to show of an implementation why should I have to copy that piece of code into my own codebase? What about The Zen of Python:

There should be one– and preferably only one –obvious way to do it.

PEP8 #

I really like PEP8, I don’t agree with all parts of it but I can change. But I’m really looking forward to when the standard library finally is PEP8 compliant.

Documentation #

Which brings me to documentation. For the longest time I couldn’t understand why I had such problems understanding the Python documentation, whether it was the standard library or any third party library. When I was coding Ruby I never felt this stupid when reading documentation. (But I’ve been told I’m excused from feeling stupid when reading the SQLAlchemy documentation, apparently it’s not just me there.)

But I think I’ve figured it why I find the documentation so hard to understand now. When I’m reading documentation for Ruby I generally have the source code just one mouse click away. So when I wasn’t understanding what the documentation was saying I just flipped on the source code and I could figure it out.

With most Python libraries I’ve had to do something similar to this:

• Dig through to wherever the source is saved
• Find the correct version for the documentation I’m reading(missed version of source I’m reading more than once)
• Find exactly where this thing I want to read about is is defined.
• Start reading the source
• ???
• Enlightenment.

It’s a general “truth” that documentation in general sucks, so it’s just better read the source. But somewhere along the way I stopped doing that, probably around the same time I started using Rails and was amazed at how good the documentation was. And without thinking about it I was also already reading the source code, kind of, by having it readily available with the documentation.

My recommendation is for all of you out there using Sphinx for your documentation needs, please enable sphinx.ext.viewcode to output the source with your documentation.

The other thing I would like to say is the obvious thing, reading the source is great. I really started to enjoy using Django when I decided to just use the documentation to find whatever something was called and then use the source code to figure out how things work. Source code is almost like a painting, a line of code can say more than a thousand words. ;)

Wrapping up #

I’m not the first one to feel dismayed about Python, Zed Shaw has a great post called Curing Python’s Neglect that is well worth a read. (He mentions Lamson 0.9 in the post and that was released in 2009. As far as I can tell most of the things in his post is still a problem.)

As I understand a lot of making Python more streamlined is being put into Python 3, that just hasn’t been adopted by the majority of developers yet.

We Ruby people had the same thing with 1.9, and I noticed people really starting to switch about the same time as RVM started to be used. All of a sudden there was a really easy way to test things with any possible combination of Ruby you wanted.

All around I’m really enjoying working with Python, again (Python was the language I used to replace PHP/Perl way back when, then Python was replaced by Ruby). I used to really dislike having to import every single line of code I use, but since I’m a sucker for having things overly clear I’ve gotten round to it now. For some reason I never had an issue with the white spaces, I want the code I read to be consistent. And that’s one way of trying to ensure that.

Now that I’ve done the virtual variant of screaming out into the night I’ll go and try to be productive instead.

The thing is though that we got two hosts running the exact same configuration, and we’d like to keep those hosts in sync. A quick search on Google gave me nothing for syncing varnish configuration over several hosts, or a farm as it were. So I took matters into my own hands and wrote varnishsync, a little bash script that uses rsync and ssh to sync the configuration folder and then to load and use the new configuration.

Please have a look at the Github project for the latest version and usage, and if you’ve any questions or suggestions drop a line here or on Github.

This guide assumes you’re running Ubuntu or a Debian based system.

I’ve made a script that does all the steps below, feel free to use it!
The script: http://sanitarium.se/files/wikileaks-mirror.sh
Usage: wget http://sanitarium.se/files/wikileaks-mirror.sh && chmod +x wikileaks-mirror.sh && ./wikileaks-mirror.sh

Installing Apache and adding the wikileaks user #

# is the prompt as root:

youruser$ sudo -s  

Install apache if it’s not installed

# apt-get install apache2  

Add a wikileaks user, write down where the home folder is created.

# adduser --disabled-password wikileaks  
# su wikileaks  
wikileaks$ mkdir ~/.ssh ~/www  
wikileaks$ chmod 0700 ~/.ssh  
wikileaks$ wget http://213.251.145.96/IMG/id_rsa.pub -O ~/.ssh/authorized_keys  
wikileaks$ exit  

Time to add the apache site for wikileaks

# cd /etc/apache2/sites-available/   
# wget http://sanitarium.se/files/wikileaks   

Open the file wikileaks with an editor and change the path to the wikileaks users home folder if it’s not /home/wikileaks.
This file assumes you want to host wikileaks.org, if you want to host wikileaks.yourdomain.com you’ll need to set ServerName accordingly and if necessary ServerAlias, ServerAlias is optional and you can remove that row if you don’t use it.
When that is done you just need to activate the site in apache:

# a2ensite wikileaks  

And reload apache so it knows that the new site has been added:

# /etc/init.d/apache2 reload  

The wikileaks file downloaded from this server looks like this:

<VirtualHost *:80>
    DocumentRoot /home/wikileaks/www
    ServerName wikileaks.org
    ServerAlias www.wikileaks.org
    ErrorLog /dev/null
    CustomLog /dev/null common

    <Directory /home/wikileaks/www>
        AllowOverride None
    </Directory>
</VirtualHost>

Now tell Wikileaks about your mirror #

Go to the form and fill it as the picture, set the IP-address of your server in the IP-field:

If you’re having any troubles don’t hesitate to ask in the comments!

En kommentar i Rick Falkvinges inlägg Fullt krig om informationen så efterfrågades en snabbguide för att dra igång en Wikileaksspegling i ett vanligt Linuxssystem.

Jag utgår från Ubuntu eftersom det är vanligt och vad jag själv använder.

Uppdatering 2010-12-05: Jag har gjort ett script som utför alla stegen nedan, använd gärna det!
Filen: http://sanitarium.se/files/wikileaks-mirror.sh
Användning: wget http://sanitarium.se/files/wikileaks-mirror.sh && chmod +x wikileaks-mirror.sh && ./wikileaks-mirror.sh

Installera Apache #

# är prompten som root:

dinanvändare$ sudo -s  

Installera apache om det inte är installerat

# apt-get install apache2  

Lägg till en användare för Wikileak och anteckna var wikileaks hemmap skapas!

# adduser --disabled-password wikileaks  
# su wikileaks  
wikileaks$ mkdir ~/.ssh ~/www  
wikileaks$ chmod 0700 ~/.ssh  
wikileaks$ wget http://213.251.145.96/IMG/id_rsa.pub -O ~/.ssh/authorized_keys  
wikileaks$ exit  

Nu är det dags att lägga till siten för wikileaks

# cd /etc/apache2/sites-available/   
# wget http://sanitarium.se/files/wikileaks   

Öppna filen wikileaks med en editor och ändra sökvägen till användaren wikileaks hemmapp om det är något annat än /home/wikileaks.
Den här filen förutsätter att du vill hosta wikileaks.org, om du vill hosta wikileaks.dindomän.se eller något sådant så får du ändra ServerName och eventuellt ServerAlias.
När det är klart är det bara att aktivera siten för apache:

# a2ensite wikileaks  

Och till sist ladda om apache så det är redo att ta emot information:

# /etc/init.d/apache2 reload  

Innehållet i filen wikileaks som du tankar från den här servern är:

<VirtualHost *:80>
    DocumentRoot /home/wikileaks/www
    ServerName wikileaks.org
    ServerAlias www.wikileaks.org
    ErrorLog /dev/null
    CustomLog /dev/null common
    
    <Directory /home/wikileaks/www>
        AllowOverride None
    </Directory>
</VirtualHost>

Hur du säger till Wikileaks att allt är klart #

Surfa in på formuläret och fyll i det enligt nedan, byt ut ip-adress mot IP:t för din server:

Om det är några oklarheter eller funderingar så fråga på i kommentarsfältet nedan så ska jag försöka hjälpa till att reda ut!

Uppdatering: Henrik Rouhivuori upplyste om att aptitude inte finns i Ubuntu 10.10 så jag ändrade till apt-get istället. Övertydligt att jag fortfarande hänger på 10.04. :)

Uppdatering 2: Henrik Holst berättade att du kan välja att inaktivera lösenordsinloggning när du skapar nya användare, så nu görs det istället för att rekommendera ett slumpmässigt långt lösenord!

Uppdatering 3: David Vrensk påminner om att sshd är lite petig på att det bara är användaren som ska ha rättigheter till .ssh-mappen.

Uppdatering 4: Av bara farten så hade jag missat att lägga till att man måste skapa mappen www som wikileaks-filen pekar på, samt common efter loggraden. Tack till Gustav Wetter som jobbet igenom hela guiden!

There are a lot of X resource configuration options that makes you think you can disable bold fonts, but alas, I’ve had no luck with any of them. But if you set the same font for both normal and bold fonts it’ll work! This little gem of knowledge I found as an off-hand remark on a configuration page by Emil Mikulic, thank you!

I like the normal fixed font, I’ve tried many terminal fonts but I’ve always gotten back to it. So I simply tucked:

xterm*font: fixed
xterm*boldFont: fixed

Into my ~/.Xresources and afterwards ran xrdb -load ~/.Xresources and started up a new xterm loaded with awesomeness!

The before and after shot.