Emily Freeman grew up in the “swamp” as Trump lovingly refers to it. With politics in her blood, she chased after her dream of living out an episode of the West Wing. After four years of arguing — pretty much sums up a PoliSci degree — she left school disappointed that campaigns are more about recruiting 20-year-olds to live in poverty than it is to wine and dine Koch brothers.

Her dreams of Aaron Sorkin-level dialogue and Michelin-star dinners dashed, Emily took up ghostwriting. No, those bloggers you read with millions of followers don’t write their own articles. Sorry to disappoint.

After many years of typing, Emily had a slightly-older-than-quarterlife crisis and made the bold (insane?!) choice to switch careers into software engineering. With no experience at all, she packed her six-month-old daughter, blind dog and a few boxes into her anti-mom mobile of a sports car and drove across the country to attend a seven-month code school.

Emily completed seven grueling months of code reviews, pair programming and learning Ruby on Rails. After falling in love with Denver, a city as vibrant as she is, Emily decided to stay.

Emily is the author of DevOps for Dummies and the curator of JavaScript January — a collection of JavaScript articles which attracts 30,000 visitors in the month of January. To learn more about Emily's story, visit Growth in Fear.


Links Referenced: 

Speaker 1: Hello, and welcome to Screaming in the Cloud, with your host cloud economist, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: This episode is sponsored by Scaylr. Because all kids hate their logs… doo do do doo do doot. 

When your site doesn't go

Or maybe it's slow

And people can't load up your blog

Where do you start

what's the state of the art

With logs logs logs

Logs, logs

Full of repetitive noise

Logs, logs, 

Awk and grep? Sorry they're toys

Everyone hates the logs

Nobody can read their logs

Improve the state of your logs

Scalyr can help with your logs

logs logs logs

Logs. From Scalyr dot com

Everyone wants a log

You're gonna love it, log

Come on and get your log

Everyone needs a log

log log log

Logs! from Scaylr.com. 

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by your friend and mine, Emily Freeman, who's a senior cloud advocate at Microsoft. Welcome to the show, Emily.

Emily: Thank you. Thanks for having me.

Corey: No, thanks for coming. So you are a cloud advocate at Microsoft, presumably Azure?

Emily:  Yes.

Corey: And that's a cloud-ish.

Emily: Hey.

Corey: So tell me a little bit, first of all, what is it you do as a cloud advocate?

Emily: Very similar to any kind of developer relations role, as a cloud advocate, I am sitting in that space between the developer communities and the product teams at Azure. And so, day to day, it can vary but generally, I focus on creating high quality technical content. That could be writing, speaking, video but also relaying feedback from those developer communities back to the product teams so that we actually build Azure in a way that solves the problems you're currently having.

Corey: I'm having many problems, and I'm not sure how much any one company can do to solve them for me. Most of my problems have long names and they're expensive to fix.

Emily: I feel like that's more like therapists?

Corey: Exactly. That feels very much like cloud is more about transitioning a group therapy into a corporate setting.

Emily: Yeah, that's not wrong.

Corey: You could argue that's what DevOps is due to some extent.

Emily: It really is.

Corey: As of the time of this recording, you have put a nearly final draft of DevOps For Dummies to press. Tell me about that.

Emily: Yes. So I'm currently in the review. They've already marked it up with plenty of red. And now, I'm kind of going through and making sure that I actually agree with my past self. But it's been an adventure. I wrote the book. It's a high level overview of DevOps as a methodology and how to actually implement it as a practice.

So, with DevOps For Dummies, I tried to hit all of the stages of DevOps including the start where like, "Okay, I've heard of this. What is it? How do I implement it? How do I transform the company and get people on board?" I talked a lot about persuasion, and showcasing how DevOps can improve your team's velocity, whether to executives or other engineers, all the way through injecting DevOps into every piece of this offer delivery lifecycle.

Corey: So, I'll admit when you first mentioned that you were writing that book, my immediate response was that DevOps is such a broad and vast topic that how could any one person be qualified to write a book on this? And then about a year and a half ago-ish, you wound up giving a keynote at DevOps Days Indianapolis. And it was the first talk given that it is a keynote, I would say, I would say it's almost a value note more than a keynote. But that's okay.

