Paul Grenyer

Having just finished The Testaments, I found the experience somewhat underwhelming. While it’s undeniably interesting to return to the world of Gilead, the novel takes a long time to gather momentum, and even once it does, it never quite reaches the depth or impact of The Handmaid’s Tale. The pacing feels uneven, and the early chapters in particular struggle to establish the same tension and atmosphere that made the original so compelling. One thing the book does make clear, however, is just how much of the long-running TV series diverges from Atwood’s story. Many of the show’s plotlines, characters, and dramatic turns are inventions of the series rather than adaptations from the books.  Where The Testaments is good is in its resolution. Compared to the open ended and enigmatic conclusion of The TV series, this sequel ties up far more threads and provides a more definitive ending. It offers closure without feeling overly neat, and its final chapters are among the strongest in the n...

I didn’t dive into AI. I was a reluctant adopter. Not because I feared it would take my job, but because I assumed the learning curve would be steep, time consuming, and probably frustrating. In reality, it turned out to be none of those things. After spending a decent amount of time with ChatGPT and Claude, AI has become an essential part of the way I work. I wouldn’t want to be without it now. It’s made me more efficient in both my writing and my software development, and it’s slotted into my workflow far more naturally than I ever expected. But, and this is important, I’m not sitting back and letting it just get on with it and neither should anyone else. The Myth of “Vibe Coding” There’s a perception floating around, often from people who don’t write software, that AI has unlocked a magical new world where anyone can describe an idea and AI will churn out production ready code without oversight, testing, maintenance, or even understanding. This is, frankly, nonsense. AI is powerful,...

  I grew up in the 80s and 90s being told, over and over, that everyone was essentially the same. Treat everyone the same, expect the same, design for the same, that was the message.  Reading Invisible Women has shifted that foundation more than I expected. What struck me most wasn’t just the scale of the data gaps Caroline Criado Perez exposes, but how quietly and consistently they shape everyday life. Page after page, I found myself realising that “treating everyone the same” often means treating everyone as if they were one very specific type of person, and ignoring everyone who doesn’t fit that mould. It’s not malicious, but it is deeply consequential. The book made something click for me: recognising and celebrating differences isn’t about division, it’s about accuracy. It’s about fairness. If we don’t include people properly when we collect data, we end up designing a world that literally doesn’t see them. And once you see that, you can’t unsee it. I’ve always been anti ...

    Building Services That Scale Part 2 of Beyond the Code: Designing Services That Stand the Test of Time   When we hear the word service, it sounds simple, almost obvious. In practice, defining what a service is can be surprisingly nuanced. A service isn’t just code running on a server. It isn’t interchangeable with a web or a mobile application.  This means a service is more than just code, it’s a self contained piece of functionality with clear boundaries, responsibilities, and relationships to the rest of the system. The term service is overloaded in the world of software engineering. For example, we’re not talking about the object oriented programming concept where a class is named Service to encapsulate business logic.  How we define a service shapes everything that follows. The architecture choices, scalability, resilience, and even team structure. Here we’ll explore what makes a service distinct, why it usually works behind the scenes without a user int...

One of the most powerful things you can do as a leader is to talk to your team every day. It sounds simple, but it’s often overlooked, especially in distributed teams. Daily conversations help build and maintain relationships, foster trust, and remind your team that they matter as people, not just as task-completers. Let’s be clear: this isn’t a psychological experiment. There’s no hidden agenda or behavioral study behind it. It’s simply about genuine care and human connection. But what should you talk about? It doesn’t have to be complicated. Ask how they are, how their family is, or how life outside work is going. The point isn’t the topic, it’s the connection. I usually start with something like: “Hullo! How’s things?” It often takes a few tries before people realise I’m genuinely asking about them, not their current task. A colleague once raised a concern: Doesn’t this feel like micromanaging? It’s a fair question, and the answer lies in how you do it. This isn’t about checking up ...

  Beyond the Code:  Designing Services That Stand the Test of Time  Wednesday, 4th February 2026   St Aldates Tavern, 108 Saint Aldate's, Oxford @ 6pm   RSVP     As software engineers, it’s easy to get lost in the excitement of implementing clever business logic: the algorithms, the workflows, the elegant domain models. But the success (or failure) of a service rarely hinges on its core logic alone. What really separates a fragile prototype from a resilient, scalable system is everything that happens around that logic: the invisible scaffolding that shapes how a service behaves, communicates, and recovers when things go wrong. In this session I’ll explore the often-overlooked aspects of building robust services. The decisions that make the difference between smooth operations and painful refactors months down the line. I’ll unpack how thoughtful design choices early on can pay dividends in maintainability, observability, and security later. Whethe...