Screaming in the Cloud - Episode 74 - Podcasting about Podcasting with Richard Campbell

Episode Date: August 21, 2019

About Richard CampbellRichard Campbell wrote his first line of code in 1977. His career has spanned the computing industry both on the hardware and software sides, development and operations. He was a co-founder of Strangeloop Networks, acquired by Radware in 2013 and was on the board of directors of Telerik which was acquired by Progress Software in 2014. Today he is a consultant and advisor to a number of successful technology firms and is the founder and chairman of Humanitarian Toolbox (www.htbox.org), a public charity that builds open source software for disaster relief. Richard is also the host of two podcasts: .NET Rocks! (www.dotnetrocks.com) the Internet Audio Talkshow for .NET developers and RunAs Radio (www.runasradio.com) which is a weekly show for IT Professionals.Links Referenced: Twitter Username: richcampbellLinkedIn URL: www.linkedin.com/in/richjcampbellPersonal site: https://rcampbell.me/Company site: http://runasradio.com

Hello and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. using Nagios at scale anymore because monitoring looks like something very different in a modern architecture where you have ephemeral containers spinning up and down, for example. How do you know how up your application

is in an environment like that? At scale, it's never a question of whether your site is up, but rather a question of how down is it? LightStep lets you answer that question effectively. Discover what other companies, including Lyft, Twilio, Box, and Jithub, have already learned. Visit lightstep.com to learn more.

My thanks to them for sponsoring this episode of Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Richard Campbell, a man who is more Enigma than almost anything else. Richard, welcome to the show. Thanks for having me on, friend. Thank you for being had. Your bio says you wrote the first line of code in 1977.

Your career has spanned the computing industry, both on hardware and software sides, development and operations. You were a co-founder of Strange Loop Networks, acquired by hardware and software sides, development and operations. You were a co-founder of Strange Loop Networks, acquired by Radware in 2013, which around then was the time I was playing with one of their load balancers, it turns out. You were on the board of Telerik, which was acquired by Progress Software in 2014. Today, you're a consultant and an advisor to a number of successful technology firms. You're the founder and chairman of Humanitarian Toolbox, a public charity building open source software

for disaster relief. But the way I found you is that you're the host of two different podcasts,.NET Rocks, which I've never listened to, and I would argue the point. And the one that I encountered you with, Run As Radio, which is a weekly show for IT professionals. Stop me if you heard this one. You're a Microsoft MVP, and you are more or less the,

it seems like a strange version of me, who, let's admit it, you're not quite as well-dressed, but that's okay, I forgive you, but over in the Microsoft ecosystem rather than the Amazonian one. Yeah, I do grow a better beard than you, though. Yes, I still look like an angry 14-year-old trying to prove a point to mommy and daddy. Well, the show is called Screaming in the Cloud. I think you're supposed to be angry. Oh, absolutely. I do my best. But I encountered you

a couple years back when I attended my first Microsoft Build, when they sent me an invitation to go and record an episode. And I thought, wow, that's amazing. They've gotten me confused with someone who knows what they're talking about. Awesome. I'm going to act as if, because as a to go and record an episode. And I thought, wow, that's amazing. They've gotten me confused with someone who knows what they're talking about. Awesome. I'm going to act as if, because as a mediocre white man, that works really well for people who look like me. Right.

And sooner or later, they're going to figure it out. But if I move fast enough, maybe I can get the show in. Exactly. And it worked. And I had Corey Sanders at the time, the corporate VP of Compute. Now he's ascended somewhere else. And we had him on again recently at Microsoft Build this year.

The interesting part, though, was that this year, you reached out and invited me up to record a bunch of shows. And people who have been following this on a week-to-week basis have noticed since then, wow, there have been a lot of Microsoft guests there. Yeah, that was recorded during a three-day span when I'm up there trying to, I guess, maintain focus after the seventh podcast recording in a row.

