Showing posts with label apprenticeship. Show all posts
Showing posts with label apprenticeship. Show all posts

Thursday, July 23, 2026

Good talks/podcasts (Jul II)

 

These are the best podcasts/talks I've seen/listened to recently:
  • Pragmatic Architecture: How to Know When It's Enough 🔗 talk notes (Vlad Khononov) [Architecture, Architecture patterns, DDD, Evolutionary Design, Software Design, simplicity] [Duration: 00:48] (⭐⭐⭐⭐⭐) Vlad Khononov offers a pragmatic framework for balancing software modularity against business value by aligning architectural effort with the essential volatility of each subdomain — managing integration strength and component distance to avoid the waste of both overengineering and underengineering.
  • From Friction to Flow: How Great DevEx Makes Everything Awesome 🔗 talk notes (Nicole Forsgren) [AI, Developer Productivity, Devex, Devops, Engineering Culture, Generative AI] [Duration: 00:37] Nicole Forsgren lays out a systematic approach to identifying and removing the friction points that hinder software delivery, ensuring AI-driven productivity gains translate into sustainable business value — with actionable frameworks and metrics to optimize developer experience, protect flow state, and navigate the challenges of the AI era.
  • How Kent Beck shapes the software engineering industry 🔗 talk notes (Kent Beck) [AI Assisted Engineering, Agile, Engineering Culture, Technical Practices, XP, tdd] [Duration: 02:28] Legendary engineer Kent Beck traces the evolution of software development from the creation of the Agile Manifesto to the rise of the AI 'genie', emphasizing that engineering is fundamentally a discipline of human trust — and why developers must prioritize technical mastery and domain understanding as the industry enters a new, high-stakes phase of exploration.
  • Platform Engineering: Lessons from the Rise and Fall of eBay 🔗 talk notes (Randy Shoup) [Company Culture, Continuous Delivery, Engineering productivity, Platform engineering, Strategy, Transformation] [Duration: 00:44] Randy Shoup shows how eBay's Velocity program doubled engineering productivity, then explains why a dysfunctional, risk-averse culture prevented those technical gains from driving business growth — a case study in why technical excellence must be paired with a generative organizational culture to achieve lasting success.
  • Thinking Like an Architect 🔗 talk notes (Gregor Hohpe) [Agile, Architecture, Cloud, Mental models, Strategy, Technical leadership] [Duration: 00:47] Gregor Hohpe reframes the architect's role as a strategic 'IQ booster': using the 'architect elevator' to bridge organizational levels, metaphors to translate technical complexity into business options, and simple evocative models to empower teams and manage uncertainty for better decision-making across the whole organization.
  • Top AI Trends From 100 Interviews | AI Briefings: nWave 🔗 talk notes (Dave Farley, Michele Brissoni, Alessandro Di Gioia) [AI Assisted Engineering, Architecture, Generative AI, Nature of Software Development, Small Safe Steps (3s), Software Design] [Duration: 00:17] Dave Farley interviews Mike and Alessandro, creators of the open-source tool nWave, on how AI shifts the developer's role toward 'behavioral engineering' — deeply understanding and specifying the problem space — while disciplined small iterative steps and agent 'teammates' bound by engineering principles keep AI-generated software solving the right problem.
  • War Is Peace, Freedom Is Slavery, Ignorance Is Strength, Scrum Is Agile 🔗 talk notes (Allen Holub) [Agile, Company Culture, Feedback cycles, Management, Slicing, Systems Thinking] [Duration: 01:03] Allen Holub makes a compelling case for reclaiming agility from the rigid 'Agile Industrial Complex', emphasizing human interaction and continuous learning over bureaucratic tools and frameworks — with insights on reducing business risk and accelerating revenue through autonomous teams and a systems-thinking approach.
Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Related:

Monday, July 06, 2026

Good talks/podcasts (Jul I)

These are the best podcasts/talks I've seen/listened to recently:
  • SE Radio 525: Randy Shoup on Evolving Architecture and Organization at eBay 🔗 talk notes (Randy Shoup) [Architecture, Continuous Delivery, Developer Productivity, Infrastructure, Lean Software Development, Microservices] [Duration: 00:58] Randy Shoup explores eBay's architectural transformation and the strategic use of lean software practices to drastically improve developer productivity and delivery speed — a masterclass in applying the Accelerate metrics to optimize engineering workflows and drive better business outcomes at scale.
  • Building Resilient Platforms: Insights from 20+ Years in Mission-Critical Infrastructure 🔗 talk notes (Matthew Liste) [Cloud, Culture, Infrastructure, Platform engineering, Resilience, Scalability] [Duration: 00:48] Drawing on twenty-five years of experience in financial-services infrastructure, Matthew Liste offers a blueprint for building resilient and scalable platforms through principles like intuitive design, dogmatic automation, and sustainable decision-making — balancing stability and security with the hidden complexity required to deliver a 'magical' user experience at enterprise scale.
  • Can You Measure The Value Of Refactoring 🔗 talk notes (Trisha Gee, Emily Bache) [AI, Developer Productivity, Quality, Refactoring, Small Safe Steps (3s), Testing] [Duration: 00:20] Trisha Gee and Emily Bache explore how to quantify the value of refactoring through its impact on code health, delivery predictability, and developer satisfaction, with practical insights on using deterministic tools and small, safe, incremental steps so technical improvements translate into measurable business value.
  • Coder vs Developer vs Software Engineer, What's the Difference? 🔗 talk notes (Dave Farley) [AI, Company Culture, Continuous Delivery, Engineering Culture, Nature of Software Development, Professionalism] [Duration: 00:16] Dave Farley explores the mindsets that distinguish coders, software developers, and engineers, arguing that shifting from mere instruction-following to ownership and scientific rigor is the key to professional excellence — and, highlighting the limitations of traditional management, offers a roadmap for adopting disciplines like continuous delivery to deliver better results and more fulfilling work.
Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Related:

Sunday, May 03, 2026

Good talks/podcasts (May I)

These are the best podcasts/talks I've seen/listened to recently: Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Related:

Sunday, April 26, 2026

How I use Claude Code to maintain an Obsidian vault

Seven mental models had been sitting in my inbox for weeks. Rough captures I'd jotted down while reading and watching things online: a stub here, a link there, a sentence I wanted to come back to. I asked the agent to flesh them out into proper notes. It dropped each one in the right folder, got the tags right, updated the central index, and committed the batch with a sensible message. No broken links. All in one session, and I didn't touch a single file.

That sentence is easy to write and easy to misread. It sounds like magic, or like marketing copy, or like the kind of thing people say about AI before you try it yourself and it puts notes in the wrong folder and breaks half the links in your vault. So let me explain what actually made it work, because it wasn't the model. It was the scaffolding.

