All Posts

Why do Formula 1 car pistons cost around 1,000 times the amount of a typical road car piston and what can this teach us about programming?

There are a lot of different technologies out there. More than anyone could possibly explore. The de-facto position is to look for technologies that are popular, following the logic that “if enough people like it, it must be good”. In my experience, this isn’t always the case though.

I’ve been reflecting on ‘what makes a good engineering assessment’, and I’ve come to the conclusion that a good assessment – as part of recruiting – should pay careful attention to three main things.

It’s no secret that testing is important. We rely on tests to describe intended behaviour, catch any subtle bugs and prevent regressions in our code. But why are tests always such a pain to write well?

The qualities we do look for are probably considered unusual compared to most software engineering outfits. Let's take a look at the three we use to ensure a good fit for working at Shamaazi.

I hate the word ‘utility’. It says absolutely nothing. And yet, I come across it in so often when programming. It can take different guises too: ‘common’, ‘shared’, ‘lib’, ‘pkg’, ‘tools’, etc. These names can appear both as filenames or as directory names and drive me insane when they do.

Here are the three React Hooks I have found the most useful for producing websites in the cleanest, simplest way possible. They manage localStorage, sessionStorage, authentication and asynchronous tasks.

I've written production code in a huge variety of languages, through Haskell, Scala, Go, Python, Java or JavaScript. Across all these, I noticed one significant trend: I pretty much never use the ELSE statement. Here's why.

Programming is all about communication. And yet, communication is a difficult thing to get right. Here's why it's so important, and how to communicate better.

Programming can be an arduous activity. You have to remember what you are doing, the context and inner workings of a system, the building blocks of the language you are using. All while coming up with creative solutions to problems. All this can lead to COGNITIVE OVERLOAD. Luckily, there are some simple steps we can take to avoid this.

At Shamaazi, we found the existing Go libraries for logging overcomplicated and not neatly doing what we wanted. Instead, we wrote our own. Here's why.

I've continually made this same mistake with reference data. It's a mistake that's incredibly common, and easy to avoid. Here's the simple trick I've found.

A common mistake is to test every piece of code you write. This can be harmful and unnecessary. Let's explore why.