What is an Authority to Operate (ATO)? - Governance in the military.

Salesforce CEO takes another bold stand on remote work - Another chapter in the no one knows WTF on WFH deal saga: “For my people that’s my message. They need to mix in person and remote together. Our engineers are extremely productive at home. We have lots of people who are extremely productive at home. But there also has to be sales people being productive in the office selling to customers and we need to make it all work."

DevOps Patterns for Private Equity: Technology organization strategies for high performing software investments - Wait, wut? As someone in the Software Defined Slack quipped, this should really be sponsored by Thomo Bravo, Silverlake, Vista, etc.

VMware Introduces Frameworks And Services At Explore Conference To Enable Enterprise Adoption Of Generative AI - Quick analysis of VMware’s AI strategy.

Everyone is Busy: Who Has Time to Transform? - Mark tries to crack the “how to engineer a corporate structure, plan, and incentive plan to actually change” problem of digital transformation. I think the answer is: make small goals that you do on a short (quarterly) basis instead giant, waterfall annual strategy plans. // “My role at USCIS involved a huge transformation project. Our initial mistake was to think of it as a monolithic effort; we were going to make all the agency’s paper processes into digital processes. It would have been better to clarify the business outcomes, which were achievable. We knew we wanted to reduce the amount of paper that moved between our offices; that let us prioritize addressing the parts of the business that moved the most paper. We knew we wanted to be better at detecting fraudulent applications; that clarity let us focus on the types of immigration benefits most susceptible to fraud. And so on for our other goals. With this clarity, we tied the transformation to everyday activities rather than going off and building technical infrastructure as a sideline project."

The week so far, a selection

I don’t really know what “platform engineering” is

Last episode I shared the the email Q&A I had for an article about platform engineering. The finished article is up, much nicer edited than just copy and pasting my email. It’s part of the buzz around the SHIFT conference next week, which I’ll be at, in Zadar, Croatia.

Wastebook

• Always use the cloakroom for your backpack at a museum. No need to carry it around.

• Adding peanuts to soup is a genius move.

• It’s hot all over northern Europe. They are not prepared for this at all. I was in the brand new Berlin airport for several hours and the AC wasn’t up for it. Europe is in for ten years or sweating their asses off for ten or so years until they figure this out. Now is the time to invest in HVAC, cologne, and handkerchiefs.

• If you’re going to use an animated gif in your presentation, you should have it loop for, like, five seconds max. You don’t want it to run over and over for minutes as you talk through the slide. (You know, convert it to an MP4 and then you can tell PowerPoint to just play it once.)

• “The secret to doing good research is always to be a little underemployed. You waste years by not being able to waste hours.” -Amos Tversky in The Undoing Project

• “I knew what time it was by watching TV” Tom Hanks

• Watering the Plants: “I wonder what’ll happen when I get a job I like. Will I keep these hobbies? I’ll have the knowledge, sure, but will I apply it, or go normal Jesse-workaholic mode and just throw myself into the job, ignoring all my previous escapes from reality?” And: “I used to be in the conference circuit and loved speaking all around the world at various user groups, conferences, and workshops. Speaking about tech you are passionate about in front of large, eager groups of strangers is intoxicating.”

SpringOn Tour in London, Oct 12th

If you’re a Java programmer in the London area, you should come check out the free SpringOne Tour conference on 12 October in London. It’ll give you a great overview of the latest in Spring, platform engineering and IDPs, and all that cloud native programming stuff:

I’m MC’ing it and will moderate a Q&A at the end. Come check it out - I mean, it’s free, and better than going into the office that day, right?

Logoff

One day, when I write some kind of book like Confessions of a Tech Marketing Hustler, I’ll figure out a chapter on this: the dissonance between being on the road and then being at home. As she says:

The city looks pretty when you been indoors
For 23 days I've ignored all your phone calls
Everyone's waiting when you get back home
They don't know where you been, why you gone so long

