For my first job after university, I worked for a company with a ISO9001 certification. This meant that every project had a complete, documented process for every aspect, from reporting, to finance, to bug tracking, to code formatting.

There was even a team whose sole job was to define the template standards and enforce them across all projects. Most people thought they were busy-bodies, meddling with things they didn’t understand. While the team was staffed by people who had started doing project work, most had not done any for years.

I’ve gone through a number of RSS clients over the years. I used to be a big Google Reader user. I used Reeder on my iPad a lot, and now I use NetNewsWire. To ensure that my feeds are shared between devices, I’ve used Feedly. I’ve paid for it, as I use it a lot and I don’t want it to go away like Google Reader did.

But they keep adding stuff that I have no interest in, including jumping on the AI bandwagon. It has, however, been fast and reliable. I don’t have much to complain about.

In a world where everything is owned by a gargantuan commercial entity, RSS is subversive, an act of rebellion. It harks back to the early days of the Internet where freedom and open standards were the future, rather than Big Data, Big Tech, and Big Lock-in.

RSS is a newsfeed than you define. You subscribe to websites and they give you a list of stories to read. How is that different from social media?

Brent Simmons:

I had a bias about engineers that worked for large corporations. I assumed that they weren’t as good as indies and engineers at small companies

I work for a small company and my clients are usually big companies, so I have some perspective here¹.

From my experience, the difference between working for large and small companies is bureaucracy and focus. A tolerance or affinity for these things means that the people attracted to each are different. Normally when we talk about “bureaucracy,” it’s a pejorative, but that’s not what I mean here. Larger companies need more formal process to function. We can save the argument about good or bad process for another time.

Some of the clients I work with have a very collaborative culture. Decisions are always run past all interested parties and buy-in is required from everyone.

The people in charge set the general direction but not how to do it.

I prefer to work for (and with) companies that are like that because, well, my opinion counts! Having the people who know the work the best make the decisions makes the most sense. People appreciate the autonomy and the trust that management place in them.

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.