Screaming in the Cloud - Episode 68: The Rise of the Cloud-First Generation with Christina Warren

Episode Date: July 10, 2019

About Christina WarrenChristina Warren is a Senior Cloud Advocate at Microsoft, where she helps shape the overall strategy for Developer Relations in Azure. As an advocate, she hosts shows on Channel 9, Microsoft’s video channel for developer content, speaks and creates content at events, conducts on-camera technical interviews within the developer community, and liaisons with product teams across the company. Prior to joining Microsoft, Christina spent a decade in digital media as an editor, senior reporter, and commentator, with a focus on technology, business, and, entertainment. As a journalist, she appeared as an expert or commentator on ABC, NBC, CBS, CNN, CNBC, Fox News, Fox Business, Bloomberg, the BBC, Marketplace Radio, The Today Show, Good Morning America, and many more outlets.She also co-hosts Rocket, a popular tech news podcast, which has the distinction of being one of the only tech podcasts with an all-female hosting team.Links ReferencedTwitter: @film_girl http://christina.is/Rocket on Relay FM

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 and we'd like it if you would give us some of that. DigitalOcean is neither. From my perspective, they bias for simplicity. I wanted to validate that, so I polled a few friends of mine about why they were using DigitalOcean for a few things, and they pointed out a few things. They said it

was very easy and clear to understand what you were doing and what it took to get up and running when you started something with DigitalOcean. That other offerings have a whole bunch of shenanigans with root access and IP addresses and effectively consulting the bones to make those things work together. DigitalOcean makes it simpler. In 60 seconds, they were able to get root access to a Linux box with an IP. That's it. That was a direct quote, except for the part where I took out a bunch of profanity about

other cloud providers. The fact that the bill wasn't a whodunit murder mystery was compelling as well. It's a fixed price offering. You always know what you're going to end up paying in a given month. Best of all, you don't have to spend 12 weeks going to cloud school to understand all their different offerings. They also include monitoring and alerting across the board, and they're not exactly small time. Over 150,000 businesses and 3.5 million developers are using them.

So give them a try. Visit do.co.screaming and they'll give you a free $50 credit to try it out. That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by senior cloud advocate, Christina Warren. Christina, welcome to the show. Thank you so much. I'm so excited to be here. I first found out about you years ago when you were a guest on the Accidental Tech podcast. And now you're on Screaming in the Cloud, which is undoubtedly a brand new career low for you. So first, my condolences. Well, first of all, thank you. That ATP episode was one of my

favorites. So we actually swapped hosts that week. So John Syracusa went to Rocket and I went on with Marco and Casey. And I still, it's funny, this just shows the reach of their podcast. Like I still have people like you who are like, oh, I first knew you from that. And I'm like, yeah, I will probably never reach an audience like that. I am still astounded when I get stopped at cloud conferences invariably.

And I'm asked, are you the person from the podcast? And it's, oh, wait, how do you know what I look like? I have a face for radio. There's a reason I do this. And it's always strange just seeing where people come in. It's, it's weird. Then you start getting loud on Twitter or to a newsletter or go fall in love with the sound of your own voice and give conference talks as I've done for entirely too long. And it's, you never quite know where people first hear of you and start following you. Yeah, no, that's great that ATP was your entry point. That's awesome. I did not know that. That's really cool.

That's still one of my favorite podcasts. It really is. Whenever I get the chance, I listen to that, but it turns out there are not enough hours in the day for all the various podcasts out there. This is becoming a real problem

that we're now adding to, obviously, but it's kind of like peak Netflix. We're not at peak podcast, but it's one of those things where I'm like, it used to be something you would do on your commute, and now you're like, you know, peak Netflix. I mean, we're not at peak podcast, but it's one of those things where I'm like, I used to be, it used to be something you would do on your commute. And now you're like, oh,

but if my commute were four times as long, then I could get through my podcast. But. Increasingly, it seems like the most valuable commodity we all have is attention. And because that is finite, we can't make more of that. And someday I'm sure the most valuable commodity

will be water. But until that societal collapse, attention seems to be it right now. I think you're right. Yeah. So once upon a time, you were a journalist. I was. And now you're a cloud advocate. I am. That is atypical as far as career progressions tend to go. It is. It is. And it's funny because I'm actually going to be giving a talk tomorrow kind of about how I switched careers. And the interesting thing, though though is that I was kind of an atypical journalist in terms of how I got into that too So even though it's a very Uncommon trajectory it sort of makes sense in my life

So as long as I can remember the two things that I will the three things I guess that I've loved the most have been computers technology gadgets, whatever pop-c, and writing, and, or storytelling, whatever. And when I was, I guess, when I was 12 years old, I was in a bike accident. And I ran into a tree and messed up the side of my face and, you know, broke my jaw and all that good stuff. Fortunately, no scars. And when my mom, when we were coming back from the ER, from getting the x-rays and stuff, she was like, you can have whatever magazines you want

