Paul Grenyer

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

  This book is unlikely to be of interest, unless you’re interested in data processing programs written in COBOL. However, I was interested in optimisation and the origin of: 1. Don’t do it.  2. Don’t do it yet. So I was satisfied with that at least. There are ideas here which have survived rather better than the examples, such as keeping programs simple, avoiding GO TO where possible and making each component responsible for validating the data it passes on. But much of the book is firmly rooted in the sort of data processing systems it was written for, and I struggled to relate many of the design techniques, particularly program inversion, to the way I think about software today. I did enjoy the occasional bit of personality, especially “A Moral Tale” and warnings to “resist this satanic temptation”. The exception was the chapter on optimisation, which was by far the most interesting part of the book. Jackson’s two rules are wonderfully simple: “Don’t do it” and “Don’t do it...

The Foundation series has been my go to for a good, enjoyable read over the last two years, so naturally I moved on to Asimov’s Robot series afterwards. However, the short stories in I, Robot were mostly a disappointment. They feel self indulgent, with too much philosophy and science, Asimov showing off, and not enough story. The most enjoyable moments come from the stories featuring Gregory Powell and Mike Donovan. Their banter and the relationship between them provide some much needed amusement and were easily the highlight of the book for me. However, it did give me food for thought for the current potential issues with the rapid development of AI at the moment, and the many concerns around safety. I wonder if all we need is: An AI may not injure a human being or, through inaction, allow a human being to come to harm. An AI must obey the orders given it by human beings except where such orders would conflict with the First Law. An AI must protect its own existence as long as such p...

The Elements of Programming Style by Brian W. Kernighan and P. J. Plauger is one of those books that makes some excellent points that every software engineer should know and bear in mind every day. The central message is simple: write clearly and don’t be too clever. Say what you mean, use the language’s good features, choose names that won’t be confused, and structure your code so that its intent is obvious. There is plenty here that still feels completely relevant, including modularisation, encapsulation, keeping modules focused on one thing, making coupling visible, defensive programming and, perhaps most importantly, not stopping with your first draft. The advice to revise and refactor rather than being satisfied with code that merely works is something that could be written today. The chapters on efficiency and documentation particularly stood out to me. The authors make the point that if a program doesn’t work, it doesn’t matter how fast it runs, and that you should make it right...

Not Like That! How to build the wrong thing on purpose instead of the right thing by accident by Adam L. Coombes I really like this book. It’s divided into seven-minute chapters, which I found particularly effective. They’re short enough that you can get through one whenever you have a few minutes, but there’s enough in each one to give you something to think about. The writing is engaging and amusing too, which makes what could otherwise be quite a dry subject surprisingly easy to read. At first, I thought the author had misunderstood Agile. The early chapters seemed to be making the argument that Agile had somehow become a rigid process, and that we had forgotten the importance of actually talking to the people who use the software. My immediate reaction was: wasn’t this what Agile was supposed to solve 25 years ago? There’s a chapter called Agile Just Made It Faster , and initially I thought this was where we were going to disagree. But I think I was wrong. The author isn’t really a...

For research for a blog post, I’m reading Computer Programming as an Art by Donald Knuth , a transcript of a presentation he gave in 1974 . This particular passage resonated with me, especially in light of the current state of software engineering: The field of "automatic programming" is one of the major areas of artificial intelligence research today. Its proponents would love to be able to give a lecture entitled "Computer Programming as an Artifact" (meaning that programming has become merely a relic of bygone days), because their aim is to create machines that write programs better than we can, given only the problem specification. Personally I don't think such a goal will ever be completely attained, but I do think that their research is extremely important, because everything we learn about programming helps us to improve our own artistry. In this sense we should continually be striving to transform every art into a science: in the process, we advance the...