You get punchy after a while when you knock them out back to back like that. Absolutely. So I did a little more digging into you. And it turns out that as of the time of this recording, you and I have recorded a few days ago, an episode of Run As Radio, your show. And you mentioned that that would be episode 650. So I'm not sure on the scheduling, we just may come out before that one. But what's fascinating to me is you've been doing this about 10 times longer than I have.

So, oh, this is what I'll be if I grow up. I'm still trying to figure out what I'm going to be when I grow up. All I know for sure is I'm pretty persistent. Yeah, and that seems to work out really well. And I've looked through some of the back catalog of various episodes you've had. We've had some people in common. You have a list of people that are high on my list of folks to wind up dragging and interrogating, I mean interviewing.

And it's just been, it's really neat looking at what someone can turn this into. I don't view this as a deviation from the typical theme of the show, which has been the business of cloud computing, because you very much have a business that is running around the world of cloud. I'm intentionally vague. I don't say a technology business. I say a business. So you've turned this into a run-as-radio company around this. You have a very streamlined production pipeline that puts mine to shame. It's just fantastic watching you. Well, it's been 12 years. So we did migrate to the cloud. You know, the original incarnation, you're talking about the early days of podcasting.

Carl Franklin, my cohort on.NET Rocks, he recorded his first show in 2002. The word podcast didn't even exist yet. And I started up Run As in 2007. So the word now existed, but it was still very early days. Of course, I started an IT podcast that was Microsoft-centric right after Vista shipped, because I'm clever like that. And so those were tough days, those first couple of years, but the machine already worked pretty well, and it was not hard to just keep every Wednesday, since April 11, 2007, make sure a show publishes,

just keep doing it, and the numbers sort of pile up. It's way more fun now that the cloud has grown up and become a thing and we're still exploring what it can do. That's a non-trivial area of conversation, week over week, along with topics like DevOps and still dealing with the reality of do you run a mail server? Do you own a domain controller? All of those kinds of problems that IT folks have and are just figuring out the right ways to do things. Right. Whereas I come from the Linux and startup world here in San Francisco, where our entire

approach to development is laughing derisively at anything that's more than six weeks old and throw everything away. When everything's greenfield, you can build amazing stuff that never looks bad because you won't be running it long enough for it to become legacy. Yeah. By that point, you've pivoted. Exactly. Where I think, yeah, a non-trivial chunk of my listeners are folks that are still paying the price for decisions made in the early aughts. Isn't that the truth? When

people say legacy, I hear is it makes money. And I'm again, I'm a three-year-old company. There's only a handful of us here now, but everything we've built is largely serverless. And I look back and I still see that I have piles of technical debt. Ooh, I would do that differently. There's a better way to have done that. Oh, my account management was crappy, et cetera, et cetera, et cetera. But it doesn't actually solve any business problem for me.

If I fix that, it just assuages my sense of something not being right in the world. It's also a balancing act on those things as well, right? You have it pivot moments, like I'm about to renew this contract for the next two years or five years. This is the moment to make a decision, like how much will I regret this when that contract expires,

that I did this again? Shouldn't I make a move to the cloud or do a re-architecture or retire a piece of technical debt? There's only certain moments when it makes sense to actually pursue that. They slowly cost you, right? There are hammers in that sack of hammers you're carrying around. And the chance you get to shake a few off, it's pretty compelling. It really is. But what's also interesting to me about you is that you and I have both gone in the same direction, where to some extent, we've stopped writing code day to day,

40 hours a week and started doing other things and the podcast is fascinating I view you as someone I can reach out to from time to time and get good advice and figure that's probably time to wind up putting you on the show as well but from my perspective when I started this it was well what do I do with the podcast like how do I structure the show in a way that makes sense for people I know I wanted an interview show, for starters, for two reasons.

The aspirational of trying to help other people tell stories and effectively give them exposure to a new audience. And the real answer, which was, I'm a nobody who no one should ever listen to seriously. But when you say, would you like to be on my podcast? People say, absolutely, instead of who are you, Get out of my office. How did you get in here?

