Programmers like to argue over programming languages and tooling. If we remove all the pretense, it usually comes down to people defending their personal choices. We have a tendency to try to justify and protect our investment in whatever languages and tools we know and use. This makes sense. But it isn’t always rational behavior.

Knowledge is highly ephemeral. In order to write a piece of code, you usually have to assemble a jumble of knowledge and keep it in your mind while writing the code. As soon as you are done, that knowledge will decay quickly. A good example is what happens when you are interrupted while programming. It can take minutes or hours reestablishing the mental context required to finish what you were doing before being interrupted.

The idea behind microservices is not entirely bad, but what can cause problems is when developers blindly adopt orthodoxy without thinking. A way to have it both ways is to adopt the idea of modular monoliths and to care about software plasticity.

I really like the Go programming language. It looks a bit funny the first time you start using it, but after a while you get that “ahh, I see”-feeling whenever you discover just how convenient Go is for writing server software. But as in any language there are a few things that are really annoying.

When whatever language I am using as my main workhorse language at the time gets new features I worry. Go is getting generics and I have to admit I’m a bit worried. I think it’ll be fine, but there is always the risk that this might attract a different crowd to Go.

When I see new projects being announced that are implemented in C or C++ I have to admit that I quickly lose interest. I think C and C++ are poor language choices for system software in 2021. Please don’t write system software in C or C++.

Whenever race car drivers serve up excuses for why they didn’t win they tend to blame their equipment, their team or both. It is never the fault of the race car driver that she or he fails to win. It’s the suspension. It’s the engine. It’s the wrong tyres. In many ways, race car drivers have that in common with a certain class of programmers who blame anyone but themselves for their hardships.

During a meeting today someone raised an interesting question about how we vet third party dependencies in software. This is not only a good question, but it pokes at something all programmers are guilty of at some point: including libraries without properly vetting them.

Perhaps there should be something along the lines of a “Dogme 95” for programming. Perhaps there is. I must admit that before writing this I didn’t check. And there is a reason for that (as you will see later).

You may be familiar with the “Dogme 95” manifesto written by Lars von Trier and Thomas Vinterberg. To quote the Wikipedia article: