Paul Grenyer

Liz Phair  When I met my wife, nearly nineteen years ago, she was obsessed with Liz Phair and in particular with the song **** and Run . I’m not sure if she was trying to tell me something….  She said she wanted to see Liz Phair live and I assumed we’d have to go to the US for that. Fortunately not! I held out through pure stubbornness / insight / belligerence / incompetence (delete as applicable) and Liz Phair eventually gave in and came to London! Supporting Alanis Morissette no less. I didn’t know what to expect. Would Liz bring a band or would it just be her and a guitar. Would it be 45 minutes of songs I didn’t know or would it be quite good. To be fair I had Liz Phair down as a talentless screecher, rather like I used to think PJ Harvey was .    Again I was wrong. I think I knew about three songs, but Liz and her band sounded great, for the O2, at least. I could have done without all the Americanisms of how wonderful it was to be there and how inspiring Alanis ...

In software development, responsibility and accountability are closely related but have important distinctions, especially when it comes to leadership roles like a team lead. Responsibility refers to the obligation to carry out specific tasks or duties. Multiple team members can share responsibility for different parts of a project. For example, developers are responsible for writing and testing code, while QA engineers are responsible for ensuring that the code meets quality standards before release. Accountability, on the other hand, means being answerable for the outcome of a task or project. While responsibilities can be distributed among several people, accountability typically rests with a single individual. In many software teams, the team lead is accountable for the success or failure of a given project or feature. They may not perform every task themselves, but they are the person stakeholders look to when results are delivered. Consider a scenario where a new feature is being...

by Margaret Atwood ISBN-13: 978-0099740919 The Handmaid’s Tale is a haunting, powerful novel that left a deep impression on me. It’s dark and terrifying in places, not because it leans into fantasy, but because its dystopia feels disturbingly plausible. What struck me most was how Margaret Atwood builds a future that feels entirely grounded in history and reality. Nothing in the novel is invented, every law, ritual, and cruelty has roots in real events or passages from the Bible. That makes the story all the more chilling. At times, I found myself struggling to imagine how such a society could come to exist, and yet, at the same time, I fully understood the forces that might drive people to create it. Atwood captures the slow erosion of rights and freedoms with such clarity that the descent into Gilead feels both surreal and frighteningly realistic. It's a world governed by power, fear, and rigid control, but built on disturbingly familiar foundations. This isn’t science fiction in...

by Hugh Howey ISBN: 978-1804940822 As I am sure many do, I read the book after watching the first two of the TV series.  They are amazing, the book is better. I like stories where there is lots of mystery, as I hate not knowing things, so Wool keeps my attention. What could be better for that than a submerged silo of people who don’t know where they came from? I do wonder if Hugh Howey has had a particularly bad experience with IT in the past as they are definitely the bad guys. I also expect he’s fascinated by engineering as there are several great explanations of machines, processes and even computer programming. Wool is great if you like a dystopian future to a world where the history is only just being rediscovered.

So you think you can lead a team? I’ve been talking and writing a lot about leading a software engineering team in 2025. I started thinking about it more deeply the year before when I decided to give a colleague, who was moving into team leading, some advice: 'Doing the work' isn't the only way to add value Remember to delegate Pick your battles Talk to your team every day Out of this came a talk, “So you think you can lead a team?” which I gave at work, at meetups and at conferences in various different formats during the first quarter of 2025. I am also turning these ideas, and more, into a book I hope to release towards the end of 2025. I’ve already explored delegation, you can read about it here:  https://paulgrenyer.blogspot.com/2025/04/remember-to-delegate-triangle-of-trust.html  And Seeing the Bigger Picture, you can read about it here: https://paulgrenyer.blogspot.com/2025/05/see-bigger-picture-and-look-around.html When I started writing the material for my talk for...

I had to cut down the “ Pick Your Battles ” chapter for my book - reviewers all felt it was too dense. That left me with some extra content, portions of which I’m sharing here, unedited, alongside excerpts I kept in the final version to provide context. What do Software Engineers Disagree About? Software engineers can, and do, disagree about anything and everything. I won’t even try to list it all, there is just too much. What I do want to do is give a flavour of the breadth of things we disagree about. Often it’s not even the technical details.  Changing Requirements Change is inevitable. I’ve already mentioned that being a software engineer is hard. Software is also complicated, but easy to change. If you compare software development to the mechanical aspects of engine design and development (putting aside that all modern engines use a lot of software), the pistons, cylinder, crank shaft, valves, etc. are relatively easy to understand. You can hold and understand the relationship...