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.

Measuring Cyle Time with Dr. Cat Hicks - The Hanger DX Podcast, Ankit Jain

Cycle time is a measure lots of people use, but has no clear audience - developers, managers, CTOs all care about it. This makes it dangerous. Metrics have to be designed and used with psychological safety in mind. If people don’t trust the intention behind the metrics use, they’ll game it.

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.

Anyone writing code professionally in December 2021 will remember the “fun” of the Log4J vulnerability. For those that weren’t - this was a critical security error that allowed attackers to run any code they wanted on your servers. The root cause was a logging library, Log4J, that is used by most projects that are writting in Java.

It’s usually used to write code something like:

log.info("Process completed successfully");

which will then appear in your logs, allowing you to track your application’s behaviour. Pretty innocuous stuff.

Agile tells us that the most critical thing for getting software right is not up front design, but getting something out there and used, and then incorporating feedback. By getting feedback early, you are able to respond faster, changing your (initially incorrect) design in small steps towards a better solution. This works better in practice than designing everything at the start very carefully, which feels rigid and inflexible in the face of new information over the course of a project.

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.