Exactly. Also, I've discovered how powerful it is just as a research vehicle. You have these amazing conversations where ultimately you represent the audience well with just helping to try and understand what's going on, what they're talking about. And if you can clarify that, you're probably clarifying it for the listener as well. But you end up in this sort of state, this gestalt state, this I have a sense of a view over this platform

because I've talked to all these different people and then gotten feedback from my listeners. And so I sit in a sort of interesting analytical space where it's like these things seem to be important for the companies that are selling them things seem to be important for the companies that are selling them but not that important for the users that that don't really care about them right and there's so much coming out across this entire environment it's our cloud ecosystem no one can keep up with it all by a landslide yeah picking and choosing different aspects of

it and when you get someone in who's well-connected in the environment and being able to ask them, what parts of this matter versus what parts of this can be safely ignored? Or even not even framing it that way, it's cool. Like when I had Corey Sanders back on or Scott Guthrie, it was great to be able to talk to them about the entire Azure ecosystem, something I don't know much about, and see what areas they focus on

because there's so much they could talk about. But instead, they pick one or two areas that they're excited about, that they want to tell a story around. And that helps contextualize and shape how I start to view that ecosystem as a result. Yeah, absolutely. And I think for your listeners as well, just to be more aware of this larger cloud world we're living in and say like who's moving where because certainly Amazon and Microsoft are paying close attention to each other. Oh absolutely. I tend to feel like

I personify my listener reasonably well because for better or worse throughout most of my career I have always been usually the first person in any given room to stand up and say I don't get it. There's something that I'm it. There's something that I'm missing. There's something that is unclear to me and it's just not clicking. And invariably, whenever I do that, other people chime in. Yeah, me too. I did an angry- That sort of relief that goes across the room. Oh, it's not just me who's like, this makes no sense. Right. Today, we're recording this on July 25th of 2019. And late last night, right before I went to bed, I tweeted that I just spent a few hours, sorry, a few hours wrestling with S3,

trying to get URL redirects working, gave up, rage quit, did it in 10 minutes in Nginx on an EC2 instance and went to bed. And the replies to that that I woke up to, massive, are falling to two camps. One of them is, well, have you considered, and then it gives some arcane Byzantine serverless solution. It's, no, because I have a job. And the other is, oh, thank God, it's not just me. This stuff is super complicated. And that's why I mentioned this makes no sense to me and I don't get it as often as I do. Because when I do that, it reminds people that they're not alone. So if I don't get it as often as I do. Because when I do that, it reminds people that they're not alone. So if I don't understand a lot of things about a product or an ecosystem

and I call that out, I feel like in many ways I'm speaking for the users when I do that. Well, and particularly in this space, you're often working alone anyway. There's lots of people depending on you, but you are the quote unquote expert. You know, you're handling our cloud migration, right? And you're like, yeah. Or when you get that pop-up dialogue that says, this didn't work, contact your administrator for more help. Like, I'm the administrator, and I have no idea what you're talking about. So I think having a show, these kinds of conversations, because you're often alone. It's like this is your one connection that reminds you you're not alone,

that there are other people struggling with this, that this is a normal part of us building a new part of civilization, which I mean, I'm not exaggerating. I say the cloud is reshaping what humanity is going to look like, and our small roles in it, whether you're building it, utilizing it, or talking about it, all are part of moving that ball forward. One of the things that I guess astonishes me is just how well this has resonated. I thought this was going to be something I'd do for a couple months and then shut down. And here we are well

over a year later. Well, I'm not shutting it down down now but what's strange is you know no one ever knows their own reputation and what you mentioned to me is that getting uh guests for the podcast initially when you were working behind the scenes where i knew you were doing that was challenging based upon the name of the show yeah well you know first impressions and and and visceral responses like but also non-technical people. When you're talking about working around an organization in a conference as large as Build, there's a lot of people who have says in different things. And so they come up from different perspectives. And if there's PR folks involved, well, they care about the optics more than anything else. And they're going to go on the simplest, easiest response. They've