And you open with the line, "The dumpster is on fire, and then the fire alarm went off." You couldn't have timed that better. I don't know who you bribed to pull that off, and that was the single greatest display of DevOps mastery that I've never seen. So the question is not who are you to write the book, it's who the hell am I to question you.

Emily: That's amazing. Yeah, that experience was hilarious. I felt like, "Okay, I've peaked as a speaker. I will never surpass this moment. I have to stop speaking now." For the record, I did not bribe anyone at the hotel. But-

Corey: Oh, yeah, your intermediary is cut out to do that for you. I understand. I understand-

Emily: Plausible deniability, Corey.

Corey: Exactly. So how long did it take you to write the book?

Emily: So this deadline was insane, in my opinion. I think overall, it took six months to write it and complete it, send it off which is really fast like that's a lot of typing at night, drinking wine in your bed, silently crying to yourself.

Corey: Oh, yeah. Write, drunk, edit, crying.

Emily: Yes. There's a whole cycle to it and it's pretty similar to coding actually. Like when you are solving a problem and building a feature and working through a nasty bug, you hit this sort of same peaks and valleys emotionally. But it's definitely more intense in a book because I think it is so final, like I am canonizing my thoughts on DevOps into a book that I cannot change in the future unless I earned a second edition.

And that's very scary that I have to like really nail it so that little mistakes don't follow me for the next five years.

Corey: Here's the $64,000 question, would you do it again?

Emily: Good question. I'm of two minds about this. The instinctual response is like, "Hell, no. I'm never doing this again." That was such a crazy experience. It's so draining. Emotionally, it's just incredibly draining. And energetically like you're just empty. But that was my first book, and Orin, my colleague, actually brought up the fact that the first book is your hardest because you don't actually know that you can finish a book.

You approach the project, you're like, "I think I can write a book," but you don't know that you can actually complete such a Herculean task. And once I finished it now, I feel almost like I finished the training course on writing books, and I feel like the subsequent books would go more smoothly for me. But I also feel like this is that sort of like post-childbirth high where you're just like, "That wasn't so bad."

Corey: And that's when the acquisition editors pounce and get you to agree to a second one.

Emily: 100%, yes. I'm definitely in that sort of blissful, "Yeah, I kind of like this moment."

Corey: Let's say that I get a wild idea that today, I'm going to sit down and pitch a book and it gets accepted. Now, not about the dummies books or any other publishers you heard of because they all have editorial standards, and well, have you met me? So I'm going to self-publish a book or get someone who doesn't know what they're getting into to agree to green light cloud for morons. And I'm going to go ahead and write that book. What should I know going into it?

Emily: Okay, what should you know going into a book? One, I think it's really important to have a unique point of view. And that can be your past experience. It can be a strong opinion for how you think the industry should continue to evolve. But it needs to be a strong point of view and that you are uniquely telling a topic in your specific story format. Like you are forming your story from your point of view.

Emily: The second thing is that I think you have to understand just how much energy it's going to take this, and with no like emotional feedbacks or little wins. There's no, like when you write a blog post, you write it. People read it. People respond. This is even a faster cycle with social media, so if I tweet something, 100 people like it, I feel good. Like that little dopamine drop-

Corey: It's very short cycle time.

Emily: Exactly. The book takes you ... It's a marathon, it's an absolute marathon, and for someone like me who's very much more a sprinter both psychologically and physically, it was a real challenge to just kind of keep pushing through.

Corey: It sounds like the exact sort of thing that I would sign up for naively, and then immediately regret that decision, and spend the next 18 months sobbing.

Emily: No, there's a lot of crying. The other thing, my editor had this great line when I turned in my last chapter and I was like, "It's done." He was like, "Congratulations on completing what more accomplished people than you could not." And I was like, "Damn, yeah."

Corey: That's heavy.

