After many years of ghostwriting, Emily Freeman made the bold (insane?!) choice to switch careers into software engineering. Emily is the author of DevOps for Dummies (April 2019) and the curator of JavaScript January — a collection of JavaScript articles which attracts 30,000 visitors in the month of January. A former VP of Developer Relations, Emily is a CloudOps Advocate at Microsoft and lives in Denver, Colorado.

Mike Julian: Running infrastructure at scale is hard. It's messy, it's complicated, and it has a tendency to go sideways in the middle of the night. Rather than talk about the idealized versions of things, we're going to talk about the rough edges. We're going to talk about what it's really like running infrastructure at scale. Welcome to the Real World DevOps podcast. I'm your host, Mike Julian, editor and analyst for Monitoring Weekly and author of O’Reilly's Practical Monitoring.

Mike Julian: All right folks, I've got a question. How do you know when your users are running into showstopping bugs? When they complain about you on Twitter? Maybe they're nice enough to open a support ticket? You know most people won't even bother telling your support about bugs. They'll just suffer through it all instead and God, don't even get me started about Twitter. Great teams are actually proactive about this. They have processes and tools in place to detect bugs in real time, well before they're frustrating all the customers. Teams from companies such as Twilio, Instacart and CircleCI rely on Rollbar for exactly this. Rollbar provides your entire team with a real-time feed of application errors and automatically collects all the relevant data presenting it to you in a nice and easy readable format. Just imagine — no more grappling logs and trying to piece together what happened. Rollbar even provides you with an exact stack trace, linked right into your code base. Any request parameters, browser operating system and affected users, so you can easily reproduce the issue all in one application. To sweeten the pot, Rollbar has a special offer for everyone. Visit rollbar.com/realworlddevops. Sign up and Rollbar will give you $100 to donate to an open source project of your choice through OpenCollective.com.

Mike Julian: Now folks, welcome to the Real World DevOps podcast. I'm here with Emily Freeman, Cloud Advocate at Microsoft. Welcome to the show, Emily.

Emily Freeman: Thank you, thank you so much for having me.

Mike Julian: Yeah, so for the folks who aren't as familiar with developer advocacy or developer relations or developer evangelism or the 50 bajillion other names that they go by, can you tell us what is that you do? What are you doing for Microsoft?

Emily Freeman: Yeah, absolutely. Along with the 50,000 names for developer relations, there are also 50,000 interpretations of the actual job. It will vary company to company and person to person. For me in Microsoft I like to say that, because I have a background in writing and I was a writer before I was a developer, I like to tell stories. My job is to tell the stories of the developers in the communities I am in and serve and represent. The most important role I think I play at Microsoft is bringing customer feedback back to the product teams. When I go to a conference, I am never one to just like helicopter in, give my talk and then peace out. I think that's just poor form and it doesn't benefit anyone at that point but my ego. My job really is to go and talk to people and to hear all their feedback, positive and negative. It's not personal, it's about making the product better for the community.

Mike Julian: That sounds like a much more reasonable job than you would hear from like reading shit shows on Twitter.

Emily Freeman: Yes, absolutely.

Mike Julian: That might be a good segue to the recent total shit storm that happened on Twitter about developer relations. I don't even know how these things started. It just suddenly appeared one day.

Emily Freeman: Yeah, and the criticisms from this last one aren't new. This is just one iteration of the sort of dev overall hate, which is like, on a very personal point, it's hurtful because it's like, “Okay this is my work, this is what I care about. I'm passionate about this and obviously I dedicate all of the time I spend at work to this role.” To hear that it just has no value or that we are simply low-key Twitter celebrities that our company shields and drink champagne on planes and party.

Mike Julian: That sounds like a fantastic life, can I get that job?