A previous post described the general system: markdown files on Dropbox, versioned with Git, an AI agent that operates on the vault. This one is about a narrower question the first post barely touched. How do you give an agent durable, specific knowledge of a vault it didn't create, so that it stays consistent across sessions, not just within one?

Rules as the agent's memory

Claude Code reads a set of rule files at the start of every session. They live in .claude/rules/ and load automatically. This is the part most write-ups about "AI plus Obsidian" skip. The rules are not a prompt I rewrite each time, and they're not a long system prompt I crafted once and forgot about. They are operational memory: stuff that persists between sessions and grows the more I use the agent.

The main file, obsidian.md, runs to a few hundred lines. It describes the PARA structure and where each type of content belongs, how wiki-links work, the format conventions for literature notes, evergreen notes, Maps of Content (MOCs), mental models. It also tells the agent which Python script to run in which situation and how to interpret the output. A second file, vault-management.md, is more operational: when to use find_broken_links.py versus fix_broken_links.py, what to do with a fuzzy match at 73% versus 91% confidence. A third, master-viu-presentaciones.md, covers the conventions for the master's program materials I teach.

None of these files is static. After every session where I learn something, I update the relevant one. Sometimes it's a convention I'd been applying inconsistently. Sometimes it's a pattern that worked better than what I had documented. Sometimes it's just a rule I'd been meaning to write down for weeks. The next session starts with that lesson already loaded, and the agent doesn't need to rediscover it.

This is what separates "I told the agent the rules" from "the rules live in the repo and improve with use." Most setups stop at the first. Getting an agent to write a note is trivial. Getting it to write a note that's consistent with 774 other notes it didn't write, and to keep it consistent over months, is what needs this kind of explicit, maintained context.

The zero broken links rule

The single most important rule in the vault is this one: if you're not certain a note exists, don't create the wiki-link. Use plain text instead.

A broken link in Obsidian isn't a 404. It's a ghost. The link renders, it shows up in the graph view, it looks like a connection. But click it and you're in an empty note. Broken links are promises the vault never kept. They make the graph misleading. They accumulate silently, each one suggesting knowledge that isn't there.

The rule is enforced two ways. In the agent's behavior: before writing [[SomeConcept]], Claude Code runs a Glob search to confirm the file exists. If it doesn't, it uses plain text. No exceptions. And in a Python script:

make find-broken-links

This runs after any session that involved creating or editing notes. It parses every .md file in the vault, extracts every [[wiki-link]], and checks that a file with that name exists. The output is a table. The acceptable result is zero.

There's a principle I keep coming back to here: you can't trust an agent's self-reporting on something like link integrity. The agent thinks it checked. The script actually checked. Both have to be in the loop.

The mechanical layer

Behind the agent there are 15 Python scripts wired together through a Makefile. They are the part of the system that doesn't improvise.

find_broken_links.py I've already described. Its companion, fix_broken_links.py, handles the cases where a broken link is a typo or a slightly different name of an existing note. It uses difflib for fuzzy matching, configurable threshold, interactive confirmation by default. --auto-apply --threshold 0.90 handles the obvious cases without asking; --dry-run shows what would change without touching anything. validate_frontmatter.py scans every note and checks that the YAML is valid, that title is present, and that tags is a list rather than a bare string. These drift surprisingly fast during fast note creation, and catching them at the script level keeps them from accumulating into a future cleanup job.

The principle behind the whole layer is the one above: the agent decides, the scripts verify and execute the repeatable mechanics. The agent says "I created seven notes." The script confirms whether the wiki-links between them resolve. Two different jobs, run by two different actors, with no overlap of trust.

The middle layer

Between rules (context for the agent) and scripts (mechanical operations), there is a third layer: skills. These are workflow protocols that combine agent judgment with script execution.

The vault has six. create-note creates a note with the right frontmatter, in the right PARA location, with the right tags. If something's missing it asks before guessing. fix-broken-links runs the detection script, applies the obvious fixes automatically, and surfaces the edge cases for me to decide. vault-health-check runs the full check-health suite and tells me what to fix and in what order.

The distinction I care about is this: a skill is not a prompt. A prompt runs once and the agent improvises the rest. A skill is a protocol. It's explicit about which tools to use, in which order, what to verify, and when to ask the human. The same skill runs the same way every time. That's what you want for maintenance work. Boring, repeatable reliability. Not novelty.



The pattern: friction → script → skill → rule

None of this was designed upfront. It evolved from use, and the evolution is visible in the commit history.

Each piece started as a friction. I'd notice I was making the same judgment call session after session, or hitting the same dull task by hand, or repeating a correction I'd already made. The first response was a script for the mechanical part. Then, when the script was being called the same way each time, a skill that wrapped the orchestration. Then, when the lesson was something the agent should always know, a line in the rules so the next session would start with it loaded.

The presentation materials for the master's program followed exactly this arc. After the third session I noticed I'd made the same mistakes twice: too many bullets per slide, explanatory content in visible slides instead of speaker notes, material that didn't fit the session dumped at the end of the main presentation. I spent an hour updating the rule file with what I'd learned. From session four onward, Claude Code applied those lessons automatically. I didn't have to remember them. The rules remembered them for me.

Every problem I solve ends up encoded in a rule, a script, or a skill. The next time the same problem turns up, the agent already knows the answer. The documentation I write once keeps working session after session, which is why this thing keeps getting more useful without me planning for it.

More tools, same scaffolding

The tools I lean on most share a shape: text in, text out, callable from a make target. That's what lets them attach to the loop without friction. The agent operates them like it edits a note. Each one adds a capability without changing how the system works.

  • Mermaid: diagrams written as .mmd files. The agent generates them, renders to PNG via mmdc, embeds the result in the note, and commits, all from a single make target. I use it for architecture sketches, process flows, the kind of thing I used to draw on a whiteboard and lose.

  • Marp: slide decks written in markdown with annotations, compiled to PDF and PowerPoint. I ask the agent to change a slide, it edits the .md, regenerates the PDF, and commits. The thing I value most is mundane: I can git diff between session 3 and session 7 of the same master's class.

  • Excalidraw: Obsidian stores its sketches as JSON inside regular .md files, so the agent edits them like any other text. Whiteboard-style diagrams that live next to the note that needs them, refined by prompt instead of by hand.

  • notebooklm-py: a client for the NotebookLM API. The agent passes a URL, a transcript, or a PDF and gets back topics, key points, and a structured summary. That's how external material lands in the vault with a consistent shape, without me writing every summary by hand.

  • yt-dlp: YouTube extraction. The vault uses it for talk-note metadata (title, channel, duration, captions), and also for downloading the video or the audio when I want a local copy of something I might lose access to.

  • markitdown: PDF and Word to markdown. It's how a paper or a slide deck someone shares ends up inside the vault as text the agent can read, summarise, and link to whatever else is already there.