Emily: That's very heavy and it made me feel good. I was like, "Yeah, I finished a book. I wrote a thing." But yeah, I think a lot of people signed up for a book, and then figure out that they're either not the right person to write the book, or they need a co-author or they just simply can't do it.

Corey: For me, it always seems that it would be a terrible idea not because I know what it takes. I don't. I sometimes lose interest halfway through writing a tweet. But I talked to people who've written a book. You, Mike Julian, who's my business partner and a few other people. And whenever I say, "Should I write a book?" Immediately they get a look in their eyes that can only be described as haunted.

"Don't write a book," is usually what they say. Like the same tone of a four-year-old girl out of nowhere who appears to you at an airport when you're boarding who just looks at you with this thousand-yard stare and says, "Don't get on the plane."

Emily: You're like, "I'm going to die. I'm definitely going to die."

Corey: Exactly. I'm training my daughter to do that incidentally so that I get to clear the upgrade list faster so I get the upgrade every time rather than just sometimes. Let's talk about the substance of what you wrote, not the ins and outs necessarily of what you wrote, because I don't think you want to continue talking about that given you're about to go on a book tour of some sort. If not, surprise, you're going on a book tour.

But the bigger question I have is, is DevOps still relevant in this year of our Lord 2019?

Emily: Yeah. This is a debate, I think, is starting to surface and I think a lot of people have different opinions. Mine is that it is still very much relevant, but the sort of adoption cycle has shifted. So the adoption curve, we're further down on the adoption curve. I think when you and I talk about it, or people like Jason Hand, Chris Short, when we talk about DevOps, we've been in it for a really long time. Many of us have actually been involved in DevOps for a decade.

And so we've seen how it kind of ... In our experience, and talking to people specifically on that sort of cutting edge of technology with start-ups and such, we see it sort of tapering off. We see the holes in DevOps and how it needs to evolve into something else. I think part of the answer for that is SRE, site reliability engineering, but that is a little bit more prescriptive and there's some polishing that I think needs to be done around that.

But that said, I still think that DevOps is incredibly relevant for people and companies and engineering teams that are just a little bit later to adopt it. Like we take DevOps for granted, but for many people, DevOps is still a very new concept. It's still something that they're not super familiar with, and they certainly don't know where to start as far as implementing it. Is it just a CICD practice? Like what exactly is it?

And so for me, writing this book, I wrote this for a CIO in Hartford, Connecticut for an insurance company. Someone who has to think about security and compliance, someone who can't move as quickly or take on the latest and greatest technology without first vetting it. And so this is the person I had in mind writing this book for.

Corey: That is absolutely a valid approach and don't let my snark in any way detract the value first of what you've done. And secondly, from the value of transitioning your culture at an organization into something. That second one was to the general you, not you personally here. I'm not terribly worried about people worrying that I'm being too snarky or sarcastic to Microsoft's internal culture.

Corey:  I think you've got that. It's been 40 years. You're a trillion dollar company. You got it. This is more for folks who are still finding their way.

Emily:  Yeah, absolutely. And I think we're all sort of finding our way in different paths. One of the things I talked about a lot in the book is I don't want DevOps to be this sort of sexy thing because I don't think that really answers the question. When you or I get up on stage and we talk about a greenfield environment, and it's all unicorn and sunshine and DevOps is the solution to everything, I think that's bullshit.

And it cheats the actual methodology of stretching and beginning to solve problems in the nitty-gritty, in the legacy systems that have existed for 15 years where there's that one piece of code that no one touches because it works and no one knows how it works, and obviously, we can't mess with it at all.

And I think a lot of code bases, probably the majority have those sorts of problems and tendencies. I've never met a code base that isn't a complete shit show that's longer, older than like two weeks. And so-

Corey: Even when writing things in the middle of it, it's a lambda function. It's four lines and I'm on line two, and I'm looking at this going, "This is a tire fire." And I know it going into it. That doesn't make it better, but at least, I'm not blind.

Emily:  Yeah, there you go. There you go. So I think it addresses some of those nitty-gritty problems and it kind of gets into the more difficult challenges, which I think are more interesting and fun to solve.

