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