got to triage hundreds of things. And what's the quickest way to do it? It doesn't make it accurate. Right. The show is called Screaming in the Cloud. Obviously, it's a ranty thing that's looking an awful lot like you just sit there and berate someone for half an hour. And unless you actually listen to the show, in which case you know, that's not even remotely true. Right. But when I started this, I didn't know what it was going to turn into. And I learned a lot as I did this in the first dozen episodes or so. For example, I thought this was going to be sarcastic, snarky and bantering. It turns out when there's an interview show and you have a different guest on every week, you can't do that in the same way. Because if you and I banter and we're snarky and we're sarcastic

and you smack it back every time I toss something your way, it's a great show. But then next week I have a different guest where they are not as good at this. And it looks instead to all the world like I'm beating them up. Someone listens to that, no one's going to come out of that thinking, oh, I'm going to be on that show. And it's not fun to listen to either if someone's confused or struggling. We have the advantage that we've known each other for a couple of years now. I mean, not every day, but we've got a couple of events, you know, and so I'm pretty sure

I know your snark when I hear it. And we both do podcasts. So we all definitionally have the ongoing love affair with the sounds of our own voices. Well, I do sound amazing. Yes, I have a face for radio. It works out well. But what's fun too is that as I was looking down this path, I realized about that time of this recording, a couple months back now, that I wanted to have a podcast where I could be snarky and sarcastic. So I launched another one,

the AWS Morning Brief. And that's now about two months in where it effectively right now is on Monday mornings. It's a 15 minute show. And it just talks about the releases that AWS has done over the past week, like I do in the newsletter. And then I make fun of them as I do in the newsletter. But I often go into more depth. I talk about why it matters. I mentioned things that don't fit in the newsletter for whatever reason.

I go off on tangents from time to time and I'm snarky and I'm fun and it's sarcastic and I don't have a guest. So I don't need to worry about making anyone look bad. Yeah. There are plans, you heard it here first, to look at expanding this to a multiple day a week show. That's a lot of commitment, friend. Because all that stuff is super timely.

It is, but that's the trick. I don't think I could do a daily show, for example, about what they released yesterday, because spoiler, no one really cares. People want to get a roundup, but they don't need to have it as breaking news. So there need to be other things to do, like talking about services, doing some sort of deep dive or whatnot, talking about things that are relevant to the ecosystem. Because frankly, just talking about releases, I get bored, let alone other people. I can't imagine what that would look like. You've got to keep it fresh. You've got to keep it interesting. You've got

to keep it snarky. Yeah. Analysis of an outage is always interesting. Like what really happened with Cloudflare the other day? You know, I know we've been making fun of a Regis mistake, which is lovely, you know, because... I have such little tolerance for that. Yeah, it turns out all this stuff is super hard. Anyone who's sitting there saying, oh, you went down because you employ morons who are terrible at these things, shut up and go away.

It's not even close to true. Yeah, it's very clear that whoever's saying that has never had to run anything of any reasonable sense of scale or importance. So if you've, like, one of the questions I always like to ask people when I was an ops manager in the interview was, tell me about an outage that you were at least partially responsible for. It always is partially responsible for.

And people's reaction to that is telling. I don't want to see people beating themselves up, but I want to see people telling a story about it. And if the answer is, oh, I've never taken production down. Well, there are a few things that are possible there. None of them are compelling. First, either you're lying because you think it's an interview and you're never supposed to have broken anything,

which, cool, we're done here. Or no one has ever trusted you with production, which, okay, that's interesting as a data point. Or you are so methodical and so careful that you need to quadruple check everything. We're looking at launching space shuttle style of software rather than something that's web-facing, and that's also useful to know,