as like solace for me breaking my face. And I'd already had that months like Teen Beat or 17 or whatever. And I'd already decided that I'd wanted to make it like my summer project to learn about computers. And so I picked up two issues, one of PC World, one of PC Magazine. I didn't understand really anything

that was in them or on the covers. And I just started reading and going to the library. And this was before I had the internet at home and just really nerding out and loved it, just loved it instinctively. And so I did web development stuff and I didn't study CS in college because when I took programming in high school, I didn't really like the people that I was in the classes with.

And I was like, I don't want to spend four years with this. And my whole career, even as a technology journalist, a lot of times I was way more technical than a lot of the other writers. But, you know, I had to explain things to a new audience. And then I come over to Microsoft, and I'm still a very technical person, but there are people who are way, way more technical than me. You know, so I kind of go from being, like, the person who was always having to kind of dumb myself down to being like, oh, man, I need to, like, step up. But if I think about it, the things that I did as a technology journalist and the things that I do in DevRel aren't that different insofar as, you know, I would go to conferences like we're at Microsoft Build right now. I would go to conferences as a journalist and I would talk to developers and I would hear about the things that they were excited about or the things they were mad about. And I would try to advocate for them. And I would try to like write articles that I would hope that the companies

were reading saying, these are real issues. You know, these are the, this is why this platform is taking off or this is why it's not. And really, these are the, this is why this platform is taking off or this is why it's not. And really kind of get the feel for those things because those people are my people. I've always been, you know, friends with developers, whether it was like web or app or whatever. And now that's still kind of my job, right?

It's just, I can now go directly to the product teams rather than having to, you know, scream, you know, on the internet. I can just go directly to the product teams rather than having to, you know, scream, you know, on the Internet. I can just scream in person. So it's still, it's an uncommon career, like, change. But a lot of it really does come down to liking the audience, liking the content, and then wanting to advocate for those people. It also speaks to a mature advocacy organization that doesn't approach you and say, well, we absolutely love your ability to tell stories. We love the credibility you've built up in the space. But in order for us to hire you, you have to solve an algorithm challenge on the whiteboard. I've gone through interviews

like that in years past for developer evangelist style roles. And the question was always, well, what is the purpose of this? Well, we need to make sure that you have technical credibility in front of an audience. Cool. How do you hear about me and consider me for this role in the first place? Oh, you have a massive following and massive credibility in front of the audience. Did you hear those two sentences put next to each other? It becomes a very strange story. And that's what it's about for me, is at least the storytelling aspects of it.

And that's one of the things I find compelling about Microsoft as a whole is a very practiced approach to telling stories. Satya's keynote on day one of the conference was pitch perfect, probably one of the best delivered keynotes I've ever seen. Every word was very intentional, emphasized correctly. And when I tweeted about that, I got a few responses of,

well, was he reading from show notes to do it? Yeah, I don't care what tool you want to use. I don't care if you have an earpiece, someone whispering what to say in your ear. Stand in front of 2,000 people and give a talk. You're going to be nervous. And spoiler, you're going to do a terrible job, at least the first few times you do that. It doesn't matter. It's just the ability to tell a compelling story

and deliver that well is fascinating. I agree. And I also, you know, okay, so does he have a teleprompter? Does he have show notes? Do you know how hard it is to read off a teleprompter? I do it all the time. I've become very good at it.

It is very difficult. And there are people I've become very good at it. It is very difficult. And there are people who are so much better at it than me. And so people who say that, the first thing I think, I'm like, okay, well, you've never done this. Because if you did, you would know that in many cases, it's actually harder to read off the teleprompter than it is to be extemporaneous or to memorize. Most of my speaker notes when I'm giving a talk on the bottom of slides are either bullet points or things not to do. Don of my speaker notes when I'm giving a talk on the bottom of slides are either bullet points or things not to do. Don't make this joke

because it's coming in three slides. Good, because after you do that a couple of times and realize you've completely neutered your own joke, Right.

you kind of don't want to do that again. No, I'm the same way and when I give talks and whatnot, my speaker notes are usually bullet points, usually not scripted.

There has been, I've been part of Microsoft Ignite, the tour for the last few months, and those talks, which are more structured, and I'm not always the only one giving them, are a little more rehearsed and practiced. And at this point, I've done them so many times that it's pat. But in general, my whole public speaking style

usually is tended to be more extemporaneous. And I don't say that as a brag. That's the easy way, right? Like, to me, people who have something really well practiced and rehearsed and written out, like that's a skill that I don't have. I mean, unless it's on a teleprompter that I can read from. One of the best things I ever did to learn to give a decent conference talk was to give a bunch of really terrible ones first. I started this way back in the early days of 2012 in the dark ages. And there was a project I was working on,

