Linky #11 - Tools Don’t Think. Engineers Do.
Why engineering is more than just using tools it’s about habits, thinking, and building the right things well.
This week’s link covers: Reflections from Agile Manchester, how good habits shape team behaviour, why LLMs need context, not just prompts, what makes testing meaningful, and how metrics shape (or warp) team incentives
Latest post from the Quality Engineering Newsletter
Some great sessions at this year’s Agile Manchester covering a wide range of topics. What stood out for me: using the Jobs-to-be-Done framework to understand real user needs, managing how our work is perceived, and leaning into uncertainty to turn what we’ve got into what we want.
I’ve also shared my personal notes from the talks I attended if you want to dive deeper into my four takeaways.
I’ve been indirectly saying QE is about quality, not testing, for some time now, but never said it this directly. This post explains why I believe that distinction matters and how we can practically move towards it.
Nudging teams towards good quality habits
Your environment whispers suggestions all day long—eat this, click that, sit here. Look around you right now. What small change could you make to your surroundings that would steer you toward good habits and away from distractions?
This got me thinking: What small changes can we make to our work environments that encourage teams to develop good quality habits?
Via 3-2-1: On enthusiasm, playing to your strengths, and living one day at a time - James Clear
Example Spec file for LLM context setting
I’ve [Rob Bowley] been reading Paul Hammond's "Claude.md" file he shared – his development standards for working with Claude Code (Anthropic’s coding assistant) which he's been having some success with.
Honestly, it’s a work of art 😍
What fascinates me most is what it says about getting the best out of AI coding tools. It reflects deep engineering discipline: test-first thinking, small incremental changes, simple design, clear boundaries, fast feedback. In other words, XP principles.
Take a look at the file, Paul’s test principles are spot on and exactly what we want engineering teams to be doing. I liked how it called out:
Don't use "unit tests" as the term is not helpful - it's too broad a term and covers too many different meanings
Behaviour-driven testing that checks expected behaviour, not implementation
Testing implementation is wasteful, and the tests document the expected business behaviour.
These principles could be a great tool to kick off a discussion with engineering teams on their testing approach.
Rob goes on:
Could someone else just copy the file and get the same results?
In theory, maybe. But in practice, without the context and experience behind the rules, when Claude Code goes off on a tangent - as it often will – you could easily get in a pickle. You won’t know how to bring it back on track.
This gets at why I think we should also study how quality is lost within software systems. It gives us the why behind what we're doing and prevents teams from blindly copying other teams’ engineering practices, only to wonder why they're not getting the same results.
Via I've been reading Paul Hammond's "Claude.md" file he shared | Rob Bowley | LinkedIn
Code is easy, it’s the engineering that’s hard
Writing code is easy. Writing the right code for a system that evolves, scales, and lasts... that’s engineering.
AI coding assistants like Copilot or ChatGPT can speed you up, but if you’re building on unclear requirements, weak design, and no feedback loops… You’re just getting faster at being wrong. In this new world, tools aren’t the differentiator. Thinking is.
Testable examples. Fast feedback. Systems thinking. Clean interfaces. Meaningful automation. These aren’t old-school. They’re essential.
That’s the thing about AI tools: if your approach has flaws, they’ll amplify them. Fast.
Start with what you have
"Start with the best opportunity available to you. If you make the most of what you have in front of you right now, better opportunities will become available as you go along."
This quote from James Clear sums up exactly why I start where teams are and the problems they see (the opportunity), not where I think they should be and the issues I think they have. I find that taking this approach, they’re more engaged, you build up trust and they are more willing to work with you on those other problems (future opportunities) when you're able to show them how it’s affecting them.
Writing is how you realise you don't understand
Writing is the process by which you realize that you do not understand what you are talking about.
This was a big reason why I started this newsletter. When I only think about things, it's fast, easy, and everything makes perfect logical sense and connects beautifully. It's when I slow down and write stuff out that I start to spot all the holes in my approach, and while it seems inefficient, I find it hugely improves my verbal communication skills too. Makes the saying "Start slow to go fast" much more practical.
Via Exciting Mornings, Peaceful Nights | fs.blog
Quality Engineering vs a Quality Engineer
III. "Education teaches you to analyze. Entrepreneurship teaches you to create.
The educated mindset is great at dissecting and criticizing. What did Shakespeare mean here? What were the major forces of this historical period? What is the limiting reagent in this chemical reaction?
The entrepreneurial mindset is great at building and improving. Design a better product. Craft a new marketing plan. Stop talking about what's wrong and make something better.
The trick is to keep learning, but to never lose your ability to build."
This reminded me of how I think about quality engineering and the role of a quality engineer.
Quality engineering is about directing and criticising quality
A quality engineer is about building and improving quality
From 3-2-1: On enthusiasm, playing to your strengths, and living one day at a time | James Clear
What incentives are your metrics creating?
🔍 We should ask ourselves:
How might this metric change behaviour?
How might people respond if this number is used as an incentive or punishment?
What unintended consequences might emerge?
Could focusing on this metric blind us to other dynamics?
As Goldhart's law states: "When a measure becomes a target, it ceases to be a good measure", which unfortunately is very likely to happen in engineering teams. So what can we do? Well, probably not very much, but if we acknowledge that a metric can be misused and then make the information widely available. Would this help? This way, if that metric is misused, people will at least know about it before it happens. These four questions could be a good place to start to explore how a metric could be used unintentionally.
Via When we create a metric, we create a game. | Tom Geraghty
Let me know which links resonated or if you’ve read anything lately that should make the next Linky. Always up for a good share.