and we'll uncover that as we have the further conversation. Yeah, I don't even know if the space shuttle is a good comparison, because that didn't always work out well for them either. Oh, yeah, it was great. I got to tell that story once from an outage that happened in a team I was running. Someone on our team wound up doing a misconfiguration that led to something else and an edge case hit it.

That's always how these outages tend to happen these days. And the discussion was, okay, so that misconfiguration really, like any one of those things not happening would have meant no issue, but that misconfiguration, and the interviewer leaned in and said, was it you? And my response was, it was the team I was managing. So, yes, of course it was my responsibility, but who actually made the mistake?

Completely irrelevant, and it could have been any one of us. It's the truth. You don't blame people for individual mistakes. The one that irritated the living hell out of me was the S3 apocalypse a few years back where, oh, it was a typo on the command line. No, that effectively was meant someone stepped on a landmine that many other people had a contributory effect in burying. If one wrong command typed into the wrong place can take down all of S3 for an afternoon, well, that is a process and systems failure. And it's a learning experience. I've never figured out who it was. And the only reason I'd want to is so that I could call them

and say, you know what? We've all been there. Can I buy you a drink? Because, man, there but for the grace of God, any one of us could have had something like that happen. And it's certainly not their fault. And I just want to validate that there was never any direct consequences to that person. I don't imagine there would have been. No, no. You would presume in these big organizations, they're mature enough now to know that this was a failure of process,

that to even be put into that situation where it's possible to do that. Yes, and Mylon Thompson-Bukovic, the VP of S3, was on this show very beginning of this year and we touched on that topic as well. But before the system had been restored, there had already been changes pushed out that would have prevented that mistake from ever happening again. They've also gone on stage since then at various folks from her organization and talked about how it's now running, I think, on 235 microservices that drive S3. They've completely re-architected a lot of it under the hood, and we're seeing performance and stability enhancements come out of it.

Contextualizing that's important, but telling the human story around these things is always interesting because a root cause analysis, I feel like companies are sort of becoming victims of a situation they've created for themselves where marketing and PR only ever release very carefully crafted statements. So people are used to having to sort through those

for subtext. But root cause analyses or cause of error reports, whatever term we want to use, so J. Paul Reed doesn't yell at me, are all very, those tend to be very honest. But trying to dissect that into the who's screwed up is counterproductive and unhelpful. Yeah. No, understanding how we can get into a situation like that and how we're not going to get into it again is the real root cause analysis.

That we get to a place where now we... Analysis isn't good enough that there's no action to take at the end. The whole point is to get to a place that says, if we take this action, we decrease the likelihood of these kinds of problems. Yeah. So I'm a consultant these days. I fix the horrifying AWS bill. I opine on architecture a lot, but I don't really run production infrastructure anymore.

So one of the things that I worry about, and I'm curious how you've addressed it, has been that now that I spend the bulk of my time, at least as far as the public sees it, of doing podcasts, writing newsletters, and being obnoxious on Twitter, how do you avoid losing touch with the technology to the point where you just become a talking head who hasn't ever used the thing that they are taste-making about? Yeah, I do think you have to use the thing that they are tastemaking about. Yeah, I do think you have to use the thing, right? I mean, it may not be large-scale websites. It's your own stuff, but that's fine. You know, actually spending time in the tool matters a lot. I laugh because, of course, doing RunAs now for 12 years, I continued to run my own exchange

server. I was allowed to. I had a license for it. It makes no sense. It should be in the cloud. But I can also look an exchange that had been in the eye and say, dude, I feel your pain, right? Like running mail service is a thankless job. Well, most of IT is thankless, right? You can only get a C or an F. If it works, nobody can tell. And if it doesn't work, well, you're an idiot. There's no win. It's just you made it through another day. Have a beer. Keeping the infrastructure up and running for the show is part of that.

