Matt Quirion

Known to say "Y'all" a lot.

Something about Running

Posted on by mquirion
@daniel.labelle How Different Actors Run. #running ♬ original sound – Daniel LaBelle

I’m a runner. I get to say that because I do run. I’m not very fast, and relative to folks you may know who you think of as “runners,” I don’t run very far or very often unless I’m training for a half marathon. One time a neighbor mentioned seeing me out for a run and having the thought, “That poor guy.” But over the last 2 years I’ve run about 500 miles each. That’s half as much as I’d like, but it’s still about 500 miles more than most. And for the last few years, at least, it’s been about 500 miles run incorrectly.

What’s kept me from getting to my goal of 1000 miles in a year has been the aches and pains associated with running, plus a mid-40s body, plus quite an accumulation of old sports injuries, bad habits, etc… All that and math.

To get to 1000 miles in a year requires overcoming some basic math. Let’s say you can find 5 days a week to run every week of the year. That’s 260 running days. 1000 miles over 260 sessions is about 3.8 miles a session. When you’re a slow runner like me, that means, with stretching and cooling down included, every session eats up about an hour a day. Five 1-hour sessions every week is tricky to come by for a dad.

So let’s say instead I aim for 3 runs per week. 3 sessions x 52 weeks = 156 sessions. 1000 miles completed in 156 sessions is about 6.4 miles. My knees kinda hurt just thinking about it. And while it’s only 3 sessions a week, now I’d be carving about an hour and 20 minutes out for each session. Again, tricky for a dad.

Fast dads don’t have these issues.

Anyway, as I mentioned, the limiting factor for me is really aches and pains. I can probably cobble together the time for 3 to 7 mile sessions over the course of a year to hit 1000 miles. But to get my aches and pains to cooperate is an entirely different matter. Any run, be it 3 or 13 miles, usually requires me to recover for a day or two. Or so I thought.

Turns out I’ve been running wrong for possibly my entire life.

I grew up being told I had a really good running stride by coaches. And it’s possible I did, I suppose, but when you grow up hearing that, and then you move into adulthood as a hobbyist runner at best, you don’t tend to think you need to “learn” much about running. After all, the last time I ran with any hope of winning anything, I was 17. I just wanted to be healthy. You don’t need to obsess over running for to be healthy right? And those aches and pains that develop are all just because I’m getting old and have a lot of old scars, right?

Maybe, but maybe not. My daughter is also a runner – the kind who people look at and go “Whoa, THAT is a runner.” She’s not elite, but she’s good enough that it’s not insane to end this sentence with “yet.” And so we’ve been learning a lot about running lately; How to get stronger for running, how to get faster, how to recover from one event in the late morning so you can run again in the afternoon. Originally I’ve been applying all the learning to my daughter – the one with potential. But after a while I finally started to read and hear knowledge and advice that could be applied to me too: How to run without pain.

Turns out what I thought was my “relaxed” stride is awful. I’m an “over-strider” when I run the way I’ve run for probably 20 years. And over-striding is basically a way of fighting physics every step of the way. Turns out doing that is terrible for things like knees, shins, ankles, and the will to keep running.

A little over 2 months ago I finished another half marathon. I finished with a really disappointing time. Maybe that bit of failure helped me finally accept that I could do something to improve on my running, even deep into my 5th decade of life. For the last few weeks, I’ve been practicing a few new techniques: paying attention to my footstrike, pulling my counter-arm back quickly on every stride, and leaning forward no matter the terrain. And today I feel great. I just ran my fastest 5K time in my dad-life, and while my legs are a little tired, nothing hurts. For the first time in probably 15 years I no longer feel like I’m running simply to slow down mortality. I’m running to get better at running.

Because I’m a cliche middle-aged dude, this entire experience has me wondering what else I’ve been doing wrong for 20 years. Rather than look at it from that negative perspective, I’m asking myself, what else could I still improve on? That and, should I buy a sports car? But while I figure all that out, I’ll keep on running.

Something Different

Posted on by mquirion

I’ve owned this domain and basically maintained some form of “blog” for over 20 years now. And like almost every other blog out there, I’ve been incredibly inconsistent at actually writing anything. I think the issue is that I’m constantly blocked by the false belief that I need to write anything for anyone or any reason other than for myself and because I find it interesting. So now I’m going to just try to use this site to organize my thoughts about… whatever I find interesting enough to cause me to do so.

