Software Engineering

The pace of the frontier seems to be picking up rapidly over the last few months. Most mornings I’ll wake up and check my phone and there’s been another breakthrough overnight and the new best model has changed yet again. One thing that’s usually quite common when a new model is released is the provider will often show off the new benchmarks, highlighting their higher numbers compared to some of their other models or competitors. I feel like this act of showing off the benchmarks all the time is drumming into people: “This one is the best, you need to use this one, and if you don’t, you’re missing out.” However, if you’re doing a task that doesn’t require a high level of intelligence, switching up the model tier will often result in either marginal or no gain at all, but it might result in you paying more for effectively the same output. ...

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