Before she held her current role as senior cloud advocate at Microsoft, Christina Warren was a self-proclaimed “content engineer.” These days, who follows a traditional career path anyway? Tune in to hear Corey and Christina discuss how to give killer conference talks, what it means to be a developer advocate, what the next generation of cloud developers looks like, why grizzled IT veterans shouldn’t be wary of moving to the cloud, and more
About Christina Warren
Christina 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.
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 technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.
Corey: This week's episode is generously sponsored by Digital Ocean. I'd argue that every cloud platform biases for different things. Some bias for having nearly every feature you could possibly want as a managed service at varying degrees of complexity. Others bias for, hey we heard there was money in the cloud and we'd like if you would give us some of that. Digital Ocean is neither, from my perspective they bias for simplicity. I wanted to validate that so I pulled a few friends of mine about why they were using Digital Ocean 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 Digital Ocean. That other offerings have a whole bunch of shenanigans with the root access and IP addresses, and effectively consulting the bones to make those things work together.
Digital Ocean 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 who done it 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/screaming
. Thanks again to Digital Ocean 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.
Christina: Thank you so much, I'm so excited to be here.
Corey: 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.
Christina: Well first of all thank you that ATP episode was one of my favorites, so we actually swapped hosts that week. So John Siracusa 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, I still have people, you hear like, "Oh I first knew you from that." And I'm like, yeah I will probably never reach an audience like that big.
Corey: 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 seeing where people come in, it's weird. Then you start getting loud on Twitter or do 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-
Corey: ... following you.
Christina: 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.
Corey: 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.
Christina: This is becoming a real problem, that we're like now adding to obviously. But, so kind of like peak Netflix, we're not a peak podcast but it's one of those things where I'm like, it used to be something you'd 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.
Corey: Increasingly it seems like one of those valuable commodity, we all have his attention. And because that is finite we can't make more of that, and some day I'm sure the most valuable commodity will be water. But until that societal collapse, attention seems to be it right now.
Christina: I think you're right, yeah.
Corey: So once upon a time you were a journalist.
Christina: I was.
Corey: And now you're a cloud advocate.
Christina: I am.
Corey: That is atypical as far as career progressions tend to come.
Christina: 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 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, well the three things I guess that I've loved the most have been computers, technology, gadgets, whatever, pop culture and writing, and story telling, 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 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 had already had that month's Teen Beat or Seventeen, 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 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. So I kind of go from being like the person who is 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 dev role aren't that different in so far as, 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 write articles that I would hope that the companies were reading saying, these are real issues. 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, friends with developers, whether it's 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 scream on the internet, I can just scream in person.
So it's still it's a uncommon career 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.
Corey: It also speaks to a mature advocacy organization that, doesn't approach you and say, "Wow, 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?
Corey: Well, we need to make sure that you have technical credibility in front of an audience. Cool. How did 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 and 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 a spoiler, you're going to do a terrible job, at least the first few times you do that.
Corey: It doesn't matter, it's just the ability to tell a compelling story and deliver that well, is fascinating.
Christina: I agree. And I also, 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'm 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 know that in many cases, it's actually harder to read off the teleprompter, than it is to be extemporaneous, or to memorize.
Corey: 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.
Corey: 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, you kind of don't want to do that again.
Christina: 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, that's a skill that I don't have. I mean, unless it's on a teleprompter that I can read from.
Corey: 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, Salt Stack, as it turns out, which did not do as well in the market as I would have 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 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 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 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 another 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 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 get tired of telling the story the same way and you want to start improvising.
Corey: And having the flexibility to do that when giving the same talk repeatedly is important.
Christina: I agree.
Corey: 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?
Christina: 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 if 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 want to 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 a challenge when you have other things to consider. And so in those cases, I'm like, all right, you know what? 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. 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 to people and explaining things, and then hopefully being able to answer their questions and provide them with more resources at the end.
Corey: It's about the audience, it's never about the-
Corey: ... presenter.
Christina: 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, it's about me and what I want to project, and what I want to do, and it's like no, 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, these other challenges of, do I have a translator? How is the audience going to know this and whatnot? Then that's enough of a kind of a difference to not make it the same old, same old. But even if it were, I think for this particular thing, and like I understand the context, it's like this is for them, this isn't for me.
Corey: 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.
Corey: 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.
Corey: 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?
Christina: 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 help improve that. I learn all the time about 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 am 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 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, "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 the solution, because this is something that's impeding the way they're using things and what they're doing.
Corey: 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 they're in 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. And I hit a, 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 spinning up a single VM, it defaulted to picking a Debian release and oh my stars, that brings me back.
Corey: 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 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, their 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.
Corey: I am loud, I would argue whether I'm influential.
Christina: You're influential.
Corey: 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 "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 because it's scale.
Christina: 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. 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, is you 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 want to connect them with somebody who can solve their problem period. Right? Like that, to me is is the goal. And that whether we succeeded at that or not, that's 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 realistically, you're not, someone else who doesn't have your following is getting the same level of maybe hand holding. But I would like to think that there would be things in place that people would pick up on and be able to say, "Hey, this is going on, or have you tried this?"
Corey: 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 at all of the major players has something very similar to this attitude. If a customer's 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, and learning from them, and supporting them wherever on the curve they tend to be.
And sure the future is going to be pure, 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-
Christina: Hahaha, you better come.
Christina: Told you, 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 lines of business that have existed for a long time where 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, I think it's kind of, legacy is always a difficult thing to kind of figure out how long do you to support something? When do you kind of force people to move on?
But Microsoft has a very, very well known history of supporting legacy things. Some would argue too much, right. So I think that that is part of kind of the goal is to, 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 an iterative development are that you get updates and things more quickly. Like I think like Office 365 is a great example of that. There's still a standalone version that it's 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 accounts. And, 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 perpetual license." And that's it.
Corey: There's an entire class of users 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.
Corey: And communicating that to the customer in an effective way that first expresses empathy with them. But secondly, it says that yes, we know this is a problem, we are working on this, thank you for continuing to do bear with us on this and communicating that well, and not leading to the various gossip rags tearing the company down in tech browse, is a skill in its own right. And it's one that I think Microsoft can foundationally teach a master class in.
Christina: 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.
Corey: And even direct honestly 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-
Christina: Right it sounds you're blaming them.
Corey: ... blaming the customer.
Christina: Exactly, I mean, that's the thing. And when we have outages and that happens you know at every company. I've actually been impressed with how well some of the write ups, some of the technical write ups are, because this used to be what I would do as a reporter. AWS would go down and usually it'll be like an S3 bucket and like North Carolina or whatever, right? Like it'd 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 you know, they don't care about the various esoteric things that oh, well if they'd had multi region, or this or that, they don't care and this is down.
And sometimes, and I always feel so bad for the dev ops 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, can not always be easy. It's, I think Amazon has actually done a really good job as of late of making those, communicating better when those things happen.
Corey: In some ways they've been forced to by their own customers.
Christina: Right, right. But that's something that I have, when we've had outages I always look for because, people usually aren't coming to me, they're not yelling at me about it. But I do a weekly show on our YouTube channel that's Channel 9, and if we have like a major outage, I need to talk about that, right? 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 log that says it's happening, but the postmortem is 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 almost, 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 a data center going down and maybe, or part of it having an outage because of something being configured the wrong way or maybe like a weather condition or something else and not having made decisions for whatever reason to architect things that might have made that 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 places a fault might happen and how they're going to recover from that. I think that it's not unrelated, and there are lessons to learn from that, period.
Corey: 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. 10 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. It is, 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.
Christina: I totally agree, I totally agree. You know, the one thing you have to keep in mind though is that if you're settling on a role 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 stop working.
Corey: Or you're assuming my code ever worked in the first place, that's beside the point.
Christina: Okay, that's my point.
Corey: It's my code, come on now.
Christina: Well, you know what I mean? I mean, I think that's something that is different, that is also, I mean, this is great, but this is also I think sometimes a challenge and a thing with educating people 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 something goes, if like a version of PHP finally has been like 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.
Corey: This is also part of the advantage of a server less story as well, where it's okay, my code might still be crappy, but I don't have to worry about the-
Christina: I don't have to worry about the other stuff.
Corey: ... TLSPs, or the web server, or the patching or-
Christina: Yes, I 1,000% agree. I think that is like the wonderful part of the server less 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. Where something's upgraded underneath me, and now my stuff breaks. Because that's like, and then that's a hard challenge too. How much do you just let people use out of date, non updated things, right? You could conceivably let them do it forever, but is that the right move?
Corey: It's always a problem. I used to work at a web hosting company running a giant WordPress grid. And that's awful the plugin 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 non traditional path.
Corey: And everyone I talked 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 2:00 AM 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 Q basic, 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 how do, 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 career in tech, where does the next generation of cloud oriented developer types come from?
Christina: 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 that's 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 the kids that are graduating from college now, because public calls have officially been a thing for long enough, they're literally like a cloud first generation. And the training and the teaching has gone level two. So they're not going to have the experiences dealing with the the old, shared, web hosts, or dealing with having to maybe like 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 and, or take things away. And I think that's interesting, because in some ways that's kind of forced the rest of the world to maybe catch up. But I also think that it's exciting because those are the people, like when I look at like Visual Studio Code, which is, even though I didn't work at Microsoft, I would be such a huge fan of that product. I think it's such an amazing editor.
Corey: It is incredible, and the one thing I'm waiting for, is I want it to work on my iPad Pro.
Christina: Yes. Which hopefully with the preview that they announced this week of the online hopefully-
Corey: They're dancing around it, there's-
Christina: I know.
Corey: ... just one missing piece.
Christina: I know, I know. Because I want it on my iPad Pro as well, that's the dream. 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-
Corey: I'm old and grumpy, 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 oh my stars is Visual Studio Code pretty, it just works. There are things I don't have to worry about and-
Corey: But my interview question still involves, what level of raid is the right one for this particular use case?
Christina: Right, which-
Christina: 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 sometimes you have to figure out, what skill is important for this particular role? 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. I love to learn, I love it. I'm obsessed with learning and knowing as many things as I can. And I'm always amazed of all the things I don't know, you know?
Corey: Looking for curiosity, looking at the, tell me about 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.
Christina: No, I'm totally in agreement and I hope that we can get away from some of those. 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 that'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 to people who can actually make the changes?
Corey: The last topic I'd like to cover with you is, the divide between ops and dev.
Corey: How do you see that?
Christina: I mean, it's so interesting. Because before I joined Microsoft, I really, I mean, I knew about operations, 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, 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 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 that DevOps is the solution. What I mean is that, I talk to so many operations people who will say to me before I talk to them, "Well you know, I'm not a developer." And then they'll show me all of their answerable or, power shell scripts, and all these things that they're doing, and all their tool.
And 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 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 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 I have, there's nothing wrong with it, but I can do more and I'm actually capable of doing these other things, I don't have to just be responsible for this one piece.
Corey: 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-
Corey: ... 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 of 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."
Corey: And first, holy crap they were right. But the follow up question, I don't have an answer for this 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 Perl for Solaris, at which point that the industry has moved on and the jobs simply don't-
Christina: ... 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, they're freaked out by the cloud, they're freaked out by their jobs going away. I totally understand.
Corey: I was that person.
Christina: 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 genuinely, how different are the fundamentals really?
Corey: 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 to do.
Christina: 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 and to setting up maybe a large scale email organization in the cloud?
Corey: 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 like 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 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.
Christina: No, you want to 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, 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 and 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.
Corey: 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.
Corey: And now you moved into, effectively what is a technical role.
Christina: I'm technically a content engineer, so yes.
Corey: 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 and-
Christina: Yes. Well this is kind of my overarching point, right? And I think that this is what sometimes I think people of all ages, this isn't just saying to the gray beards, 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 things, it's not as if you're starting from from nothing. And a lot of the things that you do, and 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. When I was in the process of that exercise I was realizing, oh, I can do this, this job I can 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, it doesn't mean that I don't continue learning, and I don't continue improving, because obviously you do and that, you should be doing that even if you were writing the same Perl code in Solaris for 40 years, you should not be, in my mind, you should always be curious and always be trying to figure out, well how do I write this better? How do I optimize this better? 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 does not mean 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 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.
Corey: 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've been there for six months and were 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 it's, 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.
Christina: Completely. I mean, that's something that, 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.
Corey: 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 were 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 whole list of hard requirements.
Corey: So if people want to hear more about what you have to say, where can they find you?
Christina: So I'm on Twitter, I'm @film_girl on Twitter, and I'm on Instagram in the same handle. I do stories from time to time, not too often.
Corey: You're on the gram.
Christina: I am on the gram. But I actually do a weekly tech news podcast called Rockets at relayfm.com/rockets, and that one's more consumer tech focused. We, and a little bit of pop culture. But it's really fun.
Corey: Thank you so much for taking the time to speak with me. I appreciate it.
Christina: Corey, thank you for having me.
Corey: Christina Warren, senior cloud advocate at Azure, I'm Corey Quinn, this is Screaming in the Cloud.
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.
Announcer: This has been a HumblePod production. Stay humble.