On-call at any size is a great primer for orgs thinking about upping their resilience and reliability game. Will Larson’s Incident response, programs, and you(r startup) is an essential companion piece.

Simon Willison pointed to this comment on the orange website last week and it struck a chord with me:

So far I also survived:

• xml is the future
• let’s use nosql for all the things
• you must use the same language at the back and front
• yes, you site must have an AMP version (ah, you forgot this one, didn’t you? It was sooo imporant, and then pouf, it was gone like tear in the rain)
• you can’t code anything without async
• yes, your home page must be an SPA
• you can’t live without a message queue
• everything must become a micro service
• of course you need a container for that
• of course you need a orchestrator to organize those containers
• of course you need the cloud, it would be crazy to deal with those containers and orchestrators yourself
• dude, why do you have a server? Use a serveless backend!
• dude, why do you have a backend? Just call saas from the edge!

Every year, some generation of engineers have to learn the concepts of “there is no silver bullet”, “use the right tech for the right problem”, “your are not google”, “rewriting a codebase every 2 years is not a good business decision”, “things cost money”.

In April I posted about finishing up at Xero after almost ten years. At the time I expected to be on the pro-leisure circuit for at least three months, but I came across an intriguing role at The Co-operative Bank, and I’ve been the Head of Development, Testing & Security for the last four weeks.

Honestly, it has been a bit of a whirlwind. There is much to learn about the bank, the people, banking in general, and challenges of building software keeps customers and their data safe but also easily allows them to access and manage the banks services. I’m having a gret time.

Johan Abildskov presented Automation is Hard! at GOTO Copenhagen in 2022 and it popped up in my feed while I was on the pro-leisure circuit.

If you’re on board with the practices discussed in the likes of The DevOps Handbook and Accelerate then it might be a little bit preaching to the choir, but if you’re still figuring out how to improve the stability of your software and the speed at which you deploy it, this is a bloody good talk.

The blurb:

Automation is a key part of any efficiency project and of being a successful software organization. But the way we as an industry approaches automation hinders our success and puts a stop in our track.

In this talk, I will cover some of the ways we set ourselves up for failure, as teams, orgs and engineers. Of course, you will also leave with a few sound practices to address the issues presented.

Doom Emacs is “a configuration framework for GNU Emacs tailored for Emacs bankruptcy veterans who want less framework in their frameworks, a modicum of stability (and reproducibility) from their package manager, and the performance of a hand rolled config (or better).” Why it’s named Doom is explained in the FAQ:

As a kid in the Cretaceous period (1999), the source code of idsoftware’s classic Doom was my first exposure to programming. Totally clueless about C and compilers, all I could do was peek at it from time to time and hope I’d absorb its secrets if I stared hard enough. It didn’t work, but it sure jump-started by gamedev addiction.

So “Doom Emacs” was what you got when you combined childhood, demon-carnage nostalgia, terrible naming sense, and the sneaking suspicion that Emacs is the unwritten tenth circle Dante censored for humanity’s protection.

The results of the 2023 StackOverflow Developer survey are up. Nearly half of professional devs are using AI to help them write code.

This great talk from by Todd H. Gardner at NDC London 2023 is a great reminder that we need to be deliberate about assessing what code we allow to run on our websites. My favourite bit is Todd’s realisation that he set out to make a useful targetted debugging tool and accidentally made “cross site scripting as a service”.

Here’s the blurb:

How much JavaScript is on your website? Do you know what it does? No really, have you looked at the code and seen what it does? Probably not.

JavaScript controls the client side environment, and we can use it to compromise users, consume resources, and steal data. Yet many websites continue to add scripts without review, audit, or thought.

Let’s explore what JavaScript can do to a browser, the vectors that JavaScript can get added to websites, and how we can defend against JavaScript attacks.