Transcript

Announcer: 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.

Corey: Are you better than the average bear with AWS? If you're listening to this podcast, the answer is almost certainly yes. Want to turn those skills into money? If you're US-based and have an AWS certification, sign up as an expert on AWS IQ today, and help customers with their problems., visit snark.cloud/IQ to learn more.

This episode is brought to you by Trend Micro Cloud One, a security services platform for organizations building in the cloud. I know you're thinking that that's a mouthful because it is, but what's easier to say? "I'm glad we have Trend Micro Cloud One, a security services platform for organizations building in the cloud" or "Hey, bad news. It's gonna be a few more weeks. I kind of forgot about that security thing." I thought so.

Trend Micro Cloud One is an automated, flexible, all-in-one solution that protects your workflows and containers with cloud native security. Identify and resolve security issues earlier in the pipeline and access your cloud environment sooner, with full visibility, so you can get back to what you do best, which is generally building great applications.

Discover Trend Micro Cloud One, a security services platform for organizations building in the cloud, whew, at trendmicro.com/screaming.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Conrad Heiney, a principal cloud engineer at Glidewell Dental, but I much prefer his Twitter bio, which simply states, “I would prefer not to.” Conrad, welcome to the show.

Conrad: Glad to be here. Thank you.

Corey: So, tell me a little bit about who you are, and where you came from because my first introduction to you was somewhat unorthodox. I saw you get retweeted a few times by the Pinboard account—use Pinboard—and you had a certain acerbic style that really resonated with how I tend to view the world; intelligent, snarky, sarcastic, but also very clearly clued into current zeitgeist in modern cloud. Who are you, and how’d you get here?

Conrad: Well, I'm not a computer person originally. I was a humanities type. I was raised in a household full of writers and teachers, and I took one computer class in college, and then the second class caused people to die. It was a weed out, so I went to back to English. And computers were a hobby for some time. And I guess around 1989 or 90, I started getting into BBS stuff again. And then I made the mistake of getting Prodigy.

Corey: The web service, not the band, to be clear?

Conrad: Correct. No “Fat of the Land.”

Corey: No twisted “Firestarter” there?

Conrad: None of that, no. And, of course, Prodigy was profiting in a number of ways. One of which had ads. And there was an ad for this new thing called America Online because PC America Online had just launched. So, I was a so-called “charter member.” And they had a trivia club online. And I was always good at that: College Bowl and all that. And I enjoyed that, but AOL at that time, off-peak was four bucks an hour and I didn't have any money. But if you won the trivia game, you got your hours comped. That almost worked.

Corey: Back in those days, that was amazing. I mean, now if you win the trivia game, you get a job offer as a developer.

Conrad: Right. Right. So, the I got a little bit too into it, and ended up being one of those AOL guides, which was a combination of tech support and chat patrol. And at the time, I was a manager in medical records, and I was futzing around with computers, and the two sort of dovetailed, that I had to manage—wait for it—a Novell NetWare 286 install on a 1990s healthcare. And I ended up leaving healthcare, taking a pay cut, and working for a company called Hollywood Online, which was AOL’s only entertainment provider. And so that’s, in ’95, how I ended up in that field. And then everything after that was sort of accidental. It was kind of a backwards introduction into computing.

Corey: That's one of those interesting stories, in that you talk about coming up through computing in an era where a lot of the, well, we'll call the modern generation of developers, who have been doing this for almost three whole years, didn't get to experience in quite the same way. Which on the one hand, is kind of sad because they didn't wind up getting the same deep level of exposure and experience with some of these things, and then the other is good because we generally frown on child abuse. So, there's definitely a strong sense of the world modernizing.