The pattern repeats every time. If a tool speaks text and a Makefile target can wrap it, the agent inherits the capability. Adding a new one is a few lines of glue, not a rewrite.

What the agent doesn't do

The agent doesn't decide what's worth capturing. That judgment is still entirely mine. It doesn't surface connections I haven't thought of, at least not reliably enough to trust. It doesn't write the parts of notes that actually matter: the "applications in software" section of a mental model note, the personal reflection on why a talk changed how I think about something, the synthesis between two ideas I read six months apart.

What it does is remove the friction between having an idea and that idea being properly integrated into the vault. Before: I'd capture something in the inbox, know vaguely where it should go, not quite have the energy to do all the steps correctly, leave it in limbo. Now: the skill handles the scaffolding, I make the judgment calls, the note ends up in the right place with the right tags and no broken links.

The honest version is that the system requires active maintenance. If I'm lazy about updating the rules after learning something new, the next session starts with slightly worse context. The skills are only as good as the last time I refined them. The scripts catch what they're designed to catch. They are not magic.

But the direction is right. Each round makes the agent a bit more useful in this specific vault, and each round is cheap: a few lines of rules, a Makefile target, a refined skill. Unlike a one-off prompt, none of it evaporates when the session ends.

Where this leaves me

774 notes, 15 scripts, 33 Makefile targets, 6 skills, 3 rule files. Around 100 commits in the last two months, most of them from sessions where I was building something else and the vault maintenance happened as a side effect.

The test I use: after a week off, how long does it take me to pick up where I left off? With the previous system (no scripts, no rules, ad-hoc organization), reorienting took twenty or thirty minutes of reading through recent notes to figure out what was where. Now it's opening the vault, running make check-health, skimming recent commits. Five minutes.

Back to the question this post opened with: what makes Claude Code reliable in this specific vault? The short answer is that reliability doesn't come from the model. It comes from making conventions explicit. Rules the agent reads at the start of every session. Scripts that verify what the agent thinks it did. Skills that turn a vague instruction into a written protocol. The model fills in the parts that weren't worth automating. Everything else is documented, checked, and reused.

I've built this kind of thing in software teams: explicit conventions, automated checks, tools that hold on to what the team has figured out so new members don't start from zero. The dynamics are the same here. The agent is the new team member who read the onboarding docs, runs the checks before committing, and asks when something isn't covered. The documentation just happens to live in .claude/rules/.

Related reading

Sunday, April 12, 2026

My second brain: markdown, Dropbox, and an AI agent

1,222 notes, 24 categories, zero vendor lock-in. My knowledge management system fits on a thumb drive.

The starting point

The oldest notes in this vault are from June 2013. Talk notes, loose ideas, book quotes, technical decisions, reflections on teams and processes. They started out in Google Keep, in scattered files, in tools I no longer remember the name of. Over time I migrated them into markdown files by hand. Slowly, in bursts, never quite finishing.

The second brain always had valuable stuff in it. Interesting ideas, connections between concepts, reference material that had taken me hours to compile. I found notes when I needed them, connected ideas across sessions. But I had this persistent feeling that there was more in there than I was getting out. Hundreds of notes that didn't talk to each other. Knowledge that accumulated but didn't compound.

And then there was the Google Keep backlog. Over the years I'd piled up around 1,500 notes and links in Keep. Quick captures, things I meant to process "later." The problem was that Google Keep has no API, so getting stuff out was painful enough that I just... didn't. The backlog grew. Every time I opened Keep I felt the weight of it.

Last Christmas I decided to just rip the band-aid off. Exported everything via Google Takeout, deleted it all from Keep, and sat down with the raw files. Using AI I built a throwaway classification pipeline: a combination of heuristics and a human-in-the-loop process where the system proposed a category and I made the final call. In a couple of days, 1,500 notes were classified and integrated into the vault. Bye bye, Google Keep.

That was the moment it clicked. The friction of processing notes had been the bottleneck for years, not the lack of a system. Once I could generate tooling on demand to solve a specific problem, the backlog that had haunted me for ages just... dissolved.

Separately, I'd been curating recommended technical talks in eferro-picks for years. 855 talks, 465 speakers, gathered over 6 years. Another project with valuable information sitting in its own repo, its own structure, disconnected from the vault.

Both projects are now one. What I have is an Obsidian vault of markdown notes on Dropbox, versioned with Git, maintained by an AI agent that understands the structure. The talks from eferro-picks live inside the vault now. 402 of the 855 have full notes so far: all recent talks get them automatically, and I'm gradually backfilling the older ones that only had a title and a link. The vault is the source of truth for the talks, not the other way around. I even have automated pipelines to process new talks I watch and want to recommend (but that's a story for another post).

It's not an app. It's a folder of text files with a system on top. And for the first time in over ten years of note-taking, I feel like I'm getting out of it the value I always sensed was there.

Why plain text files

The most important decision in the system is the most boring one: everything is markdown. .md files I can open with any text editor, on any operating system, with no special tooling.

It sounds like a non-decision. It isn't. There's no database. No proprietary format. No server. If Obsidian disappears tomorrow, or Dropbox, or Claude, the notes are still readable. I can search with grep, edit with emacs, sync with rsync. The format will outlive whatever tool I'm using to read it this year.

Dropbox syncs across devices with zero configuration. Git versions everything, so every change is recorded, I can see diffs, I can roll back. Between the two I get sync and version control almost by accident. Dropbox keeps files up to date across machines, Git keeps the history.

There's a side effect I didn't appreciate until I was living it: I can edit a note on my laptop, close the lid, pick up my phone and keep writing where I left off. Or switch to another machine at home. No export, no sync button, no waiting. Dropbox just does it. Obsidian on mobile opens the same files, same links, same structure. It sounds trivial, but it removes the last excuse for not capturing an idea when it shows up.

Not sophisticated tools. Tools that work, and have been working for decades.

Obsidian is the reading interface. Wiki-links ([[Note]]) create a navigable knowledge graph, backlinks connect ideas both ways, the graph view shows you clusters you didn't know were there. But Obsidian is a view on files, not a platform. If something better comes along, I switch. The files don't care.

The vault's knowledge graph in Obsidian.
The clusters form naturally from wiki-links and shared tags.

And it turns out that "just text files" goes further than notes. Diagrams in the vault are Mermaid, a text format that renders into flowcharts and architecture visuals. Obsidian stores Excalidraw sketches as JSON inside regular .md files. The presentations for the master's program I teach live in Marp: markdown with a few annotations that compiles into slide decks, PDFs and PowerPoints. I can git diff a diagram the same way I diff a note, and an AI agent can generate a Mermaid flowchart as easily as it writes prose. To the agent it's all text.