SaltStack, as it turns out, which did not do as well in the market as anyone wanted it to. It's sort of not really where the zeitgeist is. But this is amazing. Why is no one talking about this? Good amazing. Why is no one talking about this? Good question. Why aren't you talking about this?

So I put documentation on slides. I read my slides to people. I mumbled into my own shoes. And eventually people were like, that was great. Now here's how you could do that in a way that isn't objectively terrible. And it got slowly better. But for me, the breakthrough was when I was a traveling trainer for a puppet, going into different cities, sitting down in front of people

who'd paid a fair sum of money to learn how this worked. In some cases, a very hostile audience because they perceived rightly or wrongly that this was going to automate them out of the job. And they were sort of forced to be there by their employer. And then periodically, because computers, demos would break. So the first week, I'm white-knuckling this the entire time. By the first week I'm white knuckling this the entire time by the third week it's okay. I sort of have this. And by the seventh week it's,

this is super boring. I'm giving the same exact talk for three days and doing the same jokes and you mix it up a little bit, but past a certain point you, you get tired of telling the story the same way and you want to start improvising and having the flexibility to do that when giving the same talk repeatedly is important. I agree. So from your perspective, when you're on Ignite the tour and traveling to all these different places and giving what is fundamentally the same talk that you've given a bunch of times, but is new to the audience, how varied do you make that? You know, I haven't been varying it too much this time. I think when we do the tour next year, I might mix things up a little bit more. Part of that has been because we have the slides that have already been localized for whatever language they might be in.

The other thing is that even though, and this is a challenge that I haven't ever had before, in many cases, English might not be the primary language of the country that I'm speaking in. So that means that I might have a live translator where someone will be translating as I'm speaking in people's ears, or we're having the closed captioning translating happening. And so for those reasons, I don't wanna play too much with the format, but you're right, because that is something I always think about.

I'm like, I would really like to mix this up more and maybe make this more innovative. But sometimes it's, you know, a challenge when you have other things to consider. And so in those cases, I'm like, all right, you know what, me, I'm not the, I'm not the goal of this, right? That's, I think the important thing too, is recognizing in some ways, and this isn't always the case, but I think this is important to know, like when you are the focus of the talk, when it is kind of about you, and when it is not, when it is about the content. And in these cases, it's not about me. They want to get the information, and I want to present it the best way that I can.

But it's not the Christina show. It is about getting the information people and explaining things. And then hopefully being able to answer their questions and provide them with more resources at the end. It's about the audience. It's never about the presenter. You're right. I mean, there are a few times when you might be giving a more personal talk or might be something about your background where you can take that on more, but you're exactly right. But sometimes I think that, especially those of us who speak a lot, can kind of get caught up in that idea of, oh, you know, it's about me and what I want to project and what I want to do and it's

like no you know it's not always and sometimes you really need to even if it's boring for me to do the same talk over and over again and to be clear it hasn't been because again you know these other challenges of do I have a translator am I you know how well is the audience going to know this and whatnot um then you know that that's that's enough of's enough of a difference to not make it the same old, same old. But even if it were, I think for this particular thing, I understand the context. It's like, this is for them. This isn't for me.

One thing that you've talked about previously in other shows and things that you have done has been talking about how you view developer advocacy. And I think a common misconception industry-wide is that to do that, you need to be a public speaker. The way you've defined it, it sounds like you cast yourself almost as more of a public listener of talking to customers and more importantly, listening to customers as opposed to some companies that talk at customers, but that's a separate problem. Right. So I guess one of the questions I have is when you're out there talking to people

who are using Azure for various business tasks, for setting up new things, for exploring, what have you learned from them? I learn all the time what pain points are. I learn maybe what we're doing well, what we're not. And those are the things that I really want to take back to the product teams and then help maybe if I see something strategic that we might be able to do, I want to like help, you know, improve that. I learn all

the time about, you know, whether our message is getting across or not, because there are many times I think, and this is why I think advocacy is important, where, and it's not the product team's fault, I'm no way dismissing them, but you know, engineering, you have certain goals, and you are in sprints, and you are kind of in your own head, and you're getting, you know, engineering, you have certain goals and you are in sprints and you are kind of in your own head and you're getting, you know, your project done and you don't maybe always have the best insight into how are people really using this or not using this. Like, of course you have internal telemetry and analytics and you can see things on Twitter, but if I'm talking to someone and they're saying, you know, it's really hard for me to, why can't I take a custom image and move it to a different region or a different subscription? Why do I have to copy things to a new VM and a new storage blob