Corey: One of the challenges now is that you see that the terms have most been co-opted by people who are driving transformational change and grifters. And it's sometimes challenging to figure out what's what. You see a bunch of sysadmin teams that are just rebranded as DevOps, which if that's you, frankly, good for you because we did a survey a few years back. I think it was DevOps Days Austin, but don't quote me on that. And it turns out that with DevOps in your job title, even though the job is functionally the same, it winds up being something like 30% pay bump.

So yeah, if you want to call me something that pays 30% more, I don't really care what that is for the most part. I'd prefer nothing scatological but I'm willing to flex if you can go to 40%.

Emily: I like that. I like that resume-driven development.

Corey: Absolutely. Where do you think Kubernetes came from? But now, we're starting to see this branched out into other things with DevSecOps and FinOps, and I'm sure people put QA into it but there's no way to get that without coughing up half a lung midway through the word. QAOps is not really a thing. And at some point, it starts to take on a parody of itself element where it's no longer about having these different cross-functional teams, collaborating and communicating in a way that makes sense for everyone so much as it is, talk to other teams and do your job.

And that seems to get lost somewhere along the way in a profound way. It feels that by slapping a new shiny DevOps-ish label on something, that is going to magically fix all the broken processes and lack of cultural advancement going on in any given company, and you're not going to fix anything but you're going to feel better for doing it.

Emily: Yeah, I mean absolutely. I think you bring up quite a few of the problems that I have with the current sort of status of DevOps in the industry. I think it's suffering from a lot of the same issues that Agile has and is suffering from, which isn't surprising. DevOps was born out of Agile.

And because it is such a ... It's not a prescription. There's no like, "Do this, this, and this, and then you'll be fine." It's more, "Yeah, work together, assholes. Do your job. Talk, communicate." If you're a manager, be a good one. Protect your engineers. Give solid market salaries, incentivize the team in the same direction so that they're not fighting each other.

These all seemed like very basic principles of just good business, but the truth is, and this goes back to my power-lifting days. When I was lifting, some of the best advice I ever got was it's very easy to do the complicated thing. If you're doing like, let's take diets. A complicated diet is in some way so much more easy to actually go through it than to experience because you have like your exact prescription for what to eat, and what not to eat, or you're just on a seven-day fast or something.

It's much harder to do the simple thing, and I think DevOps is the embodiment of doing the difficult simple thing. The actual principles of DevOps are pretty simple and straightforward. But implementing them, it takes a lot of energy and a lot of collaboration. And those things like the human problems. The human problems of tech are the most complicated, in my opinion.

Corey: Absolutely, and I'm reminded of all the early days of DevOps in the serverless environment that we're seeing today. I keep hearing echoes of a blog post as it lurks around the internet. And I'll throw a link to this in the show notes called DevOps is a poorly executed scam. It's from March of 2011. So it's by a guy named Ted Dziuba, and his entire approach was that it felt like the second coming Agile, but no one was asking for money. There was no conference. There was no books. There was no training. You've gotten a bunch of buzz but no one is selling anything to you in this space.

Well, in the DevOps world, I think we fixed that. And it just took a little longer than people expected it to. But now I'm starting to see some of the same hype style stuff with serverless, where people are going significantly out of their ways to build things that turn into a somewhat insane and ridiculous approach, where everyone is trying to build things in Byzantine ways, as the best expression of ideological purity. And often, they blame each other for not wishing hard enough to build the thing and being traitors to the cause.

And it just winds up being something awful and unsightly. I don't think that we're quite there yet but I'm starting to worry that that's where we're headed.

Emily: No, I think that's fair. It's funny you say at the beginning DevOps didn't have a ton of vendors trying to sell things. I am actually coming to the perspective that engineers as a whole are not extrinsically motivated with money. I think we all want to be paid fairly and we all want to be able to support our family and do things that we care to do.

But that aside, like throwing extra money at an engineer doesn't typically gets you a ton of long-term motivation.

Corey: Repeating that again will get you highly motivated engineers to silence you who want large piles of money thrown at them.

Emily: That's fair. That's fair, yes. But that said, I think-

