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.

Via Robin Sloan comes Fabien Sanglards deep dive into the engineering behind the Street Fighter II arcade machine and the graph paper and scissors process the team undertook to ensure all their sprites fit inside the tight memory budget.

If the CPS-1 capabilities were a blessing for artists, it was a problem for project managers. In an era where ROM chips were very expensive, a game was allocated a ROM budget at its beginning which it could not exceed.

Before the CPS-1, remaining within the budget was a simple matter of a division. The number of #sprites allowed to the art team was ROM size / rectangular sprite size. But the free form factor introduced a tracking problem.

In order to make the best use of the capacity we had, we wrote the ROM’s capacity on a board, and cut and paste the pixel characters on the board.*

If there was space left on the board, then there was open capacity in the ROM. So, from there we started filling in the spaces, like a puzzle.

I very much enjoyed this short episde of the Bike Shed podcast where Daniel Nolan talked about why he likes working and fixing up existing software:

I don’t want to just know what a quick fix is or something like that. I want to actually get in. I want to read this, you know, like, an example, like, a gem that won’t upgrade, like, I want to go dive into that source code. I want to see what the source code is doing. I want to figure out the why, you know. I don’t want to just Google for, like, hey, I can’t upgrade this gem. What do you think I should do? So I’ve always been super curious. That’s how I’ve been able to sustain in software development and not really get burn out. It’s what makes me tick.