Paul Grenyer

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