Corey: Paying me large piles of money probably won't solve your problem but let's try it.

Emily: Yeah, exactly. What was that study in like a couple of years ago they found that after like 75,000 or something, extra money doesn't bring you any of their happiness is something like that?

Corey: True. That is normalized as a baseline load. It tends to vary based upon major metro areas, obviously. But you're right. Past a certain point, you are going to be measurably happier with two yachts instead of just one.

Emily: Yes, exactly. Throw that second yacht, I mean. Oh, my god.

Corey: You're truly wealthy when you can walk in and pronounce it phonetically as "yatch" and no one corrects you when you're making the purchase.

Emily: God, that would be special. I would like to see that. Can we do that? I feel like that would go viral, Corey.

Corey: This is the entire problem, is that whenever you and I hang out, it immediately leads to hilarious and disastrous encounters for everyone around us. We were at Build somewhat recently, and we happened to show up at the same off book meet-up near at the same time. And you walked over and, "Corey," you start seeing the new pin on my lapel and start fidgeting with it. And someone just asked, "Do you know him?"

And the obvious immediate response was, "No, why?" Yeah, it went super well. And everyone just sort of looks at us and stares and we're terrible influences on one another which tells me we absolutely need to collaborate more and inflict us on the world somehow.

Emily: Yes, I think both of us are very comfortable in awkward social situations, and then it becomes compounded when we're together. And then we kind of like ... I get joy out of making things a little weird. I just think it's funny.

Corey: If we're not in an awkward situation, we make it that way. That's who we are as people. That is fundamentally our nature.

Emily: Yes, which I think a lot of people just looking at me don't think about. They don't see this sort of mischievous side but it's definitely there.

Corey: Oh, absolutely. It's one of those things where it's the kindred spirit approach where we're effectively ... We see the world in the same bizarre way. One of these days, we have to find some kind of collaboration opportunity. I don't know if that's you give a talk, or something and then I give the rebuttal to that talk. Picture the political state of the union things. We have the opposition party go up and do a "well, actually" afterwards, only that with more swearing and screaming.

Emily: Yes, but we should do it in like a British parliamentary way, like where we can kind of just yell at each other.

Corey: Oh, absolutely and go round and round and round and round, forget a deadline is approaching and the continually push it back which is I'm told how you write a book.

Emily: I want to come back to that. But I wanted to do like I have an idea for a conference where it's basically debates for charity. And so you get people like I want two people that sign the Agile manifesto, like Kent Beck and someone else to debate whether they think it still holds or something like that. And then we pay to attend and donate all the money to charity. I think that'd be fun.

Corey: I love that entire idea. I think that's something that is phenomenal. I'm always a big believer as well in doing things like that for charity because let's not kid ourselves, no one is going to pay money to me to watch my ridiculous horse shit. But they might tolerate my ridiculous horse shit if it benefits a good cause.

Emily: Definitely. And I think a lot of us struggle with, okay, many developers and engineers didn't come from well-off families. A lot of times, especially with code schools, you see someone being the first person in that my family to make X amount or six figures, or be able to support their family and bring them out of poverty.

And so I think a lot of us struggle with, "Okay, we're here. We make a really solid wage, how do we make sure that we're giving back and we're not just living in a sort of self-centered and selfish way that we actually embed altruism into our everyday lives?" That's something I struggle with, like I don't always know the answer to that.

So, yeah, there's a lot of opportunities for charity in this industry.

Corey: Absolutely and there's a reason that every year, I do the charity T-shirt where it's something snarky and sarcastic for last week in AWS, and all proceeds go to a random charity. Last year was at St. Jude Medical Center for kids with cancer research. That was fun. I didn't know who it's going to be this year but I have some ideas.

But doing something like that that's larger than just my own ridiculous nonsense/corner of the internet, first, it feels good. And secondly, it helps justify, if only to myself, that I can take this ridiculous love affair I have with my own personality/sound of my own voice and use that as a force for good beyond just insulting things all day long.

