Ep. #38, Wayfinder with Heidi Waterhouse

Rachel Chalmers: Today I am super jazzed to have Heidi Waterhouse on the show.

Heidi is a technical writer, developer advocate, and world-recognized speaker. Her most prolific writing by volume is to-do lists, mine too.

Heidi lives in the Midwest with her wife, kids, and three cats who like to scream during recording sessions.

I want to point out that wife, kids, and three cats includes an Oxford comma. So we don't actually know whether Megan and the kids like to scream during recording sessions, I guess we'll find out.

Most importantly, for today's purposes, Heidi is the co-author of "Docs for Developers" and the new "Progressive Delivery."

Heidi, thank you so much for coming on the show, I'm so excited to have you here.

Heidi Waterhouse: Oh, it's great to be here.

Rachel: So we've heard of continuous delivery. What is Progressive Delivery?

Heidi: Progressive Delivery is an extension of continuous delivery.

When we realized that we needed continuous delivery to do faster releases and get more value from our work in a more immediate way, that was really revolutionary to say, releasing faster makes you safer, makes your product better, that was astonishing. But we felt like we had left something out, and what we had left out was the user experience.

Every day I log into social media and I see somebody say, "Someone updated my software and it broke my experience."

And that's what we've been calling a jerk, a technological jolt that makes you aware of using software, and frequently, makes you feel unnerved or angry or helpless.

And we think that Progressive Delivery includes the users, and uses them and their information as part of the software development lifecycle.

So we really want to extend what we think of as the DevOps Infinity Loop to have another loop that includes users.

Rachel: You are suggesting that software should be written for humans and not to punish humans? This is pretty revolutionary stuff, Heidi.

Heidi: I know it's wild thinking, but we're right out there on the cutting edge of "Maybe we should be nice to people."

Rachel: And when you say "we", you've got some pretty amazing co-authors on this book. Do you want to talk a little bit about them?

A side note, my goal is to have all of them on the podcast at some point.

Heidi: So I'm working with a team that sort of originated during my time at LaunchDarkly, and it is Adam Zimman, who, best manager ever. And he is now at Heroku and working on teams that help deliver platform as a service, is a way to summarize it.

But he and I have been working together for eight or nine years now, pretty much the same with Kim Harrison. We are working together. She's the project manager of the group.

And I think it's really important for any collective action activity to have somebody who says, "You know, there are deadlines in the world."

So Kim is the person who keeps us on track and makes sure that our message stays consistent.

Rachel: The Dungeon master for your ragtag band of misfits.

Heidi: Exactly, she's the cat herder.

And then we have James Governor who is a founder and analyst at RedMonk. And he's been doing a lot of the like, "Hey, this is a thing that's coming. This is a thing that we can see. Let's talk about how this should work."

And so uniting our powers, we have created a book called "Progressive Delivery: Make the Right Software, for the Right People, at the Right Time."

Rachel: It's very generous of me to plan to have you all on the show because of course when I was an analyst, James Governor was one of my nemesis, and we had a very friendly rivalry going on.

So very magnanimous of me to extend that invitation.

Heidi: Noble.

Rachel: How is Progressive Delivery different from CI/CD? Does it go beyond the human focus?

Heidi: So.

One of the things that we've realized is that CI/CD tools have evolved and we haven't really figured out how we evolve the software development lifecycle to include that.

Rachel: So we did waterfall delivery of continuous delivery.

Heidi: We totally did. We're like, here's our plan for how to do faster deployment.

Rachel: And it's set in stone forever.

Heidi: Right? There's a Gantt chart, man. But we have all of these tools like feature flagging has really exploded in use.

Everybody is using feature flags all the time in their software. And either companies are rolling their own or they're using one of several providers.

But either way, you don't know that you're getting the same Uber experience, the same Google experience, the same Facebook experience, even the same like HelloFresh experience as a person over, because we are constantly testing and evaluating.

And when I say evaluating, I mean like observability. Net promoter score is like, it's not the worst metric, but it's not a great metric, because it requires you to ask people how they feel at a moment in time.

And usually it's when they've had to think about your software and are therefore madly frustrated.

Rachel: I definitely wouldn't recommend the net promoter score to my friends.

