Paul Grenyer

The Maid When we were offered the opportunity to stay in a suite at the Maids Head Hotel in Norwich, even though we live in Norwich, we couldn’t resist and booked it for our 19th wedding anniversary. And I’m so pleased we did. We’ve travelled a lot this year, so it was nice to have time together away from home without a long journey. Everything about the experience was perfect. The room, which was the Paston Suite , was large and provided lovely views of the Cathedral and Tombland. The bathroom was spacious too. The staff were lovely and couldn’t have been more helpful throughout our stay. When we arrived, we found an anniversary card and two swans formed from towels and surrounded by petals. This made us feel really special and valued. There's something quite special about staying in a hotel in your own city. We know Norwich extremely well, of course, but staying in the heart of it made the experience feel like a proper break rather than simply another night at home. The Shoe Nor...

All good software engineers want to write good code. Unfortunately, many software engineers believe that good code must always be efficient, leading them to optimise unnecessarily or prematurely. Code is written primarily for people to read, so it should be as clear and simple as possible. One of the few constants in software engineering is change, and clear, simple code is easier to change without introducing bugs. However, what good software engineers really want to write is good software. This is even more important in the new world of AI, but this isn’t an article about AI. I am not suggesting that code never needs to be optimised, or that an engineer shouldn’t consider performance when writing it. For example, a value that is expensive to evaluate but remains constant should be initialised outside a loop rather than recalculated on every iteration. However, halving the execution time of a 2ms calculation in a request that also makes a 40ms database call makes very little differenc...

I've been writing and blogging for as long as I can remember, and I've never really understood the difference between articles, essays, papers and white papers. I've certainly never known when I should use each term. So I asked ChatGPT to explain the differences and when I should use each one. This is what it told me. It turns out there's quite a bit of overlap, but the main differences come down to purpose, audience, evidence and formality. Essays An essay is about exploring an idea, developing an argument or expressing a point of view. It's often personal, reflective and doesn't necessarily require extensive research or a formal structure. For example, I've been reading a lot about software optimisation recently, particularly the views of Donald Knuth, Michael Jackson, Brian Kernighan and P. J. Plauger. If I were to bring their ideas together, compare them with my own experience and reach a conclusion about premature optimisation, that would make a good es...

    OmniLog brings your observability data together, so you can understand what your systems are doing without jumping between tools. Send telemetry with OpenTelemetry , search your logs, chart your metrics and follow requests through distributed traces - all in one place. Your data stays private, and the information you need stays close at hand. Want to try OmniLog? Email me from: https://paulgrenyer.com/omnilog

As I continue working on projects of my own, as well as those in my day job, I am learning more about the best ways to use AI to create software. Mostly Claude and sometimes Codex. One thing I cannot help noticing is the sheer number of comments AI adds to the code. In January 2025, I wrote a blog post called Comments in Code: Just Don’t Do It , in which I quoted Uncle Bob: It is well known that I prefer code that has few comments. I code by the principle that good code does not require many comments. Indeed, I have often suggested that every comment represents a failure to make the code self explanatory. I have advised programmers to consider comments as a last resort. I went on to say: Comments should always be “why”, never “what”, and only when     absolutely necessary. If you feel the need to write a “what” comment, put the code in     a well-named, meaning descriptive, function instead. I stand by this view. Comments should be few and far between and,...

In my previous post, The Elements of Programming Style: still worth reading , I argued that the book is still worth reading. Going back through the rules made me think about which ones I would give to a developer today. Most need no help. Clear names, small modules, testing boundary values and measuring before optimising are as useful now as they were when Brian Kernighan and P. J. Plauger wrote the book. A few rules, though, speak in the syntax of Fortran and PL/I. Fortran is still used in scientific and high-performance computing, but many developers won’t recognise an arithmetic IF or a DATA statement. In those cases, I’ve kept the original rule and written a version that carries its advice into other languages. These are the 72 rules I took from my reading notes, in order. Where I’ve changed one, I’ve included the original, the updated rule and my reason. 1. Write clearly - Don’t be too clever 2. Say what you mean, simply and directly. 3. Use library functions. 4. Use temporary var...