Emily: I think that's wonderful, yes, insults for good. I want to loop back to the procrastination in writing because this was fascinating to me. If I had to write a book on writing a book, it would be lessons I learned from staring a carpet fibers and it's because you struggle. Like you sit there and you stare at the computer, the blank page, the word document because I had to type in Word. Feel sorry for me.

And then you're like, "Ugh," you go through this phase where you're like, "I'm not the right person to do this. I have nothing to say on this. I'm the worst writer in the world." And then you like roll around in the carpet a few times. If you have a partner, you'll talk to the partner like, "I don't know. I shouldn't be the one writing this. This isn't right."

Corey: And then the crappy partner, they come back with, "You're absolutely right. You're good at nothing."

Emily: Don't stay in this those relationships, please.

Corey: Get out.

Emily: Yes. Talk to me. I will help you.

Corey: Exactly. It's a DevOps metaphor.

Emily: There you go. So, yeah, and then you kind of roll around and after five hours of moaning, you pull your shit together and then you type some words. And about three pages in, you're like, "Oh, my God. This could be a book in and of itself." It's a fascinating sort of process.

And procrastination, I think, actually plays an important role and that you're not actually just sitting there moaning. I mean that's sort of the output. But I think the process of that and the journey of procrastination is you're truly ruminating on what you're going to say. And it doesn't feel productive but I think your brain actually needs that time to sort through random thoughts before it can be coherent and clear written.

Corey: This aligns very heavily with a pair of conflicting Twitter takes I saw going around a few months ago where on the one hand, it was, "Well, we just paid a lot of money for this conference. So, thanks for telling us you threw the talk together that were paying to see the night before. Awesome, thanks." And the counterpoint to that is, sure, they finalized their slides the night before but they'd been thinking about this talk for months and months and months and months and months. And then finally had a forcing function of building slides because you're not paying for the slides, you're paying for the viewpoint, the perspective, the story that goes along with it. So, I'm extremely sympathetic to both sides of that.

Emily: Yeah, and I think it's funny this is apt timing. I had a nightmare last night that I haven't ... I'm keynoting DevOps Days Toronto in like two weeks, and I haven't actually started the talk. And I know what I want to say but I had a dream that I didn't finish the deck and I had to talk with just like a six-slide deck and it was bad. That said, we will not let that happen.

Corey: The sneaky way around that incidentally is to give a talk with no slides. If you bring in other couple devices to do this, and talk to me after the show, I'll give you a link for these, that you can plug into a projector and it turns the thing into a paper weight because it lets the magic smoke out of the back. "Oh, no, the projector exploded. I guess I won't do my slides and I'll just do it without slides." Then all you have to build is a title slide.

Emily: Fascinating. Okay, yeah, that's one approach.

Corey: A way of the weasel.

Emily: That's not my approach. We've talked about this.

Corey: Yes, because you're good at things, and I'm just really, really, really good at distraction.

Emily: Well, and you're so comfortable sort of riffing on stage whereas my personality doesn't work like that, like I'm contextually funny but I'm not like a ... You could be a standup comedian. I wouldn't be a good standup comedian.

Corey: What do you mean could be? I go to Seattle once every month or so and do Tonight in AWS. I make fun of cloud computing for 40 minutes. It goes super well, all proceeds to charity.

Emily: There you go. And most of us just we don't have the skillset or confidence to do that.

Corey: The only skillset I'm convinced that you need is a complete lack of self-awareness and/or shame. And as long as you've got that, everything is great. Like the crowd boos. They pull you off the stage and then people ask you like, "How did it go?" "It killed. Everyone was cracking up," because you're always a legend in your own mind.

Emily: It's true. It's true. And related to that, I think writing a book is interesting. When you said you're asking your friends like, "Should I write a book?" I think of the interesting byproducts of writing a book is the credit that other people give you for free. Like I'm more or less the same level of intelligence and filled with the same level of knowledge that I was six months ago. Now, I just wrote it in a book.

But when you're an author, people give you a lot of credit. They're like, "You must know what you're talking about. You're an expert."

Corey: Really. What book did you write on that because I wrote a book.

Emily: Exactly. That's exactly it. And so it's this sort of ace card or this trump card you can kind of holds if you need it.