and do this process? And it's convoluted and I do this repeatedly over and over again. And I have scripts that will do this for me, but this is not a seamless process. And I'm going, you know what, you're right. And I can talk to the product teams and know the technical challenges around it. And I can empathize with that and I can try to express that to the customer, but I can still say, okay, but this is still a really big problem. And we need to continue focusing on finding a solution because this is something that's impeding the way they're using things and what they're doing. You're talking about something that started to, I guess, tease at the back of my mind. So at the beginning of, I'm recording the show

at Microsoft Build, and during the first day, waiting for the keynote to open, I had half an hour to kill. So I spun up my first Azure account, and I decided to spin up a VM. I was live-tweeting the entire experience because I don't have an internal filter, and the entire world cares

about everything I'm having for lunch. And I started tweeting the experience. There were a lot of great things at it. And then, huh, spinning up a single VM and it defaulted to picking a Debian release. And oh my stars, that brings me back. And it was fun and exciting. And it took 19 minutes and 22 seconds to provision.

And I'm, huh, this seems kind of slow. And people chime in and start looking into the problem under the hood. There was an issue with the storage layer in that region at that time. And I have this knack for finding corner cases by blundering into them. And one of, I think one of the directors of compute wound up, one of the directors in container services wound up chiming in and digging into this. And it was the customer service experience was exceptional, but I'm starting to realize now that by being loud and noisy, even though my cloud bill personally

is 20, 30 bucks a month, I do not at this point have the typical customer experience because I am perceived, rightly or wrongly, as being loud and influential. I am loud. I would argue whether I'm influential. You're influential.

I try. My mother tells me so, and I try to believe it, but you know how mothers can be. The problem I see as I look at this, though, is I don't have a bearing anymore on what the quote-unquote typical customer experience is. I don't know. For example, is that something that anyone who had that problem and tweeted about with Azure, would they have experienced that? I'd like to hope so, but it doesn't scale. It doesn't scale. I don't think that you would see the director of compute

responding to somebody with 200 Twitter followers, right? Like if we're being honest, like I just don't think so just because I don't think it would hit their radar. But what has impressed me, and I can't say this for all the times, is how many times I will tweet things and obviously I'm influential in so far as any of us are

and I'm loud and have a following too. But I'll tweet things without tagging people or just might be innocuous. And the tweets will be found by some of the QA teams who will then comment and reach out. So people are actively looking for these things all the time and gathering that feedback. And I think trying to help when they can. And it's not always going to be that direct kind of hand-holding, let's investigate what the issue in this region is. But I think that the goal is to hear as many inputs as we can.

And even though it doesn't scale where every single person is going to be able to have that type of experience, we do want to be able to, when I'm talking to people, I don't know or care what their cloud bill is. If they're having feedback or if they're having an issue, I don't know or care what their cloud bill is. If they're having feedback or if they're having an issue, I want to connect them with somebody who can solve their problem, period, right? Like that to me is the goal. And that, whether we succeed at that or not, you know, it's up for other people to determine. But I think that's always the goal is to get people's questions answered. And I would hope that the experience would be, you know, realistically, you're not someone else who

doesn't have your following isn't going to get the same level of like maybe handholding. But I would like to think that there would be things in place that would, you know, people would pick up on and be able to say, hey, this is going on or, or have you tried this? One thing that I will say and go on record with is that this is not at an individual level something that I see as a differentiator between any of the public cloud providers. Every individual employee I know and all of the major players has something very similar to this attitude. If a customer is having a bad time, that's a problem and needs to be addressed. The challenge that I see and where I think Azure is excelling in this space

is in making it very clear in communicating to its existing 40-year history of customer install base that they are very interested in talking to them, in learning from them, in supporting them wherever on the curve they tend to be. And sure, the future is going to be not purely but largely public cloud driven and if you're not there yet today, that's okay. There's no sense of we will begrudgingly go ahead and give you an offering that sort of works for your current environment but you really have to move, clock is ticking.

It's much more of a we are here when you are ready to go here as opposed to taking a data center and slowly flooding it and as the water rises higher and higher up the rack. Ha ha ha, you better come. I told you, I told you, we told you. No, I mean, I think you're right.

And I think part of that is when you have, as you said, like a 40 year old business that has differentiated business aspects, right? So which is going to be unique in our space where you have like lines of business that have existed for a long time where we have, we know, A, firsthand how important some of those workloads might be and how difficult it might be to migrate them as much as we might want them to. And also just the fact that some people might not want to do that. And, you know, I think it's kind of legacy is always a difficult thing to kind of figure out how long do you support something? When do you kind of force people to move on?

But Microsoft has a very, very well known history of supporting, you know, legacy things, some would argue too much, right? So I think that that is part of kind of the goal is that, yeah, we're here for you when you're ready, but we are going to continue to offer other offerings too. Obviously, the benefits of cloud and iterative development are that you get updates and things more quickly. And I think Office 365 is a great example of that. There's still a standalone version

