And they are really tricky to share with in an AI chat, like (we’re not using Chat GPT anymore, since this morning - right?) … well you choose. I’m going with Claude.

Uploading some of my presentations to an agent means 50+ Mb file, when I’m really just interested in the text in my speaker notes.

Over the years I have been going back and forth between different presenting softwares and hence I have a bit of a problem getting hold of the speaker notes.

But I’ve solved this now. Let me share it with you. And then let me share how I have fixed all of this with a Claude Coworker skill.

PPTX - the common denominator

Turns out that many of these formats that I have used over the years does not have a good format to export speaker notes. The only one that does export speaker notes in a good way is Power Point. Luckily it’s also the oldest and has a lot of automation capabilities.

Ok - so I need to convert my stuff to Power Point format. That is a very common way of doing it.

Export speaker notes using Python

Python has a tool called python-pptx (install with pip install python-pptx) that can read PPTX files. And with that in hand we can write this function and get it to print our speaker notes to the console.

# Requires: pip install python-pptx
import pptx
import sys

def get_notes(ppt_path):
    prs = pptx.Presentation(ppt_path)
    notes = []
    for i, slide in enumerate(prs.slides):
        note = slide.notes_slide
        if note and note.notes_text_frame.text:
            notes.append(f"Slide {i+1}:\n{note.notes_text_frame.text}\n")
    return "\n".join(notes)

if __name__ == "__main__":
    print(get_notes(sys.argv[1]))

Very cool - we are getting there.

Docker

But I really hate running Python on my machine. I have never got to terms with all the venv, pips and versions of Python.

Let’s use a Docker file to back all of this into something where Python works

FROM python:3.11-slim
WORKDIR /app
RUN pip install --no-cache-dir python-pptx
COPY extract_notes.py .
ENTRYPOINT ["python", "extract_notes.py"]

Now I can run the script without polluting my computer, with a lot of Python stuff that I never use for anything else. Nice!

Script

To run this I need to write these commands

docker build -t pptx-notes .

docker run --rm -v "$DIR":/data pptx-notes "/data/$BASE"

