I asked a few people in the Umain office that are relatively new to programming how they learn in the age of AI. And they graciously shared. And I learned A LOT from that.

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.

This is a post that could end up causing me problems—or at least being flagged as “not safe for work”—but here we go:

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.

One of Kent Beck’s many great things to consider is this little mind-bender of a quote

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.

Re-posted from Umain.

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.

Over and over I see that in the paradigm shift we are in now, the good old practices keep resurfacing. For example: doing BDD and TDD turns out to be a good idea even if the code is written much faster—and often not by you. Or having a solid understanding of how to create a good, well‑structured engineered application is more important now than ever.

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.

A long time ago I wrote a blog post on TCR, just now it came up again. I showed them the old blog post but realized that it was very outdated and wanted to update it to a modern stack.

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

The new craze in AI world is called Specification-Driven Development (SDD) and pioneered by GitHub SpecKit and probably other that I haven’t heard about yet.

It tries to solve the thing that many of us found troublesome with VibeCoding Dave Farley breaks this down here and instruct the AI on a lower level, taking more control of the details.

And it’s quite impressive, from what I’ve seen. Especially considering that it has a good what about existing code but it misses the mark on two fundamental assumptions I think.

With the risk of this post being out-dated before the end of the day, and me being branded Old guy that just don't get it - let me offer my thoughts on these two assumptions.

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