The structure: PARA, loosely

Notes are organized following Tiago Forte's PARA methodology, without being religious about it.

Projects for things with a deadline or deliverable. Right now: a master's program I'm teaching, this blog, a house renovation. Areas for ongoing stuff: writing, professional network. Resources is where most of the vault lives, reference material organized by topic across about 24 categories. Archive for completed projects that should stop getting in the way.

If you've read my blog before, the topics won't surprise you. The most tagged subjects are engineering culture, AI, agile, continuous delivery, software design, architecture, product and XP. Throw in DevOps, lean, teams and testing and you have a pretty accurate map of what I spend my time thinking about. The vault just makes it explicit.

Then there's The Forest (the vault borrows the digital garden metaphor), a directory with Maps of Content: thematic indexes connecting scattered notes. And Sources, where the 402 talk notes live.

Beyond folders, notes carry two kinds of tags. Topic tags (on/software-design, on/lean, on/ai) say what a note is about. Maturity tags say how developed it is: state/seedling for a raw capture, state/budding for something I've worked on but isn't finished, state/evergreen for a note I consider solid. Most of the vault is still seedlings and budding notes. The evergreen ones are the minority, which is honest: note count and idea quality are different things.

The structure isn't perfect. What matters is that it's predictable. If I'm looking for a quote, I know it's in 3_Resources/Quotes/. Finished projects go to 4_Archive/. This predictability is what lets an AI agent work on the vault without asking me where things go.

The leap: an AI agent that gets the vault

Here's where it gets interesting. Claude Code is not a chatbot I ask things about my notes. It's an agent that operates directly on the files. Creates notes, edits them, runs scripts, checks the vault's health. All while following rules I've written over time.

The rules live in .claude/rules/, configuration files the agent reads at the start of every session. Where to put each type of note. What YAML frontmatter to include. Naming conventions. How to verify links aren't broken. Not suggestions. Constraints.

Here's what that looks like in practice. I say: "create notes for these 7 mental models." The agent creates 7 files in 3_Resources/system_thinking/, each with the right structure (core idea, software applications, limitations, connections), tags them on/mental-model, updates the central Map of Content in The Forest/Mental Models.md placing each in the right domain category, and before writing any wiki-link, checks that the target note actually exists. I don't touch a file. But the rules that made this work? I wrote those myself, one session at a time, encoding what I'd learned about how my vault should behave.

Three layers, one system

What makes this a system and not just "a chatbot writing files" is three layers working together. I keep coming back to this because it's the part people misunderstand.

The first layer is the agent with domain context. Claude Code doesn't see loose files. It knows a new talk note needs topics from the 80+ taxonomy and a link to the speaker's page. A quote goes in Quotes/ with the author's name as tag. A project has a deadline, an area doesn't. Rules give it semantics, not just file paths.

The second layer is 15 Python scripts behind 30 Makefile targets.

One group keeps the vault healthy: a script that parses every wiki-link and checks it against existing files, another that validates YAML frontmatter, another that finds stray images and moves them next to the notes that reference them.

A second group powers the talk pipeline: sync from eferro-picks, pull metadata from YouTube via yt-dlp, run content through NotebookLM, generate blog post HTML.

A third handles the master's presentations: Mermaid to PNG, Marp to PDF and slide decks.

The agent runs all of this through make targets. When it checks for broken links, it's not guessing. It's running a real script with real output.

The third layer is 6 skills. These aren't prompts. They're protocols: which tools to use, in what order, what to verify, what to ask me before proceeding. When I say "process this talk," the agent doesn't figure it out from scratch. It follows a written workflow that I've refined over multiple iterations. Same when I say "check vault health" or "organize the inbox." Each skill encodes a complete task, not a vague instruction.

Take away any one layer and the thing falls apart. Without scripts the agent would improvise something different every time. Without the agent the scripts are just CLI tools I'd have to remember to run. Without rules the skills wouldn't know what decisions to make.

How it actually evolved

The current state of the system is less interesting than how it got here. Because none of this was planned.

The talk pipeline started as a single script to sync a JSON with the vault. I was doing it by hand and it was tedious, so I automated the sync. Then I wanted the agent to be able to run it, so I wrote a skill. Then I wanted automatic topic extraction, so I plugged in NotebookLM. Then I wanted to publish talks as blog posts, so I wrote another script. Over a weekend, iterating with the agent. From copy-paste to a pipeline processing 402 talks and spitting out HTML.

The pattern repeats. I use the vault, hit a friction. Write a script for the mechanical part. Wrap it in a skill so the agent can orchestrate it with judgment. Add rules so the agent remembers the lesson next time. Now the agent is better at that task, which frees me to notice new frictions.

The master's program presentation rules followed the same arc. After session 3, I jotted down what worked and what hadn't. Slides had too much text. Extra material should be in separate files. Speaker notes needed a timeline. I turned those lessons into rules. From session 4 on, Claude Code applied them without me having to say anything. The rules became the shared memory between me and the agent.

Zero broken links

Of all the rules in the vault, one appears in three separate files. I consider it the most important: zero broken links.

In Obsidian, a wiki-link [[Something]] is a promise that "Something" exists as a note. If it doesn't, the link is noise. It suggests content that isn't there, pollutes the knowledge graph, blurs the line between what's real and what's aspirational. And broken links breed. One becomes five, five become thirty, and suddenly your graph is full of ghosts.

The rule is simple: if you're not sure a note exists, use plain text. The agent checks before writing any [[Concept]]. If the file doesn't exist, it writes "Concept" without brackets. After every edit, make find-broken-links. If it created broken links, it fixes them before moving on.

Prevention, not correction. Same principle as tests in code. Cheaper to not introduce the bug.

What this isn't

I don't want to oversell this.

It's not effortless. Rules need writing, scripts need maintaining, structural decisions need making. There are 15 Python scripts and 30 Makefile targets for a personal vault. Is that over-engineering? Probably, partly. Some of it is hobby. Some is me poking at what's possible when you point an AI agent at a folder of text files.

It's not a system where AI does the thinking. Claude Code doesn't decide what's worth keeping, how to categorize a concept, or which connections matter. I'm the one who decided mental models live in system_thinking/ regardless of their domain. I'm the one who decided that domain categorization happens in the MOC, not in the filesystem. The agent executes those choices at scale. But the design is mine.

And it's not for everyone. You need to be comfortable with a terminal, with Git, with text files. If you want a polished app with automatic sync and zero setup, use Notion. Seriously. It's fine.

The question I'm left with

Every time I codify a rule or a skill, the agent gets more capable. But also more opinionated. The rules reflect my decisions today: my taxonomy, my structure, my conventions. What happens when my thinking changes? Do the rules become inertia, or are they an explicit record of decisions I can consciously revisit?