Heidi: Exactly, I would not. I'm like, "Ugh, you are asking me at a time when I am angry."

No, what we want to know is high cardinality data, about how many hours do people spend in our software, what are they doing, what are the features they actually use? What are the hotspots?

And some of that comes in from the usability side, like the usability experts in software know a lot of this.

But a lot of times we've been studying people in like a small room with a lot of video cameras. This is not a realistic expectation of how software actually works when they're using it in anger. So we could use all of that instrumentation that we are getting from observability tools and apply it to the experience of using the software.

What's the total like flow time for this particular task? How long does it take to book an airline ticket?

Rachel: This is a real hobby horse of mine because as an investor, what I was taught to look for, and what I always do look for is the moments to joy, the moments to delight.

You know, the great software products are the ones that my friends won't shut up about that transform their process and make them incredibly happy.

I will shout out to Granola, which is my most recent of these, which has completely transformed my workday.

Heidi: What's it do?

Rachel: It's a note taker, and you're like, "Oh, I've already got one of those."

But Granola takes the notes that I would take by transcribing all of my meetings, giving me a searchable archive that I don't have to lift a finger for. It's really elegant.

Heidi: Searchable is such a big deal.

Rachel: Yeah, yeah, for those of us who outsource our executive function to dungeon masters, it's crucial to have an off-board memory.

Heidi: Yes, so to go back to your original question, how this is different than CI/CD, is incorporating the user and also adding the new tools that we have.

So feature flags, AB testing, rollbacks, you know, ring deployment, sunsetting, all of these things, and observability, give us a much more nuanced set of controls for the software that we are giving to people.

Rachel: Give us an example in the wild, what are you seeing out there?

Heidi: So a positive example or a negative example?

Rachel: I'd like both, why not both?

Heidi: So a negative example is you woke up and your Samsung phone suddenly has a bunch of AI on it that you did not ask for and you don't know how much it's listening to you. Maybe you're excited about this.

Rachel: I am not excited about this.

Heidi: I'm not excited about this. I didn't sign up for that, I didn't want that, it was pushed onto my phone, and I can't get rid of it.

I do not have any autonomy in how my phone, which is a cybernetic extension of myself, is behaving. That's really enraging.

But a positive version of this is every time a website remembers who you are and what you want.

So Libby, my personal instance of Libby, there are a lot of things I don't like about it, but it does remember that I want audiobooks first, and it says, "Oh, last time you searched on audiobooks, I will restart there."

Okay, that's super useful, but that's not what everybody wants. There are people who want eBooks, there are people who want to use Libby to place paper holds.

Everybody should get the experience that works best for them.

Rachel: Mm-hmm, why is Progressive Delivery a useful book right now?

Heidi:

I think that right now in our current state, we're realizing that software doesn't have to happen at us. Like software doesn't have to be a thing that comes on a disc and is immutable. It is a conversation with the user, it is a conversation with the software maker.

You want to be able to say, "Remember me," or "Don't remember me," or "Only remember me at this, you know, geolocation," like "Only unlock my phone all the time if I'm at home."

Okay, I don't want to carry around an unlocked phone, but I also don't want to unlock my phone every time I pick it up to check the time.

Okay, that's a conversation that I've had with the software that gives me more autonomy and more power, and I think that the book is about explaining to people how they can empower their users and their developers, and their organization structure to say, "It is valuable to all of us to give people more optionality."

It's not going to cost that much more, it's not like we're doing entire separate streams, we're just flipping a few bits, and that really increases the usability for people.

So the book is about creating a conversation with users. And we get to it through talking about how abundance has helped us, like how compute is cheap and plentiful for most of us.

And autonomy, like how does a developer get to make things and how does a user get to do them?

And alignment, what does it mean to be aligned with the user, to be aligned with your team, to know that you're making the right thing?

And finally, automation. If we have to do everything by hand, it's still very expensive. I'm not scrubbing my clothes by hand.

And in some ways, that's changed how many clothes we own, and in other ways, it's a great savings for all of us because we have more time.

So the book right now is to help people understand how they're already part of the way to progressive delivery, and if they commit, they will get a lot of power and autonomy and joy without a lot of extra effort.