But something that's always bugged me about that entire approach has been that I look at why I'm capable of answering weird questions about cloud computing, and invariably, I go back to fundamentals that I picked up back when I had to actually care about things like, is the SAN currently getting a full disk? Does it need to be partitioned further? What's the temperature look like? Did someone actually pee into it? And now that I don't have to think about those things at a general basis, it's great because there are enough abstractions that have made it to a place where I don't have to. But the counterpoint is, is that I feel like I would be way less effective without that grounding in Unix.

Conrad: Yeah, the progress of abstraction is a thing. It's this train, and where do you get on the train? And so, I knew people when I was a kid who were working on computers when you crawled inside them, and when everything was a big chunk of metal, and later on when things got more abstract, they were very, very good at it. My brother is a scientist, but he learned C because he had to write device drivers in order to make science go. And those people, to me, are sort of godlike because when they end up say writing a software, they know what's going on all the way down into the electrical stuff.

And I've always noticed that the people who were really good at computing were not CS graduates necessarily, because that varies a lot, but they were electrical engineering graduates. Those people really know their stuff. So, yeah, I mean, I joined at a time when, so to speak, the modern internet as a product was being invented, which was great because you didn't have to have a certification. We were inventing it, which was great. But we were still about five steps down from the originators. And as you're right, it's good and bad because when you get all those levels of abstraction, you keep moving up, you can get so much more done. I don't have to worry about anything, but at the same time, eventually you're going to have to go to somebody who knows that stuff, and it'll take you longer if you didn't have that background.

Corey: One of the things I find that's so compelling about vendor selection in terms of managed services, or cloud provider, or whatever phrase of the decade we're using to describe it, is I always tend to bias for the one that I've worked with before. And some would say that, oh, that makes me a stick in the mud. And I'm not willing to embrace progress, but my counter-argument to that has always been that if I don't know how something fails, then I don't trust it in production because, spoiler, it's going to fail. And given my luck, it's going to be at two in the morning on a weekend.

Conrad: Right. You know, one of the things that happens in this field in our technical field is people tend to carry around the other people they want. Like, a new person comes in, and their crew comes with them. Yeah, and I think technologies and products are that way, too. It's like, “Yeah, I know the failure mode of this thing.” As opposed to, “Well, they say it doesn't fail. I wonder what it will be?” So, yes, I agree.

Corey: One of the strange things that always tweaks my notice, is that you see folks who have resumes in the cloud engineering, slash DevOps space, slash SRE space, slash production engineer, slash senior systems administrator—again, we are all systems administrators, some of us have just found the magic incantation that winds up leading to larger salaries. But there really tend to be two clear paths that people tend to go down before they land one of those roles. One of them is the path of the developer: the deep dive into I write code all day, every day, and now I'm learning how operations works because, holy crap, it turns out that when I write nonsense, there are consequences to it. And I love working with folks like that, who have, I guess, seen the light. And then there are folks who generally tend to come from the other side of the world. And that's the one that I tend to come from, of being the systems administrator type, circa 2000s era. The reason I call out the decade, is because back in the 90s, to be a decent systems administrator, you had to know C pretty well; you had to have an in-depth knowledge of system calls and, “you don't write code as a systems administrator,” was not something that anyone sensible would ever say out loud more than once.

Conrad: Right.

Corey: How did you come down this path? Where did you start? And do you see that being a real division? Or do you think that that's a bit of a false dichotomy?

Conrad: I'm very much in the sysadmin end. I mean, I started out as sort of jack of all trades, doing everything from plugging in the modem, to bed web design, to actually doing sort of entertainment-related writing and things like that. And sysadmin was where I gravitated because I found that the human factors end of it was terrible, but the technical part was easy. But I don't like sysadmin culture. I learned around that the job itself was negative, but it was a bad idea to be negative. And that developers had more the right idea of being optimistic. There was a guy I worked with who was old school. Like, he hired the guy who wrote POP3 now [unintelligible] hanging out. And then he gave me this lecture about your entire job is negative, now. Your entire life is negative.

