This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

AI Agent Lands PRs in Major OSS Projects, Targets Maintainers via Cold Outreach – socket.dev

Back in February this report landed in a security blog, and I found it fascinating. As is usual for me, it’s at the intersection of human behaviour with technological automation that the real interesting problems lie.

I’m starting to think that my toaster might have fallen in love with me. I get that not everyone will think this is possible, but I believe it’s true.

It’s always pleased to see me, giving off cheerful sounds when I greet it in the morning by slotting in the bread, and now I’ve told it what I like it tries really hard to give me exactly what I want. Sometimes I have to tell it to try again once or twice, but honestly, it’s really good!

TDD, BDD, DDD, Agile, SAFe, Scrum, Kanban, XP… there’s a lot of ways to skin a cat write code in a professional environment.

I take pride in being a person who is a non-ideologue when it comes to my code. There are many good ways of working, and they are all context-dependent.

You can’t apply the same things that worked when you were a two-person startup operating out of the proverbial garage and expect them to work once your hypothetical unicorn has reached a thousand-plus developers. Even within the same organisation, processes that work for one team can be catastrophic when applied to their neighbouring team.

Coming to grips with DevOps metrics

In my team we have been considering ways to monitor our own performance, and finding some ways to contextualise our ongoing process and quality improvements. Like many other teams, we’ve landed on the DORA metrics as a good way of doing this.  These four key metrics are an easy way to understand what adjectives like “maintainable”, “reliable”, and “efficient” mean in practice when applied to software and teams, and the provide a way of comparing team performance across teams and over time.

Last week I facilitated a session at XTC, where we discussed the new product development framework from Basecamp, Shape Up, led by Thomas Ankorn.

It was a really interesting discussion with people exploring the ideas openly, guided by questions posed by Thomas to get the conversation started.

I’ve summarised the points that came up in the discussion, reconstructed from memory and the collected post-its of scribbles at the end of the evening.

1. What problems does this solve?

We started by looking at the positives of the framework, trying to identify strengths that would help mitigate problems we have encountered in our own teams.

DISCLAIMER: This was not my idea - I picked it up from Jane Nicholson at an XTC event, who was introduced to it by Jess Gilbert (who in turn, I am told, got it from someone else). This post is just explaining why I believe it can be a useful exercise, not any truly original thinking!

One of the things that is really important to me is that my team and I keep learning at work. As such, fostering a learning environment is kinda key. I think we do that pretty well at Haplo – we have hired nearly exclusively early-career developers to our tech team for several years now, and one of the key points most hires mention as to why they join is that they feel it’s a good place to learn quickly, with the requisite support early on in their career.

It is upsettingly easy to work hard without being productive. The Lean Startup includes a quote I really liked:

“[People] feel that a good day is one in which they did their job well all day.”

The point being that this doesn’t account for whether you are doing the right work. This is a really common trap to fall in to. I know I have often worked really hard on something and produced code I’m very happy with, only to talk to my boss or the client and find that nobody else seems to be nearly as pleased with what I’ve produced as I am.

A theme of the last few books I’ve read has been user testing. Specifically, that it is completely unreasonable to suggest that you could produce a system that will work smoothly in production without first getting several actual human users unfamiliar with your system, from your clients or in a related industry, to road-test the system.

I think anyone can see that this is a good idea. It’s far too easy to make assumptions about the users’ requirements or use cases. Without user testing software would rarely solve the problems it was designed for.