Rachel: I love how human-centered this vision is. I do need a lot more time because you know, staring into my little metal rectangle takes up a lot of my day.

But I love the idea that these conversations are actually a negotiation that they have a concrete outcome, which is a balancing of the needs of the software creator and the needs of the software user.

It's software diplomacy, soft power.

Heidi: Oh, I like that.

Rachel: Instead of software as war.

Heidi: Mm-hmm!

Rachel: Who is this for? Who is the ideal audience for Progressive Delivery?

Heidi: So the ideal audience for the book is people who are trying to figure out what to do next in order to make their software stay relevant.

We're definitely in the Red Queen's race where you have to run very fast just to stay in the same place. And in order to keep your software relevant, it's not just adding more things, it's adding more of the right things.

So we're looking for people who are working in features, working in development, working in deployment.

This book, there will probably be others, but this book is for the software people, so that they can understand what they're making and how to make it better.

Rachel: Who will dislike this book?

Heidi: Oh, this book is going to be honestly super painful for people who already knew this and didn't have a name for it.

That's the thing that we found out right now, is that, it's like, well duh, but you're not going far enough and you're over-explaining, and like how do you do those trade-offs?

And we're like, "We can't talk about the trade-offs until we talk about like how we get there."

And so people who aren't going to like this book are going to be distracted by the fact that we're explaining it in very basic terms. And people who don't like this book probably include people who are like, "I'm so tired of new software modalities. Could we please not?"

Like I was here for DevOps, I was here for SRE, I was here for CI/CD, but I'm just done.

Rachel: It's also got some interesting crossover I find with the modalities of the founder community, in particular, the lean startup and the agile development movement in that customer discovery, user research, moves to the core where it always should be.

It's the process of building an organization that listens to its customers.

Heidi: Mm-hmm, and that's honestly very frightening for people who want a more command and control understanding of software, who, like you said, have a waterfall understanding of like, "We're going to build a task manager, we're going to build tracking software, and I know how tracking software works, we're just going to do it better with AI."

Rachel: For those people who want the certainty of a world where like they know what their next nine months of development is going to look like, are there compensations to moving towards a more Progressive Delivery method?

Heidi: I think there are, and I think what we try to say in the book is like even a little bit of optionality is very useful for your whole team to say like, "Okay, this is the goal, how you get there matters less to me."

It's sort of, I think of it as like microservices. Like I don't care what's inside the skin of your microservice.

As long as your inputs and outputs are reliable and well-documented, I don't care, I just need to consume it.

And so in that way, I think we can say what's inside matters less than the fact that you're giving people more handles on the outside, more ways to use the API, more things that can happen, and they could still be writing a very regulated piece of software and have different ways that it manifests within that system.

One of the things we say in the book is, "This is not the appropriate modality for all kinds of software."

Like Progressive Delivery is really intended for software that does not have external requirements that prevent that kind of rapid motion.

Rachel: Please don't make the software in my pacemaker reactive or responsive.

Heidi: Exactly, and I think, you know, life critical systems are and should not be at the cutting edge of technology.

Rachel: Nuclear submarines are an appropriate site for command and control.

Heidi: Right.

Rachel: Okay, so we've been dancing a little bit around the elephant in the room.

You know, you and I grew up in a world of microservices where like everything seemed chaotic at the time, but we're about to enter a world with a million agentic robots and vibe coders, and everything's about to get even sillier.

What does Progressive Delivery mean for AI? And I guess what does AI mean for Progressive Delivery?

Heidi: I think it's always useful to disambiguate what we mean by AI. If what we mean is machine learning, then it sort of plugs into the observability and understanding how things actually get used parts.

If what we mean by AI is chat interfaces, I think that we have a great opportunity to let people tell us in natural language what they want software to do, and then gather that data up and use it to make software that is more closely tailored to what people are actually trying to do.

I think if we mean AI in the sense of the always six months away, like intuition machine that's just sort of knows what we want, I think that Progressive Delivery doesn't have a lot to say about that because what we want to deliver is something tangible, not something aspirational.

We want to give people real things as soon as we can, and not like in the sweet by and by.

Rachel: But what about the hype curve, Heidi? What about...

Heidi: You know--