Friends treat you like a stranger and
Strangers treat you like their best friend, oh well

In the enterprise tech life-on-the-road, uh, life, you exist in a spick and span world of daily showers, well cleaned and air conditioned hotels, fancy meals, and smily handshake meetings. You expense everything, and shuffle along in a TV-show-like luxury world. Then you get home, and it’s just like real life. Dirty dishes, kids that need help with homework, exhaustion at the everyday things. This is all “fine,” of course: it’s the ping-ponging back and forth that can make you lose your mind.

This is a thing where, I think, if you know it’s going to happen, you can prevent it from happening. Rather, you can see yourself getting all tangled up during this transition and say “ah! I know what’s happening here - so I’ll stop it.”

Sometime later…

By topic-coincidence, I had lunch with my old pal Robert Brook who’d been on a multi-country train tour recently. He asked about this same problem: how does one deal with the cognitive exhaustion of so many life context switches? I think what I do is this: I make myself be OK with a drop in productivity. That is, I’m happy to “do nothing.”

When I’m traveling for work, giving a talk or having one meeting, I’m basically intensely at work for 2 hours: the 30 to 60 minutes of giving a talk, and making sure I show-up on time before that. You’d think I could fill the rest of the time with, like, writing a blog post (a newsletter?), editing some videos, making some videos. You know, just pull out your selfie stick and excoriate executives for being asleep at the wheel, or some such shit.

But, no. You will not do that. You will not have the brain power or the energy to be productive. The good news, having given a talk, having had a meeting with some prospects, having sat through a five hour EBC, dog and pony…you will have been productive. You will have done your work for the day, and you may space out. You may stare at a Deutsche Bank airport ad and contemplate the failed life.

The same is true for hectic tourism. There’s much advice about how to have a good vacation, how to be a good tourist. Here is mine:

1. There are three types of vacations: going to a beach, going to an event/amusement park, and going to a place (usually a city).

2. When you go to the beach, you do exactly that. You stay in a house or a hotel at most, a five minute walk from the beach. You wake up everyday and, if you’re someone who’s finders can automatically type out the word “productivity” perfectly, without having to do spell correct each time, you will think: “What will I accomplish today? Where do I need to go?” And then, as you figure out how to make the coffee machine work (again), your mind will kick in (rather, slink in), and say, “no, no. You are already doing it. You are at the beach. Productivity is now maxed out. You will either sit here, enjoying your coffee, or you will sit on the beach, enjoying the sun and the water and the sounds. Perhaps you’ll have a hamburger later, maybe a beer, or a cup of fruit if you’re lucky. And then, you come back here and sleep, and then away to the beach again. Golly, my KPIs will be maxed out in no time.”

3. When you go to an amusement park (Disney, Legoland, etc.) there is more “work” to be done, sure. But it’s like being at the airport. You just are comfortable waiting in lines and you sort of space out while you stand there. Do the kids want to eat awful corndogs, terrible fries, and other shitty fried food? Well! Let them! You are hitting your quarterly goals out of the park. You just shuffle along, going to things at whatever time they’re at, letting kids enjoy a tea cup ride or just playing in a sandbox for three hours.

4. When you go to a place, usually a city, there are more options. Your first goal is to get a sense for what normal life is like there. For this, I suggest walking around in a neighborhood, and spending some time in a few grocery stores. Being Just imagine what it’d be like if you lived here, and you had to get kids to school each day, figure out how to hire someone to clean your gutters, but also just sit on your stoop enjoying a fashionable rose, or lager. This is being a flâneur, which is all you really need to do when being a tourist. The second thing to do is to go a museum of some sort. You don’t need to see it all, or even the most famous things, just pick one period to look at. (The Mono Lisa is highly overrated, but all Van Gough painting are, despite their fame, very underrated - you should always see a Van Gough, each one will be amazing, no matter how many times you see it - the Dutch Masters [Rembrandt, Vermeer, etc.] are equally so, but it takes some training: no one likes bourbon or Scotch the first ten times they drink it, but on that 11th time, you think, “ah, I see what’s happening here - er, yes…well…I might just need to try it a few more times to make sure though…”). For example, you could go to Musée d'Orsay and just plan to look at the art deco interior design and furniture. Or the Rodin statues. If you happen to stroll by the other art, how thrilling for you! The third thing you should do is spend an annoyingly long time at a cafe, coffee shops (standard, or Amsterdam-style, I suppose, as your life-style dictates) restaurant, or a bookstore. Even just shopping works. There’s also, of course, nature, but that just seems like a type of walking about aimlessly.