Finishing a story is difficult. It’s even more difficult to do well. It’s practically impossible to finish a trilogy well. I think Dust finishes the Silo trilogy quite well. Dust is a surprisingly short book, given all the threads which need tying up and the mysteries which need explanations. Rather than concentrating on the main threads, it meanders quite a bit in a few places. About 80% though, it feels like there’s no way there’s room left to finish the story. I can’t help feeling there’s scope for so much more and that Howey either wanted to, or was encouraged to, bring it to a quick end. The threads all tie up, but there are just so many unanswered questions. Having said that, it’s a difficult book to put down throughout and I enjoyed it to the end.

I’ve given my Beyond the Code: Designing Services That Stand the Test of Time presentation a few times now. It started as a talk I put together for the ACCU Conference - which wasn’t accepted - and has evolved quite a bit as I’ve presented it to different audiences, and had conversations with people afterwards. The original idea was fairly simple. As software engineers, we spend a lot of time thinking about business logic. We think about the domain model and how to operate on it, the workflows, and the data. These things are obviously important, but a service is more than its business logic. The things around that logic matter too. How the code is structured. Where responsibilities live. How components communicate. How we expose functionality through APIs. How we deal with failures. How we observe what the system is doing. What we test, and how. These decisions can have a significant impact on how easy a service is to understand, maintain and change. Because while almost everything ab...

I really like Lukasz Quilter and his little band, they get into some fantastic scrapes. A Sound Inhuman has a gloriously gory beginning and then builds really nicely. I like a sci-fi story which creates lots of questions, which gradually get answered as the story progresses. This story has that in spades. However, there are two mysteries which go unanswered, and aren’t part of the setup for the next story, which is a shame. There are lots of characters to get your teeth into, which is great as they’re all quite different, and the dynamics between them work well. Personally, I can’t wait for the next Lukasz Quilter story. I hope it will be longer, with more Space Opera. I am a bit biased though, as the author is a long term friend and was kind enough to dedicate this story to me. A Sound Inhuman: A Lukasz Quilter Novel Ray Adams ISBN-13: ‎ 979-8198705548

Surrounded by Idiots: Entertaining, Thought-Provoking, but Don't Take the Colours Too Literally Thomas Erikson's Surrounded by Idiots is one of those books that's easy to see why it became a bestseller. It's funny, engaging and full of memorable examples. It starts well with a sense of humour - the "keep the receipt" joke immediately sets the tone - and throughout the book Erikson has a knack for making behavioural psychology feel approachable rather than academic. One of the first ideas that struck me was his challenge to the Golden Rule. Rather than treating others as you would like to be treated, he argues you should treat people as they would like to be treated. It's a simple shift in thinking, but one with obvious implications for communication, leadership and relationships. The core of the book is the familiar DISC model, expressed as four colours: 🔴 Red – task-oriented extroverts who focus on results and action. 🟡 Yellow – relationship-oriented ex...

In June 2026, a new HTTP request method, or verb, was introduced. RFC 10008 describes Query as: A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests, but QUERY requests can be automatically repeated or restarted without concern for partial state changes. But what does that mean and why do we need it? What’s Wrong with GET? When we want to retrieve a resource from a RESTful interface, we use GET. It’s simple. It’s easy to use. A GET request has no defined request body, and it should be idempotent. That means we can make the same request over and over again without changing any state in the service. The response itself might be different if the resource has changed, but the GET request shouldn't be the thing that causes that change. Sometimes we need to add query parameters to a GET request. Perhaps we want to specify the maximum number of resources ...

I’ve been doing a kind of tour with my Beyond the Code: Designing Services That Stand the Test of Time talk. I’ve given it in Oxford, Norwich, Cambridge, London and York*, between February and August this year. I’ve really enjoyed giving it, but what I’ve loved the most is the feedback and the energy (sorry for the cliche) of the audience.  In Oxford they ripped my logging examples to shreds. In Cambridge I couldn’t convince anyone of the merits of sharing data - so I reframed it in terms of caching. In Colchester they were convinced that it was fine to return a success indicator in a HTTP response body - this resulted in me writing, Should HTTP Status Codes Reflect Business Outcomes? . And in London someone started arguing after just the second slide, but they, and the rest of the audience, went on to ask rich and engaging questions. In Norwich, my home city, and off the back of me describing what had gone on in Colchester a few weeks before, a couple of different people asked me...

