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.

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.

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. 🙂

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.

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.

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.

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.

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.