Git has the full history. I can see when I added each rule and why. I can change them. But there's a gap between being able to change them and actually doing it when the system works well as-is.

After years trying tools, what works for me turns out to be the most boring stack imaginable: text files, a synced folder, an agent that knows the garden's rules. 1,222 notes and counting.

Whether the system helps me think better or just organize faster what I was already thinking, I genuinely don't know. Probably both. Probably the distinction doesn't hold up under scrutiny.

Related reading

The methodology and ideas behind this:

  • The PARA Method — Tiago Forte's original post on the organizational system this vault uses
  • Evergreen notes — Andy Matuschak's thinking on notes that evolve and compound over time, which inspired the seedling/budding/evergreen maturity model
  • Building a Second Brain — Tiago Forte's broader framework for personal knowledge management

The tools:

  • Obsidian — The editor I use as a view on the vault's markdown files
  • Claude Code — The AI agent that operates on the vault
  • Marp — Markdown to slide decks
  • Mermaid — Diagrams as text

Sunday, April 05, 2026

Good talks/podcasts (April I)

These are the best podcasts/talks I've seen/listened to recently:
  • No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer 🔗 talk notes (Dex Horthy) [AI Assisted Engineering] [Duration: 00:20] (⭐⭐⭐⭐⭐) Dex Horthy explores advanced context engineering and the "Research, Plan, Implement" (RPI) workflow to effectively solve complex problems in brownfield codebases while minimizing AI-generated "slop" and maintaining team alignment.
  • Kent L Beck: You’re Ignoring Optionality… and Paying for It 🔗 talk notes (Kent Beck) [Agile, Engineering Culture, Software Design] [Duration: 00:49] (⭐⭐⭐⭐⭐) Kent Beck discusses the tension between delivering features and maintaining software "optionality," advocating for a "tidy first" approach to make hard changes easy by improving code structure as both an economic and moral necessity.
  • #156 How to deploy lean projects and more with author Michael Balle 🔗 talk notes (Michael Balle) [Engineering Culture, Lean, Management] [Duration: 01:02] (⭐⭐⭐⭐⭐) Michael Ballé redefines Lean as a humanistic engineering philosophy centered on "making people before making parts" by prioritizing technical competence, Gemba-based collaboration, and strengthening workplace conditions to bridge the gap between top-down management and true frontline engagement.
  • Platform Engineering in 2025: Still Stuck in Ticket Hell? 🔗 talk notes (Steve Smith) [Devex, Platform engineering] [Duration: 00:07] Escaping "ticketing hell" by evolving platform engineering from a manual service desk into an automated self-service model that reduces queue times and empowers delivery teams to accelerate.
  • Forget Velocity, Let's Talk Acceleration • Jessica Kerr • GOTO 2017 🔗 talk notes (Jessica Kerr) [Engineering Culture, Mental models, Systems Thinking] [Duration: 00:54] (⭐⭐⭐⭐⭐) Jessica Kerr redefines software development as software parenting and system moving, arguing that teams should prioritize acceleration—the ability to change direction and improve the system—over mere velocity by fostering generativity and mutual learning through strategic automation.
  • The Best Product Engineering Org in the World 🔗 talk notes (James Shore) [Engineering Culture, Product Strategy, Technology Strategy, agile-XP] [Duration: 01:40] (⭐⭐⭐⭐⭐) James Shore outlines a holistic framework for building a world-class engineering culture by focusing on six core pillars—People, Internal Quality, Lovability, Visibility, Agility, and Profitability—while leveraging Extreme Programming (XP) and Fluid Scaling Technology (FaST) to drive sustainable business impact.
  • What Skills Do Developers NEED To Have In An AI Future? 🔗 talk notes (Trisha Gee, Kent Beck) [AI Assisted Engineering, Engineering Culture, Technical leadership] [Duration: 00:24] (⭐⭐⭐⭐⭐) This videopodcast examines how AI-augmented development shifts the developer's role from writing syntax to exercising high-leverage skills like curiosity, design taste, strategic testing, and effective communication to navigate rapid feedback loops and maintain optionality.
  • o11ycast - Ep. #87, Augmented Coding Patterns with Lada Kesseler 🔗 talk notes (Lada Kesseler, Jessica Kerr, Ken Rimple) [AI Assisted Engineering, Generative AI, tdd] [Duration: 00:48] (⭐⭐⭐⭐⭐) Lada Kessler introduces Augmented Coding Patterns to navigate the "black box" of AI-assisted development by employing specialized single-purpose agents, high-level test specifications, and emoji-based context markers to monitor an agent's focus and internal knowledge.
  • The state of VC within software and AI startups – with Peter Walker 🔗 talk notes (Peter Walker, Gergely Orosz) [AI, Engineering Culture, startup] [Duration: 01:19] A data-driven exploration of how shifting venture capital dynamics and AI are reshaping startup hiring, team structures, and the engineering landscape.
  • Should Test-Driven Development (TDD) Be Used MORE In Software Engineering? 🔗 talk notes (Emily Bache, Dave Farley) [Agile, Software Design, tdd] [Duration: 00:26] (⭐⭐⭐⭐⭐) This expert discussion highlights how Test-Driven Development (TDD) acts as a fundamental software design tool that facilitates Agile development by providing constant feedback, enforcing separation of concerns, and enabling developers to proceed with confidence through small, iterative steps.
  • An AI state of the union: We’ve passed the inflection point & dark factories are coming 🔗 talk notes (Simon Willison) [AI Assisted Engineering, Security, tdd] [Duration: 01:39] (⭐⭐⭐⭐⭐) Simon Willison explores the "inflection point" of AI in software development, detailing agentic engineering patterns, the rise of "dark factories," and the critical security challenges posed by prompt injection.
  • Data vs Hype: How Orgs Actually Win with AI - The Pragmatic Summit 🔗 talk notes (Laura Tacho) [AI, Developer Productivity, Devex] [Duration: 00:29] A data-driven exploration of how organizations can move beyond AI hype to achieve real impact by focusing on developer experience, organizational transformation, and clear measurement frameworks.
  • Making Codebases Agent Ready – Eno Reyes, Factory AI 🔗 talk notes (Eno Reyes) [AI Assisted Engineering, Developer Productivity, Testing] [Duration: 00:15] This talk explores how rigorous automated validation and specification-driven development serve as the essential foundation for scaling autonomous AI agents and unlocking exponential engineering velocity.
  • The Most Polarizing Practice In Modern Software Engineering? 🔗 talk notes (Dave Farley, Dan North) [CI, Trunk Based Development, tdd] [Duration: 00:33] Dave Farley and Daniel Terhorst-North explore the industry's most polarizing practices, such as trunk-based development and estimation, advocating for a pragmatic and outcome-focused approach to software engineering.
  • The Forest & The Desert Are Parallel Universes • Kent Beck • GOTO 2025 🔗 talk notes (Kent Beck) [Compliance, Engineering Culture, XP] [Duration: 00:39] (⭐⭐⭐⭐⭐) Kent Beck contrasts trust-based "Forest" and control-driven "Desert" development cultures, revealing how these parallel universes fundamentally redefine the meaning of metrics, accountability, and engineering practices.
Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Related:

Monday, December 22, 2025

Good talks/podcasts (Dec II)

These are the best podcasts/talks I've seen/listened to recently:
  • You ONLY Get Code LIKE THIS With TDD 🔗 talk notes (Dave Farley) [Continuous Delivery, Software Design, tdd] [Duration: 00:16] This talk explores Software Design as the core of development, illustrating how test-driven development (TDD) serves as a critical design tool for achieving modularity, cohesion, and continuous structural improvement.
  • Building effective engineering teams; lessons from 10 years at Google | Addy Osmani 🔗 talk notes (Addy Osmani) [Agile, Continuous Delivery, Engineering Culture] [Duration: 00:31] An exploration of how Engineering Culture integrates Technical Leadership, Management, and Developer Productivity to optimize Teams through Agile and DevOps practices.
  • Rethinking growing engineers in the age of AI | Meri Williams | LDX3 London 2025 🔗 talk notes (Meri Williams) [AI, Engineering Career, Engineering Culture, Technical leadership] [Duration: 00:23] (⭐⭐⭐⭐⭐) Meri Williams explores the urgent need to rethink engineering growth in the age of AI, advocating for a shift from manual coding tasks toward early tech leadership, systems thinking, and a "healthy paranoia" that allows leaders to "surf" the waves of technological change rather than be overwhelmed by them.
  • The Biggest Problem With UI 🔗 talk notes (Dave Farley) [Continuous Delivery, Software Design, team topologies] [Duration: 00:15] This talk explains why UI/UX design should be treated as an integral software design choice rather than a static specification, advocating for development teams to own the UI to ensure the system accurately reflects the user's mental model.
  • Shaped by demand: The power of fluid teams | Daniel Terhorst-North | LDX3 London 2025 🔗 talk notes (Dan North) [Agile, Product Discovery, Teams] [Duration: 00:23] Daniel Terhorst-North presents demand-led planning as a framework for building fluid, autonomous teams that self-organize quarterly to balance delivery, discovery, and Kaizen based on real-time organizational demand.
  • Tidy First? A Daily Exercise in Empirical Design • Kent Beck • GOTO 2024 🔗 talk notes (Kent Beck) [Agile, Engineering Culture, Software Design, XP] [Duration: 00:57] Kent Beck explores software design as a socio-technical exercise in human relationships and economic optionality, offering a framework to balance feature delivery with a sustainable engineering culture rooted in Agile-XP principles
  • Rafa Gomez - Attacking tech Debt: A Marathon, Not a Sprint - SCBCN 25 🔗 talk notes (Rafa Gómez) [Architecture, Product, Technical leadership] [Duration: 00:41] Learn how the "Marathon" approach enables engineers to tackle technical debt by adopting a product mindset that aligns long-term technical health with business value and consistent product delivery.
  • An Ultimate Guide To BDD 🔗 talk notes (Dave Farley) [Continuous Delivery, Software Design, tdd] [Duration: 00:18] Dave Farley explains how Behavior-Driven Development (BDD) utilizes executable specifications to improve software design and collaboration, facilitating excellence in Continuous Delivery through a user-centric, outside-in approach.
  • Unit Testing Is The BARE MINIMUM 🔗 talk notes (Dave Farley) [Continuous Delivery, Software Design, tdd] [Duration: 00:20] Learn how Test-Driven Development (TDD) serves as a critical act of design to achieve high-quality software by specifying behavior over implementation and enhancing modularity
Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Related:

Saturday, December 13, 2025

Good talks/podcasts (Dec)

These are the best podcasts/talks I've seen/listened to recently:
  • This Mental Model Changed How I Design Software FOREVER 🔗 talk notes (Emily Bache) [AI, Agile, Architecture, Mental models, tdd] [Duration: 00:09] (⭐⭐⭐⭐⭐) Applying the mental model of Test-Driven Development (TDD) as an empirical engineering approach to master software design and manage complexity alongside Agentic AI tools.
  • From here to there and back again 🔗 talk notes (Simon Wardley) [AI, Strategy, Technology Strategy] [Duration: 00:57] Simon Wardley introduces maps for strategic situational awareness, detailing how technological evolution, inertia, and the rise of AI impact decision-making and software architecture, emphasizing the challenge of deciding where humans maintain control
  • Who Does What by How Much? Customer-Centric OKRs explained with Jeff Gothelf and Josh Seiden #ccokrs 🔗 talk notes (Jeff Gothelf, Josh Seiden) [Agile, Company Culture, Management, Strategy] [Duration: 01:14] (⭐⭐⭐⭐⭐) Experts Jeff Gothelf and Josh Seiden detail how to define customer-centric Objectives and Key Results (OKRs) by focusing on measurable outcomes, encapsulated in the framework’s core question: "Who Does What By How Much?"
  • Jim Womack on Lean Thinking: Past, Present & Future 🔗 talk notes (Jim Womack) [Company Culture, Lean Manufacturing, Management] [Duration: 00:32] (⭐⭐⭐⭐⭐) Jim Womack offers a comprehensive retrospective and prospective view of Lean thinking, exploring its evolution, current relevance, and future potential for a "second lean leap".
  • Vibe coding in prod | Code w/ Claude 🔗 talk notes (Erik Schluntz) [AI, Agile, Continuous Delivery] [Duration: 00:31] A discussion on how to safely practice "vibe coding" (letting AI generate code while forgetting the code exists) in production by acting as the AI's Product Manager and focusing on verification of leaf nodes and abstraction layers.
  • Analytics for not-so-big data with DuckDB 🔗 talk notes (David Ostrovsky) [Data Engineering, Performance] [Duration: 01:02] A deep dive into DuckDB, an embedded analytical database optimized for running high-performance analytical queries on "medium data" (1-100 GB range) locally on a single machine, with seamless integration for Python and diverse data sources
  • The New Code — Sean Grove, OpenAI 🔗 talk notes (Sean Grove) [AI, Agile, Architecture, Devops] [Duration: 00:21] OpenAI's Sean Grove introduces "The New Code," arguing that specifications are the universal artifact of intent, crucial for aligning both humans and advanced AI models.
Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Feedback Welcome!
Your feedback and suggestions are highly appreciated to help improve the site and content. Feel free to contribute or share your thoughts!
Related:

Saturday, October 11, 2025