I have feelings about the hype curve, and I'm really looking forward to the thing where we level out on AI and we say, "Actually this is a useful tool for a lot of things, but not for everything. And here's where we think it's going to be useful," and continue to improve and iterate on that.

We'll see, I could be wrong. I've certainly been wrong before about technology hype curves.

But I feel like when we talk about AI as just this amorphous thing that is smart, we don't give it enough credit for what it's good at.

Rachel: I think that's exactly right, and it feels like we've done a very poor job of educating users and centering users in this wave of AI.

Your distinction between machine learning and chatbots and the imaginary intuition machine is a really salient one because, you know, there are machine learning and even chatbot applications that are real and compelling and already available.

But when people treat ChatGPT as the intuition machine, or worse, when they treat it like Google, it betrays a fundamental misunderstanding of what these transformer systems actually do.

And I feel that especially for folks like you and me who sort of sit between technology and the real world and try to translate, I feel like we fell down on the job a little bit with this.

Heidi: I think we were pushed aside. I think a lot of us said, you know, the way we're running straight toward this is ominous.

I've seen this before where we get very excited about something and try and put it into everything and then we realize it's only useful for some things. And when I think about how I want technology to be adopted, I want people to consider safety, not just like physical safety, not just data safety, but like the safety of the humans who use it.

Are we building things that are indistinguishable from humans for, you know, vulnerable populations, and Google developers? Is that something that is safe to do?

Rachel: Even, you know, what are we doing to our own future?

I don't want the machines to paint pictures and write poetry. I enjoy painting pictures and writing terrible poetry.

I want the machines to do my tax returns for me. I don't want them to take the good parts of life away, I want them to take the tedious parts of life away.

And the lack of that kind of user centricity in AI is bewildering to me. Why would anybody want the opposite?

Heidi: There are a lot of theories on why it seems so attractive, and I think it's because it's hard to prize something when you start doing it, because you're not good at it.

Like, you know, the first step to being good at something is being bad at it.

That is an extremely painful experience for very bright people, to look at a poem that you wrote and say, "Actually that's quite shit."

And there are some people who are like, "Okay, poetry is not for me," and there are some people who are like, "If only I could ingest all the poetry in the world and then like juice it, and then condense the juice, then I too would be that kind of poet."

Rachel: And you can, you can do that, but you still write a really bad poem, because there isn't a shortcut to attaining mastery. By definition, it's about the process, not the outcome.

Heidi: But have we been rewarding people for that?

Rachel: We have not. No, we absolutely have not. We rely on intrinsic reward.

Heidi: Yeah, but I feel like this is actually like a reflection of where we come from and the people who end up in power in technology is, you know, it's very painful to be bad at something if you're good at almost everything else.

And maybe there is a way that I can use this thing that I'm very good at to catch up to people who have spent years practicing.

Rachel: Says more about them than it does about the good poets.

Heidi: It does.

Rachel: Speaking of writing and being precious and killing your darlings, what parts of the book did you hate cutting out?

Heidi: I had an amazing analogy about how basically dev and ops and users could be like "The Three Sisters" of Native American agriculture.

Rachel: Squash and corns and beans.

Heidi: Right, where the corn supports the beanstalk, and the squash covers the ground so that there are fewer weeds, and the beans provide nitrogen fixing for the squash and the corn, it's a beautiful analogy.

Rachel: Shout out to Robin Wall Kimmerer. Please, could she adopt us all?

Heidi: Yes, exactly, and feed us, it sounds delicious. But we ended up needing to cut that because it wasn't making sense in the context of what we were talking about, and we found some ways to address that, that were equally useful, if less poetic.

Rachel: What are some of your favorite sources for learning about AI?

Heidi: So when I'm learning about AI, first of all, I like to be clear about what I'm trying to learn.

Like am I trying to learn how the model works? Am I trying to learn how it's being applied? Am I trying to figure out how to use an AI tool?

Those are all different things. But I will say that the thing I read most consistently is a hater, I read a lot of Ed Zitron and listen to the podcast.

But as a balance, Kelsey Hightower did a really cool thing about like, "Okay, I'm going to learn AI. What about this is useful because I need to understand."

Rachel: And he did that with Kubernetes as well. Learning in public is such a powerful move.

