Paul Grenyer

When One Beyond invited me to take part in the London Tech Leaders Summit, I wasn’t quite sure what to expect. What I definitely wasn’t expecting was a seven‑foot robot interrupting the opening welcome. As the doors flung open, the robot ducked to fit through, marched to the side of the stage, interrupted the speaker, and proceeded to continue the welcome itself. It was initially a little unsettling, but to be fair, its jokes were better. What followed was a full day of presentations, panels, roundtable discussions, and workshops. All were framed through a leadership lens and all centred on AI. I know what you’re thinking: not another AI conference. But this one really stood out. Rather than theoretical hype, it was software leaders - many in similar roles to mine - openly sharing what they’ve learned from using AI, where it’s taken them, and how it’s shaping their organisations. There were several highlights. Hywel Carver , CEO of Skiller Whale , made a particularly memorable point:...

I wrote Deep Imports Considered Harmful for two reasons. Obviously to persuade people not to use deep imports, but I also wanted to reinforce that components should have an abstract interface and an encapsulated concrete implementation. I was expecting some pushback, but all I got was something I should have seen coming and covered in the original piece. Here’s the follow-up to get it covered. Every time you tell someone that deep imports are a bad idea, there’s always one reply waiting in the wings: But deep imports perform better. It sounds plausible. It feels intuitive. But it’s wrong. To be fair, this myth didn’t come from nowhere. In the past, some libraries really did ship poorly structured entry points with giant index.js barrels with side effects, no tree‑shaking - a build‑time optimisation that removes code you never use from your final JavaScript bundle - support, and no clear separation between public API and internal implementation. In those cases, deep imports sometimes ...

Looking ahead to next year, I want to talk about Abstraction, Encapsulation, Cohesion and Loose Coupling as it seems they are missing from a lot of modern software design. Back to Basics: Why the principles that built our industry still matter today There are only three things certain in life: death, taxes, and constant change in software. For decades, we’ve tried to limit that change. Up‑front design and predictive methodologies promised control, but too often delivered the wrong software for the user. In the late 90s, Kent Beck urged us to embrace change through methodologies like Extreme Programming and concrete practices such as Test‑Driven Development. These weren’t trends, they were reminders of fundamentals we already knew. Design behind interfaces. Keep responsibilities narrow. Make dependencies replaceable. These boundaries matter, from functions and classes to services, systems, and infrastructure. These ideas have been with us since the 60s and 70s. The challenge isn’t inven...

Keep It Loose Deep down we all know it’s important to componentise software systems.  It allows different parts of the systems, the components, to change and evolve over time with minimal effect on other parts of the system. Designed and implemented correctly, components are loosely coupled , as well as highly cohesive .   In practice this means that components can be changed, replaced, or evolved independently, without causing widespread change throughout the system. Components with responsibilities, and that naturally change together, are grouped together. Components have abstract interfaces and concrete implementations. Interfaces describe the features provided by a component and hide the concrete implementation. Users of components - usually other components - depend on the interface rather than the concrete implementation. If clients come to depend on concrete implementations - the internal details of a component - the benefits of componentisation are lost. The comp...

Persepolis Rising is set thirty years later and goes off in a different and uninteresting direction. It is of course possible that the entire book is setting up the story for the final two to be brilliant, but the story arc is only referenced in the epilogue. At the beginning the story makes the reader feel that there is no resisting the invading forces and initial resistance attempts fail and result in surrender. However, by far the best part of the book, other than the epilogue, is when Holden’s team find a way to hijack one of the invader’s ships. There are only two books to go, maybe it will pick up.

I’ve been using Claude Code without many rules for a while. It’s certainly not the most efficient or effective way to use it. With its help, I learnt how to create some persistent rules around logging. When we’d finish I had Claude produce this blog post. It’s been reviewed and revised by me. See what you think. The Problem with Tribal Knowledge Most teams have coding guidelines. They live in many places, including wikis, onboarding documents, and the heads of senior engineers who will politely point out in code review that you shouldn't log the request body. The problem is that guidelines only work if they're applied consistently, and consistency requires either constant vigilance or automation. I wanted to find out whether I could move my team's logging rules out of a document and into the tool itself, so that Claude would apply them automatically, every time, without being asked. Two Mechanisms Worth Knowing Claude Code offers two complementary ways to encode behaviour: ...

I always look forward to the AWS Summit. It’s a great opportunity to learn what AWS, and the engineers who use it, are up to, and to catch up with my colleagues. This year, though, turned out to be a bit different. The first year I attended, I skipped the keynote entirely and spent the time in the AWS labs instead. Last year I did go to the keynote, and wished I hadn’t. This year I attempted to do both, but it didn’t really work. I managed just one very simple lab before I had to leave for the keynote. Although I did manage to get to the Red Hat stand early and be the first to get an actual red hat! Although I did have to carry it around all day and all the way back to Norwich that evening.     One of the main issues is the size of ExCeL. It’s big. I mean really big. You may think it’s a long way down the street to the chemist, but that’s peanuts to ExCeL. It’s a long way from anywhere to anywhere else. Poor Hitchhiker’s Guide to the Galaxy references aside, many things, inc...