Good talks/podcasts (Oct I) / AI & AI - Augmented Coding Edition!

These are the best podcasts/talks I've seen/listened to recently: Reminder: All of these talks are interesting, even just listening to them.

You can now explore all recommended talks and podcasts interactively on our new site: The new site allows you to:
  • 🏷️ Browse talks by topic
  • 👤 Filter by speaker
  • 🎤 Search by conference
  • 📅 Navigate by year
Feedback Welcome!
Your feedback and suggestions are highly appreciated to help improve the site and content. Feel free to contribute or share your thoughts!
Related:

Sunday, August 24, 2025

Good talks/podcasts (Aug)

These are the best podcasts/talks I've seen/listened to recently:
  • Red Bead Experiment with Dr. W. Edwards Deming 🔗 talk notes (W. Edwards Deming) [Lean, Quality] [Duration: 00:09] (⭐⭐⭐⭐⭐) The Red Bead Experiment vividly demonstrates that quality and performance are products of the system, not merely individual effort or willingness to do one's best.
  • Vibe Coding Is The WORST IDEA Of 2025 🔗 talk notes (Dave Farley) [AI, Software Design, testing] [Duration: 00:17] This talk critically examines "vibe coding," arguing that effective software engineering requires precise problem definition, structured thinking, and robust automated testing to manage complexity and enable evolvability, rather than relying on vague AI-assisted code generation.
  • Diversity, AI, and Junior Engineers with Meri Williams 🔗 talk notes (Meri Williams) [AI, Diversity, Engineering Culture, leadership] [Duration: 00:52] (⭐⭐⭐⭐⭐) This talk explores how AI is changing the development and growth of engineers, particularly junior co-workers, emphasizing the increased importance of foundational skills, critical thinking, and the shift from writing to reviewing code in the age of AI.
  • Continuous Deployment and Pair Programming for Lean Software Delivery Even without Jira 🔗 talk notes (Asgaut Mjølne Söderbom, Ola Hast) [Continuous Delivery, Lean Software Development, Technical Practices] [Duration: 00:54] (⭐⭐⭐⭐⭐) This talk details how a tech company achieved 5-minute code-to-production and high quality in banking software through practices like pair programming, TDD, continuous deployment, and fostering a lean, people-centric culture.
  • Lean Product Development: Resource management vs. Flow efficiency 🔗 talk notes (Johanna Rothman) [Flow, Lean, Lean Product Management, Teams] [Duration: 00:24] (⭐⭐⭐⭐⭐) A compelling talk on Lean Product Development that contrasts resource efficiency with flow efficiency, demonstrating how optimizing for flow through cross-functional teams enhances project delivery and portfolio management.
  • From Noob to Automated Evals In A Week (as a PM) w/Teresa Torres 🔗 talk notes (Teresa Torres) [AI, Feedback cycles, Generative AI, Product Discovery] [Duration: 01:10] (⭐⭐⭐⭐⭐) Product discovery expert Teresa Torres recounts her journey from a self-described "noob" in AI to implementing automated evaluations for an AI-powered interview coach within a week, detailing her iterative process of building and refining the tool with significant LLM assistance.
Reminder: All of these talks are interesting, even just listening to them.

You can now explore all recommended talks and podcasts interactively on our new site: The new site allows you to:
  • 🏷️ Browse talks by topic
  • 👤 Filter by speaker
  • 🎤 Search by conference
  • 📅 Navigate by year
Feedback Welcome!
Your feedback and suggestions are highly appreciated to help improve the site and content. Feel free to contribute or share your thoughts!
Related:

Wednesday, July 16, 2025

Good talks/podcasts (Jul) / AI & AI - Augmented Coding Edition!

These are the best podcasts/talks I've seen/listened to recently — AI & AI-Augmented Coding Edition! All of them explore how AI and Large Language Models (LLMs) are reshaping software development, product design, and engineering culture.
  • How To Get The Most Out Of Vibe Coding | Startup School 🔗 talk notes (Tom Blomfield) [AI, Software Design, testing] [Duration: 00:16] A talk exploring best practices and practical tips for leveraging AI tools and Large Language Models (LLMs) to achieve great results in software development through the "vibe coding" approach.
  • Stop Writing Code – That’s what LLMs are for 🔗 talk notes (Steve Yegge) [AI, Engineering Career, testing] [Duration: 00:29] (⭐⭐⭐⭐⭐) This talk by Steve Yegge exploring the inevitable transformation of software engineering due to AI and LLMs, detailing changing developer roles and the increasing importance of testing and validation
  • Andrew Ng: Building Faster with AI 🔗 talk notes (Andrew Ng) [AI, Product, startup] [Duration: 00:43] (⭐⭐⭐⭐⭐) Andrew Ng's talk provides best practices for startups to achieve unprecedented execution speed by leveraging new AI technology for rapid engineering, product iteration, and strategic decision-making
  • Vibe Coding For Grownups with Gene Kim 🔗 talk notes (Gene Kim) [AI, Architecture, Devops] [Duration: 00:37] Gene Kim discusses the transformative power and inherent dangers of AI-assisted "Vibe Coding", emphasizing the critical role of architecture and sound practices in achieving high performance and avoiding "vibe coding disasters"
  • How custom GPTs can make you a better manager | Hilary Gridley (Head of Core Product at Whoop) 🔗 talk notes (Hilary Gridley) [AI, Management, leadership] [Duration: 00:36] This talk demonstrates how custom GPTs significantly leverage managers' time by scaling their expertise and providing consistent, automated feedback to their teams.
  • AI prompt engineering in 2025: What works and what doesn’t 🔗 talk notes (Sander Schulhoff, Lenny Rachitsky) [AI, Generative AI, Product, Security] [Duration: 01:37] Sander Schulhoff, discusses tangible prompt engineering techniques (including few-shot prompting, decomposition, self-criticism, and additional information), distinguishes between conversational and product-focused prompt engineering, and delves into the critical and unsolvable problem of AI prompt injection and red teaming.
  • How AI is changing software engineering at Shopify with Farhan Thawar 🔗 talk notes (Farhan Thawar, Gergely Orosz) [AI, Developer Productivity, Engineering Culture, Technology Strategy] [Duration: 00:47] (⭐⭐⭐⭐⭐) A deep dive into Shopify's AI-first transformation, emphasizing pervasive AI tool adoption, internal AI infrastructure, and cultural shifts empowering all employees to leverage AI.
  • Gene Kim on developer experience and AI engineering 🔗 talk notes (Gene Kim) [AI, Developer Productivity, Devex, Generative AI] [Duration: 00:44] (⭐⭐⭐⭐⭐) Gene Kim explores how Developer Experience, Generative AI, and Platform Engineering serve as the next chapter in organizational transformation, fundamentally improving developer productivity and value creation.
  • TDD, AI agents and coding with Kent Beck 🔗 talk notes (Kent Beck, Gergely Orosz) [AI, XP, tdd] [Duration: 01:15] Industry legend Kent Beck, creator of XP and TDD, shares insights on the evolution of Agile, Extreme Programming, and Test-Driven Development, alongside his current experience of "most fun ever" coding with AI agents.
  • The Agent Native Company — Rick Blalock, Agentuity 🔗 talk notes (Rick Blalock) [AI, Company Culture, Management, Teams] [Duration: 00:20] This talk introduces the concept of agent native companies, where AI is fundamental to their operations, fundamentally reshaping culture, workflows, and team structures
  • AI at Honeycomb: What’s Actually Working 🔗 talk notes (Charity Majors) [AI, Engineering Culture, Product] [Duration: 00:11] A talk with Honeycomb's CTO exploring AI's impact on engineering velocity and culture, the emergence of disposable software, and the future of product interfaces focused on production.
