In my last post, I complained about my (and others’) flow being disrupted by institutionalized blockages — in that case, pull requests (PRs).

Often, when that happens, there are things you can do to improve the situation.

For example, let’s say (because it was the case) that I had to wait for an approved PR before I could test something — a GitHub Workflow, for instance. The workflow needed to be approved and merged into main before I could run it in GitHub Actions.

Now imagine that I waited for approval, only to discover — over the weekend, when I was off — that my fix was wrong. I’d need to make a tiny change and then wait for approval all over again. Annoying, right?

Being someone who cares about flow, I wanted something better. What could I do so that, once my code was ready to...

I’ve been writing some code this week. Well, I do most weeks, but this week I teamed up with some folks here at work. It was great fun — and actually did something pretty useful.

What struck me, though, were the blockages in the process. Some of them was even built-in. That kind of slowness was frustrating, and I think it could have been avoided.

I was lucky to work alongside Lars Albertsson, learning from his vast experience at a few of the top software companies in the world. One phrase Lars kept repeating stuck with me as we set up and refined processes at Scling:

Flow is sacred. Do not disturb the flow.

This simple mantra carries profound implications. Not just for you.

Yes. Me too. I felt that had to write something about AI and how it affects our professions (I consider myself a software developer, agile coach and product development person for the scope of this article).

Because reading about AI, and it’s application in digital product development, is very scary since some reports makes it feel like our entire profession is gone in 2-3 years (not true, but hecka-scary as big companies are laying off developers en masse). While others are more in camp “this is a fad and will soon all pass” (not true either, me thinks).

I do think that generative AI is a paradigm shift, but just as with others that I’ve experienced (Internet, Open Source, Agile, Cloud, Serverless and DevOps to mention a few) it is hard to know where it will take us, how it will change us before the dust has settled.

I stay...

Just back from a four-week vacation (out of the 5 weeks mandated by law in Sweden, btw. Sweden is great!) and as always this downtime has led to some reflection on my part. What I am about to write about, might just be me, but I found this useful and stress-relieving. maybe you do to.

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

In this presentation, my great inspiration David L. Marquet, drops a quote that I somehow hadn’t heard before:

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

On my Mac I was struggling to keep different version of .NET updated. I tried Homebrew (which is the Mac-way) but that gave me more problems. I remember reading a Scott Hanselman post on how to install .NET with a script. And that is an official way to install .NET.

But I wanted to automate this to be run as part of my dotfiles installation. Let me describe what I did.

My old twitter handle marcusoftnet is being used by someone that is not me.

Don’t trust a word they are saying. It’s a scam. I deleted that account a year after Elon took over Twitter. Since then I haven’t used it. I have, however, used this handle on other sites and this blog - and it’s become my official handle on the internet.

They are stealing content from my LinkedIn to make it look more like me. With this content and over the course of a few months they have created a trustworthy profile and accumulated a few thousand followers.

Then they launched a crypto-currency with my employers name. So … yeah… that’s one way to introduce yourself as a newly employed person at a company. (More on that below)

As I wrote in the last post I’ve created a little script that spell checks all my blog posts. That was about 3000+ spelling mistakes.

And I then created a similar script to lint the markdown on all blog posts. Another 1250 warnings and errors.

Now that I’ve cleaned that up - I never want to do that again.

No - rather I would like to check for problems every time I make a change. Preferably just before I check stuff into Git.

Turns out - there’s a built-in Git-tool for that.

Let me show you how I put these things together to make a guarded check-in that don’t allow spelling or linting errors to be committed into the repository.

In the _posts directory of this blog I have 1247 posts… Some of them are not very good or readable since they are WAY dated - I wrote the first in 2006. During these years I have also used a number of different tools and ways to write the blog (starting with Blogger way back when). Much have changed. With the tooling and with me.

One concrete example is that in my code editor now, I have instant and brilliant spell checking. I’m using Code Spell Checker which seems to be the default choice for many.

It’s great but work on one file at the time. I wanted it to work on all my files at the same time. Let me show you how I made that work.

I have just landed a new job! (Super-happy about that and I’ll write a separate post on it later).

But that means that I leave one of the heavier periods in my working life - looking for a job in early 2025. I’m not kidding - there’s been tears and a few screams of frustration, self-doubt and generally low-watermarks of Marcus.

I wanted to write a few words for anyone else that is in the situation, share a few tips and advice that I wish I had. And in some case, had taken, because I heard some of these but didn’t apply them.