The Machine Crusade is mostly another middle of the road science fiction story, like The Butlerian Jihad , however what saves it are moments of brilliance from time to time and the ending, which accelerates considerably and keeps you wanting more. There are many characters, and I wish I’d made a note of who was who and where they came from and how they were related at the start. However, the characters are quite rich, making this a more enjoyable read. This felt a bit more like a Frank Herbert story, as most of the characters were selfish, narcissists driven by power and wealth. The robots are more believable than before, but the story is starting to date when you consider it in the context of modern AI. I’m pleased I read it. I’m looking forward to the third and final instalment. Let’s see where this goes. Brian Herbert, Kevin J Anderson ISBN-13 ‏ : ‎ 978-1848943414

I don’t usually enjoy ‘art’, however I’m often in museums as my wife enjoys it. We’re on the Victoria and Albert Museum (V&A) mailing list - mostly because my wife wants tickets for the David Bowie exhibition - and an email about the new Bharti Kher (https://bhartikher.com/) exhibition: Hybrid forms and lived realities: the sculpture of Bharti Kher  looked like her sort of thing, so we went. It consists of four sculptures, one outside at the front of the museum and three intermingled with other sculptures in one of the main concourses. My initial thought was that we’d gone all that way, and it was just four sculptures, and I should have read the V&A article properly. The thing is though, they were really good, imaginative and right up my street. I particularly liked Warrior with Cloak and Shield: and even though Ghost looked like a statue that had got out of the shower and taken the shower curtain with it, I really liked it: Animus Mundi: and Gaia were equally impressive....

There’s something about Software Crafters Cambridge - and it’s not just that I can never remember the order the words go in the name. They’re a quiet group of software professionals, but the talks and workshops are always interesting, and it quickly becomes apparent that there’s a lot of knowledge and experience in the room. I’ve known Carl Farmer for several years. I helped him set up SyncIpswich back in the mid-teens. However, I hadn’t seen him for ages, so I was keen to come along and hear what he had to say. I wasn’t disappointed. Carl works in AI at Microsoft as an AI Solutions Engineer - sales, basically - so he’s seen it all. He took us expertly through how to measure the real ROI of AI. It turns out it’s the same way we measured it with human engineers; we just mustn’t forget to keep doing it that way. Carl then explored ways of working with AI, how to get the most out of prompts, and how to minimise costs. I came away with a lot of notes and useful tips. The part that resona...

I hadn’t written a line of C++ since 2011 before I read this book, and that was just for fun. I hadn’t written a line professionally since 2006. Introducing C++ made me want to write some C++ again, so I did. Early in the book, Frances tells us that prior knowledge of another programming language is useful when reading the book. A lot of what I had forgotten about C++ came back very quickly - I think I would have struggled without prior programming knowledge. However, if you don’t know another language, or C++, already, don’t let that put you off picking it up - give it a try! Introducing C++ is very easy to read throughout, and that is its biggest strength. The introduction to the language is gentle until about the final quarter. There is a great introduction to class basics, and then the pace picks up considerably. The example code is introduced a little at a time and used to build a trading game throughout the book. This worked really well for me. The book certainly left me wanting ...

We saw Skunk Anansie just over a year ago and I haven’t seen Garbage since the Version 2.0 tour in 90s - the best time to have seen them in my opinion. When the opportunity to see them both together came up, of course Charlotte wanted to go - despite it being half way across the country. Soon after we bought the tickets, Garbage announced a gig at the Roundhouse, which would have been closer, cheaper and far more convenient. Support came from Ian Davies and Du Blonde. We eventually figured out that the DJ playing when we arrived was Ian Davies, he had some good tunes, especially when he kept to the 90s.  Du Blonde was quite good, the sort of Indie Rock band which were common in the 90s, singing about similar themes, such as the music industry. Probably the best which can be said about Garbage is they were good. The two guitarists were lackluster, but of course Shirley Manson was great, marching around, in bright red boots, like she owned the stage - which of course she did. Great ...