What Automattic Should Do With Pocket Casts

Last week, I…

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

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”

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.

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

We Don’t Need Commutes. We Need Rituals.

I love it when I see, hear, and/or read the same themes in seemingly very different contexts. I don’t know if it’s the Baader-Meinhof Phenomenon at work or just something like it, but I’m sure it’s because something’s on my mind that I notice the same theme everywhere. Young people in love see themes of love and romance everywhere. This week I keep seeing the theme of how to get yourself in the right place mentally to be productive towards personal and business goals. C’est la vie.

Last week, I…

  • Listened to the After Hours podcast discuss “Old Habits and New Rituals.”
  • Listened to Thirty20Eight podcast discuss “Disney Ritualogy.”
  • Read several different articles and columns on post-pandemic commutes and a return to the office.
  • And read this review of a documentary about Anthony Bourdain.
  • I even re-watched this absurd video where the CEO of an office leasing company claims that those who would prefer to keep working from home are the least engaged. Gosh. I wonder what could have incentivized the CEO of an office leasing company to argue that working from home is bad.

A few of those things are not like the others, but in my mindset they all have to do with what we mean when we talk about getting back to normal in a post-pandemic world. We’re talking about getting back to feeling more human. To feel more human, many of us want to get to a place where we feel productive. To do that, we don’t need offices. We don’t need commutes. We need schedules and habits. We need rituals.

People will create a ritual for anything if given the opportunity. As Bourdain often illustrated in his writing and on his shows, everyone on the planet creates rituals around food and eating. Some say a prayer. Some have preparation rituals. Some have certain kinds of foods they eat for certain occasions. Fans of theme parks have rituals (often involving food!) that both expand their enjoyment of the parks and prepare their minds for returning back to the real world. Athletes do seemingly nonsensical things to prepare for a game or even a single play.

Basketball superstar Michael Jordan wore his North Carolina shorts underneath his Chicago Bulls shorts in every game; Curtis Martin of the New York Jets reads Psalm 91 before every game. And Wade Boggs, former third baseman for the Boston Red Sox, woke up at the same time each day, ate chicken before each game, took exactly 117 ground balls in practice, took batting practice at 5:17, and ran sprints at 7:17. (Boggs also wrote the Hebrew word Chai (“living”) in the dirt before each at bat. Boggs was not Jewish.) 

It’s no surprise that though most of us probably hated our commutes when we had them (for good reason), some of us now miss them, as we basically converted them into rituals in preparation for a productive day.

Commutes aren’t the only rituals we “lost” recently. Remember “Must See TV?” Linear, scheduled TV viewing has cratered in an age of on-demand streaming services. Many series release an entire season or more at the same time. As a result “binge-watching” is extremely popular. As many as 72% of Netflix’s customers consume shows via binge-watching. We don’t attend religious services nearly as often as we used to. Almost 70% of America did that at the start of the century. In just over 20 years, only a minority of Americans are active religious participants, attending services weekly or more. And thanks to smartphones, the vast majority of us have an always-on, constant source of distraction from “the usual.” We don’t consume news every evening from 6 to 7pm before Jeopardy. We get pinged and distracted by news as it breaks. We don’t “need” the Sunday paper anymore. Though now that I think about it, maybe we do.

Rituals (and schedules) are a way to mentally anchor oneself in an otherwise chaotic world. As exhausting and, uh, “kinetic,” as it may be for their parents, our kids have a nightly bedtime ritual where they read after prepping for bed to hopefully help calm their minds. On Fridays, during the pandemic, we have “takeout Fridays” as a dining ritual to mark the end of a work/school week and the start of a weekend. In my entire childhood, I only remember one time that my father skipped a daily run. It was so surprising, my sister and I thought he may be gravely ill. We used to think he ran every day for fitness, and he probably did, but now that I’m also a dad, living in an even more chaotic world, I realize he also did it as a matter of ritual.

I’d always naturally resisted rituals. As soon as I could get away with it, I’d stay up late and never keep a steady bedtime. When we first married, my wife had to adjust to me constantly coming up with new things to try to cook for dinner rather than having a set menu at the start of the week. In my 20s, as I adjusted from a youth full of coaches and scheduled athletic practices, I exercised, but it was anyone’s guess if I’d exercise in the morning, the evening, or possibly even at 11pm. Didn’t want exercising interrupting something like getting a beer with friends. Unsurprisingly, my lack of ritual often led to me skipping an exercise session.

I’ve come to understand how much I need rituals. I had it backwards in my 20s. I should have been worried about not letting “life” interrupt my rituals. I find that scheduling things at regular intervals and knowing what’s coming (even with food!) helps my mind function better. I don’t get bored (well, okay, maybe I do with some of the food). Instead I don’t get as exhausted. And my head is free to think up things that are useful rather than worry about reacting to every little thing in life b/c I didn’t plan for it and didn’t put some rituals around it.

I often tell members of my team that if they want to get something done, schedule time to do it. It’s so easy (particularly at the office, ironically) to just “plan” to do some work with a coworker or 2 whenever the moment is just right. Then 3 weeks go by, and much to everyone’s shock and disappointment, that thing everyone was meaning to get to never got done. Often it wasn’t even started.

We humans are creatures of habit, but we’re also creatures of adaptation. We don’t need commuting for a ritualistic anchor. At an evolutionary scale, commuting is a blip of a phenomenon. We need new rituals – rituals that won’t make us and the world more miserable. Find new habits. Start the day with a cup of the same coffee as every other day. Or hell, start the day testing a new kind of coffee every day. Take a walk every day before lunch. Doesn’t have to be long.

I need new rituals. I want to organize my thoughts. I want to continue getting more fit. And I want to golf more, so I’m going to schedule time to do all that. I’m going to set aside time every week to write and structure what I write about in order to use constraints to breed creativity. I’m going to run another half marathon so that I have to work with a training plan. And… Somehow I’m going to find a way to schedule golf. Or maybe to schedule time at the range. Or maybe just putt around in our playroom every evening after dinner. The golf one might be tough.

Anyway, welcome to my writing ritual. Thanks for reading.