Reminder: All of these talks are interesting, even just listening to them.

You can now explore all recommended talks and podcasts interactively on our new site: The new site allows you to:
  • 🏷️ Browse talks by topic
  • 👤 Filter by speaker
  • 🎤 Search by conference
  • 📅 Navigate by year
Feedback Welcome!
Your feedback and suggestions are highly appreciated to help improve the site and content. Feel free to contribute or share your thoughts!
Related:

Friday, June 20, 2025

YAGNI and the Value of Learning: An Additional Premise

For years, I’ve been applying—almost without realizing it—an extension of the YAGNI principle that I want to share. It’s become part of how we work as a team, a “gut feeling” we’ve refined through experience, and I believe it’s worth making explicit.

Beyond Traditional YAGNI

YAGNI (You Aren't Gonna Need It) is a fundamental principle reminding us not to implement features just because we think we might need them in the future. It's a powerful defense against overengineering and unnecessary complexity.

But there are situations where the premise shifts. Sometimes we know we’re going to need something. It’s not speculation—it’s a reasonable certainty based on product context, business needs, or the natural evolution of the system.

In those cases, our response is not to implement the full solution just because “we know we’ll need it.” Instead, we ask ourselves:

Is there a smaller version of this that lets us learn earlier?

The Value of Learning as a Decision Criterion

The key is to evaluate the learning value of each intermediate step. Not every small step is worth taking—only those that provide meaningful insight into:

  • Actual user behavior
  • The technical feasibility of our approach
  • The validity of our assumptions about the problem
  • The real impact on the metrics we care about

When the cost of that small step is lower than the value of the learning it brings, it’s almost always worth it. This is a practical application of Lean Startup principles to technical development.

Nonlinear Risk: Why Small Steps Matter

There’s another factor reinforcing this approach: risk doesn’t grow linearly with the size of the change. A change that’s twice as big doesn’t carry twice the risk—it carries exponentially more risk.

Small steps allow us to:

  • Catch issues while they’re still manageable and easy to fix
  • Validate assumptions before investing more resources
  • Maintain the ability to pivot without major cost (optionality)
  • Generate more frequent and higher-quality feedback

How We Apply This in Practice

We’re quite radical about this approach. We aim to get product changes to users within 1–1.5 days, and within that cycle, we ship even smaller technical changes to production. These micro-changes give us valuable information about the “how” while we continue refining the “what.”

Our mental process is almost instinctive: whenever a need arises, we consider multiple options—some that others might call “hacky”—and always choose the smallest possible step, no matter how strange it may seem.

We use techniques like Gojko Adzic’s hamburger method to slice functionality, but we go even further. We constantly ask ourselves:

  • “Can we start with a hardcoded version to validate the UX?”
  • “What if we begin with a manually uploaded CSV before building an automated integration?”
  • “Can we simulate this feature with manual config while we learn the real flow?”
  • “What if we do it just for one user or a specific case first?”

This isn’t about being naive about future needs. It’s about being smart about how we get there. Each micro-step gives us signals about whether we’re going in the right direction, both technically and functionally. And when something doesn’t work as expected, the cost to pivot is minimal.

This obsession with the smallest possible step not only reduces risk, it also accelerates real learning about the problem we’re solving and the behavior of the solution we’re implementing.

Connection with Other Premises

This way of working naturally aligns with other guiding principles in our approach:

  • Postpone decisions: Small steps allow us to delay irreversible choices until we have more information
  • Small safe steps: We work incrementally to reduce risk and increase learning
  • Software as a means: We focus on impact, not on building the most complete solution upfront
  • Optimize for feedback: We prioritize fast learning over perfect implementation, because we know we don’t have all the answers—we need to discover them

A Premise in Evolution

Like all the premises we use, this isn’t universal or applicable in every context. But in software product development, where uncertainty is high and the cost of mistakes can be significant, it has proven extremely valuable.

It’s part of our default way of working: we always look for the smallest step that lets us learn something useful before committing to the full step. And when that learning has value, it’s almost always worth the detour.

Have you experienced something similar in your work? How do you evaluate the trade-off between implementing something fully and taking intermediate steps to learn?

References

Thursday, June 12, 2025

Good talks/podcasts (Jun)

These are the best podcasts/talks I've seen/listened to recently:
  • Data - The Land DevOps Forgot 🔗 talk notes (Michael T. Nygard) [Architecture, Data Engineering, Devops, Platform] [Duration: 00:47] (⭐⭐⭐⭐⭐) This talk offers a critical look at why the analytical data world is "the land DevOps forgot," and presents Data Mesh as a paradigm shift to enable decentralized, autonomous data operations, emphasizing that successful adoption requires significant organizational and cultural change.
  • Jeff Bezos explains one-way door decisions and two-way door decisions 🔗 talk notes (Jeff Bezos) [Management, Mental models] [Duration: 00:03] (⭐⭐⭐⭐⭐) Jeff Bezos explains his mental model of two-way door (reversible) and one-way door (irreversible) decisions, highlighting how to apply different decision-making processes for each in organizations.
  • TDD, AI agents and coding with Kent Beck 🔗 talk notes (Kent Beck, Gergely Orosz) [AI, XP, tdd] [Duration: 01:15] Industry legend Kent Beck, creator of XP and TDD, shares insights on the evolution of Agile, Extreme Programming, and Test-Driven Development, alongside his current experience of "most fun ever" coding with AI agents.
Reminder: All of these talks are interesting, even just listening to them.

You can now explore all recommended talks and podcasts interactively on our new site: The new site allows you to:
  • 🏷️ Browse talks by topic
  • 👤 Filter by speaker
  • 🎤 Search by conference
  • 📅 Navigate by year
Feedback Welcome!
Your feedback and suggestions are highly appreciated to help improve the site and content. Feel free to contribute or share your thoughts!
Related: