This week we chat with Stephanie Morillo, author of 'The Developer's Guide to Content Creation.' She explains how coders can become successful writers, expanding their network and improving their resumé, while learning new skills and sharing their technical insights with others.
Along with her work writing and editing, Stephanie works as a product manager at Microsoft and runs Developer Content Digest, a biweekly newsletter with content tips. She has worked for companies like Digital Ocean, GitHub, and General Assembly.
Newsletter and blog: stephaniemorillo.co/links
Stephanie Morillo Really that's what the editor is there for. They're looking at things. And considering them from the reader's perspective, almost like, you could think about it like UX, right, like the user experience. They are there to try to understand how a reader who is reading this piece or experiencing this for the first time, how they may react to your piece.
Ben Popper Now many cloud technologies are emerging that are open source and relatively untested. Smart organizations rely on tested mature technologies. NetApp's proven cloud storage service supports innovative and evolving infrastructures, so that you strike the perfect balance of time, cost and risk. Regardless of where your data lives. Learn more netapp.com/stack.
Sara Chipps Hey everyone and welcome to the Stack Overflow Podcast. I am here with my amazing co-hosts, Ben and Paul. Hey Ben and Paul.
BP Hello! Hello!
PF Hey Sara. Hey Ben. Wait, was that an accent, Ben?
BP It's British.
PF Far be it for me to produce the producer, but come now.
BP Sometimes it just slips out. We were reading a lot of Harry Potter this morning. So I've been working on my various British accents.
PF This happens, my daughter loves Harry Potter, which means that as an eight year old, she thinks she's excellent at British accents. And, it's a lot.
SC That is a lot. After I introduce our guests, I need to know everyone's Harry Potter house. Very important. Okay. [Sara laughs] Today we have an amazing guest with us. Stephanie Morillo. She's an author, and teaches developers things like how to produce content, which is hard for developers. Welcome, Stephanie.
SM Hi it's nice to be here.
BP I was telling Sara, this is really my sweet spot. I'm the content guy who works with a bunch of developers so, very excited for this episode.
SM Awesome, my people!
PF Great, welcome. Break it down for us a little bit. How can you help me Stephanie? I'm a good programmer. I post on Stack, I just don't, no one seems to understand what I'm talking about half the time.
SM There are a few things. I can help you if you are trying to figure out what to write about, right? So you have a bunch of ideas in your head, but you don't know which one you actually want to get started with. Or maybe you have a bunch of ideas. But sitting down to write is a dreadful process. And it takes you a really, really, really long time to get a draft out and actually publish it if you're scared about sharing your content. So maybe you're just hanging out on the Stack Overflow forums, and you're lurking for a bit, maybe you answer a few questions, but you know that you could write an article about something but you're nervous about how people are going to react to whatever it is that you're writing. So what I do is, I help you understand the content production process from end to end. So for a lot of people, writing seems to be like this mystical activity that happens only among Nobel Prize winners and literature. Everybody else doesn't, you know, it's a gift that the rest of us don't have.
PF I mean, as a writer, that's what I often tell people, I'm just like, this is not for you. Come now.
BP Nobel Prize and underpaid bloggers, those are the only two kinds those those are the only two kinds.
SM Those are the only two kinds. So then for the rest of us, it's like, ''Okay, well, how do I write this beautiful, beautiful thing?'' So what I do is tell you that first of all, Nobel Prize winners in literature also have editors, they also produce really bad first drafts like the rest of us. So it's about finding the time, I help you understand how you can find the time to write, I can help you find multiple ways to get ideas so that you don't actually run out of ideas, I can pretty much break down what the writing and editing process should look like, so that you feel like you have a guideline, and then get you to start publishing, you still might be a little bit nervous and afraid, because it's natural. It happens to me too. And I've been writing for a very, very long time, but you'll feel a little bit less nervous every time you do it. And you might find that you actually enjoy it. And then you start getting into a rhythm of writing a lot and publishing a lot, which is what we want.
BP I mean, I think one of the things that's different about writing and coding and Sara, I'd love to hear your opinion on this is like, if you're writing great code, and then it has to, you know, run through a compiler and work with the system and your colleagues look at it, you know, if it's really good, and it performs really well, you'll be able to tell that like, you can test it and measure it, you know, certain metrics, speed or reliability, you know, size, memory. When you're writing, like my experience, I would sometimes spend a year working on a feature piece, and we would publish it and it really wouldn't take off. And then I'd spend 30 minutes doing a blog, a hot take, and it would go viral, and people would talk about it for weeks, you know, so with writing, it's like, so there's good writing, there's bad writing, but it's like, it's often also about like, ''Am I hitting the right zeitgeist? Did I have the right headline? Did the right person retweet it early in the morning?'' you know, so that is a kind of element of chance. I think it's a little bit different than the world of software development. But Sara, you've done writing and programming, what are your thoughts?
SC I think what I've observed and Stephanie, I'm glad you're doing this, because what I've observed is there are some developers that are very good at this very comfortable. Like, I'm just like a very like, train of thought writer. And for some reason people have responded well to that. But I think that what I've observed is there, not a lot of developers that are super comfortable with it. So I think getting a guide together is really helpful for them.
BP I've also noticed that a lot of developers are excellent writers in the sense that they, I think, spend a lot of time sitting at a computer for hours trying to work through a problem. And so they're used to that kind of that's like a habit for them. That's a place where they're ready to go, like, I'm going to work on something, get stuck, spend a few hours thinking about it, go back again and sit in front of my computer for a couple hours. And that is you know, the process of writing, the heart process of it. And if you're not used to that, you know, it can be tough to do, so I think in some ways developers have built certain muscle memory in their activities that is actually kind of useful for writing.
SM Writing is a is a vulnerable activity for many people and Ben, to your point about how with certain assets of coding, you can have more or less like a quantitative measurement. Whereas with writing, a lot of it can be rather subjective. And you don't always know or you can't always tell, what's the thing that's actually going to hit the mark or get people to really, really, you know, get all the eyeballs on your blog, for example, and it happens to me, I will have like an emotional attachment to a piece that I'm writing. And then I publish it and you know, it gets a lukewarm response. And I'm like, I didn't expect that. And the thing that took me 10 minutes to whip up, that I think no one's going to want to read, that's the thing that ends up being the thing that people want to read. [Ben laughs] And I think also with programming, I feel like programmers have done a really good job of breaking down not just the aspects of writing code itself, but the systems and the processes behind, you know, like, like the methodologies and the frameworks of actually creating something whereas with writing it, a lot of people don't see it as like a systematic process, right? It's like, you sit down on this, you know, beautiful wood oak table and the words just come out and everything is right. [Ben laughs] Like it's it's a lot of like the the fluffiness. But I think a lot of it is because we can't always quantitatively measure how content is compared to coding. So as a result, we see it as more of like a spontaneous activity that just happens and that some people happen to be really, really, really good at it. I've been writing for most of my career. And I've during the course of that time, I've improved substantially, but you know, even then, even then, there's people that are way, way better at it than I am, I have some metrics that I can use to at least measure whether or not somebody liked what I read, but they're not going to be you can't you can't measure it all.
BP I've been sort of very deep into the world of documentation, because we just put out a new product called Articles, which is like supposed to help developers who are using our teams, and they're doing a lot of Q&A, but now it's like, hey, maybe something doesn't just fit as a short question, answer. Maybe you want to write longer form prose. And one of the things you just said really resonated, which is like developers were telling me, one of the things I hate About documentation in the past, I'd do it for the Wiki. I'd spend 10 hours on it. And then I didn't really get any feedback. Like, I don't know, did people read it? Did they? Did they like, I don't know, I just put it on the Wiki. Whereas, you know, with Articles more like Stack Overflow, you get pageviews, you get up votes, you get comments, you know. So they're like, I'm much more inclined to do it now. Because I at least get some of that tangible feedback. And in fact, they were saying I used to sort of cheat, I would I would do documentation, then I'd sanitize it. So like, I wasn't showing any proprietary information, and then I'd publish it on my blog, because then I could get some feedback. And then, you know, for my 10 hours of work, at least I'd get some, you know, people to share it on social media, whatever. So people, as writers, like you said, definitely crave that that feedback, because not just the investment of time, but the vulnerability. These are my thoughts. I'm sharing. I'm trying to give you my best thoughts. I hope somebody will tell me that these are good thoughts. [Ben laughs]
SM For sure. For sure.
PF Stephanie, you know, one thing I find when new writers start writing and they're edited for the first time, that's a very mysterious process, when someone is taking your words and shaping them and it can lead to all kinds of emotional challenges or and all sorts of complexities. So what advice would you give for writers who are working with editors?
SM That's a great question. Paul, I think you know that the writer editor relationship can sometimes be fraught even if you work with an awesome editor, but then you just get your your draft back, you know, with a bunch of markup, and then this is wrong and this is wrong. And it's this does not meet style guidelines or whatever. And you're just like, ''Well, can we just do the thing? Can we just ship the thing?''
PF One of the things I like to say is like, your words are not precious diamonds, they're more like gravel that are getting moved around for landscape purposes. [Paul & Ben chuckle]
SM Ohh I like that! That's a good one. Yeah.
PF The editors job is to shovel not to polish, especially at first.
SM Yeah, that's a great analogy. I think for writers, I think that it's easy to look at the editor as the bad guy, the person who's here to just like crush all of your hopes and dreams but I'd tell writers that the editor is there looking at your piece from the readers perspective, you know, they haven't looked at it before we, you know, if you're writing and you're drafting you've looked at your piece hundreds of times, it's really easy to gloss over certain areas not know what's missing, not know, if there are areas that are confusing areas that could be fleshed out more. And really, that's what the editor is there for, they're looking at things. And considering them from the readers perspective, almost like, you could think about it like UX, right? Like the user experience, they are there to try to understand how a reader who is reading this piece or experiencing this for the first time, how they may react to your piece. And there's looking for things like improving readability. I mean, like, any writer can tell you how difficult it is, especially I think, technical writers, because a lot of technical writing can be really dry. It is really difficult to be clear and concise, like, you know, sentences that are less than, like 20 words long and you have to convey so much information in a way that you don't lose the reader any step of the way. So I tried to tell folks, the editor is not there to grade your draft. They're there to to make it easier for your message to be conveyed to the reader, right? They want your writing to shine so that the reader can understand, comprehend what it is that you're trying to say and take whatever action it is that you want. I also tell folks, if you don't understand why an editor made a choice, you can always ask the editor, you know, you can and if there's certain areas that you're pretty sure that you want to keep, that's a conversation. So I think it's the editor relationship reminded me very early on of like getting graded by a teacher, right? Like, you get everything marked up. This is wrong, this is wrong, this is wrong, and as a student, you know, a fourth grader, you're not going to necessarily challenge the teacher on you know, certain word choices, or you know, your spelling of a certain word. But as a writer, it's supposed to be a partnership. So you you can do more of that. And if there's a particular choice that you're not clear on, it's important to talk to the editor. I think more writers should have open conversations with their editors ask them about their process too, that's always really helpful. You want to know what to expect when they are finished reviewing your piece. You want to know what you're going to get back? Is it just like a bunch of things crossed out? Are they going to add comments? Are they going to expand on why they made a specific choice? Are they, like what happens there? So I think a lot of it needs to be conversation. And I think writers should feel confident going into working with an editor, knowing that it is a partnership, there is not it's not that the editor is better than the writer and the editors like the overlord of your work, it is very much they are there to help improve it so that it's better for the reader. But you as the writer, you are a part of that conversation. So you should feel empowered to speak up when needed.
BP I like what you said about UX. You know, a lot of times I think great editors really help out with things like transitions between ideas, which is kind of like the flow. Like if if somebody is in your app, and they're trying to find something in a menu within a swipe, and then they get lost, you know, like they're gonna have a bad experience. It's the same where it's like, I introduced this idea. Now I'm transitioning to something different and I want to circle back to that idea, you know, you have to help people connect the dots there, like you said, readability. Sara, I wonder like when we talk about vulnerability as a writer, when you're working with a bunch of people at Stack Overflow, or you're working on the open source side, and you're working in some kind of Git, you know, with with requests, people are commenting on your code or saying this could be better or why did you write it like this? Do you think there's that same element of vulnerability where it's like somebody is looking at my work and critiquing it? You know, do you feel as you're writing it, knowing that other people are gonna look at it, some of that same vulnerability that a writer might feel before they publish something?
SC Yeah, I wonder how similar it is to like a pull request. Commenting on someone's pull requests. I find that like, some people are very good at being thoughtful about giving that kind of feedback and sensitive to how much works must have gone into something and some people are just like, this is bad. This part needs this needs to be better. So I suppose that's the difference between a good and a bad editor as well.
PF Now wait, there are all kinds of editors and all kinds of writers right? Like it actually, it's like a shrink. It's the one that works best for you.
SC Well, do some people need that editor that's like ''this is bad''?
PF Of course, look, I'm gonna be frank, the more advanced you are in your career, the more that is actually a really useful editor to have. The very delicate ones are who are protecting your feelings or advocate, by doing that they're advocating less for the reader, the more you can give them the opportunity to advocate for the reader, the better your piece will end up, but a lot of times emotions, people believe that the things they write are themselves. And that's that's a lot to process.
BP I wonder, yeah, thinking again, about like, the parallels between writing and code. A lot of times, if you were to give an editor a piece that's, you know, 1000 words, 1500 words, and they were to say, you know, if you just cut this, this and that, like, you'll really have the best parts, and it's hard to let go, you're like, but I liked that. But I spent, you know, three hours on a sentence, but that sentence is funny, but it's like, well, actually, but if it's just the best 800 words, this piece is gonna reach a lot more people it's going to get shared more, it's going to like people are gonna be like, wow, I came away from that, you know, and I sort of the idea was was really flesh, not just fleshed out, but like succinct, you know? And I wonder if the same thing is true for code when you're when you're making requests or like working as a team where it's like, people are like, well, we could just tighten this up, we could do less. But you've written a lot. Do you ever feel like I don't want to take away, like, take the taking away as the hard part, after you've done the work. It's the deleting, it's the, you know, the removal that's can be painful
PF With code? Yeah, sure.
SC Yeah that makes sense. Code review and removing code has a slightly different culture than around prose. Like the thing with code is it does something and usually multiple people work on it before it even kind of takes its its true form. And so it's just a different editing culture because you there isn't one author. It's not one. But you know, your code rarely has a byline, and it's not like one opinion. So Stephanie, tell us about your book.
SM Yes. So the Developer's Guide to Content Creation was a book that I almost didn't write because I thought that it would be too, too self evident, too basic for people to want.
PF Oh no, it's such a great idea. I'm so glad you did it. [Stephanie & Paul laugh]
SM Thank you. I mean, that's it came really out of my it was born out of just my experiences in the developer space being a content person. I started out as a copywriter at Digital Ocean, so all cloud infrastructure stuff and then through that experience, I worked my way into product and then eventually owned the company blog, which at that point was kind of like this. It was really, really underutilized. No one was doing anything with it. There was no plan for it, Digital Ocean's, a lot of their content strategy at that time was really centered around the tutorials and articles that they've become really well known for. So I decided to take the blog under my wing and do whatever I wanted with it and whatever I wanted with it was trying to find the interesting things that the engineers in the organization were doing because I wanted to be able to have them tell their own stories. So that was awesome because I pretty much just trawled this bunch of engineering Slack channels at work. And if an engineer was talking about something really awesome that they did I ping them and say, yo, do you want to write a blog post on this because it'd be really awesome to have on the blog. And it was great, because a lot of the folks that I reached out to, not all of them were writers or comfortable with writing, rather, they're all writers because they were all published, but they, a lot of them were very early in their journey or, and a lot of them actually said, Oh, this was something I thought I'd write for my personal blog, I didn't know something that I could do for the company blog. Through that experience, I edited their work and deliver feedback and had them do peer reviews with someone on their team so that someone on their team could review their work from the perspective of a colleague, which is really important, just technical accuracy, checking for all of that fun stuff. And then I did a lot of the copy editing and some developmental editing. And that was fun. I felt like that was where I really learned how to work as an editor for engineers on technical content. We ran the gamut in terms of the kind of things we publish, we publish an article on like, you know, like a go mono repo and on networking and running a platform team, an internal platform team and a bunch of stuff. So I was, you know, even if I was someone who was a developer and came into that role as a developer, there was no way that I was going to be an expert on everything because we just had team members that specialized in a bunch of stuff. So it was really, really educational. And then I started doing freelance. So I started working with developers as a freelance copywriter. I edited books for O'Reilly, folks just started reaching out to me, Hey, would you edit this? Would you do this and then eventually, I became the in house content strategist for Microsoft's Developer Relations team, their Developer Advocate team, which was really cool, because I wasn't an editor I was kind of like a conduit between the Developer Relations team marketing, I was, I was reviewing marketing stuff from like the perspective of a developer marketer, right? Like, okay, this messaging is not gonna work. This is gonna fall flat. This is what you need the CTAs to be. So I was looking at everything from like, a bunch of different angles, right, somebody coming at it from marketing, somebody coming at it from a freelance perspective. And then Developer Relations. So I, felt like I, all the content, I had it already I when I understood the scope and when I really like honed in on who I wanted to reach out to. And it was the folks who were kind of like I really, really want to blog, but I don't know how to start or I blog before but I got burned. And I don't know if I want to do it again. It became actually very easy to write. I wrote the entire draft in 11 days.
PF Wow! Okay, wait, whoa, I'm like, yeah, 11 days. For those who don't do a lot of writing, that is, that's about how long it should take to write like a nice long article. So this was in your heart. You were like, I've got to get, developers need to be thinking better.
SM Oh 100%.
BP Yeah, when you're when you're sort of like taking a few years that were really meaningful and where you learned a lot it sometimes it can be distils that right? Like I found that was true. If you did reporting out in the field, and you actually met people and you talk to them, then when you got back, it was always easier to write because you had all the details of what actually happened, not just the big ideas, but like the process of it as well. But there was one thing about your story I didn't find believable at all, which is that I also asked developers to write for the blog. And they always say yes. And then they don't do it. They just get too busy and they don't do it. And then I'm like, I thought you said you'd write for the blog. And they said I did. But then my manager said to do this, and I'm so sorry, I'll do it next...
SM It is 100% believable. And in fact, when I left Digital Ocean, there was a backlog of like eight or nine articles that were in progress that got published, like, three, four months after I left, they didn't really have to do much
PF Unless someone is tending in a managing editor role to that pipeline, it does not happen. And this is always the fantasy that somehow the CMS or there'll be some magical thing that will unlock content in your organization and it is your listening to Stephanie now that is who unlocks content in your organization. It's a person.
BP Stephanie, after this you need to give me your tricks for, going from getting the yes to actually getting that first...
PF I'm on year 20 of knowing that you need exactly like, I'm sure it was like steady communication like...
SM A bunch, a bunch and with multiple people at one time so that you are never dependent on that one engineer for, you know, like, when I took over the blog, my manager who was then the Director of Communications was like, we want to have a healthy pipeline of about eight blog posts at various stages have done, right, in progress things in the backlog. So it wasn't just, yeah, I mean, so it wasn't just that I was reaching out to that one engineer and then bugging them. I was reaching out to them, their manager, a bunch of other people checking emails like it was, I was constantly hunting for stories. And I knew that we would hit exactly what Ben alluded to, which is engineers are busy, right? They're doing this in addition to their core work and to their additional work. So I had to adjust my process to account for the fact that there would be changing priorities that it would take longer than a week or two to get a draft. And that as a result, I would need to basically have as many conversations with as many people as possible to ensure that I could hit the publishing cadence, which at that point, at first, it was like once every two weeks, then we hit once a week. And then when I left, it was almost two blog posts a week. So and I mean, I did the same one, I went to GitHub, I was actually GitHub, right after Digital Ocean for a spell for a few months. But GitHub was different because they had a culture of everyone feeling that they could contribute to the blog. But additionally, I was pinging engineers and saying, Yo, I saw that you did this awesome thing, I want to write it, I want you to write about it. Let's work on it. And people were really excited. I found that people were willing to make the time for it, even if they couldn't get it like within what we consider a timely manner, which is like two weeks. Still, people were still committed to getting something because they appreciated the validation that I gave them from saying this is a story worth telling. And moreover, it's a story that's worth publishing on the blog. And frankly, talking to engineering managers is key here because you want the engineering managers to understand the value that exists for their team and their organization, in having an engineer write about something. And a lot of, a lot of engineering managers are like you know what, this is awesome. This is something that I definitely want my team to do. So we work together to figure it out, right? Like, I know that it's not going to be the same as if I had a content marketer writing a blog post, I know that they're going to get something to meet within a week, maybe even a few days, an engineer is going to be different. But you know, doesn't mean that necessarily that they don't, that they're not interested. It's just the touch points are different.
BP What we usually do at the end of every episode is we read out a lifeboat, which is a badge we give to folks who have helped to save a question that was languishing with a negative score, and now has a popular score of 20 or more. So this question is two years old. It says 'Angular six material animations do not work. Animations and material components do not work. I tried these different things, and it didn't help.' We've got a lot of code here. Answer 'I solved the problem by removing the imported new animation module from the app module.' Thank you Kim Cindy, for saving some earning yourself a lifeboat badge.
PF Life moves on, there it goes.
SC It does, before we wrap it up just really quickly. We don't have to. It doesn't have to be a discussion. What is everyone's Hogwart's house? [Ben chuckles]
SC I'll start. I'm a Slytherin. I did not expect it.
PF I'm a Hufflepuff. I always have been.
SC Wow, Paul. I never saw that coming. I'm so sorry.
SM Oh, my goodness. What did you think he was?
PF No, that's what a Slytherin would say. [Sara laughs]
SM True. True. Very on brand.
PF Yeah, Hufflepuff is a noble house, our sigil is the badger and you can all go mmm yourselves, as far as I'm concerned, because that's Hufflepuff.
BP Yeah, Stephanie. Tell people where they can find you on the internet if you want to be found and where they can check out your book.
SM Sure, you can check out my book at developer'sguidetocontent.com. I am on Twitter at @RadioMorillo and you can find me at StephanieMorillo.com.
BP Awesome. I'm Ben Popper, Director of content here at Stack Overflow. And you can find me on Twitter @BenPopper.
SC And I'm Sara Chipps, Director of community here at Stack Overflow. And you can find me on GitHub at @SaraJo.
PF And I'm Paul Ford, friend of Stack Overflow, you can find me on Twitter @ftrain.