Sometimes, naturally, that will involve writing about tech or business. But I think other times it might involve things I’m learning about running in my 40s (turns out I’ve been doing it all wrong for about 40 years!). Still other times I might write about making bagels, the best new British espionage miniseries I’ve seen in a bit, or, hell, maybe just a very funny meme.

Anyway, in the spirit of trying new things:

Something I Found Amazing

Apple’s App Store “economy” is now larger than all but the top 16 or so national economies’ GDPs.

Per Apple:

the App Store ecosystem facilitated $1.1 trillion in developer billings and sales in 2022, building on developers’ track record of strong, resilient growth, an independent study by economists from Analysis Group found. The App Store continues to create incredible opportunity for developers around the world, with more than 90 percent of the billings and sales accruing solely to developers and businesses of all sizes

According to World Bank data, that places the value of services and goods in the App Store “economy” just between The Netherlands and Indonesia. Which would make it the 17th largest “economy” on the planet. This is incredible.

Something I Expect to be Useful

Nobody won anything in Succession, but we all win because of this GIF

Plenty has been written or spoken about the Succession finale. Personally I’d been cheering for the Roys’ private jets to all collide with a meteor. I won’t spoil much by saying that did not happen, but we did get what I suspect will be an enormously useful GIF for many tweeting, tooting, and slacking occasions in the near future:

via GIPHY

In our post-ZIRP era, I think we’re going to find plenty of uses for this meme. For example…

Cloud Legos, Not Cloud Jack-of-all-Trades-in-the-Box

Posted on by mquirion

This week Corey Quinn wrote about what the “next million cloud customers” will need from Amazon. In the post, he warns Amazon that if they don’t provide a higher level abstraction of all of their cloud services, essentially pre-architecting industry vertical appropriate cloud architectures that will help get the many yet-to-covert companies onto the cloud, then someone will eventually show up and meet this market opportunity, eventually relegating AWS to the domain of NTT and CenturyLink; vital, yet unknown. It’s a compelling argument. But what if AWS doesn’t build this abstraction, and what if nobody else does either?

In 2003, while helping my CTO decide between buy vs build for a CRM to service our VOIP-startup, I experienced my first real appreciation for just how difficult it is to create a service you can sell broadly to many enterprises to fit their needs. Nothing among the ocean of CRMs we could find matched our VOIP-startup needs in a way that wouldn’t create so many new headaches for us as to be worth the cost or implementation. We ended up building a solution ourselves. The CRM we needed had to fit our particular way of doing business. And our particular way of doing business was our secret sauce – our differentiator.

In 2006, I helped rescue a massive project to modernize a major insurance company’s quoting software from COBOL and mainframes to Java and the Web. Many of the problems they’d run into during the move were the result of one assumption: That the way this massive insurance company did business was somehow separate from the encoding of their processes and policies within that old COBOL code. The result: 100s if not 1000s of bugs where the web-based Java software ran exactly as designed, but not in a way that the company needed it to run. And it’s not like the architects were idiots. Things just got lost in translation. Ultimately, that company had to change the code and itself in order to make it all work together.

In the 2010s, Marc Andreesen pointed out that “software is eating the world.” SaaS finally had an acronym people recognized and understood. And ever since, 100s of disruptive new companies have sprung forth, eating the worlds of many older enterprises who can’t just start anew. There are at least 534 billion dollar “technology” companies. In today’s parlance, a “technology company” is often any company that realized you could do something established companies had done for a long time, but with a lot of software to do it, and find margins the established companies could not. You either are a SaaS, or you’ll be eaten by one.

Corey suggests that AWS could possibly understand verticals in which they do not operate at all well enough to pre-architect these cloud implementations. I’m skeptical, even if it is Amazon. No non-trivial business software today is able to execute at a generalized enough level to be applicable to a broad enough market that it would move the needle for a trillion dollar business. And no software that was so broadly attractive to a large enough market would function specifically well enough to meet any one customer’s real needs. Adoption of cloud abstractions overly generalized by industry non-experts would be corporate suicide.

I actually like Corey’s idea. It’s a multi-trillion dollar idea if you can do it right. Which means that there’s an opportunity to become one of many, many multi-billion dollar companies if you can do some piece of it right. And that’s what I think will happen. Hell, that may actually be what Corey meant all along. If nobody shows up to build the uber-abstraction-layer for all things cloud for all industries, then we’ll get dozens if not 100s of industry-specific, cloud-category specializing players.