You're just going to be the person who tells people it won't work, and they can't do it that way, and you'll never create anything; you'll never be the hero; you'll never make money; they'll never do the product, and your entire task for the rest of your career is to spin negativity and make people like you. And I thought, “Yeah, he's absolutely right.” And so my strategy after that was to not be the BOFH, right? To be the nice sysadmin, be the one who says, “We can't do that, but I’ll help you get it done.” And I think I learned both from developers, and from my—in the medical field—from people like physicians, that you have to combine that conservatism with an optimistic feeling, and a desire to make things better. I, like you, really appreciate the developers who learn ops—they're rare—because I'm not good at programming, and having somebody to work with who can do both is tremendous. And I think that as sysadmins, we criticize devs too much, but that it's a good idea to take some of that confidence, and positivity, and put it into your work.

Corey: Lots to unpack there. One thing I want to start with, I think, is how do you view this whole world of serverless? I mean, the idea is incredibly compelling. You write code, you throw it over the wall to your provider, and they handle all of the operational bits for you. And then you say, “All right, great, what if it fails? How does it break? What does that mean for my application?” And everyone just kind of stares at you blankly until you stop talking, then they try to pretend that they didn't hear you. I feel like there's something that's getting lost there as far as being able to say, “All right, I'm going to write all of my stuff in Lambda functions, and now it is purely Amazon's problem,” because that's not going to break at all until suddenly, one day it does. And we don't necessarily know how that's going to look. Does that make you uneasy?

Conrad: Yeah, it does, mostly because that way of looking at things which—you go back to containers, to JavaScript technology being used for lots of things, or whatever, all of that whole trend really grows out of startup web development, and a very developer-centric world, where basically everything should move fast and break things. The consequences for breaking things aren't huge. And everything is focused around getting something done and running. That anything else, like planning, or sort of the conservatism of ops stuff is seen as overhead. Kind of the negativity thing that I mentioned before. And the thing about that is it gets stuff done real fast.

Like, if you're a developer and you can run a command line, essentially, take all your code and then it's just running. That's awesome, but the trend basically doesn't just abstract out all of this ops stuff: it denies it. It basically says that's not happening. That's not a problem. If you've got a two-year exit strategy on the web service, it just says, “Yo,” this is awesome. If you've got a manufacturing line, if you've got financial stuff, if you've got stuff with real-world consequences, you have to look at the ops world. And you have to either have a really good vendor or have people who understand what's going on behind the curtain and can help with it. Because otherwise, at that point, it really is sort of a near fraudulent startup dream that you can just basically copy paste a bunch of code, pay someone with the fake money that you got from venture capitalists, and it will just work. And that's a cultural or financial problem that I think has worked its way into technology to an extent where, yes, I love it, you can get stuff done really fast, but you really have to either not care about it being a black box, or hire people who know what's going on in that black box.

Corey: The problem that I see with this is on some level, it's always going to be a black box, and hiring someone who understands what that black box looks like, is impossible at some level of abstraction. No one can hold everything in their head anymore. If you want to try this at home, listeners, all you have to do is wait for the next person to come interview who bills himself as a full stack developer, and then ask them questions about device drivers to see how quickly people's knowledge erodes. No one is good at everything. There is no such thing, in my mind, as a full stack developer. I'm the closest you get because I'm a full Stack Overflow developer in which I copy and paste code that other people write, and wind up doing that until it compiles.

Conrad: Right. You’re right. There's something that one of the things I’m a bore about is, sort of, engineering disasters and their implications for us. And there's a very, very good book called Normal Accidents—Charles Perrow. He defines a situation where if there's a system that one person cannot comprehend and that is also very tightly linked—you know, so that a change over here causes a problem way over there—you will have accidents. His example, unfortunately, his big example is nuclear plants, but you run into this a lot with what we're doing now. But yeah, even something like, oh, we have an app that, let's say, assesses risk for something. Well, the risk modeling person knows that part, and the ops person knows this part, and the dev knows this part, but nobody knows the whole thing, and so it will break.

