Paul Grenyer

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

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