Blog

As you work on projects, you’ll often find yourself making and keeping notes. These could range from whole step-by-step guides to little snippets. You know that eventually, you’ll be back at this point, and you’ll need this little nugget of knowledge again. I like to encourage people to keep their notes in a public place. In the context of an organisation “public” may just mean internally with others in the engineering team (I don’t literally mean go and post it on X!). You can spend a few more minutes tidying up the note to turn it into a mini “doc” (which is even easier now with AI). Notes are just a manifestation of your knowledge, and this slowly and organically helps you offload your knowledge into a searchable and sharable place. ...

Usually, when we set out to build software, we work from a specification or Product Requirements Document (PRD), which outlines how the software should function from a user’s perspective. This focuses us on the horizon of end-user functionality, and from there, we start working backward, filling in the gaps and building a model of how all of the pieces fit together to deliver this functionality. This might involve database reads, writes, API calls, validation, etc. If all of these steps go well, the user gets what they want, and the application meets its goal. But how many opportunities are there for failure along the way? How many known failures could there be, and perhaps more scarily, how many unknown failures could there be waiting to trip us up? The Pessimistic Software Engineer doesn’t just assume things will probably be okay, but actively assumes things will break, in every way possible, at some point in the future. ...

I’ve recently been experimenting with the idea of creating a generative AI prompt which can build other prompts for specific personas. Sometimes I know roughly what I want, but I don’t really know all of the required detail of how to describe it. For example, let’s say you want to have a conversation with a Large Language Model (LLM) which directs you to Cognitive Behavioural Therapy (CBT) techniques. You might know that this is what you want, but you might not know all of the detail of how to describe this. To do that you’ll first need to know how to write a good, detailed, targeted prompt. On top of that, you’ll need to understand exactly how CBT works and then describe it in terms of a prompt. The idea behind this approach is to use the autoregressive nature of generative AI (text-to-text) to first have a conversation that extracts exactly what you want, amend and confirm what it suggests, and then narrow this down into a prompt template which you can keep and use in a repeatable way. I will show some examples of how to do this with ChatGPT, however you could experiment with the same approach using any other similar LLM provider, or even a local LLM via GPT4All or Ollama. ...

There’s a neat Ubuntu command which allows you to easily import your ssh public keys from Github to your server user account. 1 ssh-import-id-gh <github username> By default, it will append the fetched public key (or keys if you specify multiple accounts) to the current user’s ~/.ssh/authorized_keys file. Once you’ve run the above, you will be able to ssh to your server account using the same key you would use to push code to Github. ...

When I first started learning Go, I heard a lot of people talk about the idiomatic way of doing things. “Sure, that way works, but this is the way we do it in Go.” I’m OK with that - a strict convention can give every piece of code a strong sense of familiarity - and Go has quite a few of these. One such convention is to use short variable names. Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex. ...