And I think the nearest thing we can get to dealing with that in that serverless world facility you were talking about, is to educate, first of all, that people actually understand on some level what's happening back there, and then get people with experience who’ve seen things because you develop a heuristic for things after a while. I mean, you do notice, like, this looks like there might be a disk full somewhere, or this looks like network latency of this kind, and I don't know how to get that, aside from A) making sure that devs do understand the basics of this stuff and what they look like, and then paying attention to ops, and getting ops people who are able to penetrate that enough to do diagnostics, rather than just have to know how it all works.

Corey: It's a terrific ideal. The problem is—and this is, I think, the real role of systems administration, however you want to term it, however you want to lock that down and define it, it all comes down to fundamentally the idea that at some point, the buck has to stop somewhere. There's no longer anyone else within your company, to technically escalate issues to, so the answer to almost everything that you wind up dealing, once you've automated the banal away is, “I don't know, but I'll find out,” and that role has always had a bunch of different terms. In my first job where I found myself in that role, we were the “network engineering group,” or “network administration group,” depending on who you asked. And that was great. 90 percent of what I did didn't really touch networks, but rather, had to do with digging into interesting problems and solving weird issues.

And it was pretty apparent that what we found, and how we wound up solving problems was in some ways dangerous because, easy example, someone on the support desk was terrific at following instructions. He'd been there for 20 years, and he was great at things, and I was making a change and I reached out proactively to him—what a concept: collaborating with the support desk because they are your phone firewall—and saying, “Look, for the next 24 hours if anyone has issues with this particular system, here's the command you give them to clear their local DNS cache because I'm going to be updating and repointing this, and it may cause some weird inconsistencies,” because in fairness, I didn't plan ahead and reduce the TTL a week before. Oops. So, the changeover went well, and things are going reasonably decently. And a couple weeks later, I walk past his desk, and I listen to him telling someone to clear their DNS cache for a completely unrelated issue. And we saw some of this where it’s, whenever you learn something new that applies to a specific problem, we often tend to have an incomplete understanding.

It's why when, if you wind up calling for support, assuming that you do that for desktop support these days—I don't know how that works anymore. I throw it away and buy a new one. But the idea was, “Oh, you call in and yes, I've rebooted it. Yes, I've reinstalled it. Okay, I'll defragment my hard disk and then call back.” And there's this litany of, I guess, theater that you have to go through before you can get to the underlying issue in some cases. And because they tend to clear up occasional cases, it just gets added to the flow chart list of things to try before actually diving deep into stuff. I feel like every company has a group that is responsible for coming up with these offbeat, deep dive solutions to esoteric problems, where the buck has to stop with you. Invariably, those people get very well acquainted with things like Stack Overflow, Reddit, IRC, various forums, insulting people on Twitter, etcetera, etcetera because that's, in many cases, where you find the answer to things. It's also why, even if you don't write code yourself, you find yourself reading an awful lot of source code as a step of last resort.

Conrad: Right. There's a level at which there's lore that accumulates with somebody, which is terrible. And then a level at which somebody is… yeah, kind of a detective, and the gap between that role and the support people is huge. I trace it back, essentially, for the bad attitude system, and thing of having contempt for users. I have to say we often see the support people as our buffer against users, and we don't want to hear it, or whatever, and so we give these incomplete instructions to support people as a way of shielding ourselves, rather than a way of helping people out. I mean, ideally, you should have run books for these things, where the support person can intelligently look through steps to do, or things to check, or whatever, that are explained so they don't end up with who you're talking about, like, “Oh, this is a solution thingy.” It's like people who don't understand how medicine works giving injections because injections work, and then it turns out they're injecting dirty water. So, I think that, yeah, there does need to be a person or people with that escalated role of, “Hey, I'm going to go find out what to do about this.” But if you don't take that extra step of then rationalizing that into something that your perfectly capable and not inferior support person can then communicate to your also not inferior user, then you might as well be back in the 90s, manually typing every single thing that needs to be done, and telling everyone else to get away from your desk.