A market may well demand a singular uber-abstraction, but there’s such a thing as unmet demand. One of my favorite econ profs in college would jokingly call that an “unyet supply.” (Always love a dad-joke.) And in that vacuum of unmet demand we can build an ecosystem of integrable abstractions. But the enterprises still waiting on the sidelines will need to identify and utilize these abstractions quickly, because the domain of benefits will not only belong to them. 100s of other startups will be able to benefit too.

So… a funny thing happened:

I started writing this post on Wednesday of this week, and as I usually do, slept on it to see if I still agreed with myself the next day. And wouldn’t you know it, something did happen: Smart minds, including Cory’s, got their heads around Cloudflare’s new R2 product.

Here’s smart-minded Ben Thompson to explain part of what this means:

That is one way this could play out: R2 is a compelling choice for a certain class of applications that could be built to serve a lot of data without much compute. Moreover, by virtue of using the S3 API, R2 can also be dropped into existing projects; developers can place R2 in front of S3, pulling out data as needed, once, and getting free egress forever-after.

So R2 proves Cory right, but in a funny way. Someone is showing up to take advantage of AWS’s margins, and provide a kind of modular replacement of S3 by supplying a compatible front-end that enables developers to build much lower cost interop between cloud service providers. Do you have any idea how many times in the last several years I wished I could affordably move a ton of data across CSPs without incurring huge costs so I could take advantage of the relative strengths of each? Anyone want to write a quick ETL that takes advantage of Route 53, Lambda, S3, and Google BigQuery? Now you might be able to without upsetting your CFO.

But this is still not quite what Cory had in mind, at least in his stated thesis. This is no abstraction. Indeed, R2’s API is a copy of S3’s API. You still have to have a good bit of actual knowledge – now about 2 cloud providers! – to get lower cost multi-cloud interop working together in a way that suits you. But it’s still a major step forward for those of us with the know-how. And maybe it’s a small step forward to a future of companies that can provide industry-specific abstractions that cross clouds.

It’s Better To Be Liked

Posted on by mquirion

…it is much safer to be feared than loved because …love is preserved by the link of obligation which, owing to the baseness of men, is broken at every opportunity for their advantage; but fear preserves you by a dread of punishment which never fails.

Niccolo Machiavelli (Author of The Prince and probably a terrible manager of people)

I’m unaware of Niccolo Machiavelli ever trying to lead a team while building a software product, but I’m guessing if he ever tried, he was terrible. Fear breeds loathing, and if you’re loathed, you are not liked. Software engineering teams don’t need to love one another and their leaders, but they absolutely have to like them. And as a leader of a software engineering organization, it’s not just unpleasant for your team to fear you or dislike you. Fear and loathing in software engineering generates a massive productivity opportunity cost.

First, an axiom: Software Engineers aren’t paid to code. They’re paid to think. And to paint with a very broad brush, most of the sort of people who become software engineers tend to think all the time. Next, a definition of what it means to be liked: In a working team, to be liked is to be thought of much like a good neighbor. You trust them. They’re pleasant enough. You may be best friends, but that’s not necessary. You know they’ll return your weed whacker if they borrow it. Most importantly, likable people don’t occupy your mind in a negative way.

Members of teams who occupy the minds of engineers in a negative way are productivity killers. When a team member creates an environment where engineers are thinking about them or their relationship rather than thinking about a technical or business problem, the team as a whole suffers. And that’s a real cost to an engineering team. Engineering members don’t need to spend every waking hour thinking about “work,” but should their mind wander during some personal time, it’s much more beneficial to everyone that it wanders into something technical rather than something interpersonal.

Not only will unlikable people injure productivity for a software engineering team, but they’ll even kill off the teams. Another axiom: “People don’t quit jobs, they quit bosses.” That’s not quite right. People will quit a job because of a bad manager, but they’ll quit a job because the job is bad too. And unlikable people make for bad jobs. So you get reduced productivity by engineering teams while they’re still working for you, and then you get 0 productivity as the engineering team quits on you. All because of unlikable people.

It’s better to be liked. As a manager, it’s vital that your people “like” you, at least in the way I defined earlier. Also as a manger, it’s vital that you have zero tolerance for unlikable people in your organization, whether they report to you or not. Unlikable people are a malignant form of productivity blocker. Be likable yourself, hire and retain likable people, and lead the way towards likability in your organization.

What Automattic Should Do With Pocket Casts

Posted on by mquirion

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

Posted on 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 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.

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.

Posted on by mquirion

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.