July 2021 – Matt Quirion

What Automattic Should Do With Pocket Casts

Posted on July 27, 2021 by mquirion

Last week, I…

Read this piece on the news that Automattic, owners and operaters of the WordPress empire, bought Pocket Casts.
Which caused me to eventually find and read this newsletter item on the same merger.
Meanwhile I also read this piece about Google Reader and how much many of its enthusiasts miss it (myself included).

It got me thinking about what I’d recommend to Matt Mullenweg, CEO of Automattic, if I were running the Pocket Casts product strategy.

What helped the Web grow so massively was the users’ ability to follow links from sites that already interested them to discover other sites relevant to their interests (Curation). Further helping the web’s popularity explode was the ability to search for something that interested a user and usually discover at least one resource relevant to their interest (Discovery). What made people love Google Reader was the ability to “subscribe” to those resources they found useful in case the same site published more they found interesting.

I found it odd that every piece I read about Pocket Casts last week mentioned that it was a well-liked app partly due to its discoverability and curation features. It’s odd b/c I’m a very frequent user of Pocket Casts, and I was under the impression that Pocket Casts makes absolutely no effort toward curation and discoverability. If what Pocket Casts offers for curation and discoverability is in the upper echelons of the podcast world, then the podcast world is in a dire state. Podcasting has dozens if not hundreds of “Readers.” It’s easy to subscribe to any podcast about which you already know. It’s the finding of podcasts that’s hard. It’s a problem that’s basically the inverse of the one web pages had.

WordPress, a platform that already runs 40% of all webpages in the world, should leverage its power to build a discoverability and curation service for Pocket Casts to consume to help people interested in a given subject find new, relevant podcasts. Automattic should aim to make that service so good and Pocket Cast’s discoverabilty and curation UX so delightful as a result that other podcast players seek to use the service as well. And Automattic should let them. Use the service to force other podcast players to adhere to the use of web protocols.

Most every podcast has an associated website of some kind. WordPress should build tools to help with managing a podcast’s RSS feed, tagging episodes, transcribing episodes, and even scanning both the content on the WordPress site and any sites linked on an episode’s correlated “blog post” to better identify context of an episode. Imagine if WordPress could then use a highly-invested user-base to create a way for one podcast producer to notify another podcast producer that their most recent episode actually discusses things from the receiver’s podcast. How great would it be, as a podcast listener, to be able to follow a “conversation” from one specific episode of a podcast to another specific episode of an entirely different podcast even if you didn’t follow the 2nd podcast?

The platforms that are putting “podcasts” (note: if you can’t use RSS to subscribe, it’s not a podcast) behind walled gardens can’t do this. And while those companies may attract huge numbers to their listening platforms, they’re stuck with strategies catering to quarterly reports. Automattic is uniquely positioned to play a much longer game, continuing to help the open Web grow, adding features atop protocols, and eventually, possibly, helping a much larger, true network solve the second problem for podcasts: monetization.

Rotting Gangnam Style

Posted on July 22, 2021 by mquirion

This piece has been making the rounds among tech heads this week, and there’s one key point made by the author that I wish I could make to every stakeholder in every organization on the planet at once rather than having to explain it here and there as I encounter them personally.

The problem with code, in general, is that it rots.

There is no shortage of perfect code in the world. Perfect code is written every day. Probably every serious software developer has written perfect code several times in their career. The problem is that perfect code is temporary. Time ticks away quickly, and the perfection of the code decays. Perfect code is not impervious code.

So why and how does code rot? It’s so frustrating to stakeholders. “We” haven’t changed that code in months, sometimes years! That code was just fine last April! Now you’re telling us it needs to be reworked? What happened? You weren’t even with the company when that feature was built. What did you do?

The circumstances changed. The code’s just an innocent victim. At best it was just over there in the code management repositories silently passing automated tests, or at worst it was running in production on someone’s server, minding its own business, doing exactly what it’s supposed to do: telling some computers to do something exactly as the code commands.

As time passes, the circumstances under which the code was originally written changes, and so the ability of the code to tell the computers to do the right things changes. Particularly in a business context, circumstances necessarily change. Otherwise, the business has become static. A static business is not a business pursuing competitive advantages. A static business is a dead business; Possibly a walking-dead business, but dead nonetheless.

Code in a business context is a codification of how at least some part of that business operates. And so as the business pursues new competitive advantages with stakeholders making decisions both big and small, the circumstances under which the code operates will change. And when I say “decisions,” I mean every decision. Implemented a new notification system? Code’s rotting. Decided to start doing company all-hands every 2nd Thursday of the month? Code’s rotting. Using a new Notion.io “app” to track inbound sales? Code’s rotting. Changed the IPA in the office kegerator? Sorry, code’s rotting.

Further, every other business competing with the business for which that code runs will, themselves pursue competitive advantage. As such, the code’s circumstances change again, no matter what the owning business did. The old code doesn’t work as well as it used to b/c the business has lost some competitive advantage.

