I have talked about my ability to hear high pitched sounds before.
Recently I have worked out a source of this noise: automated lights.

The motion sensors on lights emit sound just outside the “normal human range”.
I had thought that it was fire alarms, but these are now more common.

The average time a developer spends at any given company is 2-3 years.
This seems to also apply to more senior positions such as CTO’s.

A new CTO will arrive, hopefully wait 6 months before starting the changes that they want to make to the organisation.
This puts an upper limit of 3 years on any change program.

The problem comes when you have systems that are 3-5 years old. That can mean that very few (if any) of the initial developers are still working at the company. Those that are will either be deeply embedded in systems or have been promoted to different areas.

This is where having living documentation and actively maintained tests come in handy.

This looks like a good way to get demos that are more interesting than a slide deck:

https://revealjs.com/

Here is a quick example of implementing gRPC in node.js: https://grpc.io/docs/languages/node/basics/

I work on a large system that has a number of external dependencies. We have a shared repo that provides mocks for these services. Other teams are moving some of the services from http or graphql to gRPC. We need decent mocks or we end up with a fragile local development experience.

These are the changes you make because a system does something that annoys you.

I have a personal practice at work of looking at the error logs of our system each day. This leads to actions to make small improvements.

At the start of this year my engineering manager encouraged me to expand this to a team activity. We meet once a week and look at the highest frequency patterns. These are turned into either tickets for us to fix or requests for other teams. We have halved the volume of errors. The logs are now mostly free of noise and we are clearing real errors, some of which have been in production for years.

The next step is to expand this to the entire company.

The key point is that an observability platform is more effective if everyone is looking at it every data. I aim to inspire curiosity: what has caused this error and do I need ho fix or ignore it.

The basis for this is a simple dashboard in Datadog. List error logs for a number of systems. Look at errors in production grouped by patterns. Add exclusion rules to ignore things that are too expensive to fix now. View over a 1 day time window. Sa e as a favourite.

Look at this every day. Keep stats in a spreadsheet – datadog has a limited time window.

Analyse it every week.

Fix issues raised.

The first point people raise is to automate this. Resist this urge as it is the looking at it regulatly that is the point.

Logs are great for this as it is always possible to drill down to find a specific example to look at.

As a side effect the team will become better at writing log messages and using the observability tools. They will learn more about the systems they are supporting.

I have been skeptical of using AI in development work. Recently I have been using Vapi. This is a means of having a voice UI without having to do the Alexa rules option.

You give it a prompt that must include acting professionally and sticking to a knowledge base. Thats the core feature.

What really impressed me is that Vapi have applied this in chatbot form to their own documentation.

In a few questions I was able to get key information that would not have been found without exhaustivly reading the documentation.

I am still wary of using AI to write code having worked with Genetic Algorythms – you can end up with a solution that works for some cases but can’t say why it does it.

I curently working for a medium size company that is slowly moving towards using DDD. We have notionally been domain based for the last 18 months.

Its an international company with distinct business in three countries. The difficult part is working out what can be made global without breaking the existing offerings.

Each country has different preferences and work at different scales.

Common infrastructure pieces could be extracted. It makes sense to only integrate with payment providers once.

Each country will have regulatory requirements for reporting that need to remain country specific.

I like Vaugh Vernons definition of DDD as

Developing ubiquitous language within a bounded context

I like to have a ubiquitous dictionary so we have somewhere to document a Ubquitous Language.

One of the fundamental GDPR rights is the right to be forgotten.

I recently received a cold call on my mobile number from a company that I had not given it to.
They had purchased it from Cognism.

Now Cognism are reasonable and have decent records (kind of they needed to be reminded that the initial daraset was incomplere) of where they have sold it to.
Their website has a simple form to remove me from their database,

The problem is now the companies they have shared my details with:

lead-forensics

zymplify

lightrun

revgen

ukfast

These all have gdpr compliant messages on their sites but don’t have a simple form to access them.