Essays on software development with a focus on quality and production engineering. Mostly.
In a previous thread, I covered some techniques to approach on-call shifts and maintain your own well-being. In this thread, I will touch upon the things you can do, as a team, to make your service more sustainable. 🧵 👇
In my career so far (which isn’t that long… but also not that short 😉), I’ve been lucky enough to not be subject to strict deadlines. That’s why I’m always in awe every time I talk to fellow long-time Microsoft employees. A thread! 🧵
A good philosophy to live by at work is to “always be quitting”. No, don’t be constantly thinking of leaving your job 😱. But act as if you might leave on short notice 😎. Counterintuitively, this will make you a better engineer and open up growth opportunities. A thread 👇.
Companies grow, and with them do the software projects that support them. It should be no surprise that larger programs require longer build times. And, if I had to guess, you have seen how those build times eventually grow to unbearable levels, reducing productivity and degrading quality. In this post, I examine how we can leverage the common techniques we use for production services—namely SLIs and SLOs—to keep build times on track.
Last week, I was first-time on-call for a part of Azure Storage. My previous background as an SRE at Google helped me remain calm despite my inexperience. And as we have more first-time on-callers joining soon, I couldn’t resist writing some advice for them. Let’s start! 🧵
Monorepos are an interesting beast. If mended properly, they enable a level of uniformity and code quality that is hard to achieve otherwise. If left unattended, however, they become unmanageable monsters of tangled dependencies, slow builds, and frustrating developer experiences. Whether you have a good or bad experience directly depends on the level of engineering support behind the monorepo. Simply put, monorepos require dedicated teams and tools to run nicely. In this post, I will look at how almost-perfect caching plays a key role in keeping build times manageable under such an environment.
After a very active month of development since the 0.5 announcement, it is time to welcome EndBASIC 0.6! This new 0.6 release is super-exciting for three reasons: preliminary GPIO support in the standard library specifically tailored to the Raspberry Pi; multidimensional array support in the language; and availability of binary releases for the most common platforms. You can dive right in by: visiting https://repl.endbasic.dev/ for an interactive session, reading more about the project at https://www.