This is something you need to use every year in the UK if your salary/income exceeds a certain level (or if the tax man tells you to).

Its a fairly clunky system. There has been minimal UX work. You only find out that amounts of zero can’t be submitted on amount fields after a page is saved.

Company names are limited to about 20 characters. I was transferred between legal entities (same company) during this tax period. The problem is I can’t enter either legal entity name in full, and the difference between them is at the end.

It is worth perservering with as you may get a tax refund.

The use of google authenticator is better than a previous security system that required having a code sent by snail mail in a tamperproof printed format.

This has been a problem for many developers recently. It seems as if the call me feature calls you from north america. The problem is that line does not have global reach. You can reach a UK or US number.

Try using a phone redirection service such as vonange that allows you to buy a phone number for less than a euro a month.

Recently I have been making more international flights for work. It seems that all airports now have a shopping mall as part of the process.

The process seems to be: pass a gate that requires a boarding pass. Ditch or drink liquids so you can pass the security check (which varies wildly between airports).

There is then some form of passport check – frequently automated.

You are then left with a curving path through a duty free store before you get to the screens announcing the gates.

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.