Even beyond that, the world in which that business runs changes. Even if the entire industry of that business colluded and agreed to do nothing at all in pursuit of competitive advantage, the code running in all of those businesses will, before long, find that the circumstances have changed. Or the code is now running on a newer version of an operating system. A version made necessary due to security updates and patches so that the operating system runs better. Or a cloud vendor running the virtual machines on which the code is installed has decided that this particular flavor of cloud hosting is no longer a business worth pursuing, and so the code needs to be moved. Either way, the code is rotting, and there’s not really anything anyone can do to prevent it.

My favorite example of “The world changed, and now the code that worked just fine is rotten,” is the Gangnam Style video on YouTube.

In 2014, the video – already YouTube’s most watched ever, and 2 years old – actually broke YouTube as the count for the number of views of the video outran the maximum for the type of field YouTube was using to store that count.

The world changed. The world started to watch more and more videos on the internet. The world couldn’t stop loving Gangnam Style. The code sat, static, and rotted. At the time the code was written, 2,147,483,647 probably seemed so huge a maximum field value that an engineer or product manager likely thought, “by the time enough people are watching videos online at that scale, we’ll have had a chance to re-engineer this.” Woops.

What’s great is that by then, everyone freshly remembered the Y2K Bug – itself a “simple” issue of field type maximums. But YouTube’s rot was different from that. The Y2K Bug was a problem of a very intuitive code rot. Of course decades-old software would run into problems. Of course the code would rot. But YouTube’s rot was because everything about the world changed so quickly. YouTube enjoyed more success. Success breaks things.

Gangnam Style and Y2K are well known, singular examples of code rot, but very similar examples of rot occur every day in every code base. And as every business becomes more and more a software company, every business must account for that rot. While rot is unavoidable, it can be mitigated. I’ll find another 30 minutes to write about how to mitigate the rot some other time. I really just wanted to hammer home the point about rot and get you singing Psy’s biggest hit in your head.

There’s No “AI” In “Software Engineer”

Posted on July 13, 2021July 13, 2021 by mquirion

The last couple of weeks, I…

Listened to the always excellent Postlight Podcast, in which Rich and Paul talked about Code and, specifically, Python. That lead me to…
Re-read Paul’s “Ode to Code,” better known as: What is Code?
And then I shared a tertiary, virtual chuckle with Rich, Paul, and Bill Gates as Bill reminded us all that when it comes to code, nothing much has changed since Bill’s coding days.
Then I read this bit by Ben Thompson over at Stratechery on, essentially, how code kinda helped save ~~the world~~ a lot of the economy.

That alone had me thinking a bunch about the nature of code and what it means for an organization. But then came…

Github Copilot: An “AI” Pair Programmer. A service that promises to help make coding more efficient by providing a very advanced form of auto-complete or type-ahead for programmers. It won’t just suggest terms or variable names. It’ll suggest entire algorithms.

It’s caused quite a stir in the world of code. A lot of digital ink has already been spilled on this topic.

Questions on how well it really works.
Debates on whether it’s the end of programming as a career.
Concerns about the legality of it all.
Investigations into the security concerns it creates.
Curiosity on if it will just make every piece of software into Quake 2.

But one thing I haven’t seen discussed yet is any concerns about what such a tool will do to creativity in code.

Software engineering isn’t “just programming.” Many people who can write code are not strong software engineers. Some folks who can write particularly good code – even genius algorithms – may not be particularly great engineers. As a manager of software engineers, I’ve found that sometimes “great coders” can be a tricky fit for a team. Software Engineers have an ability to build software products that solve problems in a given domain in a manner that makes some facet of life better. There’s a “zoom in, zoom out” nature to software engineering; A need to keep many of the details and the big picture in your head at once. The more zoomed in aspect of a software engineer’s work often involves code. And creativity springs up in both the zoomed out and zoomed in modes of a software engineer’s work.

This “AI” that Copilot represents is not clever. It’s simply not creative. It will often just repeat what it’s already “seen.” It’s really just a regression to a mean based on a massive body of historic coding records. It may never be creative. And while a lot of code writing can get repetitive or rote, occasionally someone finds a creative approach to the most mundane code and eeks out another competitive advantage. I’m not sure it’s particularly wise to forfeit those small moments of “ah ha!” that only ever seem to happen at the crossroads of domain specific knowledge and boredom.

A long time ago I worked for a CEO who would always say, “sales is the lifeblood of a company.” That may well be true. It’s certainly vital. But in the age when software is eating the world, every company is either already a software company, soon to be one, or soon to be killed off by at least one. Software may not be the lifeblood of a company, but it’s almost certainly the nervous system. The software a company runs defines how a company “thinks” and how it executes. Code in that software can define advantages. The advantages may be revolutionary or they may be on the margins. There are many opportunities to find advantages in code. So if software engineers begin adopting “AI” tools that “write code” for them, then those engineers are forfeiting an opportunity for creativity. Any forfeit of creativity is a forfeit of competitive advantage.

There’s sure to be a use for Copilot and its inevitable successors. I don’t really want to write any more code than is necessary myself. But we should tread carefully as we adopt these sorts of tools. We should think carefully about the strategic and competitive costs we may subject ourselves to while adopting tools that promise more efficiency.

UPDATE: This is a nice post showing where/when a “happy medium” between efficiency and lossless creativity might be found. It’s much more “you don’t need to remember this arcane API” and less, “here’s an algorithm.”