that is kind of locked in time and you'll get some maybe security updates and whatnot. But if you want to get the frequent feature updates that are pushed all the time, you need the cloud account. And, you know, I think that for a lot of people that can be a compelling reason to do that. But there might be some people who are like, no, you know what? I don't care. I just want my, you know, perpetual license. And that's it. There's an entire class of user out there who if you move an icon, the thing is broken, They open a support ticket. I've been accused of being insulting when I say this before,

and it's never intended that way. But Microsoft has 40 years of experience in apologizing to its customers for software failures. And you need that expertise when you're working with cloud. I'm sorry, it's computers. It breaks. That's what they do.

And communicating that to the customer in an effective way that, first, expresses empathy with them, but secondly, says that, yes, we know this is a problem. We are working on this. Thank you for continuing to bear with us on this. And communicating that well and not leading to the various gossip rags, tearing the company down in the tech press, is a skill in its own right. And it's one that I think Microsoft can foundationally teach a masterclass in.

Oh, I think you're right. I mean, and because you're right, I mean, with that history and with products that are used by as many people as use them, even if you had the highest level of QA in the world, you're still going to have issues. They're computers.

And even direct honesty doesn't work here. Well, if your software had been written differently, our outage wouldn't have taken you down. While true, and while something useful and valuable to communicate, if you're not very careful with the phrasing, it sounds like you're blaming the customer. Exactly. I mean, that's the thing. And when we have outages, and that happens at every company, I've actually been impressed with how well some of the technical write-ups are, because this used to be what I would do as a reporter. You know, AWS would go down

and usually be like an S3 bucket in North Carolina or whatever, right? It would be like Eastern region and it would go down and then the entire consumer internet goes down. And you have to explain to mom and dad why Pinterest isn't loading. And they don't care about the various esoteric things of, oh, well, if they had multi-region

or this or that, they don't care. They're saying this is down. And sometimes, and I always feel so bad for the DevOps people and the SREs in those situations who are getting the calls and are trying to get things up and running, because you never know what's going to happen. But sometimes, getting the information about what it is, it can not always be easy. I think Amazon has actually done a really good job as of late of making those, you know, communicating better when those things happen.

In some ways, they've been forced to by their own customers. Right, right. But that's something that, like, I have, when we've had outages, you know, I always look for because people usually aren't coming to me, like, they're not yelling at me about it. But, like, I do a weekly show on our YouTube channel, this week on Channel 9. And if we have like a major like outage, like I need to talk about that, right? Like I need to actually be able to explain this is what happened. And this is what we're doing about it. Because otherwise, I don't think that that's authentic or helpful, right? Like if this is, we're publicly communicating with people, we need to do that. And so I've been really impressed with how well some of the

write-ups have been, like the postmortems after the fact, right? Like you have the logs as it's happening, but the postmortems after the fact, I'm going, oh, that's interesting. And then when you look at that, you can kind of understand, wow, these are massive challenges. And these are like maybe a set of events and circumstances that would not be anticipated and that would be whatnot. And in some ways, I almost wish that we would have some of our instances be used as almost like a class or talks for our users to be like, this is what we've learned from this and this is how you can learn from the same things that we have because the challenges aren't wholly unique, right?

Like, you know, a data center going down and maybe or part of it having an outage because of something being configured the wrong way or, you know, maybe like an errant weather condition or something else and not having made decisions for whatever reason to architect things that might have made that, you know, not happen. When you learn that, when you look at what are the trade-offs, those are interesting discussions to have with your end users too, because they're going to be, they're not worrying about the data center itself, but they might be having to worry about their own, you know, places where fault might happen and how they're going to recover from that. Like, I think that it's not unrelated, right? And there are lessons to learn from that, period.

And one of the most understated parts of the cloud as a whole is let's say that I write a reasonably terrible web app because that's the level of developer I am. And then as soon as it's done, I make the final commit, I host it on a cloud provider, and then I sail around the world. Ten years later, I come back because I'm as good at sailing as I am at writing code.

If I'm running this in a cloud provider, things are great. The storage has gotten faster. The reliability has increased. Whereas if I leave this running in my own data center, the raccoons have taken it down by year three. Things inherently get better as opposed to succumbing to bit rot. And that's something that I think is not talked about nearly enough. I totally agree. I totally agree. The one thing you have to keep in mind though, is that if you're selling around the world for 10 years, your software and stuff, your VMs, they've all been updated, right, to keep up with security. But like your code might not,