Emily Freeman: I know. I was telling someone I'm going to Milan next week for Microsoft Ignite | The Tour. It's very exciting, I've never been in Italy, I'm thrilled. I was just telling them like, "I sound a lot cooler than I am. I just got from Toronto and I'm going to Milan." No, I'm just on the plane sad. Yeah, the travel is part of it, I think it's the part that people cling on to. I also think that we as an industry have not done a great job recently at actually representing what the work is. Yeah, I think so much of the emphasis has been around Twitter and a lot of the developer relations folks especially the people Microsoft is picking up, have really — if not enormous Twitter following — substantial ones.

Mike Julian: Well they are already super well-known people to begin with in their own right.

Emily Freeman: Yeah, but there's a cult of personality thing happening. I think when we have that and when we focus so much on the persona and that sort of Twitter platform, then we lose the actual benefits of developer relations, both for the community and the company that they work for.

Mike Julian: Yeah, so some of the criticisms that I saw, you alluded to this one, that you are the representative of a company, but when you're speaking on behalf of the company, you're not saying that you are. Therefore, it's like influencer stuff, but you're not saying that you are. You're not divulging where you're getting your pay from. To me this sounds like a dubious argument, because your employer is right there on your profile.

Emily Freeman: Yeah. I mean I'm pretty open about any employer I've had. I think everyone knows I work for Microsoft and certainly when I go speak somewhere Microsoft's logo is on the deck. I will say that I'm a Cloud Advocate for Microsoft. That's probably all I'm going to say about Microsoft and I think that's the important thing. Unless it's a Microsoft event, I am not applying to like a DevOpsDays and today let me talk about Azure DevOps, that doesn't benefit anyone. If I think Azure DevOps can seem something really cool with the different storyline, like an actual problem set that I think the community is struggling with, awesome. If I think another tool that Microsoft does not own can do it better, I'm going to talk about that. We were all hired by Microsoft with that understanding that we represent specific communities. We target our talks to those communities and we are not going to be just a different version of a sales engineer.

Mike Julian: At the end of the day your job is to help build a product and help build a community around the product. Like you're bettering both sides.

Emily Freeman: Absolutely and it's sort of like the middleman where we get the negative parts of both sides. It's like we're stuck in the middle, "We're trying to make things better," and everyone's kind of mad.

Mike Julian: As someone else and myself also kind of waded into this whole storm, I look at developer relations in a much more foundational sense. Basically everyone in the company is there to do sales in some capacity.

Emily Freeman: I agree.

Mike Julian: My job is when I was working in Ops and SRE was to help build a product so that we could sell more of it. The job of developer relations is to be out there in community, building community, bettering the product so we can sell more of it. We're all here to sell more stuff. To me, when I see developer relations get up on the stage it's like, “Oh they're on stage.” They're clearly here to sell me more stuff, but I don't take that as a negative. I know their goal. If they weren't here to sell more stuff, they wouldn't be on stage to begin with. Their role wouldn’t exist. 

Emily Freeman: Yes, and it's not a direct link. To be very clear, no one in developer relations has any kind of sales metrics or are measured by that. We get no rewards based on that. There's no direct link between okay, if you buy Azure then I get a bump. That's just not how it works. You're right in that everyone is supposed to, you know, we all work for a company. We get paid because they make money and so if you're a purist and just want to develop, to think that you don't need to worry about the end user, that's just I mean not being realistic I think.

Mike Julian: Right, it still doesn't work even as an engineer. Yeah, you're building a product but why are you building a product? So that you can sell more of the product. Even engineers don't have sales goals. They're not measured on how much product was sold, but if sales go down they lose their job. It's very much the same in developer relations of you're playing the long game. You're building a community because a community will become self-sustaining and grow the company overtime. When you're looking at it, it's not like you're not a salesperson, you're not trying to meet the quota for this quarter. You're thinking, "How can I build something that people actually want, that people really want to be part of this community for the long haul, for years at a time?"

Emily Freeman: Yes, absolutely. I will not promote a product I don't believe in. I'm not going to get up there and say like, "Yeah, this is awesome product," when in reality I'm thinking like, "What a shit show this is." That's not my style.

Mike Julian: That would be really hard.