In all of these cases, I hope what you see is that doing nothing is the goal. You can’t waste time if you weren’t looking to spend it wisely in the first place.

And, please, if you’re looking to be productive while you’re traveling for work: don’t do it. You’re just making it harder for the rest of us to look good.

Press Pass

I’m speaking at the SHIFT conference next week in Zadar, Croatia. Here’s some questions they asked me ahead of time for their ShiftMag outlet. I’m not sure why, but I didn’t send the third one in and saved it up for this here newsletter.

(1) Where do you stand in the DevOps vs. SRE vs. Platform Engineering debate?

I guess by stance you mean “are these things different, or all the same thing, really?” I go back and forth on this a lot. The sum total of both is helpful - they’re both giving helpful practices and changes that organizations can follow and make to get better at how they do software.

It’s fair to say that the first wave of platform engineer thought-leadering was harsh on DevOps, but I think that early “DevOps is Dead” take has dissipated.

The platform engineering community is doing a great job of promoting the idea of product managing platforms, the notion of a platform itself. What exactly platform engineering means isn’t exactly sorted out yet. It either means “everything” or it might mean building and maintaining up the developer tools and runtime environment (the platform).

I don’t think we really know yet since the concept of platform engineering is. It’s only like, what, two years old? We can predict what it will be using the old trick of “most things in the future are a continuation of the past.”

I don’t really know if I’m part of the core platform engineering community, so I’ve recently stopped myself from trying to define it. I’m too much of an outsider at this point.

(2) How do you define developer platforms?

I define it mostly as everything above IaaS - what we used to call PaaS. For whatever reason, people don’t like to use “PaaS” anymore, but it pretty much perfectly defines what a “platform” is. I mean, it’s right there in the name of Platform as a Service.

You could also throw in developer tooling like CI/CD piplelines and the collaborative sites/consoles/dashboards developer use (internal developer portals - another category figuring itself out). If those tools are tightly integrated with the platform to make building, deploying, and running the applications better, it’s probably worth including them in the definition of “platform.”

(3) Another hot topic, connected to developer platform is – developer experience. What would you say is good (internal) developer experience and what would some of the killers of DevEx be?

That’s easy to answer but hard to get right. In general, good DevEx is when your developers can get their code to production fast. Of course, it shouldn’t be bad code, insecure, and all of that. Good DevEx should be when developers don’t spend a lot of time on “toil” or work that can be automated instead. Bad DevEx is when they have to file tickets and wait for things.

On the other hand, sometimes you need to do these things for good reasons. You might have compliance and laws you need to conform to or get shutdown by the government. In those cases, you can likely improve DevEx if you know how to apply new tools and ways of thinking to old governance processes, but you might not ever get to the point where developers can deploy at will, multiple times a day. And, you know, I don’t know if I want my bank having that much innovation on a daily basis.

I know this is a kind of consultant-talk, airport book mystical answer to your question, but I’d say the best way to measure developer experience is to ask them “are you happy with how you’re do your job?” And if they say “yes,” you have good developer experience. If they say “no,” you should ask them what could make it better.