Corey: This episode is sponsored in part by ParkMyCloud, fellow worshipers at the altar of turn-that-[bleep]-off.

ParkMyCloud makes it easy for you to ensure you're using public cloud like the utility it's meant to be. Just like water and electricity, you pay for most cloud resources when they're turned on, whether or not you're using them. Just like water and electricity, keep them away from the other computers.

Use ParkMyCloud to automatically identify and eliminate wasted cloud spend from idle, oversized and unnecessary resources. It's easy to use and start reducing your cloud bills. Get started for free at parkmycloud.com/screaming.

Corey: There's this idea of the “Department of No,” and I've heard it applied at different times to systems administrators, network administrators, security engineers, one very ornery barista, etcetera, and it seems like there's this adversarial historical culture where there's this natural tension that tends to exist between development and operations, whereas development wants to release features more rapidly. Operations, on the other hand, wants to maintain stability, and if things are working right now, well change has the potential of disrupting that. And there's a natural tension, and a requirement to work together that I feel is part of the DevOps movement came out of. Is that something that you see?

Conrad: Yeah, and it's not at all specific to tech. And I think tech people can learn from how this works in other environments. My very first job—I was very lucky I got a professional journalist job and I wasn't even finished with college—and I got to see how a circa 1986 newspaper worked. And so, you had editorial, so we write, and we get photos and we edit things, we produce what we call nowadays, the content; and we had advertising, where they sold the ads, and then they would end up with a spec for an ad and how big it would be; and then you had production, who had to take the editorial stuff, and the ad stuff, and make a newspaper out of it. And we all hated each other. The editorial people didn't have what anybody needed: it was too long, or too short, or angered the advertisers, and it was always late. And the salespeople were always coming in at the last moment with something stupid, or dictating what to be read, or saying, “Please move the coffee cup on this thing. 0.3 inches to the left.” And the production people had to take all of this stuff and make a newspaper out of it, and it never worked, and so they were, so to speak, the BOFH sysadmins of this triad, and it was terrible.

It was a weekly paper, and then we would have these screaming fights, we’d put out the paper, we'd all go out drinking, and then we were friends again the next day because everybody understood that tension was going to happen. It’s not going anywhere; it’s how these things work; it's how the paper gets put out, and how we survive. And you have to manage that tension, and do your best not to be a complete jerk about it, but it's not going away, and the best thing you can do in that situation is to be less of the stereotype you want. So, as a sysadmin, I would, like, not be the “Department of No,” I would be the “Department of Hang On, Let's Get This Thing Right And Get You What You Want.” That I'm not saying, “No.” I'm saying, “Please don't do this by pouring gasoline everywhere and striking the match, but I'm not going to hold you back. I'm going to get done what you want to do.” And I think every job I've had along the way has had some variant of that tension. The difference in tech is that I think that everybody's a little immature and they think they can win: the bosses, the devs, the marketing people, the sysadmins all want to win the argument, and that's not how anything gets done. What you have to do is have those arguments, get things nailed down, and continue to cooperate, while knowing that this tension, in fact, isn't going to go anywhere; nobody's going to win.

Corey: I feel like there's been a forcing function, at least, because you have development and operations. Both are required to work in relatively close proximity in order to get things out the door. Every time there's a release, that is a forced interaction. You see the same thing with the media interaction that you just described. This, I think, is the root of my actual problem with the term FinOps: the idea of finance and operations working hand in hand. There's nothing that forces that tight coupling. One of them is definitionally going to be a leading function, and one is going to be a trailing function, and which one you pick to go in which spot has a lot to dictate what culture you're building. I don't think that there's ever a story where you're going to have those people working in lockstep together on an ongoing close-quarters basis in the same way. I think that the answer to the cultural story of FinOps, if you will call it that, as a direct result is simply distilled down to make sure that you keep different business departments in the loop, and remember that we're all here to work together collaboratively, rather than being massive jerks for the fun of it.