Emily Freeman: It really would be. Yeah. I don't even think great salespeople do that, because you have to believe in that and you have to be honest with your customer. If I mislead someone they're not going to trust me again, so I'd rather be honest and be like, "That's not a great product for you, that needs help. Let's go use this other thing." Have them come back and trust my word and my reputation — that's important to me.

Mike Julian: Yeah, absolutely. I've been having a lot of conversations lately about like the Microsoft we all know and hate and the Microsoft of today.

Emily Freeman: I know.

Mike Julian: I've set dinner just recently and someone made the comment that, "You should go to Microsoft. They're a much better company." I'm like, "I'm sorry, what? When did that happen? What universe is this?"

Emily Freeman: I know, I know.

Mike Julian: You mentioned, what got me thinking about that is, you mentioned that there are situations where you won't recommend Microsoft products, because even though you represent Microsoft, their products may not be the right solution for you. It reminds me of the old Microsoft certification exams of like, “The answer to everything is this Microsoft product.”

Emily Freeman: That's amazing.

Mike Julian: Everyone would have this problem, but especially people in the industry, well, there's the right answer and then there's the answer the test is looking for. They're not the same.

Emily Freeman: Yeah, absolutely. I think so much of the emphasis at Microsoft right now is changing that perception and actually living up to the new vision and the new goal that we want to have as a company. I think Satya [crosstalk 00:11:35].

Mike Julian: Which is just impressive.

Emily Freeman: Oh yeah, absolutely. It is impressive. Satya has done a great job at setting that vision and then making sure that people at Microsoft understand that and live that every day. Obviously we're like a big company and there are faults. I'm not one to say that everything's unicorn and rainbows. It's a work-in-progress, but aren't we all? Yeah, absolutely, it's funny because I think 10 years ago or so Microsoft was actively undermining open source communities. Now it's one of the largest, if not the largest open source contributor and so they're doing a lot of work around that. I wonder sometimes if some of the developer relations controversy is affected by the fact that all these corporations who are now hiring a bunch of developer relations folks, who come from open source are then like either acquiring the open source or getting more involved in the open source and there's this fear of conflict of interest?

Mike Julian: No, I could absolutely see that.

Emily Freeman: Yeah.

Mike Julian: Yeah, I think you might be onto something there. I don't know how much that plays into it, but I think there's some truth there.

Emily Freeman: Yeah. I think that a lot of it is just fear-based and it's like here are these mega corporations. We're also in this acquisition season with a really big corporations are acquiring all these like medium companies. That gets always a little scary, because then it's just, oh there's five companies, okay.

Mike Julian: Right, all the 50 bajillion dollar companies are acquiring the 10 bajillion dollar companies.

Emily Freeman: Exactly, yeah and may we all make some money off this please?

Mike Julian: Yes, please. On a completely unrelated note, I heard you're writing a book.

Emily Freeman: I am indeed, I am writing DevOps For Dummies.

Mike Julian: That sounds awesome. My condolences and my congratulations.

Emily Freeman: Thank you. I see you've written a book.

Mike Julian: I've also written a book. I know the pain, so I'm not going to ask you how your book is going, lest you punch me through the phone.

Emily Freeman: It's true. I think we all have those friends that are like, "Oh how's the book going? Are you making tons of progress? Are you excited?" Then you're just like, "No, none of those things. I'm not making any progress. I feel sad. I actually don't want to talk to you anymore. Where's a drink?"

Mike Julian: Been there.

Emily Freeman: Yeah, it is the hardest thing I have ever done. I don't know how to describe it. I think all authors are all people who have attempted this get it, but it's incredibly difficult to convey just how difficult it is.

Mike Julian: Yes, I've had that same struggle. I've read several books by like the Stephen King wrote on writing where he gets into that. Steven Pressfield wrote The War of Art, it's the same idea and then Anne Lamott who lives in the Bay Area and is absolutely wonderful wrote Bird By Bird, which is kind of the same thing, but for creative writing. All of them talk about the same idea of writing sucks.

