Paul Grenyer

Apparently ‘So Good’ stood in at the last minute for someone else who couldn’t make the tour. I know established bands like to help out new bands, and that’s to be applauded, but So Good’s reinvention of Shampoo with worse lyrics should probably have been passed over. Having said that, they gave it their all and they clearly believe in what they’re doing. Skunk Anansie, for me, were at their best with Stoosh. Post Orgasmic Chill and Sunburnt and Paranoid are good, but it’s always the singles that stand out. A good third to a half of their set went by before I recognised anything. It didn’t matter though, it all sounded so good. Ace is a better riff writer than he is a live player. His playing didn’t sound right in lots of places and for one song his guitar was clearly out of tune. The crowd didn’t care though. Every song received an enthusiastic response. Skin jumped into the crowd on several occasions, catching her minder out the first time - his face was a picture. At one point she r...

Infectious Generosity by Chris Anderson ISBN-13 ‏ : ‎ 978-0753560495 I was recommended this book, out of the blue, by a colleague. I am not entirely sure why, but now that I’ve finished it I am looking forward to finding out! Infectious Generosity looks at the state of generosity in the world and looks at the ways in which it might be improved with lots of real world examples of people who have been generous and a framework for becoming more generous. Most importantly, it explores how being generous, even in small ways which have little cost to you, makes you happy. It takes a good hard look at the internet, especially social media and how, in the author's opinion, it is a massive source of evil in the world. He examines everything from cyber bullying to toxic masculinity. But then he describes how, with just a few simple changes to the way we approach the internet and social media, we could turn it into an even bigger force for good and encourages the reader to do so. The part of ...

 The One Minute Manager Meets the Monkey by Ken Blanchard, Hal Burrows ISBN-13: 978-0007116980 When I made the move to lead engineer from senior engineer my instinct was still to try and fix everything for my engineers rather than get them to complete their own tasks, or as Ken Blanchard puts it, Monkeys. It was useful and interesting to read about someone in a very similar situation, how it affected them and their family and how they eventually overcame it with four simple rules: Rule 1: Describe the Monkey: The dialog must not end until appropriate “next moves” have been identified and specified. Rule 2: Assign the Monkey: All Monkeys shall be owned and handled by the lowest organisational level consistent with their welfare. Rule 3: Insure the Monkey: Every Monkey leaving your presence on the back of one of your people must be covered by one of two insurances: Recommend, then act Act, then advise. Rule 4: Check on the Monkey: Proper follow up means healthier Monkeys. Every Monke...

What: So you think you can lead a team? When: 2.45pm, Thursday 3rd April 2025 Where: Delta Hotels Bristol City Centre, 2 Lower Castle St, Bristol BS1 3AD More Info:   https://accuconference.org/  Get tickets: https://accuconference.org/booking Software engineering is hard. Leading a team, as an engineer, can be even harder. Many of us are better at developing software than we are with people and feel our value lies in actually writing code. When you step into team leading, there are more people than code and your value increases. Over the last 25 years I’ve been unexpectedly dropped into team leading a number of times, but three and a half years ago I chose to do it. It took at least twelve months for me to realise I was only starting to understand what leading a software team is and what it means. Join me for some of the highs and lows of team leading and an insight into some of the things I learnt to help me be a better team lead. I can’t promise a panacea as I...

In February 2025 I gave a 15 minute version of my "So you think you can lead a team?" talk to my colleagues on park in Devon. You can watch it here: So you think you can lead a Team? Software engineering is hard. Leading a team, as an engineer, can be even harder. Many of us are better at developing software than we are with people and feel our value lies in actually writing code. When you step into team leading, there are more people than code and your value increases. Over the last 25 years I’ve been unexpectedly dropped into team leading a number of times, but three and a half years ago I chose to do it. It took at least twelve months for me to realise I was only starting to understand what leading a software team is and what it means. Join me for some of the highs and lows of team leading and an insight into some of the things I learnt to help me be a better team lead. I can’t promise a panacea as I  still have much to learn, but I hope to help you avoid some of the mista...