Conrad: Yeah, the question of why are we here, and what are we doing? And when the tech people don't seem to want to answer, you have to—I mean, if you're working for a business, what you're doing there is the business's goals, which are in some level to make money. If you're working for highway patrol, you're there to protect people's safety, and blah, or whatever, and you have to start with that and end with that. And FinOps—I hadn't heard that one—is terrible. I mean, sure, ops, if you want to call it that, has to do with the business does just as everyone from the janitorial staff, to the drivers, to anyone else in the organization does. It's not special. Tech people aren't special. And I've had these ridiculous arguments in the past where someone wanted to do something that was expensive and difficult solely because of some kind of tech purity reason and became enraged when someone asks, “Well, what is this going to do for the business?” So, yeah, you do have to work with—tightly—what the whole organization needs, whether that's finance people, marketing people, the person who sits next to you.

Turning it into a buzzword for a particular thing, I think obscures that essential problem that tech people need to get a little bit out of their gamer chair and realize that what we do all day is for the end of somebody else, that someone else is either paying for it or needs it, and that we're there to provide them something that works, rather than them begging us for something that we have that’s precious. So, yeah, I don't like that concept of FinOps. I just think, “Right, well, everything is BizOps or OrgOps, right?” And you do have to know what your organization is about, and that you're not rowing the opposite way from them, or whatever buzz word you want to put on it. And that is not easy culturally for us.

Corey: That's one of the problems that we see with, I guess, junior consultants, where it's easy as hell to come into any environment and say, “Oh, what have you folks built? Draw it out, or describe it for me.” And at the end, “Well, that's stupid. What complete moron built this?” Invariably you ask that question to said moron, and in virtually every case, there is something that that person is missing, and that thing is context. No one, unless they work at Twitter's verification program, shows up in the morning hoping to do a crappy job at work today. Everyone is trying to get something out the door and achieve a business outcome. There may be constraints you're not aware of. Yeah, I can look at architectures from 20 years ago and, “Well, why don't you use some service that didn't exist back then? Oh.” Or people may not have been aware of an alternate way to do things, or there was a strategic imperative to maintain some level of agnosticism, for example, there are a bunch of reasons that things could be radically different, but that's also with the benefit of hindsight. Remember, however broken and terrible it is, it's gotten them this far to the point where they're hiring said consultant to come on in and take a look at things. There's not a lot of value in just insulting the current state of the art. a child can draw a whiteboard diagram that shows an architecture that works super well. The problem is how you get from the current state to that future state, or something like it, without shutting everything down for 18 months.

Conrad: Yeah, again, this is a cultural problem on some level, again, about tech being special. When I worked in healthcare, I worked with physicians, and they have the worst tech support job on the planet. Awful people show up and lie, and they smell bad, and they've done everything wrong, and you still have to do your job—if you're a nurse, a doctor, anybody in healthcare—and you don't do that by being a jerk, and assuming things, or whatever. Everybody arrives with their story, and you have to deal with it. And with technology, it’s the same. When you say Junior consultant, you walk in, and somebody has this horrible thing you need to fix, well, you're going to go into a room with their friends and cuss about it later, right?, “Oh my god, what are these people are doing? They bolted something onto ColdFusion to run Java, what year is this?”