might stop working. Oh, you're assuming my code ever worked in the first place. That's beside the point. It's my code. Come on now. Well, you know what I mean? Like, I mean, I think that's something that, but is different. That is also, I mean, this is great, but this is also, I think that's something that is different. This is great, but this is also, I think, sometimes a challenge and a thing with educating people is saying, okay, yeah, once you have this, this is great that these things are going to be staying up to date and get the patches, but if a version of PHP finally has been out of support for a long time and we're going to cease it and force an upgrade on the library to that,

if your code hasn't been updated for that, it might break. This is also part of the advantage of a serverless story as well, where it's, okay, my code might still be crappy, but I don't have to worry about the TLS piece or the web server or the patching. Yes, I 1,000% agree. I think that is the wonderful part of the serverless story, and hopefully we can get some more of that where because ultimately that would be a great thing to not have to worry about that stuff or something's upgraded you know underneath me and now my stuff

breaks because that's like and then that's a hard challenge too right like how what how much do you just let people use out of date out of non-, right? Like, you could conceivably let them do it forever, but is that the right move, you know? It's always a problem. I used to work at a web hosting company running a giant WordPress grid, and that's awful. The plug-in problems,

the outdated version of PHP that everyone was using and people are paying 10 bucks a month for it. You can't break all their sites and uplift them. You'll lose the customers. How do you solve that problem? And this sort of gets at one other point I wanted to talk to you about. You have entered technology as a profession through what I would classify as a nontraditional path.

And everyone I talk to at this stage of the game seems to have come from a few different pathways that are increasingly closed to people who are entering the workforce today. Well, how do you get really good at cloud? Well, spend a couple of decades building out data centers and things like that. Oh, spoiler, you're going to be woken up in the middle of the night and have to fix something at 2am while crying. And it builds character because character is what you get when you don't get what you wanted the first time. And you iterate forward from there. Well, today you can leapfrog over that entire thing.

My daughter is two years old, and I'm not going to be teaching her QBasic as how to use a computer. She instead turns and talks to the robot lady who lives inside of the phone or the speaker on the counter or something. And that is her interaction with technology. And I guess not that I'm trying to plan for the two-year-old case, but people who are graduating college today in 2019 or considering a career in tech, where does the next generation

of cloud-oriented developer types come from? I think they come from people, the way they've always come from, people who tinker, people who play with things, people who are getting excited about things. It's just the way you're tinkering is different, right? I mean, I think we were kind of talking about this before we started recording that I think it's interesting to think about that, you know, the kids that are graduating from college now were, because the cloud is, public clouds have officially been a thing for long enough, they're literally like a cloud first generation, you know, and that the

training and the teaching has gone that level too. So they're not going to have the experiences dealing with the old shared web host or dealing with having to maybe rent their own servers or co-locate or whatever. They've always known a world where the cloud has been what they use, what they deploy to, what they develop on, how they deal with any of their networking stuff. And it's always been flexible.

They can always add more power or take things away. And I think that's interesting because in some ways, that's going to kind of force the rest of the world to maybe catch up. But I also think it's exciting because those are the people, when I look at Visual Studio Code,

which is even if I didn't work at Microsoft I would be such a huge fan of that product I think it's such an amazing editor

it is incredible and the one thing I'm waiting for is I want it to work on my iPad Pro yes which hopefully you know with the preview that they announced

this week of the online hopefully they're dancing around it there's just one missing piece. I know. I know. Because I want it on my iPad Pro as well.

Like, that's the dream, right? Like, that's ultimately the dream. And I think we're getting super close, especially with some of the remote stuff that they're doing. Like, we're almost there. But... I'm old and grumpy.

And I'm an old, grumpy Unix sysadmin, which we call sysadmin because there really is no other kind in that world. And my editor of choice is vim i've been using it that way for a long time but all my stars is visual studio code pretty it just works there are things i don't have to worry about right and and but my point too is that you look at the ecosystem around it you look at the people who are building some of the best most inventive plugins

you look at people who have even before we announced Visual Studio Online, were doing their own kind of implementations of Monaco, which is the open source, source of the browser engine or the text engine, I guess, for Visual Studio Code, where they're putting that in containers that can be run in a web browser. And it can be used on your iPad, right? A lot of people doing that work are like 21, 22, 23 years old. You know, you see so much stuff happening in JavaScript

that is in, you know, containers in general, but serverless, right? Like, are young people who are just playing around and excited. But my interview question still involves what level of RAID is the right one for this particular use case? Why? Exactly, right, which is particular use case. Which, why?

Exactly. Right. Which is wrong. And I mean, I think that that's one thing where we're going to have to catch up on how we interview and what questions we're asking and how we're assessing people's skills. And I also think, you know, sometimes you have to figure out what skill is important for this particular role. Right. And because it can change and it can alter. I mean, I always think the biggest thing

whenever I interview people is I'm wanting to know not what they know, but what they're willing to learn. And because to me, that's the biggest thing. Like I love to learn. I love it. I'm obsessed with learning and knowing as many things as I can. And, you know, I'm always amazed

