Last night I took a dive into the Tony Stark “conversational programming” future and asked my computer to build a page that collects the Youtube videos I’ve links and plunks them randomly in a playlist that you can put on in the background for what must be close to a day and a half of viewing. It took about 10 minutes with a little back and forth.

Today I updated the metadata on three dozen posts and pushed it up. The result is Iterative TV. I’m gonna chuck it on in the background and see what happens.

Update the next day: It turns out that it sometimes (often on iOS) doesn’t load the player correctly for no easily discernable reason. So I guess I’ll have to go down the road of creating an actual YouTube playlist at some point in the future.

John Cutler: Productivity (The Clash):

If your company is currently mired in discussions about productivity, realize that this is a proxy discussion for something else. Like many things, it is about power, narrative, and worldviews. It is probably about a clash—paradigm, professional, cultural, or otherwise.

Keep that in mind when you try to address this “rationally”.

It probably will not work.

NZ Tech Rally 2023 was a tremendous success, with top-notch speakers and genuinely useful and entertaining content.

A particular pleasure for me was Adam Howard’s talk titled Fostering a quality quality culture. Adam and I were team mates and I was lucky to see Adam and his team transform Xero’s approach to quality engineering. This talk, and the model Adam describes boils several years of experimentation and hard work in to a succinct, repeatable framework for improving practices by enabling communities of practice inside an organisation.

Adam’s blurb:

Quality is a slippery notion, and not something that can simply be manufactured and measured. In that sense, it’s a lot like culture.

And just as culture is emergent from a peoples’ values and behaviours, quality emerges from teams’ principles and practices.

In this talk, Adam describes a model for shaping those principles and practices in engineering teams that can nurture a culture of quality engineering.

Reliability, constant work, and a good cup of coffee

If you make coffee one cup at time, like a trained barista does, you can focus on crafting each cup, but you’ll have a hard time scaling to make 100 cups. When a busy period comes, you’re going to have long lines of people waiting for their coffee. Coffee urns, up to a limit, don’t care how many people show up or when they do. They keep many cups of coffee warm no matter what. Whether there are just three late-night diners, or a rush of busy commuters in the morning, there’ll be enough coffee. If we were modeling coffee urns in boring computing terminology, we could say that they have no scaling factor. They perform a constant amount of work no matter how many people want a coffee. They’re O(1), not O(N), if you’re into big-O notation, and who isn’t.

Pat Kua: Happiness

Many leaders feel that it’s their responsibility to make their team happy. While having happy team members is an admirable goal, it’s also not the sole focus of leaders. A leader has failed if people are happy, but the team has yet to make progress towards their goal. Happiness can also be elusive. You might offer challenging work, a supportive and friendly environment, compensate well, and someone may still be unhappy. Happiness is a choice; you can’t “make” someone happy.

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”.