Linky #1 - Quality, Trust, and AI: My Favourite Reads This Month
Introducing Linky, a monthly roundup of articles, books, and ideas I’ve been exploring, complete with commentary on why they’re worth your time.
Great ideas often come from unexpected places, and for me, that’s the beauty of reading broadly. Over the years, I’ve cultivated a habit of exploring diverse subjects that capture my interest. Alongside my regular fortnightly posts, I want to try something new: sharing more about what I’ve been reading.
Welcome to the first edition of Linky, where I’ll highlight articles, essays, or books I’ve recently enjoyed, with some commentary on why they caught my attention and why I think they’re worth yours.
For now, I plan to publish these monthly, but if I stumble upon more fascinating finds, I might increase the frequency.
I’d love to hear your thoughts. Does this format interest you? Would you like more of it or something else? Let me know in the comments or reply to this email.
Free Remote Event: Quality Engineering in Focus
Join me on Wednesday, January 29th, from 14:00 to 17:00 (GMT) for a free online event hosted by the Ministry of Testing, focused on quality engineering. We will discuss various approaches, roles, potential pitfalls, and frameworks within the field. It would be great to see you there! LINK
Latest posts from Quality Engineering Newsletter
Imposter syndrome affects nearly everyone at one point or another. These are some of the things that have helped me over the years, and I think they can help others, too. As quality engineers, building quality into people means helping them move past their fears. Taking practical steps to reframe uncertainty can help us reduce imposter syndrome and build lasting confidence.
The problem with saying quality is everyone’s responsibility is that it can often leads to no one being responsible. But to foster a culture of quality, we need it to be a joint responsibility. So what can we do?
Systems Ideas that Sound Good But Almost Never Work—"Let's just…" | Hardcore Software
This is a great list of ideas that sound like they’ll improve quality but will probably cause a loss of quality instead. Steven Sinofsky worked at Microsoft from 1989 to 2013, where he held many roles, including technical assistant to Bill Gates and President of the Windows Division—so he's seen a lot! LINK
Atomic Habits 3-2-1 Newsletter | James Clear
“You have to work hard to discover how to work smart. You won't know the best solutions until you've made nearly all the mistakes.”
This reminded me of my Speed Vs Quality talk and how working smarter and working harder loops are interconnected. LINK
Atomic Habits Illustrated Book Summary | Lewis O’Brien
Speaking of Atomic Habits, here's a handy visual refresher on the key idea. LINK
Anthropic’s Claude Computer Use Is A Game Changer | YC Decoded
How does it work, and what can it do? LLMs using software via the UI will have some implications for automated UI testing going forward. One to watch. LINK
Building effective agents | Anthropic
Excellent guide on building (automated) agents to carry out tasks, including workflows and areas where they could go wrong. Building agents reminds me of doing UI automation work. You need to understand the context you’re working in, and in some cases, even change the system to make it easier to automate or, as we used to say, make the system testable. LINK
Reddit thread on what developers are using CoPilot for
Many comments from experienced devs say juniors are just copying and pasting the output from LLMs. I like to think of LLMs (CoPilot, ChatGPT, Gemini, etc.) as collaborators—someone I can bounce ideas off, get explanations from, and learn different approaches. But to get the best out of them, we have to figure out how to work together, and I think for each of us, this will be a little different depending on our context and working styles. I don’t see LLMs replacing us but augmenting us. Like with any tool, you have to learn how to use it. The best thing we can do is help these folks use these tools more successfully, starting with reframing how they help. They don’t replace you in doing the work, they help you improve your work. You still have to think and apply your experience and understanding, sometimes even more than before. We're not called knowledge workers for no reason. LINK
AI Eats the World | Ben Evans
Analysis of AI use and its growth based on data, not just opinions. What I like about Ben's analysis is the analogies he uses to try and explain things. For example, the current LLM chat interfaces are a blank slate, and we don't really know what to do with them. It's like giving someone Excel and hoping they'll figure it out. They will, but maybe not for the intention you had. We don't know what Artificial General Intelligence (AGI) will look like and how it will affect us. We don't even know if we'll achieve AGI. Well worth 30 minutes of your time. LINK
What trends are we likely to see across travel, tech, art, and design in 2025
Putting a couple of hundred annual trend reports into ChatGPT and Notebook LLM and summarising the conclusions. This could be helpful for gaining insight into domains you're unfamiliar with and would like to learn more about – a good way to feed your curiosity. LINK via Benedict’s Newsletter
FS blog on trust
The best leaders I know extend trust and loyalty long before receiving it - they treat people as if they've already proven trustworthy. This seems naive until you realize it's a forcing function: by acting as if people have already earned your trust, you create the conditions that make it almost inevitable that they will.
One skill that will help you as a quality engineer is building trust quickly, especially with groups of people. This reminds me of the saying, “Always assume good intent.” While there will always be some who take advantage of you, the vast majority are not only unlikely to do so but will also extend that trust back. LINK
Testivus - Testing For The Rest Of Us | Alberto Savoia
I'd never heard of this before, but while mooching around on Reddit, someone mentioned one of the principles, which got me googling around. Originally from 2007, the core idea is rather than trying to get devs started with TDD, why not get them going with some testing and build up from there? I like the pragmatic approach; most devs avoid testing, so getting them started with something is better than never starting. The final principles are a good read and could be a good way to kick off the unit testing discussions. LINK
That concludes the first Linky. What do you think? Is this format appealing to you? Would you prefer more content like this or something different? Please share your feedback in the comments or reply to this email.