Emily Freeman: Awful.

Mike Julian: There's a quote by some author he's like, "Writing is easy. All you've got to do is slice your wrist and bleed out."

Emily Freeman: Then it's done.

Mike Julian: Right, and then it's done, like it's just that easy.

Emily Freeman: Yes.

Mike Julian: Writing a book is hard and I just realized I don't think we've mentioned the title of your book here.

Emily Freeman: Oh we did briefly, DevOps For Dummies.

Mike Julian: DevOps For Dummies, okay.

Emily Freeman: DevOps focus through O'Reilly but the standard yellow dummies books, so yeah it will be a high-level book, because it is.

Mike Julian: Sure. Why another DevOps book?

Emily Freeman: Well there's not actually a ton of DevOps books. When you actually look at it, there are the really well-known ones. When you look at the actual authors it's like 10 people. I think it would be, my pitch to O'Reilly was one, don't think there's a ton of work done for the dummy or the beginner or the manager or the developer who knows nothing about operations, but has heard of DevOps and wants to like see this. I do think that DevOps is still very Ops-focused and I think when you go to DevOpsDays events or any of these DevOps focused communities and you ask, "Are you a developer? Are you an operations person?"

Mike Julian: You're right and mostly sysadmins.

Emily Freeman: Exactly. I think it's really interesting sitting between those two communities, because a lot of operations folks express their concerns to me about, "Well I don't know how to code and obviously I can't. How do I evolve? What's this place for me in the future especially with cloud? Am I losing my job?" There's no Ops which I think is absurd. Then the developers, interestingly, have the opposite fear. I was like, "Well I can develop, but I don't know how the systems run, I can't deploy I don't know what to do. AWS is big and scary. Azure is confusing." All of these things. I think it's interesting to bring those communities together, but because I have a development background, I think I bring a unique perspective that some of the other books just haven't had because they're written by Ops folks.

Mike Julian: Yeah. I love that pitch.

Emily Freeman: Thank you.

Mike Julian: What sort of stuff will you be covering in the book?

Emily Freeman: I broke down into like five parts with very much the DevOps focus of like people, process, tooling, people-process-tools. The first part is more focused on getting started in DevOps. You've heard about this DevOps thing, this is what it is. It's born out of agile, it's an evolution. How to transform your organization to start thinking like this. How to get people on board, finding internal evangelists. Then we kind of get into the development life cycle and making sure that DevOps is integrated into every step. I've kind of brought it down into, let's look at this linearly and then let's create a cycle around this. To center the customer within that cycle and then to round it out how you can tool or add tools to your pipeline.

Mike Julian: Okay.

Emily Freeman: Yeah.

Mike Julian: Yeah, that sounds pretty good. I love how you've broken that down.

Emily Freeman: Thank you, I'm glad you're enthusiastic. One of the things ...

Mike Julian: One of us has to be, right?

Emily Freeman: I know. I try to be really genuine and open and honest about this process, but one of the weird things about writing a book is, I'm halfway through. You go through these cycles where it's like you get excited about it. It's like, “Okay this is good. Oh that's a brilliant idea. Yeah, write that down, this is great. Oh no, that's terrible. I'm unqualified. I should really just get out of tech. I think Kim's going to cry when he reads this.” Yeah, it's this weird cycle, so I'm constantly thinking like, "Yeah, I think this is good, but maybe it's not." In some beautiful irony, you cannot DevOps a book. It is a wonderful process.

Mike Julian: Absolutely.

Emily Freeman: I write it and then people decide whether it's great or shit and then I find out. If it's bad, you can't rewrite it and you only get to rewrite it if it's good, which is funny I think.

Mike Julian: It is funny, funny in a, “oh God kill me sort of way.”

Emily Freeman: Yes, absolutely.

Mike Julian: O'Reilly who I wrote my book for, they modified the traditional process a little bit. You write several chapters, basically half the book, and then it goes off to for an early release. Then you're supposed to solicit feedback during this period. They also send the entire draft to technical reviewers, people in the community that are practitioners and are good at whatever it is you wrote the book on. For example, I was one for Jason Dixon’s Graphite book, so I read that book. I was there while he was writing it, writing technical feedback on it. Then he had several other people also doing the same thing and the same thing for my book. I think I had like six different people — all fantastic well-known people in the industry — that were providing feedback on it. I got this as I went through which was really, really helpful.

Emily Freeman: That's awesome.

Mike Julian: Right and then by the time you get to the final draft, the communities already seen it. You have some feedback, but it's still not as great as you would want. At the end of the day you're just writing a bunch of words and you're hoping they make sense. I was talking about it, I would love to write a second edition of mine, because my book doesn't include a bunch of information that I wish it did just due to time constraints. Like my book doesn't talk about observability. I don't even think the word is in the book at all. That is kind of dumb and people are asking me about it, but you can't do a second edition unless the first one sold well.

Emily Freeman: Exactly.

Mike Julian: That's really dumb. Like I want to do a second edition because I can do it better than the first.

Emily Freeman: Yes, absolutely. It will be better than the first. That was your first book right?

Mike Julian: Yeah.

Emily Freeman: I think one of the struggles I've had as a first-time author is just recognizing that this, Mary Thengvall actually put this best. She was like, I was having a total panic attack and I called her. She was like, "You are writing a book on DevOps, not the book on DevOps."

Mike Julian: You're writing the first?

Emily Freeman: Yeah. Like, "You're not the first, this isn't the Bible, calm down." I think just the difficulty of actually getting it out is such a hurdle that you're never going to be satisfied with it. You want to make those changes and updates.

Mike Julian: One of the biggest struggles I had, I don't know if you've experienced this, like I would sit down and I would look at my notes and be like, "Oh man I have this great idea, I know exactly what I want to say," it's just rolling around my head. Sit down, bang it out and then you look at the paper like, "Wow, that is absolutely like nothing that meant to say."

Emily Freeman: Yeah, it's a great process. I had this tweet at some point and I don't remember exactly what it was, but it was like, the process of writing a chapter. It was like, “Think about it, have existential crisis, write a little bit, hate everything. Drink too much, write some more. Love it, feel confused, brace for editor feedback.” I'm like, “I think that's apt, yeah that's pretty much the process.” Yeah, it's a fascinating thing to do. I think from every author I've talked to, it is absolutely worth it. It will be great. Outside of the benefits of creating a platform for yourself and a personal branding thing, it is really good as a learning process.

Mike Julian: Absolutely.

Emily Freeman: Stretching some of these atrophy muscles. It's a marathon. That's where I think what the hardest part is, it's a marathon and there's no rewards.

Mike Julian: Yeah, like you just keep grinding.

Emily Freeman: Yes. It is an absolute grind until it's over and then you're like, "I hate this whole thing, I don't want to talk about it." Then you're like, "Promote it."

Mike Julian: Then the real work starts.

Emily Freeman: Exactly.

Mike Julian: It took me 19 months for mine start to finish.

Emily Freeman: Dang, okay, yep, yeah. 

Mike Julian: That was about 40,000 words, 45,000.

Emily Freeman: Dang that makes me feel better.

Mike Julian: Yeah. This is one of those things that when you talk to a publisher you say, "Well how long does it take to write a book?" Then they're like, "Oh about six months." You're like, "No." When you talk to authors they say, "No, the average book, nonfiction book, takes about two years to write." There's this huge disconnect between what the publisher is telling people and what the authors are actually doing. No one's really talking about it.

Emily Freeman: No, and I think the publishers have gone on to the fact that they have to put arbitrary deadlines in to stress us the fuck out. Then we actually ...

Mike Julian: I'm pretty sure O'Reilly did that to me, because my original contract said the book would be draft complete in like three months.

Emily Freeman: Same, exact thing.

Mike Julian: I'm like there's no way that's going to happen.

Emily Freeman: No.

Mike Julian: I don't think I hit draft until like 14 months.

Emily Freeman: Okay, all right, yeah, that works. No, I just talked to my editor, who's fantastic, he's great. He just pushed it back. Editors play a really funny role, because they're like a coach in that they have to push you but not so hard that you break. It's like this like, "You need to get this done, but also we love you and it's okay."

Mike Julian: One of the things that really pushed me was when they asked/threatened to get me a co-author.

Emily Freeman: Oh my God they all play this game. There's a run book. There is a publisher run book.

Mike Julian: I think there is.

Emily Freeman: That is hilarious. Yeah they said like, "If it's not like 75% done by March or something we've got to get a co-author." I was like, "No."

Mike Julian: That was my response too. Like, "No, no, I've got this. Give me a little bit more time."

Emily Freeman: I know. Mostly because I don't want to have emails back and forth arguing about things. I'm like, "I will just get this out."

Mike Julian: Yeah, it's like, "Let's spend the time arguing what DevOps means instead of writing about it."

Emily Freeman: Yes. Which is a very tech thing I think.

Mike Julian: Right, of course.

Emily Freeman: It's how engineers write books I think.

Mike Julian: Yeah. When I look at other authors it's like James Tangle who just routinely cranks out tons. I'm like, "How do you do this?" Then Ryn Daniels and Jennifer Davis and The Effective DevOps, like holy crap that was an amazing book. They both wrote it together which is already insane feed and it's big. It covered a lot of stuff, and like I look up to people like this. Before I started writing mine, I was looking at people like, "Wow, this is the sort of stuff that I want to do." Now that I'm having done a very shorter version of that, it's even more impressive what a lot of these authors are able to accomplish.

Emily Freeman: Yes. Absolutely it is.

Mike Julian: I'm very much glad I wrote a book, but the process of doing it is pretty crappy.

Emily Freeman: Yes. I always compare it to childbirth, like once the baby's there, it's like, 'Oh totally worth it, “Easy, I'll have another one." You know when you're in stage of labor and everything hurts and you're just like, "I will murder everyone in this room immediately." Yeah, it's a hindsight. It's much lovelier vision.

Mike Julian: Yeah.

Emily Freeman: Can I ask you, before we can move on, I want to just highlight. I think one of the things like you saying Jennifer, she's my colleague and I love her. She's fantastic. She cranks out books and everything. It's just funny like how to the outside world I probably look fairly productive and put-together. Then like I'm sitting in a room where there's like a pile of stuff that I need to put away. There's unfolded laundry. There's toys everywhere. Things are just a disaster. It's like I feel like I'm not functioning at all and yeah, it's funny how we compare our other people's highlight reels to our bloopers.

Mike Julian: Yeah. I would love to see Stephen King's process, him having been writing for 30-plus years. I'm sure it's not that clean. Like I'm sure you look at round his office and he's probably in just as bad a shape as we are.

Emily Freeman: Yeah, absolutely.

Mike Julian: Well on that note, you mentioned on Twitter a while back and what got me reaching out to you to have this episode. You mentioned some, I don't know how to describe it. Like all you said was just like a hint of an idea that you see a parallel between legacy code, railroads and subways.

Emily Freeman: Yes, so I wrote this abstract. It's the talk I want to give this year and I have to figure out who might actually be interested in it. It's talking about maintaining our legacy systems by comparing them to the first subways. I believe London was first, the Underground was first, then the Metropolitan subway in Paris. Then New York City. At this point we're dealing with century-old train systems that were sort of haphazardly put together. The engineering feats that these initial engineers actually overcame during the building of these is fascinating. If nothing else, like go listen to some podcast about just the first subways. For instance, there is a subway station in Paris that is underground, but actually suspended. It is on an underground bridge, because the plastered Paris quarries, I always screw that up. The plastered Paris quarries are so deep, going back to the Romans, that they are just these massive holes underground. They built these enormous structures to hold these trains and stations up.

Mike Julian: That's incredible.

Emily Freeman: That kind of thing.