What's the right way to do this? When do we improve it? How do you think about the sort of next stages on that? At the same time, you're having conversations with the people that run these larger installations and pursuing those case studies. you're having conversations with the people that run these larger installations and pursuing this case studies. In the early days of Azure, I stopped talking about it on the show because the only people I

could get to talk about it were the people building it and the folks that were talking about the people who are building it. I just hit a point where I'm like, until you have a case study and there's somebody running it that's meaningful, I don't think this is worth talking about anymore. Because that's, I think, what people actually wanted to hear.

Talk to me about a regular group of humans who use this tool successfully and what they liked and what they didn't like. That, to me, is a useful conversation. All too often, you're caught and you can be stuck in the bubble of the people who want to promote it more than the people that actually are using it. One of the things that astonished me as I did this, because I started off building all the infrastructure myself, because, hey, I run infrastructure. It's what I do. The newsletter and the podcast and the rest have gone from toy projects to viable businesses. And at that point, I felt a sense of responsibility

to stop keeping this all with this arcane architecture I built in my head. I migrated all the web properties from this to WordPress. WP Engine hosts that. I'm giving a conference talk about moving it off of serverless and onto WordPress over at Serverless Conf in New York later this year called Benjamin Buttoning Serverless.

And I expect to mostly be shouted off the stage because it's something that flies against common wisdom and true believers which okay I get but by the same token I want to make sure that we're actually doing things that are right for the business yeah what what astonishes me is I whenever I find myself talking to analysts they look at me and they think I'm a kindred spirit because I talk to the people building these things yes I do then I. Then I talk to customers using them. Yes, I do. And then I build something with it myself to validate what I've heard. And invariably, when I tell that to an analyst, I get a flicker of terror in their eyes. As if somehow... Why would you do that?

Well, not even that. About, am I about to be the person that the kid that points out that the emperor has no clothes? Because you have entire analyst firms that never touch this stuff, but are very good at talking about it. And I never want to be that. No, and I think it's a conscious choice that you also make in your work, right? I mean, the good news is, especially when we're talking about the cloud space, is that we're all using it to some degree. It's just how aware are you and how responsible are you for it? I mean, it'd be way harder to be in a space that was much narrower, more specific, where you really wouldn't have many excuses to utilize it. But I think we also make a choice, right?

It's interesting that you pulled away from a serverless architecture over to a WordPress solution. Sounds like very practical engineering. And I think people value that. I could hire someone to handle all this stuff for me on the development side. I can pay a company probably too much money to host this all for me, and I don't have to think about it or touch it. Absolutely. I could hire someone to handle all this stuff for me on the development side. I can pay a company probably too much money to host this all for me, and I don't have to think about it or touch it. Whereas finding someone who can do that same sort of work on the bleeding edge

of serverless stuff, well, okay, that's not a basket full of money. That's a dump truck full of diamonds. So it gets incredibly expensive, but and for what business value? Because again, well, you'll have better availability and utilization, et cetera, et cetera, et cetera. Yes, true. Will I, if I actually have to take care of it myself, because I'm awfully busy. Right. My time is worth more than the infrastructure cost at this point, because it's the opportunity cost of not doing something that adds business value. Well, I think you get more uptime out of having, you have people who can take care of it, even if it's a bit more fragile. The people factors on all these things

matter. The availability of resource matters. You have to be able to scale. It's not just scaling the site, it's scaling having people around that you can trust to make sure those things keep working. Right and if WP Engine falls over they have an entire team of people who are paid nothing, do nothing other than make sure that that doesn't happen. They're going to get it up and running and notice it way more effectively than I am. Long before you do.

And that's the whole point of the cloud is we're concentrating the best and brightest around these infrastructures. And my use case isn't what people tend to, I think that people lose sight of that. If I'm an ad network, for example, people are not going to come back and if my site is down and try and view an ad later.