Corey:  It's definitely one of those appeal to authority things. And there's also, not for nothing, but again, I've written no book of any stripe, color, et cetera. At this point, I might be able to write a matchbook and that's as far as it goes.

But it also has its own gravitas when you're with the known publisher as well. I mean the For Dummies series was transformative. This dates me, not like anyone else will, but back in the 90s, I got started with Linux For Dummies. That was my first outing to the idea of a Unix-like operating system. And it was captivating.

Emily: I love that. Yeah, I'm excited about The Dummies. And I think it doesn't get the credit that it deserves and that it fills a piece of the market where you can be a complete beginner. You don't actually even have to know much about tech to read my book, like you can glean a bunch of things about management in there, about being a leader without a management title, about energizing and galvanizing your team no matter what your job is.

And so I really tried to write it and meet people where they were at to make sure that it would be applicable to them no matter where they are along the process, what their background is, what they look like, where they came from, how they got into tech. I didn't want any of that to matter. I wanted it to be completely open and to answer the questions that anyone coming to it would have.

Corey: And I think that's absolutely the sort of thing that is important for people to hear. We've been joking a bit and snarking at one another as we do. It is our way. But there's extreme value in making things like DevOps and modern technological practice and culture shifts accessible and approachable to people on a wide variety of spots on the spectrum.

And I don't want our sarcasm and joviality to wind up occluding that.

Emily: Yes, absolutely. And I think tech in general could do better at this. I think, because we are such an intelligent-focused industry where we measure ourselves and each other based on what we know. It's very difficult for us as engineers to say, "I don't know that," or, "I've never heard of that," or, "Explain that to me."

Corey: Or the mistakes things that are common to the industry as prerequisites, "Well, I don't think I'd be very good at doing DevOps style of work because I'm not very good at coming up with puns." Wait, what?

Emily: No, absolutely. We think that you need to have X factor on your resume to do whatever else. And I think that's bullshit. And something I've been focusing on at Microsoft is IaaS, usually stands for infrastructure as a service. And I apply it as idiot as a service.

So, I am open to looking like a moron and asking the dumb questions so that everyone's on the same page because if you don't have that foundation of clear communication and context, and understanding why you're working toward a goal, the whole thing is going to fall apart at some point. It's a house of cards.

Corey: And something I'm trying to focus more on is giving more airtime to my stupid questions. Most of the time, it turns out it wasn't a stupid question at all. There's something there that I'm not getting and I need to understand. That's the point of asking a question.

But it's easy to lose sight of it when people aren't doing that in the open, where they realize they spent three hours messing around with something and realized that they missed a comma or they're using the wrong version of a thing and the documentation says in giant bold red letters "Do This Thing First". And if you don't do that, surprise, it doesn't work.

And everyone has those experiences of going back and forth rapidly cycling between, "I am a genius and how am I allowed outside unsupervised." It's back and forth so quickly.

Emily: I know. I talked about this in my Dr. Seuss talk where there's this rhythm to software developments. And it's like, "Oh, this should be easy," no problem, you dig into it a little bit and then you're like, "Uh, that doesn't seem so easy or straightforward and then you're like, "Help! I need help! I've no idea how to do this. I'm an idiot."

Emily: And then when you actually solved the problem either individually or as a sort of team, you feel like a god, like a god of all things machine.

Corey: So, if people want to hear more of your sage thoughts/scintillating wit, where can they find you?

Emily: You can pre-order DevOps For Dummies on Amazon. You can find me on Twitter, @editingemily. @editingemily was my writing business before I moved into tech. And you can watch my talks at emilyfreeman.io.

Corey:  And we will put links to all of those in the show notes. Emily, thank you so much for taking the time to have a chat with me today. I appreciate it.

Emily: Thank you. I love talking to you.

Corey: Emily Freeman, Senior Cloud Advocate at Microsoft, of which Azure is a cloud. I'm Corey Quinn. This is Screaming in the Cloud.

Speaker 1: 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.

Speaker 4: This has been HumblePod production. Stay humble.