Mike Julian: Right.

Emily Freeman: Yeah, and then New York deals with so many problems. I mean some of the electrical wires that we still use for communication are insulated in cloth, if you can believe that.

Mike Julian: I had a house like that.

Emily Freeman: Did you really?

Mike Julian: I really did.

Emily Freeman: Like how do you mean? That just sounds like impossible and a fire hazard.

Mike Julian: I mean it absolutely is a fire hazard.

Emily Freeman: Okay. Solid. 

Mike Julian: In the 1940s and I guess back to the '20s there was this type of electrical wiring setup called knob and tube and it's like the cloth is wrapped in wax. Then you wrap the wire connections in that. You're not actually wrapping it in cloth, but of course over time the wax breaks down at which point everything just sparks and catches fire.

Emily Freeman: Yes, absolutely. I mean if you look at, I think rats cause a bunch of problems in the New York subway.

Mike Julian: Oh yeah. As it turns out rats really like electrical lines.

Emily Freeman: I know. It's fascinating. Yeah, I just think it's really interesting how we take these ideas. We execute them without really knowing what we're doing of course, because just like the first time you write a book, the first time you write code, it's not going to be beautiful. Then we typically, 90% of the time never get back to actually fixing it. I mean I think if we're honest, probably most companies have a corner of code, where like the new employee orientation is just, "Don't touch that. If you touch that everything breaks. No one knows how this works. It's written in cold fusion. Just don't touch that." I think it's important to have a respect for the initial engineers who actually did something that was really hard even though now, with hindsight, those decisions may look bad. They were making the best decisions they could with the data they had at that moment. Then how do we, with that understanding and respect for them and the systems they produced, update and maintain them and maintain all these availability, reliability for our current customers? I think it's pretty interesting.

Mike Julian: Yeah, that is really interesting. If you're interested in more about the London Underground history, I think there's a documentary on I want to say Netflix about them building the first Underground.

Emily Freeman: That's amazing.

Mike Julian: Yeah, it's super cool. I really enjoyed it.

Emily Freeman: I'm going to write that down. I'm a documentary nerd.

Mike Julian: You seem to have a flare for this, the parallel stuff. I was looking at some of your talks just recently and you did one on building teams and how it relates to Sparta.

Emily Freeman: Yes.

Mike Julian: I'm like, it was really cool.

Emily Freeman: Thank you, I'm glad. Yeah, this is my contribution to tech. It's like I have a humanities degree. I went to school for political science. I love history. I wrote for so many years, so I like books and that kind of thing. I think every talk is somewhat related. I have Humpty Dumpty Guided DevOps, the Sparta talk, Dr. Seuss's Guide to Code Craftsmanship.

Mike Julian: Which is also really great.

Emily Freeman: Thank you. There's a pattern here.

Mike Julian: I see that.

Emily Freeman: Yes. I have a shtick and I'm shticking to it, I will just say that.

Mike Julian: Bravo.

Emily Freeman: Thank you. Yes.

Mike Julian: Well that sounds like it's going to be a really awesome talk. I'm looking forward to 

seeing it on stage wherever it gets selected.

Emily Freeman: Thank you.

Mike Julian: I guess for anyone listening to this, if you have a conference, please invite Emily.

Emily Freeman: Yes, that'd be lovely.

Mike Julian: She has a talk.

Emily Freeman: Yes. That'd be awesome.

Mike Julian: Well thank you so much for joining me on this. It's been absolutely fantastic.

Emily Freeman: Thank you so much. I've had a wonderful time chatting with you.

Mike Julian: Yeah. Where can people find out more about you and your work?

Emily Freeman: Yeah, so on Twitter I'm @editingemily, like writing and editing. You can find my website at emilyfreeman.io.

Mike Julian: All right then. Well, and thank you for all the listeners for listening to Real World DevOps podcast. If you want to stay up to date with the latest episodes, you can find us at Real World DevOPs.com on iTunes, Google Play or wherever it is you get your podcast. See you in the next episode.