Cool, but I will never remember that. Let’s create a script, `run.sh´.

#!/bin/bash

if [ -z "$1" ]; then
  echo "Usage: ./run.sh yourfile.pptx"
  exit 1
fi

INPUT_FILE=$(realpath "$1")
DIR=$(dirname "$INPUT_FILE")
BASE=$(basename "$INPUT_FILE")

docker build -t pptx-notes .

docker run --rm \
  -v "$DIR":/data \
  pptx-notes \
  "/data/$BASE"

Very cool - now I can run it like this, to output the result into a text document that I can share with an AI.

bash ./run.sh ~/Downloads/Agile\ for\ real.pptx > agile_for_real_speaker_notes.txt

But, AI?

Yes, obviously I wrote this tool with the help of AI.

But I could also have asked Claude CoWork to do it for me. In fact I did. But then I looked that the skills it used and I wanted to understand deeper how that would work, so tried to do it for myself. I might do the next conversion with Claude CoWork, I might use this. Now I understand the concept and approach, and have built a tool.

Yes - I’m talking about AI. But this post will be about some ideas how to navigate this change, trying to calm ourselves a bit and, quite frankly, give some comfort. Hopefully.

Someone asked me a question just as I left the office this Friday. The question was really good and the person showed genuine worry. I’m sure that person was not the only one. At least one more share the feelings. Me.

I wanted to share my response, a bit embroidered, here. The question was basically this, but better formulated:

Marcus, how do you stay positive in the light of all potential downsides of AI?

The background was that I had just shared some stories from speaking at Tech Arena — an event packed with AI stuff. It was a really positive vibe in there, but dear God so many new things, and big changes. My head was spinning.

I shared that and in doing so probably contributed to the feeling of overwhelming and scare (What? You haven’t tried Ralph Loops, it’s several weeks old?!)

I don’t know if I am that positive really, but I’m old. I’ve been 3-4 of these paradigm shifts (the .com boom, the cloud, agile, the tab/spaces wars - I’ve been around). Even if I’ve never had a clear plan going into any of these paradigm shifts, I’ve seen things that works better than others, when it comes to navigating uncertainty.

Being IN a paradigm shift is scary**

Acknowledge that. We don’t know what the future holds. Let me say that again; we DO NOT know how this will play out. No one. On the planet. That is scary. It’s ok to be scare, worried, annoyed and confused. And it’s ok to be kind to people around you that feels like that around you.

I’m worried, confused and scared too. I kinda like refactoring code, will that go away? Is Agile even a thing in the AI-infused future? Or Consulting?

It’s scary stuff to think about.

Feeling bad yet? :) Ok - here’ comes the comfort-part.

However, in none of these shifts that I have been through - it has never been as bad as the worst I thought. And never as good as the best I thought. Some ideas that I thought was awesome didn’t stick. Some tools that sucked did stick (looking at you JIRA). You will learn things that will not become anything good (huh, tabs are better… who knew) - but you have learned in the process. The learning was the thing. Speaking of.

Our profession is learning

Both as product developers (in the wider sense of the word), and consultants. The tools, ways, ideas and needs are ever changing. We have chosen to be in school for ever. Welcome!

We need to keep learning in the paradigm shift too. But when you do - learn deeper, reflect and think deeply. Use the tool, but focus on the practice. Do the practice but try to understand the principle behind it.

For example; so Ralph loop is a new thing that might be a big thing. Or not. Learn about Ralph loops (the tool), use it in Claude Code (the tool), but when you do - think about HOW you are using it (the practice). Then, after you used it for awhile - think about WHY they invented the Ralph Loop (the principle); what problems did they want to solve, why was that a problem, which ideas led them to come up with Ralph Loop as an idea.

By lifting yourself to the principle-level of any practice and idea you will gain a super power in understanding the next tool or practice easier, and faster. Most of the ideas that pops up builds on previous ideas and concepts - so by understanding the concepts you are future proofing yourself.

But you will have to Keep learning. This can be done by reading (listening or watching) something, but I’ve found that reflecting on you practice will help you know what to learn.

Also; the best way to learn is to share. Write a blog, as if someone was reading (I did for the first 8 years of my blog existence), or use an AI as a learning partner, or better yet make a presentation and share it. Teaching is the best way to learn deeper.

Let me start by sharing - here’s a great talk that I’ve used to think differently about uncertainty.

Jevons paradox

Let’s get some comfort history and people even older than I.

Have you met William Stanley Jevons? He’s an economist that, in 1865, was going through a paradigm shift like we are now. Someone invented the steam engine and it was considered, rightly, a big threat to manual labor. It promised to replace ALL WORKERS EVERYWHERE, no one will ever have to work in the same way again, everyone will be unemployed (<= this is me being liberal with history, but you see the similarities, right?)

In 1865, Jevons noticed that when the steam engine got way more efficient at using coal, total coal consumption didn’t go down — it skyrocketed. Because coal was now cheaper per unit of useful work, people found way more things to use it for. The paradox is that making a resource more efficient to use can actually increase overall demand for it, because the drop in cost opens up a flood of new applications.

AI makes “cognitive work” dramatically more efficient. So the fear is that we need fewer humans. But if Jevons holds, the opposite happens — because it’s now cheaper and faster to build software, analyze data, write content, explore ideas… the demand for those things explodes. More products get built. More experiments get run. More ideas get explored. The total amount of “cognitive work” goes up, not down.

In short, history (and Mr Jevons) suggests that when you make something dramatically cheaper, you don’t get less of it — you get wildly more of it, in ways no one predicted.

Stay positive

Staying positive has value in itself. If you go in trying to find the good, joy and positive vibes you will see other things than if you going in hating the idea. This is true to a point; you need to combine the positiveness with a healthy skepticism. But I think positive with skepticism, will get you to a better place than negative with skepticism.

Our thoughts can actually shape our future, like that. Be a positive change. Focus on the good. You don’t need to not learn the bad - that will take care of itself. When you see someone around you struggling, pull them up. Maybe you have another spin on it that can help them. Tomorrow they will help you.

Being through something hard is easier when you are more people. Looking for better will make it easier than looking for worse.

Outro

You are probably already ahead, just by feeling a bit worried and confused. You have already started to reflect. Good on you - this is the start of improving.

Let me share what I shared with each class at School of Applied Technology, where I was head of curriculum (headmaster for normal people) for 5 years. On their first and their last day I repeated these approaches to work, learning and people around you:

• Be curious - our job is to learn. Keep learning. It’s fun - imagine that we live in a time where we can learn new things happening every day. I much rather be there than in a world where it’s all the same.
• Be humble - you don’t know everything. There might be better ways. Look for them. Understand them. Take help. Also - you probably know more than others in some areas. Help out, learn by sharing.
• Be kind - others does not know what you know. Share, help and support. Treat their confusion, worry and sadness with empathy and kindness. That is good for them. And soon you might need it right back.

My friend, asking the initial question; we’ll get through this one too. I’m actually positive right now, that it will be something great in the end. Looking forward to learning more with you and others.

It’s a VERY different world now, picking up programming when AI has “always” been around. You have to actively disregard help from the tools, to learn. And actively go into learning mode to actually learn.

Since they shared with me it’s not more than right that I do the same. Sorry, this will be long - I’m old.

When it comes to programming itself I started way back on a Vic20, learning basic. But I never really got any skills that way. We typed programs from long listings in magazines. I did eventually apply for University (1994) and even though I didn’t think it would be for me and it was very close that I couldn’t get in, I got in and out 4 years later.

I was very lucky to have study-buddy that was a great programmer (Thank you, Mats) so much of my early experience there was basically just sitting next to him and mimicking a lot of his approach. In Uni I also got a lot of foundational stuff down that I didn’t see the use of then, but has later. At this point I really didn’t enjoy coding, but I could do it. More follow along than being creative.

First professional experiences

My first job in this industry was an onboarding program / job at a big insurance company, where I directly got introduced to enterprise ways. It was quite confusing I can tell you, but mostly on the “where on earth do I fit in in the puzzle”-level. I was doing C++ coding then, and we were mostly following a structure that was in place. Shoveling data between different databases and making some structural changes between in- and output. It never really felt … real to me. More abstract and weird - coding from a detailed (pseudo-code) spec. I did learn a lot of about managing projects by Staffan - such a cool dude!

I then (2000-ish) started to work with CapGemini (because I felt that my opportunities were minimized at the insurance company). Here I had the joy of coming into a GREAT team of developers and was swept up in the culture, style and approach to development. A few of these people are still in my wider network today. I especially learnt a lot from a guy that had worked a few years more than me, just moving in from Norway - Öystein. We worked side by side for a few years and wrote a few projects from scratch.

Falling in love

HERE is when I fell in love with programming. When I started to be able to put the pieces together by myself. I did that by reading articles, books on programming and watching videos. But moreover I had the opportunity to learn from people around me, some were very good at sharing, lifting others up (me to responsibilities I didn’t deserve) and sharing. There’s a mantra from that time that I still think about and use; Ask To Know To Learn To Share.

I got assigned a project that grew to be big and I was suddenly in charge of the architecture and a team. I read more, books on programming mostly, but blogs too. The application went on to be a 5 year project that eventually was sold to a company where we were asked to make it into a configurable product. I learned so much there, by doing and learning from an IT-architect called Lars. He taught me a lot about consulting too.

The agile revolution

At this point, 2004-ish I got the opportunity to take the Scrum-master course (given by Ken Schwaber, the inventor of Scrum) and it was an epiphany for me. I went in one man and came out another. I could never go back. And I never have. Practicing agile in those early days meant that you had to learn from one day to another. I started to read blogs. A LOT. Back then just about all people agile were also developers (which is probably a great thing still today for agilist). That meant that I learned a lot about how to write software in a way that can be worked on in an agile way. It opened my eyes for testing, TDD and modular architecture. But also Continuous Integration, BDD/Specification by example and many more things. I learned here from great people around me (Thank you Jens, Joakim, Christoph and many more)

At this point I started this blog (2006). And I wrote like crazy. As a way to remember. For me. But I realized that people started to read my stuff too. And I got questions and suggestions. So I learned by sharing with others. Also, in 2005 I started to work for Avega - an absolute learning factory. I enjoyed every second there, and was given a lot of room to learn, teach and apply my thoughts.

This put me in a spot where learning was really part of my job. I also was given a great opportunity to share my stumbling blocks with others in many different forms. At the end as a coach with others in the company as my daily job. I picked up new things everyday. I failed and tried again.

A LOT of reading happened now, blogs and twitter were my hangouts. But now YT has taken over as my main source of inspiration. SO. MANY. Tutorials. I especially like, don’t tell anyone, doing tutorials for things that I already knew. Especially katas and TDD-tutorials. Just typing along. Rob Conery, Dan North, Scott Hanselmann, Gojko Adzic, Ron Jeffries, Woody Zuill, Phil Haack were (and ARE) a few of my heroes.

During this time I started to share and speak at user groups, conferences and different company gigs. Live coding was done on more than one occasion and I can tell you; pressure has never been felt until you get a compilation error you’ve never seen on stage in front of an audience that all know what happened.

I was early in another consultancy started by some Avega-friends called Aptitud. We built learning new things into our normal way of working and it escalated my domains further.

Indonesia

One fun, but also telling episode, was that I moved abroad to work for the Salvation Army in 2013. On my last day at the Aptitud office I realized that I hadn’t packed any programming books, so looked around the office. I saw “JavaScript - The Good Parts” and brought it. I didn’t know any JavaScript at this point.

This was the start of another love story for me. That single book led me to learn not only JavaScript, but also functional programming, Node, and a whole new ecosystem. I kept blogging about my experiences and eventually I got to do a few online course on somethings I learned. I recorded them in a closest in Indonesia… you can hear the prayer calls in the background.

Learn and share to learn and share, or how was it.

Making a school

When I got back from Indonesia I eventually got offered to create a bootcamp for developers, trying to teach people with little programming experience to learn how to code in 3 months. Together with an absolutely brilliant developer and consultant called Jacob, I put together the most intense learning I’ve ever seen.

It turned out that packing you learnings together like that is a real challenge since a lot of the things I know are superseded by new ways, tools, and technologies. But it turned out really well and we ended up running it for 5 years, before I had to quit due to mental health reasons. 800+ people have gone through that training and I meet them in the industry just about every week. Some of them have jobs I could only dream of.

AI coding

With the advent of AI coding my workflow has been rocked and things that I really enjoy doing are now not important (refactoring and writing tests are good examples). The tools are starting to do that better than me, as long as I prompt it together. This is a weird feeling; on one hand I’m worrying that what I know will be irrelevant, on the other I have never enjoyed building things more than now. I can build things that I couldn’t but I worry about not knowing the code.

My approach, when I’ve done it to scale, is to iterate the specifications (in text, or code) with an AI, then ask it to build it for me. I also ask it to build tests. Once the feature works - I refactor the crap out of the code; breaking it up into more component, testable functions. By refactoring I learn. And since I have tests I can fearlessly refactor the solution and be sure that it still works.

It might not be faster in the end, but I have control and understanding of what I have built, which I think cannot be underlined enough. Even though an AI wrote the code I am still responsible for it. “The AI wrote it” will not suffice when a feature fails. You should still care about the code.

If you want to be really great at something, understand how it works one level deeper. If you want to be a great C-developer you need to understand how assembly work. If you want to be a great software engineer by prompting you need to understand how JavaScript/TypeScript, C# or Rust works. I think. This is new to me. Please tell me more on how you learn.

So - how did I learn to code?

I’ve (without thinking) used a three part solution:

1. I’ve read, watched and listened to people. A lot. Everyday. And still do. Everyday.
2. I have been lucky to work with people better than me. You can too - just reach out to the person next to you and start to learn. Turns out - we are all good on different things. Learn from each other.
3. Which brings me to the last part - share. When someone asks, or just when you have learned something. Share! Write about it somewhere and post. Most people don’t share. You’ll find that by sharing you will learn. It’s harder to express your thoughts in a manner that someone else can read. And then you become a person that someone (see bullet 1) read, watch or listen too. Now they learn, and you will learn from that…

This blog post is an example of those 3 steps put into action - I learned from the team that shared with me. They are amazing, so I learned from them. And then I shared with y’all.

I hope you found this somewhat useful. Thanks a lot for reading and for sharing your journeys with me, which inspired this post.

I've started going naked to meetings!

To clarify a bit, I’ve started to go device naked to meetings. In other words - I try, hard, to not bring any of my devices to meetings. If possible. It is hard work being device naked, I can tell you.

Any other interpretation would render disgust and probably me without a job. The social code in Sweden doesn’t really allow for your dirty thoughts, dear reader.

What I’m writing here is purely for me and I’m only going to relate my own reasons and experiences but maybe you find some value in this post.

The problem

I’m old and have been doing this for a long time. But with the rule of chats over emails, AI agents that do my heavy code lifting and note taking etc. I find myself being interrupted and disturbed more and more in meetings.

It has got increasingly worse the last year or so. If I bring my computer (“to take note on”) I inevitably end up reading an article, writing a Slack or even coding. Rarely related to the meeting. There. I’ve said it.

In fact, it’s leaking into my private life where I found (I’ve stopped) myself reading news during rehearsals, or unable to watch a movie without IMDBs trivia section open.

It has to stop. Drastic measures are needed. I’m going naked!

Going device naked

Yes. I will not bring a device. Not even the phone, if I can avoid it (see challenges below), to meetings.

I will bring myself, my intellect and my full attention and engagement of the topic at hand. I’ve already started and found some great changes.

In meetings, I will keep my Work in Process limit to 1; whatever is being talked about

Benefits

What I’ve noticed already is that meetings are more interesting than before. I seem to remember more details, (yes, without taking notes) and also see people.

That last part is embarrassing but sure, I’ve noticed others before. But now that I listen - actually focused - on what they say and do, I connect with them better.

Hopefully my nakedness engagement will also benefit others, as they have more of my attention.

Challenges

Here’s some of the challenges I’ve stumbled into, and that you might encounter if you try to be device naked.

Others

People will look weirdly at you. I’ve actually met a fellow device nudist (who asked to be anonymous) that was met with a comment like; Oh? No computer? So you are not working in this meeting then?

Well, the hope is that it will be an even better meeting, without a computer screen.

Taking clothes on, but then off again

The first challenge I stumbled into was that I needed my computer or phone. To look up something we need in the meeting, to take notes or to present.

Being device naked is not a rule, it’s more of a guideline.

I do what I have to and the … gulp … close the lid of the computer again. Without looking at Slack. I’ll do that after the meeting.

Remote nakedness

Most of the meetings that we have today have one or more person being remote. And being naked remotely is really awkward. Being device naked remote is impossible.

What I’ve found is that having the computer away from me helps from me switching over to another window and coding some unit tests.

I try to avoid having the computer in my lap. I put the phone on another table.

Notes

Aha! But how do you take notes then?, someone asked in the last meeting.

The short answer is that I don’t really know. But I see two potential solutions.

1) I take fewer, but focused notes. See taking clothes on. Or I might use paper. If I’m the notetaker I try to make use of the Focus mode that most OS have built in. I even shut down other apps down.

2) There are so many great note-taking tools now. Especially in meeting tools, they are becoming increasingly good. The best I’ve seen is the one found in Notion, but you do you.

Then you can put the computer on the side, to take notes for you - while you enjoy the device nakedness and focus. Then spend a few minutes after the meeting picking out the most important things.

But, but, but - I’m super busy

(No, your dirty mind ran to butt. Your mind. Not mine.)

There are some people around me that are engaged in A LOT of things. I see them buzzing around to do different things. Sometimes I’m one of them.

But me being unengaged in a meeting because I’m responding to Slack messages, or writing a comment on document or fixing a Slide - all of those things are not helping this meeting.

It is actually better to skip the meeting, if you cannot be there fully, or attend for awhile, than being half-committed.

You know what, the slides I created during the meeting also suffered from me not focusing on that.

Small burst of focus is better than big bursts of half-ass:ing it.

Summary

Being device naked is scary at first. And it will feel weird, and you will fail and fall into going full device clothed again.

But I see this effort as me (and you?) giving each other the gift of our full attention. This will lead to better interactions and outcomes of those interactions.

Remember, the goal is not to be device naked. The goal is to have a good interaction.

It has too, right? Otherwise I’m running around naked here for no reason.

for each desired change, make the change easy (warning: this may be hard), then make the easy change

The quote is on X but I first read it in his great little book Tidy First?. Yes, the question mark should be in there. Read the book for more.

Ok. This quote forces you to think for awhile, but is very good practical advise for any software developer I wanted to relate a story from last week where I used it.

The problem at hand

I have built an application for myself. But then people started to ask me to use it. The problem was that I had built it as a single-user system; no notion of users in the code and using SQLite using better-sqlite3.

I tackled the first problem improvement opportunity by simply adding a user_id in each table, adding login via Firebase and tweaking the entire code base. That was just a lot of work, but quite simple. Thank God for an agent that could push through it for me.

But the other improvement opportunity was a bit more challenging.

The challenge

Since I hadn’t designed the system for anything else than SQLite I had been a bit sloppy and there were database code (SQL-queries) in a few different place. Also I was using the better-sqlite3 abstractions in other placing, passing around a Database-reference.

Well, I thought to myself - that’s a lot of places, but surely another agent can just fix that for me.

It could. But it caused a horrible mess. Not because it failed, but it was touching too many things at the same time.

The SQL needed to be updated (the dialects differs a bit), the Database abstraction from better-sqlite3 doesn’t behave in the same way as the PostGres (pg) abstractions.

All in all - the change was not at all easy. The AI agents could not save me. It was not just a lot of work, but complex and tricky.

The approach

This was when Mr Beck’s wise word above hit me like a brick wall. How can I make this change easy.

(There’s no big innovation here, it’s just my experience. Get your expectation on the right level, people)

I decided to implement an Adapter with a shared interface. Like this, for example:

export type DatabaseProviderName = "sqlite" | "postgres";

export interface DbAdapter {
  query<T = unknown>(sql: string, params?: unknown[]): Promise<T[]>;
  queryOne<T = unknown>(sql: string, params?: unknown[]): Promise<T | null>;
  execute(sql: string, params?: unknown[]): Promise<void>;
  transaction<T>(fn: (db: DbAdapter) => Promise<T>): Promise<T>;
  close(): Promise<void>;
  databaseProvider: DatabaseProviderName;
}

I then implemented a SQLiteAdapter that implemented this interface.

import Database from "better-sqlite3";
import { readFileSync, mkdirSync, existsSync } from "node:fs";
import { join, dirname } from "node:path";
import { DbAdapter } from "./DbAdapter";
import { DatabaseProviderName } from "..";

export class SqliteAdapter implements DbAdapter {
  private readonly db: Database.Database;
  public readonly databaseProvider: DatabaseProviderName = "sqlite";
  constructor(private readonly dbPath: string) {
    this.ensureDatabaseDirectory();
    this.db = new Database(dbPath);
    this.db.pragma("foreign_keys = ON");

    this.ensureSchema();
  }

  // ------------------------
  // Initialization helpers
  // removed for brevity
  // ------------------------
  private ensureDatabaseDirectory() { /*...*/ }
  private ensureSchema()  { /*...*/ }

  // ------------------------
  // DbAdapter implementation
  // ------------------------

  async query<T>(sql: string, params: unknown[] = []): Promise<T[]> {
    return this.db.prepare(sql).all(params) as T[];
  }

  async queryOne<T>(sql: string, params: unknown[] = []): Promise<T | null> {
    return (this.db.prepare(sql).get(params) as T) ?? null;
  }

  async execute(sql: string, params: unknown[] = []): Promise<void> {
    try {
      this.db.prepare(sql).run(params);
    } catch (error) {
      console.error("Error executing SQL:", error);
      throw error;
    }
  }

  async transaction<T>(fn: (db: DbAdapter) => Promise<T>): Promise<T> {
    return new Promise<T>((resolve, reject) => {
      const trx = this.db.transaction(() => {
        fn(this).then(resolve).catch(reject);
      });
      trx();
    });
  }

  async close(): Promise<void> {
    this.db.close();
  }
}

Now the simple change was to move all database access code to use this interface.

Turned out - that was hard (remember the quote (warning: this may be hard)). As in complicated by not that complex. There was A LOT (I’m ashamed) of places to change, but each place was pretty simple.

I had two tools at my disposal that was essentials

Lean on the compiler

First I was using TypeScript, which means that I had a compiler to help me.

When I change a reference from a import Database from 'better-sqlite3'; to my own DbAdapter deep down in the nitty gritty of the code, I got a lot of compilation errors.

This is a Good Thing (tm). Compilation errors is a very short feedback loop and fixing each of them is often relatively straight forward.

Automated tests

The second thing I had in place was a bunch (700+) of automated tests. This means that I could know if the changes made broke the code as I went through each route or function.

Since my SqliteDbAdapter was the only adapter being used, I would expect the SQL-queries to behave in the same way.

So in a way - the change was easy but it was hard work. Took me almost 3 days to get through.

After making the change easy

But once I was done implementing the DbAdapter throughout the codebase I was now in a much better place: the next change was now easy.

Meaning; all I had to do now was to implement a PostGresDbAdapter : DbAdapter and then start to use it, rather than the SqliteDbAdapter.

That was actually just one single row to change, but it caused a lot of problems (SQL didn’t work, I had to setup a local database via Docker etc. etc.)

BUT - each of those steps was now easier.

And with that

Often when faced with challenge we think that we can only do it in one go; making all the changes at once. I think this trap is especially easy to fall into with AI Agents doing the heavy lifting for us.

It’s easy to think that if I just let it run a bit more it will eventually come through with a solution.

But just as with humans breaking the down the problem into smaller pieces will make each step not only easier, but also less risky.

Much of the work we do is shaping the work we need to do. Even more so with agents doing the actual work.

Hence;

for each desired change, make the change easy (warning: this may be hard), then make the easy change

As I entered the office I found a seat next to a nice coworker in the quiet corner. Perfect!

Only thing… that screen didn’t have a USB-C cable. No worries I’ll run down to the IT department and nick one.

Only thing… once I got back up I realized that the screen didn’t even have a power cable. Back down to IT, but this time I checked and yes - there were missing extension cords too. So I asked for that.

Once back at my desk I now had to unplug (and UNTANGLE) the cords, so that I could plug in the other 3 desks, interrupting my coworkers flow 2 times. And then connect my own desk to power.

Now I could attach the power cord. And then the USB-C. And then connect my computer so that I could … what was I doing now again.

Yak shaving defined

Recognize this? It happens a lot in daily work - spend (an unreasonable amount) of time doing something that is hard, tricky and often boring in order to be able to do the work we were here to do in the first place

This, my friend, is known as Yak-shaving and has been plaguing worker generally and programmers specifically, for as long as work has happened. The term was, probably, coined by Carlin Vieri at MIT (of course - anything IT-related seems to stem from there) and has a tighter definition that goes like this:

Any apparently useless activity which, by allowing one to overcome intermediate difficulties, allows one to solve a larger problem.

Yak etymology

This section is written from hearsay, but I kind of love the story.

Apparently (^^) the reason yak shaving was used for this type of activity is due to an activity in managing actually yaks. Yes - those half-tonne cows that people in the Himalayas are using.

They are big, smelly and have a thick fur. The yak herders (hey - that’s a job title if I ever saw one) take the yaks up to the mountains in the summer where they graze the lovely green grass.

Now, that means that they fatten up, and when the herders take them down the yaks do not fit on the tiny bridges that go over high pass and rivers.

The herders then have to shave the thick fur off. It’s hard work, takes a lot of time and they cannot really do anything with the fur as it lies in the mountains. But they have to do it to get the Yak down.

That’s the original yak shaving story. I think.

Yak navigation

Ok, but seems that there are a lot of Yaks to shave in the world and it might be hard to know how to do that properly, and even which yaks to shave and which one to leave hairy.

I remember a brilliant lightning talk from Gabriel Forsberg at Agile Sweden 2013 called “Yak shaving the right way”. And I wanted to share his findings here, as I remember them, and add my own comments to it. Any comic relief goes to Gabriel.

There are 3 things to consider when faced with a yak to shave:

1. Shave the right yak
2. Shave it well
3. Share the yak-shaving

Shave the right yak

When faced with a yak you are first overwhelmed with the size and the amount of fur that needs to shaven. It can, for that reason, be worth some reflection time and consider - is this even the right yak.

For example, when I came to the desk, I first thought about if these desks are going to be around here for awhile, or if it was just temporary. I could easily have switched to another place, or just unplugged another screen if these were temporary desks.

The time it will take is also something to consider. This can be hard, as we often don’t discover the work we need to do until we are doing the work (Woody Zuill quote). Or, I guess, we don’t see how thick the yak hair is until we start to shave it.

This conundrum can be overcome with time boxing. I, actually, checked my calendar before starting and realized that I had time to fix the desk (shave the yak).

Another consideration is to ensure that you are not just shaving the yak for your own pleasure. Hairless yaks are ugly and they don’t like being shaved - if you are going to shave a yak, please let it be for others enjoyment too.

In my case; yes - other will benefit from me solving this problem properly.

Shave it well

Once you have decide to shave the yak, don’t mess around. Shave it, and shave it well. A job worth doing is worth doing well.

In my case, I could probably have got it to work by borrowing some outlets that are on top of the table, and have used only one extension cord to connect all tables. But then the extensions on the table top would not have been useable for charging stuff with, as intended. And by entangling the cords the table might not be possible to raise.

Once I was done, I spent one extra minute to check that everything worked. It’s easier to fix as I’m in my shaving mode than to go back later, bring out the razor and protective gear again… (am I taking the metaphor too far?)

Do the work so that no one else has to do it again. No one should have to shave this particular yak again. In the metaphorical world of yak-shaving yaks, hair typically don’t grow out as fast as on real life yaks.

Once you see the well-shaven yak in front of you, a sense of pride will fill you. Something better is in place in the world, thanks to you. You want to tell others - hey that’s the last step.

Share the yak-shaving

Just shaving a yak, the right yak well, so that others don’t have to, might not be enough to ensure that others don’t accidentally shaves the yak again.

This can be bragging (Hey guys! Look at me - I shaved this Yak. ALL. BY. MYSELF!) but the tone of your announcement can help that.

In my case, fixing the cords for a screen is not much to talk about. My hope is that the next person that sits here, just don’t have to get cord. I presume that I’ll tell IT, they might have this on their todo-list. But other than that I’ll leave it.

I did, however, write this blog post to let the WORLD, know about yak shaving and hopefully giggle a bit. Funnily enough, in writing this post, I had to look up some facts on yaks, how to spell etymology , find a yak picture and many other things not related to my work. Meta-yak-shaving.

Summary

Yak shaving is part of life for all of us. But remember the three golden rules of yak shaving:

1. Shave the right yak
2. Shave it well
3. Share the yak-shaving

There are more things, but I’ll get to that at the end.

In this post I wanted to share some thoughts about lead time that I cannot get out of my head. Let’s go back to the beginning by me sharing the simplest diagram I can think of, presented here in my handwriting from 2018, first shown in a blog post on flow efficiency.

This is a very crude version of a value stream map, but I’ve always found it useful. Even just presenting it like above is typically enough to get people’s attention.

A few things that we need to point out, because sometimes I do a poor job of explaining it:

1. This is the lifetime of a single feature. The work or waiting is when the feature is waiting for someone to work on it. This diagram follows the work, not the workers.
2. Obviously (but also problematically) I’ve seldom met anyone who puts their feet up when faced with a waiting time. Instead we start a new thing. That soon gets blocked like the first feature, so we start yet another thing. Then the first thing comes back and requires our attention. And then also—what about the second thing; could you take a look at it now? More things going on at the same time will actually hurt the focus and flow of the original feature. But it’s a totally reasonable way to behave—I would probably do the same.

With that out of the way—let’s do some math-y things. There’s a metric known as flow efficiency that is interesting to observe. It’s the time we work divided by the total time to complete the work (feature in this case).

You might be surprised to know that for most processes (that have not been optimized for flow) the flow efficiency is… 10–15%. Only 48 minutes of actual work is done on something that took 8 hours before it was delivered.

The time from “Could you please” to “Thank you” is known as lead time. It’s not until we are done with the entire feature that our customer is happy.

Improving output – original observation

My original post observed that we spend a lot of time improving the speed with which we work, trying to do things faster. Which is a worthy goal, but we are not really making a huge impact on the overall time to complete the work.

See?! Totally amazing—we cut that step to 1/5 of the original. But it barely matters for the overall lead time. Also note: since we didn’t do anything about the waiting times, the flow efficiency is actually worse. We wait more of the total time.

Instead we need to do something about those pesky waiting times, which is a different story altogether. That requires us to work differently (for example, consider using mob programming where all the waiting times are obliterated, as well as some of the working stages) and also steer differently.

For example: one of the things we wait for could be related to getting approval from a stakeholder, or even getting input on what we should build. To remove that waiting time we need the team to know what to build and own the feature so that they can approve things themselves.

Improved output – in the age of AI

Earlier when I talked about this, I sometimes had a hard time coming up with how we could move faster in some areas. Better refactoring tools? Someone who types faster? Automated tests?

With the advent of the AI tools we can now see that not only some of the parts of the value chain can produce output much faster, but all of them. Design, writing requirements, coding, testing—there’s AI everywhere. And all of it helps us work faster. We get the output faster.

Which means that the flow efficiency is even worse than before. Now 99.4% (<= Marcus makes numbers up to prove a point) of a feature’s lifetime is spent waiting.

Disclaimer

I’m the first to admit that there might be entire steps that are now redundant in some AI scenarios. Maybe we can have the AI do the code review for us and fix the problems while we do something else. Maybe the design can be translated to React components automatically. But we are not there yet. At the time of writing.

What to do instead?

The waiting time in the lifetime of a feature is often related to how we have organized and structured the value flow. Things like our team setup, cadence, and ceremonies for planning and review. This means that in order to address the bulk of the waiting time we need to focus our attention on the things around the people doing the work—our operating model, if you will.

And it should be clear that more checks, more tollgates, and more manual intervention will not harness the improved speed in the output steps.

Instead we need to lean in, even more, to some of the values we talked a lot about in the early agile days; things like empowerment, trust, and steering with outcomes and goals rather than tasks and plans. (See—that thing from earlier in the post came back. Told you.)

I have a lot to say about this, but we are packing it up into something a bit more digestible, so I’ll just leave you with a few core beliefs that I think will be increasingly important in the age of AI:

• Empowered teams that are allowed to move at their own pace toward goals.
• Teams that are trusted to do the right thing, trusted to get help when needed, and trusted to find the information they need to do the right thing.
• Radical transparency so that anyone in the organization can pull the information when needed.
• Organizations aligned not on plans and milestones, but on outcomes with priorities and shared definitions of success.
• Cross‑organization collaboration built in from the start, where dependencies between teams are managed to support flow of value rather than utilization of resources.
• Continuous improvements of our process on all levels. No more best practices—just good‑enough‑for‑now practices that we use until we find a better way. Like tomorrow.

Summary

Strap in everyone. This will be another interesting paradigm shift.

Improving the speed of work (output) will soon make the problems in our flow (waiting times etc.) very clear.

This cannot be solved with AI, but needs to be solved by unlocking the true potential of every team and individual and giving them room to be awesome.

Get on the Trust‑train—it’s a great ride.

Read the original post to understand what this about. You can find my code here

The initialization

Here are the commands I ran to get started:

1. mkdir fizzbuzz-tcr-ts && cd fizzbuzz-tcr-ts to create the directory and jump into it
2. npm init -y to create an empty package.json file
3. npm i -D typescript vitest to install the tools I need
4. touch index.ts index.test.ts to setup the two files we will work in
5. npx scradd test "vitest run" to add a test script

6. I then wrote the first test to check that my infrastructure worked. In the index.text.ts:

    import { describe, it, expect } from "vitest";
    describe("Testing", () => {
      it("should work", () => {
        expect(true).toBe(true)
      });
    });
   

7. npm t - I ran the first test
8. npx gitignore node - I created a .gitignore from the excellent https://www.gitignore.io/
9. git init . && git add . && git commit -m "Initial commit" Finally, I initialized git and made a first commit initial commit

Setting up TCR workflow in package.json

In the package.json I wanted a single script to do the test and then commit or revert.

First I wrote the commit script like this:

"commit": "git add -A; timestamp=$(date \"+%c\") && git commit -m \"TCR @ $timestamp\";",

This will make a nice commit and add a timestamp in the git log.

The revert command is even simpler, but also more unforgiving

"revert": "git reset --hard",

Creating the final command became very simple. So simple that I didn’t know if it would work. Here’s the command:

"tcr": "npm test && npm run commit || npm run revert"

First, the tcr script will run the tests and if it works it will continue to the part after the && and do the commit. If the npm test fails the part after the || will run and revert the changes.

You can think about it like this:

(npm test && npm run commit) || npm run revert

That made it simpler to understand for me at least.

Anyway, I can now do the workflow by executing npm run tcr. Nice!

The test runs

The following sections describe the tests runs that I did to complete the kata. For each test run I will describe the test and production code I wrote, how I felt before I ran npm run tcr and … yes, what happened.

I did not enable auto-run of this command on every save. This is of course possible, but I think it take some of the thoughtfulness out of the process and just make it stressful. TCR is about, and forces you to, thinking carefully about the next step - not going fast.

First test run

Test:

import { describe, it, expect } from "vitest";
import { single } from ".";

describe("FizzBuzz single number", () => {
  it('returns "1" for 1', () => {
    const result = single(1);
    expect(result).toBe("1");
  });
});

Production code:

export const single = (n: number): string => {
  return "1";
};

Feeling before tcr-command: NERVOUS! Will it run?

Result: Passed and commit

Second test run

Test:

it('returns "2" for 2', () => {
  const result = fizzBuzzer.single(2);
  assert.equal(result, "2");
});

Production code:

export const single = (n: number): string => {
  return "1";
};

Feeling before tcr-command:

• Set up the whole test. Pretty sure of myself… failed and reverted.

• Cocky! This will work…

Result:

• Ah well…It failed and my changes was gone.

• No production code changed… Hence I returned a constant of 1.
  • And I even thought that I didn't change any production code to get this to work... hmmm... this feels strange
• Lost documentation (i.e. this blog post) too. This was the point where I decided to move the documentation from ReadMe.md in the repository to a separate blog post.

Second test run - second try

Test:

it('returns "2" for 2', () => {
  const result = fizzBuzzer.single(2);
  assert.equal(result, "2");
});

Production code:

export const single = (n: number): string => {
  return n.toString();
};

Feeling before tcr-command: Careful optimistic but still held my breath during the run.

Result: Passed and commit.

Refactoring the tests

Test:

const assertSingle = (input: number, expected: string) => {
  expect(single(input)).toBe(expected);
};

it('returns "1" for 1', () => assertSingle(1, "1"));
it('returns "2" for 2', () => assertSingle(2, "2"));

Production code:

module.exports.single = (n) => {
  return n.toString();
};

Feeling before tcr-command: Very confident

Result:

• Passed and commit.

Third test run

Test:

it('returns "Fizz" for 3', () => assertSingle(3, "3"));

Production code:

export const single = (n: number): string => {
  if(n === 3) return "Fizz";
  return n.toString();
};

Feeling before tcr-command: Carefully confident and reflecting over the amount of code I wrote now… What if I lost it…

Result:

• FAILED! I asserted for ‘3’ in the test and not ‘Fizz’…
• Rewrote and works

Fourth test run

Test:

it('returns "Fizz" for 3', () => assertSingle(3, "Fizz"));

Production code:

export const single = (n: number): string => {
  if(n === 3) return "Fizz";
  return n.toString();
};

Feeling before tcr-command: Pretty confident

Result:

• Passed and commit

Fifth test run

Test:

it('returns "Buzz" for 5', () => assertSingle(5, "Buzz"));

Production code:

export const single = (n: number): string => {
  if(n === 5) return "Buzz";
  if(n === 3) return "Fizz";
  return n.toString();
};

Feeling before tcr-command: Very confident but no changes in production code … This should work

Result:

• Passed and commit

Sixth test run

Test:

it('returns "FizzBuzz" for 15', () => assertSingle(15, "FizzBuzz"));

Production code:

export const single = (n: number): string => {
  if (n === 3 && n === 5) return "FizzBuzz";
  if (n === 5) return "Buzz";
  if (n === 3) return "Fizz";
  return n.toString();
};

Feeling before tcr-command: Again… I felt like this was a lot of code all of a sudden

Result:

• AND BLUÄRK - it failed… because I checked for exactly 3, 5 and 3 and 5… I didn’t check for things divisible with 3 or 5. In fact, under TypeScript this doesn’t even compile.
• IDIOT - I needed more cases for Fizz and Buzz

Seventh test run

Test:

it('returns "Fizz" for 6', () => assertSingle(6, "Fizz"));

Production code:

export const single = (n: number): string => {
  if (n === 5) return "Buzz";
  if (n % 3 === 0) return "Fizz";
  return n.toString();
};

Feeling before tcr-command:

• Pretty nice to start over actually
• A bit nervous

Result:

• Passed

Eight test run

Test:

it('returns "Buzz" for 10', () => assertSingle(10, "Buzz"));

Production code:

export const single = (n: number): string => {
  if (n % 5 === 0) return "Buzz";
  if (n % 3 === 0) return "Fizz";
  return n.toString();
};

Feeling before tcr-command:

• Confident

Result:

• Passed

Ninth test run

I made some refactoring here. No test changed

Production code:

export const single = (n: number): string => {
  if (n % 5 === 0) return "Buzz";
  if (isFizz(n)) return "Fizz";
  return n.toString();
};

const isFizz = (n: number): boolean => n % 3 === 0;

Feeling before tcr-command:

• Pretty nervous actually. 2 rows changed in one go. What if this goes wrong?!!!

Result:

• PHEW! Still works!

Tenth test run

More refactoring. No test changed

Production code:

export const single = (n: number): string => {
  if (n % 3 === 0 && n % 5 === 0) return "FizzBuzz";
  if (isBuzz(n)) return "Buzz";
  if (isFizz(n)) return "Fizz";
  return n.toString();
};

const isFizz = (n: number): boolean => n % 3 === 0;
const isBuzz = (n: number): boolean => n % 5 === 0;

Feeling before tcr-command:

• Pretty nervous actually. 2 rows changed in one go. What if this goes wrong?!!!

Result:

• PHEW! Still works!

Eleventh test run

Test:

it('returns "FizzBuzz" for 15', () => assertSingle(15, "FizzBuzz"));

Production code:

export const single = (n: number): string => {
  if (n % 3 === 0 && n % 5 === 0) return "FizzBuzz";
  if (isBuzz(n)) return "Buzz";
  if (isFizz(n)) return "Fizz";
  return n.toString();
};

const isFizz = (n: number): boolean => n % 3 === 0;
const isBuzz = (n: number): boolean => n % 5 === 0;

Feeling before tcr-command:

• Pretty nervous

Result:

• Passed.
• I’m done with this feature and can squash my commits into a push-able commit. I didn’t not but pressed on.

Twelfth test run

Test:

describe("FizzBuzz string", () => {});

Feeling before tcr-command:

• I just created a describe block and ran that. To commit it. That now became my mode of thinking: I need to test this so that it commits

Result:

• Passed.

Thirteenth test run

Let’s write something that can take a start and stop and returns a full string.

Test:

import { describe, it, expect } from "vitest";
import { single, sequence } from ".";

describe("FizzBuzz string", () => {
  it('returns "1" for 1 to 1', () => {
    const result = sequence(1, 1);
    expect(result).toBe("1");
  });
});

Production code, in the same file as before:

export const sequence = (start: number, end: number): string => "1";

• Feeling before tcr-command: Yes. Got the nervous feeling again. There are some lines of infrastructure in there…

Result:

• Passed.

Fourteenth test run

Test:

it('returns "1, 2, Fizz" for 1 to 3', () => {
  const result = sequence(1, 3);
  expect(result).toBe("1, 2, Fizz");
});

Production code:

export const single = (n: number): string => {
  if (n % 3 === 0 && n % 5 === 0) return "FizzBuzz";
  if (isBuzz(n)) return "Buzz";
  if (isFizz(n)) return "Fizz";
  return n.toString();
};

const isFizz = (n: number): boolean => n % 3 === 0;
const isBuzz = (n: number): boolean => n % 5 === 0;

const range = (start: number, end: number): number[] =>
  Array.from({ length: end - start + 1 }, (_, i) => start + i)

export const sequence = (start: number, end: number): string => {
  const arr = range(start, end);
  return arr.map(single).join(",");
};

Feeling before tcr-command:

• Proud of the functional style I ended up with. Yes I had to write my own range-function… Should really be included
• Cheated (?) by testing some parts out in the REPL
• VERY NERVOUS about losing these beautiful lines

Result:

• FAAAILLED. NOOOO. I took too big steps

Fifteenth test run

A small space was the problem.

Now I needed to rewrite that code from scratch. But I took the opportunity to do so to train.

Here’s the updated code

Test:

it('returns "1, 2" for "1,2"', () => {
  assert.equal(fizzBuzzer.string("1, 2"), "1, 2");
});

Production code:

export const single = (n: number): string => {
  if (n % 3 === 0 && n % 5 === 0) return "FizzBuzz";
  if (isBuzz(n)) return "Buzz";
  if (isFizz(n)) return "Fizz";
  return n.toString();
};

const isFizz = (n: number): boolean => n % 3 === 0;
const isBuzz = (n: number): boolean => n % 5 === 0;

const range = (start: number, end: number): number[] =>
  Array.from({ length: end - start + 1 }, (_, i) => start + i)

export const sequence = (start: number, end: number): string => {
  const arr = range(start, end);
  return arr.map(single).join(", ");
};

Feeling before tcr-command:

• Very confident now that this should work

Result:

• And it worked

Sixteenth (or so) test run - refactoring

I’ve changed paths here from my original post. I’m using the single method, and then I refactored the tests a bit.

Test:

describe("FizzBuzz string", () => {
  const assertSequence = (start: number, end: number, expected: string) => {
    expect(sequence(start, end)).toBe(expected);
  };

  it('returns "1" for 1 to 1', () => {
    assertSequence(1, 1, "1");
  });

  it('returns "1, 2, Fizz" for 1 to 3', () => {
    assertSequence(1, 3, "1, 2, Fizz");
  });
});

Production:

export const single = (n: number): string => {
  if (n % 3 === 0 && n % 5 === 0) return "FizzBuzz";
  if (isBuzz(n)) return "Buzz";
  if (isFizz(n)) return "Fizz";
  return n.toString();
};

const isFizz = (n: number): boolean => n % 3 === 0;
const isBuzz = (n: number): boolean => n % 5 === 0;

const range = (start: number, end: number): number[] =>
  Array.from({ length: end - start + 1 }, (_, i) => start + i)

export const sequence = (start: number, end: number): string => {
  const arr = range(start, end);
  return arr.map(single).join(", ");
};

Feeling before tcr-command:

• Felt nice to do the fast and frequent commits

Result:

• Passed
• AND commit. I like this more and more.

Seventh test run

Let’s do the full 1 to 15 and call it a day.

Test:

it('returns the correct string for 1 to 15', () => {
  assertSequence(1, 15, "1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, FizzBuzz");
});

Production code is the same:

export const single = (n: number): string => {
  if (n % 3 === 0 && n % 5 === 0) return "FizzBuzz";
  if (isBuzz(n)) return "Buzz";
  if (isFizz(n)) return "Fizz";
  return n.toString();
};

const isFizz = (n: number): boolean => n % 3 === 0;
const isBuzz = (n: number): boolean => n % 5 === 0;

const range = (start: number, end: number): number[] =>
  Array.from({ length: end - start + 1 }, (_, i) => start + i)

export const sequence = (start: number, end: number): string => {
  const arr = range(start, end);
  return arr.map(single).join(", ");
};

Feeling before tcr-command:

• Confident and pretty sure this is the final implementation

Result:

• It worked

Summary

I’m still in awe how this exercise is teaching me to take smaller steps. Every smaller. My code is here… That took a lot of commits

[When changing our ways of working] we act our way to new thinking, rather than think our way into new ways of acting.

This aligns well with many lean and Toyota Production System (TPS) principles. Toyota kata by Mike Rother shows how this practice is used extensively throughout Toyota.

I just had a mini-experience of this, where I wanted to document a pretty unwieldy conversation that was touching highs and lows in a large-ish writing undertaking we’re doing at work. Rather than start, because I didn’t know where, I thought about the best approach.

In my mind, each idea for how to approach this task, was presented and discarded. Then I just went ahead and did it. I opened a place where we had previously written parts of this - a FigJam Board. And then just threw in a few stickies and tried to fit it in the current structure.

By doing that I realized that the current structure did not only guide me to know where to put the new ideas, but also helped me formulate them. And much of the things that we had discussed in the meeting was already in there, but differently formatted.

Frequently I find myself trying to think my work into being done. When it would be better to just try something and see what I could learn by doing.

It reminds me of the first part of Bob Bemer’s motto:

((((DO SOMETHING!) SMALL) USEFUL) NOW!)

It’s better to just get going and do something. If you do it small, you will soon realize if it is useful.

We ended up in a cabin out in the archipelago that had spotty network access, only landline TV and our kids were at camps or with friends. Yes, we went directly into retirement. We set the clock to remind us about the TV-show that started 21.30.

[UPDATE] I totally forgot but a technical glitch happened that took away data traffic from my phone for about 4 days. That … reset … was very blissful and totally helped me make this transition and look at things differently.

What I noticed was how twitchy my fingers got, after just a few hours. I kept on picking up the phone, trying to check news or LinkedIn. When I went walking the dog, I kept trying to get some pod or music playing. Even at the beach reading a book, I also found myself trying to add some background music. When watching the show I desperately tried to also show something on YouTube or play a game etc.

It didn’t take me too long to just stop in my track and just go “What am I doing? Why all of these inputs?”.

There’s nothing wrong with pods and I’ve learned so much from YouTube that I really should send them part of my monthly salary - but it’s so distracting. And I don’t know where the need of adding more sources comes from.

In fact, I’ve come so far that I thinking “chilling in the tv-sofa” as having the TV going, while I’m playing a game on the phone, talking to Elin and reading the news at the same time. Come on!

What I started to do was nothing revolutionary, but I very consciously started to remove inputs, lowering the number of sources to a reasonable amount.

Because, at least for me, my brain never get time to think when I’m constantly feeding it things to keep its attention on. And when you think about it, in most activity there are more than one source by definition:

• commuting to work - I ride a bike and keep my attention there; seeing, hearing and pedaling. I don’t also need to know about US politics, sing along to a song or learn about why these particular laws in the Old Testaments was included. Just riding the bike it enough.
• walking (the dog) - just walking and keeping my attention on the dog is plenty. I don’t need to listen to an audio book too.
• watching movie - seeing a movie is plenty input already. I don’t need to look things up on IMDB too.
• coding or writing - doesn’t have to be accompanied by sound. The thoughts in my head on what to write and how to structure the text is enough.
• practicing my instrument - I don’t need to watch fun clips on YouTube while warming up. Or keep my phone handy on the stand, if the kids call. I will hear the signal.
• playing games on the phone - yes - I of course do that, but then I do not listen to pods or audio books too.

Because your internal thoughts is an input to, and for years now I’ve not giving it room but rather blocking it out with other input sources.

Here’s my new routine; for every activity I’m doing, just before I start, I think about the inputs that are flourishing around me and I try to remove one. Not more to start with.

It took me about a week to stop picking up another input source. But now I’m almost longing to get one out. As I’m writing this I’m in Noise Cancelling head phones, with no sound on - just to block out some background music at the office.