Posts

I first came across this metaphor on coding horror. The metaphor has stuck with me, and I find it applies widely. The core concept here is that if it’s easy to make mistakes, mistakes will happen. We are all human, and the “correct” thing to do is not always consistent or obvious. It might even seem to change depending on your context. This is connected to Hyrum’s law, if somebody can do something with your system with enough users they will. We cannot rely on people to magically read our minds about how we intended things to work. ...

When I was a younger man, I lived my life planning. Waiting for the right time to make my moves. And I did, but I didn’t always get it right. Sometimes my timing was wrong. What makes it the right time to do something? What does this mean? Well, at a basic level it can be about your ability to deal with the risk related to the opportunity in front of you. ...

For the past couple of years, a lot of us Software Engineers have spent a lot of our time trying to not get left behind. But where are we going? And what are we being left behind from? The token prediction genie Ever since ChatGPT was released to the world 3 years go, the core functionality behind Agentic coding and LLMs has remained the same. It is a machine learning model which tokenises input, and then produces what the next most likely token is to be. It has a “context window”, so the next token it predicts is within the context of the whole window. ...

We create applications, programs, and to do so we write code. Different programming languages work in quite different ways. But there are generally two ways to slice and abstract application code. You can organise it by grouping domain meanings and processes, or you can do it by grouping implementation details. Organising your code by implementation detail. The dotnet world is terrible for this. You will see namespaces like Your.App.Api.Services and Your.App.Api.Models. And they will be compiled as separate DLLs in this weird flat structure which actually isn’t flat, it’s just not represented in the file-structure in the same way it is in the dependency graph. ...

In a large organisation, it’s very easy to feel like a small cog in a big machine. But the truth is, the only thing keeping you in your corner is you. Engineers who really succeed in these large organisations know how and when to venture out from their little corner. Go and find the most successful, smartest Engineers in your organisation. I guarantee you not a single one of them stays in their lane, in their corner, or in their service in a larger system. ...

After finding myself in surprisingly unfamiliar territory at a new job working on a new domain ins a new programming language to me, I spent a bit of time asking myself, how do I know if this is good code and I should use it as a mental model for absorbing idioms, or if this is code written under some form of duress? Idiomatic code Idioms are important in programming. There are often many ways to solve the same problem, but a language may lean towards a particular solution because of either syntax, the standard library, or good 3rd party libraries and a long interesting history! You can solve the problem in another way, but other developers who come across the code will be confused. ...

I recently started a new job, not only at a new Company, but in a new Technical Domain (Search) which was completely new to me, and on a new tech stack (Java), which was newer to me than I expected it to be. I had done a little bit of Java at university, and my career since then had been in dotnet/C#. But I have been feeling a lot more lost in these Java codebases than originally expected. Both because of the idiomatic differences in the layout / structure of an application, and also because Java seems to be surprisingly more low-level than I was expecting! (n.b. I am not exactly a fan of the typical .NET idioms. I think there are much better ways to structure code. But I have seen the idioms enough to get used to parsing through the garbage). ...

Throughout my career so far, nearly every application I have come across logs far too much, and consistently at too high of a log level. Lots of things which should not really be logs, but rather be either operational or business metrics, or may even be a domain event, are chucked in as a log. Let’s categorise the different things which I have seen logged, and talk about how we should handle them instead. And finish up with what a valuable set of logs actually looks like. ...

In the past when we had ideas and wanted to spread them around, talk about them, discuss them. We would write blogposts. Now, we are influencing a whole new crowd, for better or worse. It’s no secret that the big foundational models are trained with as much data from the internet as they can harvest. The only problem is that this new reader does not feed back, and may not apply as much critical thinking as to whether what it’s reading is right or not. I do believe there are benefits to this though. Maybe we will all be immortalised through our writing as matrix entries in a Large Language Model. If LLMs just do whatever is written on the internet. Then there is a lot of value in publishing good high quality writing on a variety of topics. ...

Not only do I consider learning things one of my hobbies, but I also consider it a cornerstone of my career. Of the many things that I learn about every day, the one which garners the most interest from the widest variety of people is Japanese. I believe that there are some relatable lessons that you can take away from this journey. And hope that given it is a language, and we all use some kind of language (even if not spoken), we can all relate. ...