I wrote my initial thoughts about the Switch 2 announcement a couple of months ago. Against my better judgement, I pre-ordered one. What follows are a few thoughts about it now that I’ve had my hands on one for a couple of weeks.

The best summary I can think of for my initial impressions is: consider the name. The +1 label neatly captures both the good and the bad. It’s a better Switch. Faster. Higher resolution graphics. Generally… just nicer. It’s not a game changer (pardon the pun), but not everything needs to be revolutionary. Nicer is good.

In this piece, Seth Godin argues that understanding something is better than just memorising a process. Understanding is certainly key, but I think that misses something: there is value to in steps.

True, if you slavishly follow the steps, you can’t adapt. But if you don’t document the steps, it’s easy to miss one and get yourself into trouble. The challenge is knowing when to follow the steps and when to improvise.

The clue is in the name. Rather than a significant break from the past, the Switch 2 is an iteration. Bigger. Faster. Better. But not a revolution.

That’s not a bad thing. Why break with a successful formula?

I’m not a big gamer. In fact, the Switch is the first console I’ve bought. Let’s take a quick tour of the original, eight year old Switch and see what it got right and wrong.

Last time, I talked about setting up my Pi Pico by soldering on the GPIO pins and wiring up an LCD screen. Having something work is obviously no fun. I need another challenge.

I decided to update the display to show the current temperature. I’d read that the Pico has a built-in temperature sensor, so how hard could it be?

I quickly took the sample code from the Pico website and plugged it in. It ran first time, which is quite impressive, and said that it was currently… 10º.

It’s been a productive weekend, at least if you consider doing unnecessary things productive.

For reasons that won’t become clear any time soon, I decided that I wanted to get some of my Arduino components working with my new Raspberry Pi Pico. Like the Arduino, but unlike other Pis, the Pico is a microcontroller. In practical terms – for a programmer at least – this means it doesn’t have a “proper” operating system like Linux but it does have lots of inputs and outputs, both digital and analogue.

In my day job as a consultant, I often joke that “it depends” is my default answer to any question, much as Ben Goldacre made a catchphrase out of “I think you’ll find it’s a bit more complicated than that.”

I’m here today to tell you that it’s both absolutely true, and not at all true.

The truth is that, given a complex problem, the correct answer almost always is “it depends.” Without knowing all the constraints, all the things that have been considered and rejected, and all the things that affect the solution, it’s vanishingly rare that there is one, objectively correct answer that you know from the top of your head.

I don’t blame him, but Ian Dunt started his column last week with this:

Somewhere along the line, technology went from something hopeful to something threatening.

Given the continued overreach of the trillion Dollar companies (Meta, Alphabet, Apple, Microsoft, Amazon) this is understandable. Whether we like it or not, these companies have an outsized influence on the technologies we use. Their success allows them to push into even more niches, from your phone, to your watch, to your speakers, to your car, to your fridge. When they collectively decided that AI was the next big thing, they subjected us to it, whether we wanted it or not. These companies farm your personal information so they can sell advertising¹, and obscure what they do to make it impossible to opt-out or give informed consent.

You know that thing were you’re trying to debug a problem and you just know that you’re the culprit, that past-you did something stupid, and you just can’t figure out what?

Welcome to my day.

Anyway, I’m documenting my stupidity so you don’t have to suffer as long as I did.

The background: in order to debug an application that runs on a cluster can be a challenge. The way I tend to do it is to run a server in debug mode in my IDE and connect to that same server using a client. The server is super-simple:

The background story: I’m preparing to deliver a training course. Each module of the course is in a different PowerPoint deck and, once I finished, I need to export each of them as a PDF to share with delegates. There are about twenty modules so doing this wouldn’t take that long but I would probably consider using the word “mind-numbing” to describe the process.

In hindsight, I’m not sure that writing VBA code to automate it was significantly less mind-numbing, but I’m sharing it here so you don’t have to.

Apparently US regulators are considering what to do about WiFi phone callson planes. Their rationale is that many passengers think that people making phone calls is annoying.

But is that the real reason? If airlines were worried about passenger comfort would they allow the seat-back satellite phones? Is the difference here, perhaps, that they can charge a lot for calls? (Kind of another net neutrality debate, but at 37 000′.)

Similarly, if customer comfort was a priority, surely we?d get more leg space. And better air. And fewer jerks that sit in front of you and recline the seat immediately after take-off.