Judiciously: With good judgement.  Logging is one of the simplest things a developer can do, and one of the easiest things to get wrong. A single misplaced log line can be harmless, but a pattern of careless logging turns into noise, confusion, and even security risk.  The challenge isn’t teaching engineers how to log, it’s helping them understand why they’re logging in the first place. Here I intended to draw that distinction clearly: choosing logs that illuminate behaviour, support debugging, and reveal failures, while avoiding the chatter, duplication, and reassurance‑driven messages that bury the real signals. Finding the Line Between Useful and Noisy Teams often fall into the trap of believing that if they simply “log enough,” the rest of observability will take care of itself. It’s an appealing idea: produce a steady stream of detail, let dashboards and alerts sift through it, and assume that somewhere in the noise the truth will reveal itself. But this mindset skips th...

I know what you’re thinking. Didn’t I do this not long ago? It’s true, I did . Less than 18 months ago in fact. And if Winterfylleth releases another album and does an album launch in the next 18 months I’ll go and do it all again. I left work at 2pm, got the train to London, the Underground to Cambden and spent all of five minutes with the band. I had the latest album signed - which I have twice now, on CD and on vinyl which I collected from Raven Records this evening - my ARD  (mark Deeks' band) CDs and record signed, and all my Necronautical  (Rust Ob Sun's band) CDs signed. They all did the Metal pose, I see them do on social media, with me. They were all very accommodating, which made my week and is why I go! Mark Deeks was there this time, and it was great to meet him in person after much messaging on social media. It was good to meet Rust Ob Sun for the first time too! His Facebook posts are great. In a flash it was over and I was heading back to Norwich, via a few ho...

  I loved The Forcek Assignment! I’ve read most of Ray Adam’s books and this is by far my favorite so far. It’s short, at about 110 pages, but that means it’s fast paced. There are only a few characters, so you only really get to know Roo Raker, but that’s enough. It has a plot which would be at home in any The Original Series Star Trek film, a mysterious red head and a couple of twists I should have seen coming and didn’t. I’ll never understand Ray’s obsession with creating characters who smoke, but that’s no detractor, and I was left with just one question - well lots of questions, but one big one - why is Roo Raker’s name never shortened?! The Forcek Assignment! Is the first of a trilogy, and I have the second lined up already. Ray Adams ISBN-13: ‎ 979-8679926462

Over the last 18 months, the support you’ve all shown for my writing, speaking, and the journey Charlotte and I have been on has meant more than I can ever say. Every message, every share, every bit of encouragement:  it’s carried us. So we’re delighted to offer something special in return: a little piece of us that you can take with you and love forever. Meet the Paul & Charlotte Plushie Soft, cuddly, and created with so much care, this plushie is designed to bring a smile wherever it goes. It comes complete with: A miniature Paul plushie — glasses, beard, and all the familiar charm A tiny Charlotte companion plushie — warm, cheerful, and full of heart Matching accessories that tie the whole set together and make it perfect for gifting, traveling, or simply keeping close Whether you’ve followed our journey from the beginning or only recently joined us, this plushie is a lovely way to keep that connection alive. Get Yours Here https://paulgrenyer.com/shop   Thank you ...

Naked Element to reward team for taking showers. While there is a lot to be said for meeting a problem head on, research has shown that removing oneself from a difficult task, even for a few minutes, can make all the difference when it comes to finding a solution. Engaging in a less mentally challenging activity frees the mind and allows it to consider different pathways and directions. How many times have you struggled to remember the name of a contact, only for it to come to mind while putting the kettle on? Or been stood in the shower and come up with a new way to tackle that tricky code issue at work? Back in the dim and distant past, our director Paul Grenyer lived in Leeds and worked as a software engineer in Sheffield. It was an 80 mile round trip by car everyday, not something that he relished, but that turned out to be his best time for solving software problems (the copious amounts of Black and Symphonic Metal he listened to while driving may have also helped, but that’s anot...

The Imperious Horizon came out on the 13th of September 2024. 18 months (and 2 days) ago. Of course that’s not a long time between albums, especially with bands today - it’s been nearly 8 years since the last Dimmu Borgir album - but it’s also felt like forever waiting for The Unyielding Season. One of my favorite bands, I return to Winterfylleth again and again. The Unyielding Season opens with a single symbol hit which immediately draws you in! In the middle of the album the acoustic guitars come out and are fantastic. It feels like there’s a new level of intensity throughout, even during the orchestral bits. The lead guitar is better than even, but what really stands out is the richer drum sound. The version of Paradise Lost’s Enchantment, the bonus track, is something else! More layers than the original. Longer than the original. The piano is more haunting and Mark Deeks’s vocals are great! I’m only on my third listen, but already this is a great album. 

  A few months ago, Shaun Lowthorpe put out a call on LinkedIn for people willing to share real‑life experiences of using business analysis at work. Although I haven’t done what you’d call traditional business analysis for years, I work in a Product led organisation, and I love getting up in front of a room and talking. So I volunteered, and Shaun kindly accepted. I wanted to show how we use tools like Amplitude to test and measure the impact of user interface enhancements. After chatting with colleagues, I put together a short ten minute presentation about some of the A/B experiments we’d run to improve the guest booking details experience. I’d never presented this kind of material on my own before, so it was a little daunting. I was keen to make sure I had the details right, especially in case I was hit with any tricky questions. Presenting can be unpredictable. Sometimes my energy doesn’t quite match the mood of the room, even after I’ve got them all to grin and wave for a pho...

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