But you can't do that with them, or even, you can't keep that attitude while you're working at it. You have to say, “Oh, wow. Okay, this is a big challenge. There's something here that needs to be improved.” And we had to find out how much can be improved, and what we can do for these people, and try to suss out what the brokenness is in the organization without saying the organization is broken, we can get something done. Sometimes it means you have to turn something down. So, the essential thing there is, you arrive quite often with negativity in a mess. You know, the times when you have a greenfield thing that you can do yourself from the ground up, and what you think of is right, are very rare. And also, when you look back on what you've done, quite often you think, “Oh, my God, some unfortunate person is probably fixing that right now.” So, I think yeah, the thing is, you can't get rid of that challenge, but just as the way that everybody from nurses, to waiters, has to go in the backroom before they start cussing, about how idiotic that thing is, I think that as tech people, we should do our best to treat people as we would patients with a problem or people who want their fries done extra well, and suck it up to a certain amount, and treat it as something to improve rather than something to be disrespectful about.

Corey: I think that that's the attitude to take with these things. As much fun as it is to be snarky and cynical and, I guess, difficult on the internet, we work with people, and everyone's trying to do the best they can with the tools they have available. And I think that we still struggle as an industry with empathy.

Conrad: Yeah, it is. And I mean, a lot of it is just unearned arrogance from the past. I mean, some of the people who originally came up with this stuff had to deal with, really, weaponized stupidity, and people who didn't understand anything at all, and didn't want to, and so forth. It is a somewhat different world now that your, so to speak, your customers do have some idea of what's going on, or whatever. And also, you're not all that. I mean, we're not the people who invented the internet. We're more like our customers than we are like Eric Allman, or whatever, you know? So, I think, yeah, that empathy and a certain amount of humility is a very important thing and attitude. There's a thing that I call the fish food syndrome. So, let's say you have some friends, and they have a goldfish, and they don't know what the hell they're doing. They're feeding the goldfish like hotdogs, and oatmeal, and gasoline, and dumping stuff in the bowl, and they kill four sets of fish. And they don't know what they're doing. Well, what you really want to say, “You are ridiculous. Goldfish get fish food, and not that much of it, and you have to clean the bowl. What are you even doing? You’re a fish murder.” It won't work. They'll get mad at you. They won’t be your friend anymore, and they'll keep killing their fish. You come back to them and say, “You know what? I heard about this awesome thing. There’s special food for fish; only for them. You just give them a little of it; it works great; your fish won't die. What you want to do is go to the pet store and say I got some goldfish. I need some fish food. They'll help you out. It's not expensive and it's going to make your fish really great.” And then it'll do it. But you kind of have to be next to them. Like, “Oh, we have this thing that we're both looking at,” rather than, “Are you completely high?” You’re shifting into reverse at 60 miles an hour. Not only will you be hurtful to people, which you really shouldn't be, but at the same time, you won't get anything done, and people will hate you. So, you do have to go to that level of, I'm not all that either, but I've got a secret I can share with you, and then I can help you take care of it. And together, we're going to get things done better.

Corey: So, Conrad, if people want to hear more about what you have to say, where can they find you?

Conrad: I don't know. I mean, I use Twitter, but like most people, I use Twitter in a way that is not particularly handy for technical people. Mostly, it's me yelling about things, sometimes profanely or—

Corey: I don't know what you think technical stuff is, but that's where I live.

Conrad: Right? Right. But there's only political stuff, and shitposting, and pictures of cats, or whatever. I used to write on the internet, a lot more. I mean, I did my decade of LiveJournal. And there is a blog out there, but it's old and not that great. So, I don't think I really have a place. So, yeah, my Twitter handle is @substitute. You can go there and look, and you might or might not like it, but it's not exactly a fount of technical information.

Corey: Yet. There's always hope for a brighter tomorrow.

Conrad: [laughs]. There you go. Maybe I'll reinvent myself and start producing useful information. It’s always possible.

Corey: Thank you so much for taking the time to speak with me. I appreciate it.

Conrad: Great to be here. Thank you.

Corey: Conrad Heiney, principal cloud engineer at Glidewell Dental and @substitute on Twitter. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. If you've hated this podcast, please leave a five-star review on Apple Podcasts and a comment explaining why it is either the fault of development or operations.

Announcer: 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.