Paul Grenyer

There’s something about Dom . It’s not only his depth of knowledge of the topics he speaks about. It’s his charisma and his delivery too. This is why people flock to see him. It also helps that Dom has been obsessed (in a good way) with AI for as long as I can remember. He always feels ahead of the game and I frequently learn a lot. Tonight, giving his “AI: Assisted Ignorance” talk, he started in the obvious place by reframing the Terminator story into a Software Engineering context. He then went on to show us how flawed it is and demonstrated how we shouldn’t be worried about it taking our jobs - at least not yet. There is of course the current junior developer crises, but that will soon come good when companies realise they’ll have no one to replace the senior devs who are retiring or going off to earn millions fixing other companies' AI disasters. Millenium bug anyone? The really important message was that AI doesn’t reason. It doesn’t think. It’s autocorrect on steroids, a prob...

I’ve been to nor(DEV):con , East Anglia’s Largest Developer Conference , most years since its inception as syncConf in 2013. 2026 has been by far my favorite year, and not just because I had the opportunity to speak to a packed conference room with standing room only! Learning Go by becoming a drone pilot - Andrew Haine When Andrew first posted about his keynote at nor(DEV):con, it was just too easy to tease him he’d be droning on about Go ! Fortunately for me, he saw the funny side! In reality the talk was interesting, and expertly and charismatically delivered. Especially considering that there’d been a fairly major technology failure just before Andrew started. So he couldn’t share his laptop on the main screen. However, we did see him control a small drone hovering just above the stage and even saw it take a picture, all through code. Learning Python to buy shoes: A tale of studying, selectors and sneakers - Isaac Oldwood Isaac is one of the up and coming stars of the Eastang...

I was recommended Radical Candor as a more contemporary take on Marshall B. Rosenberg’s Nonviolent Communication , but I think it also works as a more up‑to‑date reference for much of the material covered in What Did You Say? The Art of Giving and Receiving Feedback by Charles N. Seashore, Edith Whitfield Seashore, and Gerald M. Weinberg . It even overlaps with, and offers a different angle on the One Minute Manager series by Ken Blanchard . I learnt a few new things which I think will be really useful. I especially liked  Care personally, challenge directly , encouraging feedback from your team early on, the discussion of why boss is the proper term and the three questions you should ask your team to understand them and where they want to be. I’m already using the terms Rock Star and Super Stars as a result of reading Radical Candor. I didn’t like the strong emphasis on 121s, especially the frequency and the perceived importance. To me this is plain wrong and should be replaced ...

  I didn’t enjoy Shift as much as the Wool . In a few places it still gripped me when parts of the overarching story were hinted at and later on explained. It was great to know where the Silos came from and why, but I didn’t care at all about Mission and I struggled to care about Solo beyond the penultimate chapter where he encounters Juliet, and brings the stories from the two books together. It’s quite a different story style compared to Wool, and even more dystopian. There’s no TV series to compare it to yet - that’s coming. It’s the middle book of a trilogy, so it is already starting on the back foot. I’ll get to the third book in time and hopefully there’ll be a happy ending. Hugh Howey  ISBN-13: 978-1804940839

On Wednesday evening I had the pleasure of speaking to ACCU Oxford about ‘Beyond the Code: Designing Services That Stand the Test of Time’.   I haven’t been to Oxford since 2012 when the ACCU Conference was held there, before it was moved to Bristol the following year. Oxford was as I remembered it and remained pretty much where I had left it. ACCU Oxford takes place in a lovely little pub called St Aldates Tavern , in a room upstairs called the blue room. It was a really nice space, up and away from the main pub with its own bar, tables and a large TV on the wall. However, it appears the TV may have shown someone’s team losing and that someone decided to take it out on the TV. A large part of the screen didn’t work, but there was enough to get the gist of my slides across to my audience. The audience was great! Laughed in all the right places, asked lots of questions, and completely ripped my logging examples to shreds. ‘Beyond the code…’ is intended for the ACCU conference , so i...

  Beyond the Code:  Designing Services That Stand the Test of Time  Wednesday, 26th February 2026 @ 13:45   nor(DEV):con The Kings Centre,  63-75 King St, Norwich NR1 1PH   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, observabi...

  When: Thursday, 12th February @ 6.30pm Where:  Dick's Bar,  19 Bedford St, Norwich NR2 1AR RSVP: https://www.meetup.com/norfolk-developers-nordev/events/312926991/ Norfolk Developers  and Dick's Bar are very kindly hosting my revised, 'So you think you can lead a team?' talk. So you think you can lead a team?   Software engineering is hard, and leading a team as an engineer can be even harder. Many of us feel more comfortable writing code than working with people, and we often believe our value lies solely in our technical output. But when you step into team leading, the balance shifts: there are more people than code, and your value changes and, often, grows. Over the last 25 years I was dropped into team leading several times without warning, but three and a half years ago I chose to do it deliberately. It still took more than a year before I realised I was only just beginning to understand what leading a software team really involves. This revised and...

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...