I’m not sure I really like the term “developer experience” very much anyway. “Developer productivity” is a little better, but “productivity” is more of a business metric than, like, a human metric. Businesses care about productivity because it means they increase their profit (literally and metaphorically): we can do the same amount of work with less effort than we used to. It used to take the developers and IT four weeks to deploy a new application, now it takes one week.

You can see why productivity can turn into the enemy of an individual: if I’m a profit-hungry business, instead of giving the IT staff three weeks off now, the business ask them to fill those weeks with even more work. And you also probably don’t give them three more weeks worth of pay: you probably still pay them the same thing.

Productivity can certainty help the individual feel like they’re doing a good job, and get a sense of fulfillment. I feel great when I’ve done a lot of work that I know matters. But at some point, whatever effort and change-stress an individual puts into being more productive doesn’t get them much, if any, reward.

But, developer productivity metrics are probably good for measuring if things are in good working order.

(4) And, why do you say they have been a thing for at least 10 years? Why are they in the spotlight now then?

We had Heroku back in the late 2000’s, then Cloud Foundry was based on that, and some other PaaSes and accidental platforms. Companies like Mercedes-Benz, JP Morgan Chase, several militaries, and others have been running platforms like those for 5, seven, ten plus years.

What I like to do in my talks is catalog the practices they’ve learned over those years, what works and doesn’t. I’m especially interested in what very large, usually 30 to 50+ year old organizations are doing with their platforms: how they make it work for thousands of developers. As a community, we tend to dismiss the wisdom of teams like this because they’re not using the next great technology. But, the ways to run a platform are pretty much constant over time, especially in larger organizations.

I think “platforms” are in the spotlight now because most organizations have finished their first round of putting kubernetes in place. It took several years to figure that out and start seeing more use in the mainstream. Once you get kubenetes up and running, then you need to start building a platform on-top of it: you have to add all that other stuff that developer use.

To pick one of the things out of the talk: the most important thing if you want to have a good platform is immediately start product managing it and think of application developers as your customers. Whatever team is building the platform should be talking with application developers all the time (weekly or so) and getting feedback on what works well for them, what doesn’t work, and if recent changes to the platform have improved things. You’d think this is what operations people who run this kind of thing do, but they’re usually more focused on the state and status of the system - if it’s running, if it’s secure, etc. - rather than the usefulness of the platform to developers.

For a more detailed discussion, if you haven’t checked it out already, you should read Jennifer Riggins’ platform engineering report, it’s free thanks to VMware:

I talked with her a couple times for it and reviewed the text ahead of time. You should check it out, I think it’s a good go at trying to nail down exactly what that term means. This month, at least :)

Checked Bags

You know how it is: as an expat, when you go back to the US, you bring back some food, clothes, toys, books (in English), and so forth. Pinto beans are hard to find in The Netherlands as are fresh made HEB tortillas, of course.

This time of year it’s candy corn. Yup: five pounds of it. But also the makings for s’more’s. Country-to-country, candy turns out to be one of the last, unique cultural artifacts of everyday life. And, of course, in the 50+ little countries that is the United States, this can be state-to-state. Anyhow, I heard awhile back that IKEA makes great duffle bags for this kind of thing, the FRAKTA. They pack small, are very sturdy (they’re made from the same stuff as those big blue IKEA bags), and are cheap. Checks out! It works great. Here’s one going from Des Moines to Amsterdam:

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking (get 50% of registration with the code 50-SRE-DAY) Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking. Oct 5th to 6th Monktoberfest, Portland, ME. Oct 12th SpringOne Tour London Oct 9th SpringOne Tour Amsterdam Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

It’s 9pm here in Berlin. I’m speaking at stackconf tomorrow, then I’m off to London for SREday (both above). I’ve been reading Legends and Lattes, and it is super fun!

Confusing outcomes with capabilities

I don’t have this sorted out well, but the baby keeps crawling on me to remind me to chill the fuck out about being a professional thought leader and be more of a professional dad. (That’s right, I’m blaming my three year old for the shoddiness of the below!)