Heidi: It's so powerful. So that was very useful to me.

But most of the time when I need to learn about AI, what I actually need to learn is which version of AI is the person I'm talking to talking about?

And then are they talking about, you know, it's almost always agentic like, "What if I could make ChatGPT/OpenAI/DeepSource?" You know, what if I could ask a questions like a search engine?

And I think that's an interesting problem. A lot of people are using it for writing, and in fact, I'm giving a talk soon on AI and technical writing, because it is a thing a lot of people consider drudgery, and it seems like you should be able to feed it enough existing documentation and your code, and have it like moosh those up and produce usable documentation.

And I think we're not there yet, but it's possible we could automate a lot of technical writing that is currently manual, tedious, repetitive, you know, all of the toil definition.

But I think that an AI will never understand something, and therefore it cannot explain it.

It can describe it, it can, you know, like vision analysis, it can say "There's a cat in this picture," but it can't explain, this is like that other thing, this is why you need to do that, in this company, we do it this way.

I think that's an important thing to really like grasp is, what am I trying to do, and how does it work for that?

Rachel: I mean, that is the classic power move in tech is taking a step back and saying, "What is the problem we're really trying to solve here?"

Heidi: Mm-hmm!

Rachel: And one of the stressful things about certain foundation model companies in particular is that the problem they're trying to solve is evidently to make their founders very wealthy.

Heidi: Yes.

Rachel: And now we have this enormously expensive tool in search of a problem.

Heidi: And there are so many cool uses. My sister works on the Kaggle project, and she's like, "Oh yeah, it was Kaggle models that helped decrypt the scrolls of Herculaneum where they like used lasers and UV to detect the paint and ink on the rolled up scrolls that had been baked by Pompeii."

Rachel: Magical stuff, just amazing.

Heidi: Right, that's super magic. Like go do protein folding, please.

Rachel: Go and find, you know, 30 more figures on the Nazca plains.

Heidi: Yeah, so there are so many amazing things that we can do with it. I just think that the thing that is easiest for people to access right now is "Make me a limerick about," you know, something.

Rachel: The problem we really need to solve is quenching the flow of bad limericks.

So I'm going to make you god emperor of the galaxy for the next five years. I just like what you stand for, I think this is a great move for us.

What is the future going to look like in five years if everything goes the way you think it should?

Heidi: If everything goes the way I think it should, nobody has to be scared.

I think a lot of the things that I see wrong with the world, both on the macro and micro scales are we're scared of losing our jobs because we're scared of losing healthcare.

Rachel: Mm-hmm!

Heidi: We're scared of electing some people because other people have told us threatening things.

We're we're scared of being deported. I think that fear makes us significantly stupider.

Rachel: Mm-hmm!

Heidi: And I would like to start by making people less scared by providing material needs. And we can tell that there's enough money for material needs if we shared it.

Rachel: Yeah, I'm even more in support of your platform now.

Last question, best question. The podcast is called "Generationship" because I'm a huge science fiction junkie, I know you are too.

If you had your own ship designed to last multiple human generations, what would you name it?

Heidi: I think I already gave you my first pick, but I think that the idea of a generation ship embodies exploration and hope.

And so I would want it to be named "Wayfinder" and to say like, "This is a ship across the Pacific. And I'm not going into the unknown because my ancestors have charted this. But the stars are here to guide me, and I am a new ancestor."

Rachel: If anyone hasn't done the deep dive into Polynesian Navigator law beyond Moana-

Heidi: So good.

Rachel: It is a rich field. The last 30 years, Polynesian people have started to revive some of the celestial navigation techniques of their ancestors.

They're sailing these double-held canoe sailboats from Aotearoa, to Rapa Nui, to Hawaii. It's astonishing. There's books and documentaries about it, it's an unbelievably rich field.

But the idea that these people got on these boats with like a pig and a yam plant, and sailed for thousands of miles, not lost, but following in the footsteps of the people who had gone before them, it's incredibly inspiring.

Heidi: Yeah, let's hope, let's dream.

Rachel: Thank you for bringing that up, one of my favorite topics, Heidi, wonderful to have you on the show. Thank you so much.

Heidi: Thank you.