Today I attended my first DataDog Summit. It was interesting, but at times, it felt like a bit of a slog. Registration began at 9am, and by 10am, we were in the main auditorium for two and a half hours straight - eight back-to-back 15 minute sessions with no breaks. The sessions were a mixture of introductions, customer experience and DataDog features. Of course the DataDog feature talks were just a little bit salesy and DataDog give the impression they think they’re the answer to everything, but it wasn’t too bad. The customer experience talks were really interesting, especially those from NatWest, WTW (big in insurance apparently) and the London Stock Exchange. It was good to see other organisations solving similar problems to my current employer and that we’re ahead of most. The new (to me) DataDog features were also interesting. I didn’t know that data into DataDog wasn’t just a one way flow. DataDog can also be configured to adjust your infrastructure to save cost or mitigate une...

In the first half of 2025 I presented a number of times on team leading. During the talk I reference a number of books which have helped me become a better team leader: The One Minute Manager Kenneth Blanchard ISBN-13: ‎978-0008128043 The One Minute Manager Meets the Monkey Ken Blanchard, Hal Burrows ISBN-13: 978-0007116980 How to Win Friends and Influence People Dale Carnegie ISBN-13: 978-8183631297 What did you say? The Art of Giving and Receiving Feedback Charles N. Seashore, Edith Whitfield Seashore, Gerald M. Weinberg ISBN-13: 978-0965043007   Nonviolent Communication Marshall B. Rosenberg ISBN: 978-1-892005-28-1   Extreme Programming Explained: Embrace Change Kent Beck ISBN-13: 978-0321278654   How to Make Friends and Influence People Terrorvision    The Work Rivers of Nihil

Async functions are a powerful feature in JavaScript and TypeScript, offering a cleaner, more readable alternative to working directly with Promises. However, it’s easy to overuse them or add unnecessary layers of complexity.  By understanding when and how to use async and await effectively, you can write more concise, efficient, and maintainable code. Let’s explore a common scenario where async and await may be overapplied, and how simplifying the function structure can improve code readability and maintainability without sacrificing intent. Take a look at this function which wraps an async function which deletes an entity form a database: const deleteEntity = async (id: number) => {     return await db.entity.delete({ id }); } You would also await deleteEntity when calling it, resulting in two promises, unnecessarily verbose code and less efficient execution.. Instead of awaiting the promise created in deleteEntity , it can just be returned: const deleteEntity ...

axios-http-builder is a n Axios i nstance builder for use on client or server side with common features pre-configured: - Timeout - Cancellation By default, Axios does not configure a timeout or a cancellation timeout. However, axios-http-builder sets both to 2 seconds by default, which remains configurable. axios-http-builder also includes an optional exception handler. Install npm i -save axios-http-builder   Usage To use the default configuration, instantiate the Axios instance with buildHttpClient and then use as normal: import { buildHttpClient } from 'axios-http-builder'; const httpClient = buildHttpClient(); await httpClient.get('https://myservice/entity'); buildHttpClient takes a CreateAxiosDefaults object, so you can use any of Axios' options as normal: import { buildHttpClient } from 'axios-http-builder'; const httpClient = buildHttpClient({ baseURL: 'https://myservice' }); await httpClient.get('/entity'); The axios-http-buil...

Something I see a lot, especially in node applications, is duplicate messages logged due to an exception being caught and logged in several places as the stack unwinds. For example with the following (contrived) code: const httpCall = () => {   const url = 'http://example.com';   try {     throw new Error('Something went wrong!');   } catch (error: any) {     log(error.message, { url });     throw error;   } }; The real error is here in httpCall , but some context about the error needs to be logged, so it is caught, logged and rethrown. const callService = () => {   const someContext = 'The service we called';   try {     httpCall();   } catch (error: any) {     log(`Service failed: ${error.message}`, { someContext });     throw error;   } } ; httpCall is called from a service wrapper, which has its own context which needs to be logged, so again the er...

How we use comments in code has come up a couple of times for me this week and when I looked, I realised we hadn't captured anything in the my teams's coding guide lines, so I added something:   Uncle Bob Says : "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." 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 (read descriptive) function instead.   There will be those of you who will be adamantly attached to your comments, but you don't need them. And at some point, in the past, now or in the future, you or someone else will update your code, making the comment wrong and forget to upd...