to all the things I don't know, you know? Looking for curiosity, looking at the, tell me what you're, tell me what's something you're the best at. And it's great to have those conversations instead of, well, you're super good at X, Y, and Z. Let me find a crack in the knowledge where you don't know the answer to a problem that I had to look up to write. That's not helpful. That is looking for absence of weakness instead of hiring for strength. And that's philosophically something I've always been opposed to as a hiring manager. Yeah, I'm totally in agreement. And I hope that we can get away from some of those, you know, you have to do this on a whiteboard to get here. Because look, in some cases, that might be valid and completely necessary. And in some cases, it might not. Because like, for instance, my job,

it really doesn't matter if I can solve the problem on the whiteboard. What matters is can I communicate with people? Can I help tell the story? It's going to help people get what they need to get done. But even more importantly, like you said, can I listen? And can I then synthesize that feedback back, you know, to people who can actually make the changes? The last topic I'd like to cover with you is the divide between ops and dev. dev. How do you see that? I mean, it's so interesting because before I joined Microsoft, I really, I mean, I knew about operations, right? But I'd never really considered it two separate disciplines because a lot of the people that I know and people who work at startups, you know, that line ceased to exist a really long

time ago. Everybody kind of does everything. And so I didn't ever know, like, how, I guess, like church and state for some people it was, but I think it's disappearing over time. And I think it's good for a couple of reasons. And I think that it's been disappearing for a really long time. It's just becoming more visible now. And I don't mean that DevOps, you know, is the solution. What I mean is that I talked to so many operations people who will say to me when I before I talk to them, you know, I'm not a developer. And then they'll show me all of their Ansible or, you know, PowerShell scripts and all these things that they're doing all their tooling. I'm like, okay, I'm sorry. This is code. This is a lot of code. And this is doing the exact same things that somebody else would do. What are you talking about? I'm not a developer. And, you know, and sometimes you talk

to developers who might say, well, I'm not an operations person, but, and then they have these amazing build pipelines and they have tests and all kinds of things going up. So I think that we kind of have to get over this idea that I think that some developers need to stop being so precious and accept that there are all kinds of things that can be code and not just whatever they think. And I think some ops people have to kind of maybe open themselves up to the idea that this identity that I have, there's nothing wrong with it, but I can do more. And I'm actually capable of doing these other things. Just, you know, I don't have to just be responsible for this one piece. From my perspective, it's always been a strange reality of our entire industry that whatever tool

you're using today, whatever thing you're great at, assuming that you are more than five years away from retirement, what you will do by the end of your career will bear almost no relation to what you're doing today. And I've talked to a number of friends about this and I'm still gathering research, but I gave a talk with Sonia Gupta a couple months back on embarrassingly large numbers, salary negotiation for humans. And someone came up afterwards because we talked about different folks from different underrepresented groups and how that was communicated and how negotiation strategies differ. And someone said, that was great, but I didn't notice you talking about ageism at all in this. Totally. And at first, holy crap, they were right.

But the follow-up question, I don't have an answer for this. No, I don't. Is how much of ageism is based on actual bias and based upon things that have no bearing in reality versus how much of that is based upon, well, I've been doing this for 40 years and I continue to insist on writing Pearl for Solaris, at which point the industry has moved on and those jobs simply aren't there. Those jobs simply don't exist. Yeah. No, I mean,

I think it's probably a little both. I think more of it is probably bias, but I think some of it is people, because I talk to a lot of IT pros who are trying to, you know, they're freaked out by the cloud. They're freaked out by their jobs going away. I totally understand. I was that person. You know, but yeah, you've transitioned and you've seen the opportunities, but you've taken, like, you're the perfect example to me because you took the stuff that you knew as an IT pro and translated it into the cloud. And let me ask you, like, genuinely, like, how different are the fundamentals really? The fundamentals are incredibly important. Learning the fundamentals required exposure to environments that don't exist in the same way today. But I started off my career being very

deep in the world of large-scale email administration. Unless I want to work for maybe five companies, that's not really something everyone needs today. But I guess my point, though, is that those skills, though, like, how hard was it for you to then transition and maybe apply those things to what you do in the, to, you know, setting up maybe a large scale, you know, email organization in the cloud? It was applicable in the sense of going back to the idea of the T-shaped engineer, where you have to be effective in something approaching an operations style role. You need to have a broad baseline of relevant experience. And then for marketing and self-promotion purposes, you want to have one or two areas in which you're deep. And I started off being very deep on email. I then transitioned into configuration management when it seemed that that was not going to be a longer-term success play. And that seemed like a great play at the time.