Every second there's down, there's a very real revenue cost to that. With last week in aws.com, which has my blog, the podcast, the newsletter stuff, if that's down, someone's not going to be able to sign up for during the duration of that happening. But it doesn't have a direct revenue impact on me. I mean, I'm still averaging 100 signups a week on the newsletter.

So if I'm down for 10 minutes or so, and I wind up losing at a high side 12 of those, it's not good. But it's certainly not the end of the world economically. Yeah, it's also a challenge to measure that too. You don't have an equation to that. Will those 12 that couldn't get there come back later? Those are hard questions to answer, but it's all still the same basic point, which is the value prop here for the amount of

effort necessary and cost necessary is high enough that this is the best way to do it. It really is. There's no ideologues, right? I mean, if you really cared to optimize everything, you'd still be handcrafting C++ and CGI calls for this, right? We don't care that much. We don't need, you know, the difference between a second and a tenth of a second. It's just not that big in this scenario. Exactly. And at some point, I mean, Charity Majors had a great line that she's said a few times that nines don't matter if users are unhappy. Yeah. And that works in the direction of the experience needs to be good.

Just technically saying you're up doesn't count. But by and large, if people don't care that my site is down at any given point in time, then is it really a problem? Yeah, right up until the cash flow stops. Well, there's that. Then I have a problem. So as we take a look back over the sweeping landscape we just covered, we've talked a lot about where we've come from and how we built these things.

What's the future look like for you? Well, I like the podcast model, I think, appeals because it isn't your principal focus. I don't think a lot of people sit down and just listen to a podcast. They tend to listen in their car, on the way to work, or their transport of choice, or when they're working out and so forth. So I'm big on the in-the-ears model. I think it's very interesting. The question is always, are we telling stories that people care about? Are we staying focused on those kinds of things? And are we cross-pollinating? Here we are crossing the streams, you and I, between my show and your show, and certainly the same thing we were doing

at Build with all those podcasts. We're all way more alike than we're different. And the more times that we can sort of mix that up and remind each other that everybody's working hard, trying to do the right things, and that all these technology choices are viable, right? There is no one right way. There's what you know, how well you can manage those costs, and how much value you get from it. I think the more times we understand that with everyone in this particular circuit, the happier we're going to be. I think you're absolutely right. The very honest truth of one of the big reasons I have a podcast that does interviews is every week you get to borrow

someone else's audience. What always drove me nuts is when I would guest on podcasts and they wouldn't promote it. It's what's the point of having me on your show if you're not going to ask me to tweet about it or leverage my audience or because that's the entire point. Yeah, that is absolutely the machine and and more sources of good information. People want to know about them. They're valuable. So it's certainly it's worth putting energy into putting that in the world. We still have engineer's disease, right? Which is if I make it, that should be sufficient. If you don't value it, well, that's on you. But that's not the truth, right? There's plenty of great things that have been made over the years that nobody got to know about because it didn't put the effort in to making it visible. I think you're absolutely right on that. And I

think that's probably a good place to leave it. Richard, thank you so much for taking the time to speak with me today. Where can people find out more? Well, for this particular audience, I hope you come and listen to Run As Radio, which is exactly the domain name as well. And that website is filled with sysadmin jokes.

So if you take a look around, you'll see little things that if you're a sysadmin, you think that's funny. And we put out a show every Wednesday since 2007. So, you know, you can count on us to be there. And otherwise, you can reach me on Twitter. I'm Rich Campbell on Twitter.

And always happy to chat and snark and have some fun with this great career that we're in. I'll be sure to throw a link to runasradio.com in the show notes, but that link will be largely symbolic. That's how all links go. Yeah.

Welcome to the SysAdmin Joke Pool. It doesn't get better from here. Richard Campbell, Microsoft MVP, founder of several podcasts, runasradio.com, and raconteur, for lack of a better term. Nice. I'm Corey Quinn. This is Screaming in the Cloud.

This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever Fine Snark is sold. This has been a HumblePod production. Stay humble.