In the technology world, you are taught to think in terms of “outcomes,” or “business outcomes” to use the longer jargon. An outcome is the final effect a technology, decision, or change has. It’s a variation of “the means justify the ends.”

What does this technology help us achieve? Revenue, security compliance, faster app response times, developer productivity, migration, etc.

As ever, things are not cut and dry, but I’d say the two other ways of thinking about a tool are capability and price.

Capabilities are things like “run on Windows,” a general programming framework, a service mesh, a configuration tool, any given open source project…this a way of thinking about the tool as the tool. When you think of technology’s capabilities, you’re not really asking “and will that be useful to us?” Of course, “it works” is an assumed feature.

Price is obvious: it is either more than you want to pay, or less than you want to pay. Or, you know, Goldy Locks. Whether it’s a capability you want or it achieves the outcome you want doesn’t matter: it’s the number you want. For handful of of technologies, price is a feature, but not nearly as much as in handbags, t-shirts, and koozies. In general, there is only one price enterprise buyers want: cheaper.

Anyhow, I wanted to talk about mixing up outcomes with capabilities.

In the infrastructure space, we’re really bad at allowing those two to intermix, even treating them as the same thing, instead of keeping them separate.

To illustrate it: there are very few things that give you the outcome of developer productivity. Even defining “developer productivity” is stacking the deck for what you want to argue. I’ll define it as “allowing developers to do more work, ship more often, and probably be happier.” You could make it too vague and say “create the most business value with the shortest amount of time and cost.” As it says: productivity! This usually means removing toil from developer’s day-to-day lives, automating/eliminating manual reviews and meetings, speeding up onboarding (getting faster laptops and test labs), and automating as many things as possible (tests, building, deploying, monitoring, managing). MY DEFINITION IS NOT GREAT, MOVING ON.

(There is another thing we do too much in marketing and that is to think about “developer productivity” as a business outcome which…it could be…but I don’t think most businesses are that sophisticated in how they think about their software strategies. For example, if you’ve historically outsources your custom programming, you’re probably not sophisticated enough. In contrast, as I learned in a recent DevOpsDays talk, John Deere does look at its software factory as a core function so they can think of developer productivity as a pure business outcome. ANYHOW.)

Here is the problem: when you sell, evaluate, use, or otherwise think about a technology based only on its outcome. Us marketers are especially bad at this. Have you ever seen a pitch about some infrastructure technology that starts off telling you about macro economic headwinds and, like, software is eating the world? Chances are you’re thirty minutes to never away from hearing about the actual technology, what it does, and how it works.

The OpenStack era of cloud was rife with this. So many pitches started off saying why cloud was important (cloud or die!), explaining what cloud was, and then that it would help you achieve all sorts of outcomes like agility and moving from capex to opex.

I know it seems like I pick on Kubernetes a lot. And…yes, I do - I have mixed feelings - but, it’s also a recent phenomena we all know. Throughout it’s history, a lot of chatter about Kubernetes has focused on the outcomes it achieves: better cost control, developer productivity, etc. As it turned out, Kubernetes doesn’t really directly give you those outcomes: it’s just part of an overall stack that helps you get there.

Sure, it’s linked. But contrast that with the capabilities of an IDE. If I right click on a chunk of code and say “refactor this code to its own method,” that directly addresses productivity. Most of what an IDE does has the outcome of developer productivity. You know this because you can look at the alternative, a text editor, and see that developers are so much more productive with an IDE.

Now, you could say that Kubernetes gives operations and infrastructure people capabilities…“ops productivity,” and I would say - YES IT DOES (though, now that I look at the chart below for the thousandth time, ops productivity seems to be going in the wrong direction year/year? You see, I haven’t really looked at this chart in terms of operational productivity, just developer productivity.):

Operations people work directly with Kubernetes to get the capability of “install a shit-ton of containers on this cloud thing I setup and obey the configuration governance and policy and have all the processes in those containers talk with each other over the network like this. Oh, and, like, be secure?” The alternatives may not be as good, or as fast, or as reliable.

