Hammatt Blog

In an age of Genies magically whipping up thousands of lines of code based off of some context, your Engineering documentation matters more than ever. Is is more and more easy to do many things, to pump them out. But how do we know we are doing the right thing? The Document The Context Before any solution can be introduced, it’s problem must be introduced. But for a problem to make sense, we must have a shared understanding of the context surrounding the problem. ...

A part 2 to my post on How Does Search Work? Vector Search as a concept is nothing new. We have been projecting data onto planes and querying the distances and relationships in these vectors for decades. But cheap(er) accessability to LLMs has lead to the rapid rising popularity of Semantic Document Search with Vectors. Similar to how Lexucal BM25 search works, Vector Search is also surprisingly easy to grock. Embeddings The heart of leveraging Vector Search technologies for Semantic Search. The Embedding ...

There’s no better way to understand what is going on under the hood than getting in there and trying to build it yourself. So that’s what I’ve done with a Search Engine. This is intentionally simplified and omits many production concerns such as advanced tokenisation, query parsing, compression, and indexing optimisations. Just the core Information Retrieval logic. To get in there and understand what is really happening. Let me walk you through what I have found. ...

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