And then this whole industry sort of pivoted around immutable infrastructure. And that seemed like a great play at the time. And then this whole industry sort of pivoted around immutable infrastructure. And that writing was on the wall. And my most recent pivot as an engineer was into this world of cloud. And only somewhat recently have I realized that if I have to pivot again and do something else, I'm almost certainly not going to find my next role as an engineer somewhere anymore. I've turned into something different that's really hard to define. But honestly, the answer is I'm not happy sitting there writing code for a living anymore. I used to love that. And now I find that I want more.

And spoiler, my code's really not that good. No, you want to look at the analysis. You want to look at the big picture things. You want to talk about those trends, which I think we need that. And that's important. But I guess what I was trying to get at is, you know, when you made kind of that transition from doing kind of the old world

things to going into cloud, I mean, obviously it takes a lot of work. I'm not trying to say that you can do it overnight, but it's not as if you had to learn a brand new language. Oh, absolutely. It's a series of half steps. It's the same way as when you talk to people in their career and they, for example, you were a journalist before this, and now you moved into effectively what is a technical role. Yes. And I'm technically a content engineer. So yes, exactly. And to do that, it was a lateral shift from taking things you were good at in your previous role and applying them in a new context to the role you're in. It wasn't what a lot of people think of a career transition being of, well, now you have to go back to square one and take an entry level job and a massive pay cut. Well, this is kind of my overarching point, right? And I think

that this is what sometimes I think people of all ages, right? This isn't just saying to the gray bears, right? This is something that people need to know that you don't have to start back at ground zero. If you are an IT pro and you are having to move to the cloud, you are not starting from scratch. Is there a lot of things that are going to be different and that you need to learn and maybe that you need to brush up on? Sure. But a lot of the things, it's not as if you're starting from nothing. And a lot of the things that you do in the experiences you have will come in handy and will be applicable when cases you don't even know it. Case in point for me, when I was interviewing at Microsoft, my whiteboarding experience was how do you break down a complex problem? And I used an

example of a story that I'd recently written that was incredibly complex and had a lot of moving parts and that I had had to learn about in very, very, very little time. And then I had to not only learn about it, synthesize it, then I had to write it down in a way that the audience could understand. It was a complicated, ridiculous thing. And that, when I was in the process of that exercise, I was realizing, oh, I can do this. This job, I completely do.

But it took being in the interview room and doing that process for me to realize, oh, these skills that I had that I didn't think would be applicable here are completely applicable. And these things that I already know, that doesn't mean that I don't continue learning and that I don't continue improving, because obviously you do, and you should be doing that even if you were writing the same Perl code in Solaris for 40 years. In my mind, you should always be curious and always be trying to figure out like, well, how do I write this better? How do I optimize this

better? What's it, what else is going on? But it does mean that I think there are a lot of things that people already have in their knowledge base that are going to give them a step up, if anything. And so just not being afraid of, just because it's different means that I'm zero. I think you put it exactly perfectly. I'm not starting from ground zero. I don't have to start school again and take a lower wage job and go to another place. It's like, no, I just need to pivot and think about how I can apply these things in new ways and also take the time to learn more and to continue growing. And I think the big thing too, a lot of people don't realize is that when you join a new role, a new company, nobody is really expecting you to be like, you know, operating at 100 the first day.

You're allowed to learn and people are going to train you and people are going to help you. I have a friend who joined Azure after being deep in the AWS weeds. And I was speaking to this person and they mentioned that they'd been there for six months and we're still learning a lot of the Azure stuff, despite the fact that this person has forgotten more about AWS than I will ever know. And you're always learning. There's always a ramp.

And being able to do the entire job written in the job description means it's probably going to be a boring job. There needs to be some stretch room. Completely. I mean, that's something that the women, especially often we look at job descriptions and studies have shown this and we think that we have to have all the requirements. But you're exactly right. If you have all the

requirements, you're overqualified. Oh, absolutely. My first job, I looked at the list of requirements that they wanted for a Unix admin. And I'm looking at that going, I don't have any of these second half of the list. And then I found out what the pay range was. And it was effectively a seventh of what it would have been if you someone who had all of that stuff. And looking back now, 15 years later, I still don't have everything on that list. It's an aspirational shopping list, not a list of hard requirements. Definitely. So if people want to hear more about what you have to say, where can they find you?

So I'm on Twitter. I'm film underscore girl on Twitter. And I'm on Instagram on the same handle. I do stories from time to time. You're on the gram. I am on the gram. But I actually do a weekly tech news podcast called Rocket at relayfm.com slash rocket. And that one's more consumer tech focused and a little bit of pop culture.

But it's really fun. Thank you so much for taking the time to speak with me. I appreciate it. Corey, thank you for having the time to speak with me. I appreciate it. Corey, thank you for having me. Christina Warren, Senior Cloud Advocate at Azure. 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. 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.