But Kubernetes itself doesn’t give a shit about application developers. For application developers, it offers a blinking cursor as if to say, “worked fine in ops, dev problem now.”

This is fine! This is what was intended! (Along with Google and Red Hat, et. al., neutralizing AWS’s competitive advantage in IaaS.) The Kubernetes thought-leaders have been trying to tell us this all along:

Kubernetes can certainly be part of a stack that makes developers more productive, but that’s not really a core thing it does. So if you’re thinking in terms of kubernetes as developer productivity, you’re at risk of mixing up outcomes and capabilities.

Things get a bit loopy here - there’s a needling distinction between being part of an overall stack that gets you come outcome (Kubernetes and developer productivity) versus directly creating that outcome (IDEs and developer productivity).

The closer the outcome and the capability are, the more accurate your thinking will be.

Another problem with thinking only about outcomes is that you can’t evaluate it against alternatives. When Puppet, Chef, Ansible, and Salt were going at it, they all wanted to deliver the same outcome. Competition came down to which had the capabilities to do it better, more reliably, in a way ops people liked, and (I assume) price. If you were talking about any of those in terms of outcomes, it’d have been largely a waste of time.

Outcome marketing is best for enterprise sales

In technology marketing and sales, there’s a relationship between the price of the technology, the seniority of the decision maker (whoever approves buying the technology), and how outcomes focused you are. As you can guess, the higher the price, the higher decision maker in the organization, the more you focus on outcomes:

(1) With rare exception, the senior executives approving purchasing something don’t have time to care about how the technology actually works, or evaluate it versus alternatives: they just have to build up a hunch that it seems like it’ll get them the outcome that they want.

(2) And, if you have a high price, you’re going to need a senior executive to approve the budget, so you’re pitching to senior executives, and then see (1).

If all you hear is capabilities talk, the pitch is intended for an individual way down the org chart. If all you hear is outcomes talk, the pitch is included for an executive, way up the stack.

SpringOne Tour is coming up in Amsterdam, October 9th, 2023. I’ll be MC’ing it. I live here, after all! It’s focused on - surprise! - the Spring Framework and programming:

Our Spring advocates, technical engineers, and application development experts bring an in-depth look into the beauty of open-source, with Spring Framework, Spring Boot 3, Kubernetes, Progressive Delivery and more, to strategize with you on how you can innovate faster.

It’s free to come and the content is great, so register and come check it out.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking (get 50% of registration with the code 50-SRE-DAY) Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking. Oct 5th to 6th Monktoberfest, Portland, ME. Oct 9th Spring Tour Amsterdam Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

I’ll be in Berlin and London this week. Whacky!

In Iowa

I was in Des Moines this week to give one of the keynotes at DevOpsDays Des Moines (it went well). Here’s some snapshots from around town:

CEO Therapy

This week’s Software Defined Talk:

This week, we discuss Netflix's DVD deprecation, the remote work debate, and how to fork an open-source project. Plus, thoughts on why Europe needs more ice.

Have a listen!

Transcripts

For all the podcasts, videos, conference talks, and even notes to myself: I haven’t figured out what to do with automated transcript systems. It’s nice to have text, but the work involved in doing anything with feels almost as high as starting from scratch.

I’ve done hundreds of hours of video and podcasts over, like, 25 or 30 years. If I got actuate transcripts, I’m not sure what I’d do with them. When I do an hour interview with someone, you’d think getting a transcript would be useful.

You’d think that passing it ChatGPT to write an article would be useful. First, ChatGPT can’t handle that amount of text (at least, I don’t know how to get it to). Second, the result requires a lot of editing. Over that 30 years I’ve trained to become a good writer: I’m good at going from a blank screen and getting to 500, 1800, or many more words.

Maybe transcripts are not so good for writing, but they do seem good for:

• Voice Notes - I’ve never been a big user of voice notes. But that might actually be helpful. I’ve been it more than ever recently, and like many quips about taking notes, the value isn’t really in the note itself, but in using writing as thinking.

• Also, dictating writing might be good, but typing is so much faster and you can edit and correct as you go.

• I do read transcripts of other podcasts when I don’t want to listen to them, that’s fine.

This is a free report from Jennifer Riggins at The New Stack. I talked with her a couple times for it and reviewed the text ahead of time. You should check it out, I think it’s a good go at trying to nail down exactly what that term means. This month, at least :)

Wastebook

• “Survival is optional. No one has to change” is cold comfort to the employees of companies that didn’t survive. I wish we’d spend more time in the “digital transformation” world focusing on getting people to change, not just tell the survivors how awesome it’ll be once they change.

• Remember the positive feeling that you could be fine taking actions to do things instead of focus on your own hobbies. Working on your life instead of vague FOMO.

Relevant to your interests

• VMware Expands Tanzu into a Full Platform Engineering Environment - Overview of our take on platform engineering, product-wise.

• Dangerous Dimensions: Mind-Bending Tales of the Mathematical Weird - Looks like fun, right?

• HashiCorp Retools Licenses And Software To Grow Its Business - Extensive look into the HasiCorp financials and talk of their OSS licensing shift.

• The Works of Mars, 1671 - Fortification engineering.

• Here’s Something Past Its Expiration Date: the Expiration Date Itself - “Food experts broadly agree that the expiration dates on every box of crackers, can of beans and bag of apples waste money, squander perfectly good food, needlessly clog landfills, spew methane and contribute to climate change.” // And, they’re gone for the most part in the UK.

• Texas’s Biggest Barbecue City Is Attracting a New Crop of Exciting Restaurants - Lots going on in Lockhart.

• Favorite coffee-making setups from the Ars Technica staff - I made coffee with a Chemex for a few years. The coffee was good, and the overall ritual of it was just fantastic.

• Books Recommended With Uncommon Wisdom and Tender Care - “Over and over, Aoyama demonstrates how it’s done. In her Hatori ward, good fortune is not arbitrary or unearned; it is never a gauzy gift from the universe. It arises instead from action, experience and wisdom. Her characters appreciate each other; they are grateful to each other; they recognize in each other quality and potential. (Put these folks in a laboratory dish with the dramatis personae of a cynical HBO show and they’d annihilate each other, matter and antimatter.)” And: “You’ve got to be careful with novels about libraries and bookstores… The risk, in all these cases, is flattery. It feels nice to be assured that the places you find appealing are, in fact, wonderful. It’s also boring. The standard for such novels, therefore, is that they reveal something interesting and true about these environments.”

• It’s Not You, It’s Me: What It Really Means When Budget Is The Reason For The Breakup - Something that’s not useful isn’t worth paying for.

• Forrester’s Impressions: VMware Explore 2023 - A brief overview of VMware’s strategy and where Forrester thinks it going.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking (get 50% of registration with the code 50-SRE-DAY) Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking. Oct 5th to 6th Monktoberfest, Portland, ME. Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

Des Moines, 7:38am

I’ve got a lot of travel coming up - like the old days! Two more weeks of long trips.

More importantly, it’s the start of the school year for my three kids. You’re supposed to look at actual New Years as the start of a new cycle, but the school year has always been the beginning of the cycle for me, back to when I was kid, college, and even when I was kidless for a long time. It’s a time to start new habits, especially when it comes to parental pedantry. But, the structure of the school schedule also clear out all the time-wasting that comes with schedule ambiguity and openness. I was told once that I thrive in structure, which seemed right at the time, despite the chaos-driven nature I can seem to have: that’s just my writing and content style, though.

HashiCorp Retools Licenses And Software To Grow Its Business - Extensive look into the HasiCorp financials and talk of their OSS licensing shift.