The Changelog: Software Development, Open Source - The developer's guide to content creation (Interview)

Episode Date: February 21, 2020

Stephanie Morillo (content strategist and previously editor-in-chief of DigitalOcean and GitHub's company blogs) wrote a book titled The Developer's Guide to Content Creation — it's a book for developers who want to consistently and confidently generate new ideas and publish high-quality technical content. We talked with Stephanie about why developers should be writing and sharing their ideas, crafting a mission statement for your blog and thoughts on personal brand, her 4 step recipe for generating content ideas, as well as promotional and syndication strategies to consider for your developer blog.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by DigitalOcean. DigitalOcean's developer cloud makes it simple to launch in the cloud and scale up as you grow. They have an intuitive control panel, predictable pricing, team accounts, worldwide availability with a 99.99 uptime SLA, and 24-7, 365 world-class support to back that up. DigitalOcean makes it easy to deploy, scale, store, secure, and monitor your cloud environments.

Head to do.co.changelog to get started with a $100 credit. Again, do.co.changelog. What's up? Welcome back, everyone. This is the Changelog, a podcast featuring the hackers, the leaders, and the innovators in the world of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. Today we're talking to Stephanie Murillo about her new book, The Developer's Guide to Content Creation. This is a book for developers who want to consistently and confidently generate new ideas and publish high-quality technical content. You may know Stephanie from her awesome work in leadership as a content strategist, where she served as editor-in-chief

of DigitalOcean and GitHub's company blogs, as well as her writing for Bundler, RubyGems, and RubyTogether. We talked with Stephanie about why developers should be writing and sharing their ideas, crafting a mission statement for your blog, and thoughts on personal brand,

her four-step recipe for creating content, as well as promotional and syndication strategies to consider for your developer blog. So Stephanie, thanks for joining us. We are here with you, somebody who seems to have done it all. You've done a lot. So you have a great background in this industry, and most recently you've done something that I think is for the first time,

is you've written a book, The Developer's Guide to Content Creation. So congrats on publishing, and thanks for coming on the show. Thank you for having me. I'm excited to be here. So if I were to look at people who are qualified to talk about content creation for developers, it seems like you are very well qualified, working with Bundler, RubyGems Projects, as well as Editor-in-Chief previously at DigitalOcean and GitHub's company blog. So you've been doing this for a while. I have been. I've been doing content for as long as I remember. And it was funny when I learned how to program many years ago, I did it under the premise that I was going to become a developer. But I realized that I hated coding. And I mean, it went beyond the whole, you know, this is a learning curve, you're going to hate it for a little while. I was like, No,

I actually don't like this. But what I do like is when I find a solution to a problem that I'm having, I like writing about it. I was in communications prior to moving into tech. And it was funny because I learned how to code. And most people would think the next step is you're going to be a developer. And I was like, no, I don't want to do that. I actually want to be doing what I'm doing, but in the tech industry. I love reading what people put out, what technologists put out. I love seeing how they promote their stuff. I really enjoy reading good documentation that doesn't make me feel frustrated with a product and enables me to get things done quickly. And I love it when people pay particular attention to how they write things, how they present things, because I think we tend to take writing for granted. We assume it's a skill that everyone has and a thing that everyone can do because on some level.

Sure. If you're literate, it's something you can do. It's something that you take for granted. But there's a difference between doing it and doing it well. So I really appreciate it when people do things well and I want to help more people do it really well. What do you think the secret sauce is to, in quotes, what you said, doing content? What's the secret sauce there? Well, frankly, there's no secret sauce. You can ask anyone from Stephen King all the way down to like, I don't know, your sister who's writing poems like in high school. It's writing more.

Writing is hard and you just have to write a lot. Show them practice. And you also have to read a lot. It's really just practice. The more you write, the better you get. The more you read, the better you write. Because when we read and we're not necessarily aware that we do this when we read, but when we read, we notice things that work really well or things that we like and we start to incorporate them into our own our own writing style. So you'll read something and you're like, wow, that's actually really good. I love how they did X. And then you start using that almost as a template for your own content. And then you start incorporating that into your own writing style. So the best way to get better at writing is by reading more and just keep writing even when you don't want to.

It's conditioning, really. It's the more you read, you're conditioning your mind to, I guess, you know, see each other's phrases and how you write something out or lead a story or narrate a story. It's similar to the way if you hang around somebody more often, you know, if they start a phrase a certain way or begin speaking a certain way, at some point you will both eventually mimic one another or vice versa. So it's almost like picking up good habits, I suppose. It's almost like you are who you hang around. Like if you hang around people who are, you know, doing terrible things or not doing very good in their careers, you might also do terrible things or not do very

well in your career. Whereas if you hang around somebody who is, I guess, more accomplished or has ambition, you might also mimic their ambition. Yeah, that's true. And there's also the fact that if you read about different perspectives on the same piece of content, so let's say you were learning Git and you feel comfortable enough to actually start using Git in your projects and you used, you know, one particular book to help you learn Git. If you read more and more content related to that topic, even though you've already mastered it, sometimes you'll find that the concepts stick better in your mind. So that was actually a lesson that I learned from my mentor, Steven Nunez, who taught me how to code. He told me that every time he would buy a book on Ruby, he would always

read from the first chapter, even though he was already by that point, a mid-level Rubyist. He said he always would read it from the beginning because sometimes people would explain things and then you would learn one new thing about that concept that you didn't know about before. So that's the opportunity also of reading things is that it shows you that there's no one right way of doing things, which I think is really important because sometimes we'll find our favorites and we'll say, this is what I want it to be. But frankly, there are other people who are doing it really well, who are explaining certain concepts or writing things using a completely different style. And as a result of being exposed to that particular style, you may now see or understand that particular topic in a brand new way. So I think that's also the benefit of

reading enough. I'm reading a lot is that you'll learn one new thing that you didn't know before, which says a lot, frankly, because, you know, technology is so big, there's no way you're going to know everything about any one single thing. It's a wonderful way, I think, of just exposing yourself to different perspectives on explaining the same concept. You certainly helped many authors get the first several chapters of their books read because, you know, at some point you do feel like you've, you know, you've grown beyond the, the sort of bootstrap or the training wheels, for lack of better terms. Like that's something that you use a lot whenever you're first riding a bike. There's a reason for that. So you don't fall down,

you know, but I never really considered, I guess, going back. It's back to the basics. You hear that a lot, right? Back to the basics. We even did a show about that, Back to the Basics of Agile was, you know, a very good show from 2019. So it would make sense to revisit what seems familiar or second nature, just because you might learn a different way and it just expands your experience level with it and your know-how of it. That's a really good point because when I was first scoping out what I wanted this book to cover, I was really trying to think what back to basics meant. And it was interesting because at first, I almost didn't write this book. I was like, there are a lot of blog posts about it, about various topics that I touch in the book. Or I thought that it was foundational almost,

that it was so one-on-one that no one would find value from it. I'm glad I didn't listen to that hunch. Me too. Yeah. I'm actually glad that I didn't listen to that because what made me realize that we needed to go back to basics was working with developer advocates, developer advocates at most companies are just content powerhouses. They're blogging all the time. They're writing articles all the time. They're contributing to documentation all the time. They're giving talks all the time. They're doing all of these things just at a level and a scale that most individual developers can only dream of. And it's because that is part and parcel of the role. But when I started working with developer advocates who were, I think, much more farther along in their content production process, I realized that a lot of them didn't actually have the foundational knowledge when it came to content creation. And that's okay, because they're not

content marketers. So there was no problem with that. It was more like, they would hit a bump in the road, and they would ask themselves, okay, what's next? Or how do I measure the impact of what I'm doing? Or how does this affect something else, a goal, a company goal, or, you know, those kinds of things. And that's actually when I realized, okay, then that's incumbent on us to kind of take a step back. And I can show you how you can put all of those, like systems, very foundational systems in place that'll help you get over that that particular obstacle. Why do you think that is for dev rails that this back to basics or this basic level of foundation you say isn't there? Is it because many of them kind of fell into this roles or evolved into this role very taxing because it requires a lot of, as you said, content output and also travel. So there's a unique kind of person who can do that job. Why do you think the foundation is lacking though? That's a great question. From my

observation of developer relations, developer advocacy is that it grew very organically. So I think a lot of people were doing DevRel type work or developer advocacy type work before that particular role actually coalesced into a function that we now see at companies. And depending on where the developer relations team sits also dictates what kind of resources they have on hand to help them build. How do you mean like where they sit? Do you mean like adjacent to a marketing department, do you mean? Yeah, for example, you mean like where they sit? Do you mean like adjacent to a marketing department? Do you mean? Yeah, for example, right?

Like, are they marketing? Are they their own team? Are they engineering? In my team's case, we sit under engineering and the setup was actually very unique because I was a content strategist that was embedded in the developer relations team. And I wasn't from marketing in that.

I was telling the developer advocate, you know, we need more traffic on this, or we need you to promote this, right? Like I wasn't dictating marketing strategy, I really was trying to help developer advocates maximize their content output and make sure that I could help them tie those into like broader team company goals. And I think the problem is that developer advocates have to produce so much and do all of that stuff. And I think the problem is that developer advocates have to produce so much and do all of that stuff. And I don't think that the many teams that work with developer advocates are necessarily aware of what the gaps are, or they haven't been able to articulate it yet. Our team was really unique in that they decided to have this very unique function embedded within a developer

advocate team. And it's not something that I've actually seen before. So I think as a result, our team was really able to take content, their content production to the next level because we were actively planning. We were actively talking about, you know, like tracking and dashboards and analytics and doing all of these things for the developer advocate team

and showing them the value of that. Whereas I don't know enough about how other developer relations teams work to understand whether or not other teams have that particular kind of functionality. But it was nice for the developer advocates to have a content person that wasn't really dictating what they needed to do. It was more like, okay, I'm going to show you best practices, but I'm also going to liaise between marketing and us and try to, you know, be the conduit, like be the bridge between both teams, because oftentimes you need that. You do. Frankly, there's not always like

an alignment or understanding between developer advocates and marketing. I think there might be some tension between both teams or not a real understanding of how both teams kind of roll up into company goals and then how they can help each other without it being kind of like a power struggle for who is more important than the other. Right. That those power dynamics are very, very interesting, frankly. But I've had the opportunity, thankfully, to be in a position where I was able to play nice with both and show both how we could work together without anyone stepping on each other's toes. That's important. Yeah. Let's zoom out for a minute. This area of conversation, content creation,

makes a ton of sense for developer advocates or developer relations teams. Your book is dubbed as for devs who want to consistently and confidently generate new ideas and publish high-quality technical content. But let's start out with the premise itself, because there's lots of devs out there listening who maybe aren't even interested in doing that. Is there a solid sales pitch of why that's valuable? Why should they care and what are the wins from creating content if you're not a dev rel?

Yeah, that's a great point. Well, frankly, a lot of developers themselves, not necessarily developer advocates, but the individual developer who is learning something, they are the ones that are driving the literature that is used to educate other technologies and other developers. We're the ones that are writing the content that other developers are using. So someone is learning how to, I don't know, how to use a specific framework.

They decide that they want to write about how they did something and share it on dev.to, for example. So individual developers are doing this already, even if they don't have any kind of corporate backing. They want to learn how to blog. They really love community platforms like dev.to. They've seen people screencast or they've read engineering blogs that they really like, and they want to try their hand at writing content that's going to add value to another individual developer somewhere else. So the fact is that I would say the majority of technologists, developers specifically, let me get more specific, developers specifically, the majority are content creators. They are already writing short blog posts, they're already recording screencasts and video. They are already contributing maybe to documentation for their own teams, if not open source documentation and other forms of writing. And they care about these things.

We know that developers really deeply care about good and really well-produced written content because that removes any blockers from their capability to do something. I always cite this particular stat, but GitHub conducted an open source survey in 2017. I would say one of the most salient points there was that 93% of respondents said that missing or outdated documentation is the single biggest problem in open source. Documentation, which tends to be for some people, unfortunately, an afterthought, more often than not, it's a written artifact and it shows you how to actually do something. open source documentation, which tends to be for some people, unfortunately, an afterthought. More often than not, it's a written artifact and it shows you how to actually do something. It tells you how to do something. Ninety three percent that said that it was a big problem. And developers are already filling the gaps for that.

Right. If they're seeing that the documentation is missing something, they're producing guides and tutorials that show people how to use that technology with something else. So I think it's a necessity because developers are already doing this in the community at large. And then secondly, I think from a, and I know people hate this particular word, so take it with a grain of salt, but from a personal branding or from a career development perspective, demonstrating that you can communicate clearly and concisely and that you can present an argument or write out points in a way that

enables someone to do something is very powerful. So I believe very strongly that being a good communicator is just as important as some of the more low level technical skills that are needed to do a role. Because you're going to have to communicate what you're doing to someone anyway, whether that's through written communication, whether that's when you have a meeting with stakeholders and you have to present to them and explain to them why you can't build this one feature in 24 hours. You have to be able to explain all of that. So I think that learning how to write better in particular, but that goes to speaking or any other form of content creation demonstrates, I would say, one's rigor as a developer. How often do you think about internal tooling? I'm talking about the back office apps, the tool the customer service team uses to access your databases,

the S3 uploader you built last year for the marketing team, that quick Firebase admin panel that lets you monitor key KPIs, and maybe even the tool that your data science team had together so they could provide custom ad spend insights. Literally every line of business relies upon internal tooling. But if I'm being honest, I don't know many engineers out there who enjoy building internal tools, let alone getting them excited about maintaining or even supporting them. And this is where Retool comes in. Companies like DoorDash, Brex, Plaid, and even Amazon, they use Retool to build internal tooling super fast. Retool gives you a point, click, drag and drop interface that makes it

super simple to build these types of interfaces in hours, not days. Retool connects to any database or API. For example, to pull data from Postgres, just write a SQL query and drag and drop a table onto the canvas. And if you want to search across those fields, add a search input bar and update your query, save it, share it. It's too easy. Learn more and try it free at retool.com slash changelog. Again, retool.com slash changelog. So you mentioned sort of this, you kind of half apologize, I suppose, for saying personal brand or career development. Why is that? Why do you think people, you know, devs in particular, have this angst against this idea of personal brands? I think that overall, there tends to be a tension with marketing among the developer set in particular. Marketing is met with a lot of suspicion. And I can't say that I necessarily blame developers

for that particular notion. We've all seen examples of bad marketing or marketing that is deceptive, similar to the concept of dark patterns in UX, right? We've seen these more or less neutral things be used in nefarious ways or see it done ineffectively and we find it more annoying than anything. That actually took me a while to get over because I realized that developers thought, you know, marketing isn't that great. But frankly, a lot of developers are doing marketing.

If you do word of mouth, guess what? That's marketing. If you're tweeting to show people about your new blog post or your new podcast, You're marketing. If you're sharing anything, that is a form of marketing. So marketing in and of itself is neither good nor bad. It's really just a way of us showing or sharing with people something that we really enjoy. Obviously, you know, organizations, every company has a marketing department because an organization wants the world to know what they're working on. They want people to buy or use their products. And that's also not a bad thing. That's why we build products. We want people to be able to use them.

So personal brand, I think, tends to have a rap because it's almost like the commodification of a person, which I can completely understand, right? You know, when we start looking at ourselves as products or as businesses, as opposed to people and individuals. But I'm using personal brand simply because I don't know that there's a, if there is a better term for it, I'm definitely open to using it. But I do think that for the most part, many of us understand what we mean when we say personal brand. And that's why I kind of use that term. But with the understanding that it's kind of charged. So let me add a little amen to that in terms of of I think you're hitting on some of the right strokes. And myself as a developer, I've definitely had a adverse reaction to certain

forms of marketing in my life. And I think it comes down, one facet at least comes down to authenticity, which is something that I value very much. And I think many developers do. And there's something about a personal brand that feels inauthentic because it's as if you're doing something for this public face versus something you would naturally do. And I think that might, like you said, there's this ickiness there. I mean, in the past we called it reputation. I mean, it really is about your reputation, right? And so whether you call it that or you call it career development. That's why I'm kind of confused why you feel so bad about it. Well, there's definitely a stigma around that.

Yeah. There is an icky factor there. So maybe my roots for the matter might clarify things or only make them more murky is Gary Vaynerchuk. So many years ago, I was highly influenced by him. And still, I mean, I still listen to him often, but I still take him with a grain of salt because he's got different energy than I do. I can't keep up with Gary. I will admit that. However, in a time whenever no one, to my understanding, was thinking about this idea of personal brand, he was sharing this message of it. And, you know, I guess I can see to some degree the inauthentic sides of like this public

facing, you know, shell, so to speak. But for me, it really helped me understand what am I optimizing for? What am I trying to do? Who do I want people to know me as in my professional life? And not that that was inauthentic or, you know, whatever, you know, it really helped me to clarify sort of like, who is Adam? What is his goals? What is he trying to do? Who's he trying to, you know, be known as? And that really helped me to figure out, okay, if that's who I want to be, or if that's who I am, that's my identity, then what am I going to optimize for? That's a really good point. Because one of the topics that I touch upon in the book is the concept of target audiences. When you write a blog, or when you have a screencast, you have a target audience, even if you have not properly defined

who that audience is. There's some type of person who has some type of experience that you expect will read your post or resonate with your content. And in that particular chapter, I discuss how to tease that out and to properly define your target audience. So when you're thinking about a personal brand, as you just explained, you're thinking, you know, who is Adam? And who is he trying to reach, you have an idea of what this ideal target audience is, and what they might be interested in, and how that relates to what you're working on so that you can, you know, like you said, optimize for that particular audience. Obviously, you're, you're optimizing for an audience that you care about, and you're doing something that matters to you. It's not like you're optimizing for people who say, I don't know, it's not like you're optimizing for,

I don't know, the oil industry. I'm pulling it out of thin air here. You're not, that's not your audience, right? You're not actually like, you know, creating stuff that might appeal to people in that particular industry. I'm guessing that your audience is developers, and those are the kinds of people that you care about. So what you're doing is optimizing for an audience that you care about because you're a part of that audience. So how do you niche down even further into that?

Or do you? So if I was a Joe developer and I was thinking, okay, I'm going to start my blog because I think that this is a valuable thing. I want to give back to the community. I also want to establish my reputation or my personal brand as somebody who knows what they're doing. All the reasons we've discussed,

like I'm going to write a technical blog. One of the things you talk about, like this mission statement idea which you have in the book as well as what we just started talking about is defining your target audience. I'm writing my blog for developers. Do I niche down even further and say this is for front-enders who live in Europe? How demographic is it? What are some examples

of target audiences you could write for? Yeah, that's actually a good point. Some people might want to actually target it down to an exact demographic. I think a notable example there would be a developer who is writing content not in English, right? Maybe they're writing in Spanish or in Brazilian Portuguese. So we know that they are interested in writing for developers in Brazil or Portugal. And that is why they're utilizing that particular language. But I do think getting a little bit more specific about what type of developer is really important. So just as a way of helping you focus your content, no matter what kind of blog or podcast you create,

you're not going to be everything to everyone. And what you want to be able to do is to help you focus your content to meet the needs of a particular audience. Now, there is the concept of a primary audience and a secondary and tertiary audience. So your primary audience could be front-end developers, but your secondary audience could be engineering managers, right? You want to get hired for a job at a cool company. So you want a potential engineering manager or a recruiter to

look at your blog. So they get an understanding of your thought process and how you break things down. Maybe they also want to read what kind of topics you're interested in and what you want to cover. And then, you know, a tertiary audience might be someone who's looking for front-end developers in Brazil for, you know, some random project. Maybe they need, maybe they really need a developer. They don't know where to start. They found your blog through Google.

They're like, wow, this person seems to be hitting all of the target keywords that we're interested in. We need somebody who understands React Native and we need this, that, and the third. And then they decide to reach out to you as a result of your blog post. That's happened to me. So my primary audience is software developers. And I mean that very broadly, people who don't know much about content, but are interested in writing. They love consuming content. So they love reading newsletters. They love reading blogs. They love reading really good documentation. Maybe they may or may not be super confident in their own writing skills, they might actually struggle with being able to write, but they want

to write better. That's a desire, a desire for them is learning how to be better content creators. A secondary audience for my book could be publishers, right? Somebody's like, we need somebody to write a book about content marketing for developers, and they come on my blog. They are not my primary audience, but they're nonetheless interested in that particular content. And then a tertiary audience could be people who are interested in hiring a technical writer to write the documentation for this open source project that they created. They have it upon my blog. And they're like, you know what, we're going to reach out to Stephanie because we like what she has to say. And she wrote this really awesome article about content strategy and open source. That's the kind of person we need, you see. So there are levels to this, but you have your primary audience

defined, but you also have the other ones in the back of your mind. As long as you have the first primary audience defined, you at least have a starting point, right? Because it gets really overwhelming. If you have no, if you're just like, I point, right? Because it gets really overwhelming. If you have no, if you're just like, I'm gonna write for developers. Well, guess what? There's a lot of things you can write about. But if you say, I want to write for fellow beginners who are new to React, or new to like certain JavaScript frameworks, that gets you targeted, you can always change it later down the line. But that functions as your North Star. So you know that at the end of the day, this is the kind of content someone can come to your blog and expect to see. What do you feel about this then? I often hear YouTubers say this and often even see bloggers

say this. They say, I'm creating the content that I wish was out there, the kind of content I would want to consume. So does it blur the lines with target audience or is it sort of defined it better because they can sort of empathize with their would-be readers, so to speak? So for them, they probably think, okay, I am my ideal reader or my ideal viewer, but what are the attributes? Like you still have to kind of fluff out what the attributes of your target reader are just again. So the reader becomes real in your mind. Because you're making assumptions when you create a blog post, or you create a video, you're making an assumption about what people understand or what they know before they come to your blog. So if you say I want to

find like, if I were to say that, and I'll just turn it to myself, because it's easier to use an example. If I were saying I'm writing the content that I wish existed out there, well, I know that I am a content person. I'm very, very odd in that I'm a content person who kind of came to the dev space through engineering. I did not come through like a traditional marketing path. I became interested in developer marketing through the developer track. And in all of my interactions with developers, I realized that there were misconceptions, common misconceptions about writing or creating content or even things that I learned as a result of working with engineers and helping them, I don't know, place their articles in different publications or writing their first ever blog post for the company blog.

So if I were writing for myself, that would be the kind of person that I would be writing for it. And it's important, again, just to you can say, okay, what is if I'm writing for myself, or somebody who's like me, what do I possess that this person should possess? Should they possess certain amount of years, you know, with certain skills? Are there certain like, are they interested in front end or back end? Do they like, like, what are they doing? What are they interested in? What are their problems? You have to define what their problems are. Because at the end of the day, even if you want to write the kind of content that you wish somebody else had written, you are not your audience. Your audience has certain problems that you are presenting the solutions for. So you have to define that you have to understand what problem am I solving for this

person? Because nobody is going to want to read a blog post, frankly, that sounds like you were just having like, you were just laughing the whole time at your own cleverness. Right? Like, like, nobody, nobody finds that fun. So that is the reason why it's kind of important to separate yourself from your ideal reader and your ideal user, so that you can better articulate what the assumptions are that you have about this particular audience and that you can better define what their problems are so that you can create content to solve that problem. Another aspect of this, in addition to audience, you talk about mission statements.

And I'm curious, you say you talk about crafting the mission statement that clearly defines your blog's goals. What's a mission statement look like? And how do you create one? A mission statement is the way the way I wrote it was, I kind of write like the reason why my blog exists. So I decided, you know, I want to write a blog for, you know, for developers to help them become better content creators. And my goal is to empower developers to become better content creators. So my goal, my goal is like, this is the reason why my blog exists, followed by what my goal is. came out of me working on DigitalOcean's blog, their company blog. I was their first content manager on the blog. The company blog was, it's really funny. It was kind of like a resource that existed kind of nebulously. DigitalOcean's really great with their tutorials and their documentation. I'm sure y'all have seen it. Their company blog was kind of used just like as a promotional channel

for the occasional feature release or like, we have a new data center here. So in that particular point in time, we were publishing something like one blog post every 30 to 60 days. And I'm talking late 2016 into the first quarter of 2017. So when I took it over, I was convinced that the company blog could really be used as a way of getting people interested in the company. Like, wow, DigitalOcean is doing really awesome things. This is the kind of company I would want to work for. And also as a place to kind of like pull the curtains back

and show people a little bit more about like how our engineering team works and how the products were actually designed and like what some of the design decisions were, right? Because a lot of company blogs tend to be, look at us, look at this thing we did. And those blog posts tend to perform really well. But then there are also people who are interested

in actually learning more about the inner workings of the company. So that's what I started at. I didn't start with a mission statement. I started with, I just need to get as much content as possible. So I was interviewing everybody under the sun, the VP of engineering. I was having conversations with multiple engineers.

I convinced the brand design team to write a blog post. I convinced HR to write a blog post on remote teams, but it got to a point where we were like, okay, that's great. Now we've increased the publishing cadence. We have more content. Now we're publishing twice a month. Now we're publishing once a week. Then it got to be, okay, but why are we doing this to begin with? What is the point? And the question there was, what do we do well? And what do we want the blog to achieve? That's separate but corollary to the other content channels.

Because every other content channel had a strategy. The documentation, product documentation had a strategy. The open source tutorials, that team had a content strategy. We needed a reason to exist. And that's why the mission statement is important because it keeps you from having to constantly pull at straws to figure out what works. It tells you, this is my North Star.

This is my goal and this is my aim. And everything that I'm trying to work on, everything that I'm working on is with that goal in mind. That way, when something, when you do hit a wall, you know, it's not actually pointing to that goal, to that North star. It's easier for you to disregard it and say, you know what? No, this isn't really something that I need to be working on because it's not actually helping me achieve my goal. Something I heard recently regarding, I suppose, mission statements, but it's more, what's

an easy way to describe it? The basics is the way you described the mission statement for you was the goal my blog is. And what I've heard as a reverse of that is people tack themselves into beliefs. So if instead I said, or I was in your shoes, Stephanie, I said, I believe that software developers have great ideas. And the one thing keeping them from that great idea is being able to communicate it. So if you said, I believe, rather than my goal is, how do you think that changes for you? I love that. I believe software developers need to have a better communication lens to communicate their

ideas. That might be one way to say it, but this aspect of I believe. I love that because I think it really centers the user and the reader in that particular statement. And you're kind of stating like, okay, this is something that, you know, I have anecdotal reason to believe, right? You're not stating it as a fact, so you're leaving it a little bit flexible. But I do love that it's, you know, I believe these this particular audience has a problem. And what's keeping them is, you know, bracket the thing that I can help them with. I actually like that a lot. I've never seen that before, but I think that would function very well as a mission statement. It also helps you to believe in yourself, right?

You can do something wholeheartedly every single day and show up if you believe in it. That's very true. That's very true. It's almost selling it back to yourself. Like it is the first litmus test. Does it pass the you test? Do you believe in it? And if so, then you can write it down and hopefully lead others to also believe in that. I like that a lot. I'm just over here trying not to make an r kelly space jam joke i believe i can fly i believe i can touch the sky you're showing your age everybody likes space jam come on one of the coolest websites in history billy eilish likes space she knows what that is that's right so there's a phenomenon with developers probably with lots of people but there's a phenomenon with developers, probably with lots of people, but there's a phenomenon wherein we want to write a blog or start a blog,

and we find ourselves doing everything tangentially related to doing that. Oh yeah, I know what you're going to say. The common thing is like, oh, I'm just working on my platform or my blog CMS, or I'm setting up my Jekyll, I'm designing my blog, and there's one post on the blog that's like, hey, I'm here. I relaunched. I've got a new system, right? Like I've switched from GitHub flavor markdown to my own markdown parser. And so we do everything, but, and I'm just curious

what your advice is with regards to mission statements and audience and all of this stuff, which is kind of like blockers to getting going. Do you advise people to just start writing and then figure these things out as they go? Or is it like, hey, we need to sit down and really consider these things before I'm going to put that first post out there? Because I fear many people will never get their first post out if they can't figure out who their target audience is, or they don't like their mission statement. I advise that they start off with figuring out their audience, their mission statement,

and with actual drafting of their content before they get into figuring out what the right solution is. I do, there is a section in the book that does touch upon different blogging solutions just to give people an idea, a sense of what's out there. My general advice is to choose the platform that makes the most sense for you in that it's not going to be too time intensive. Like for me, I started out with my blog, my blog was on Jekyll, and it was hosted on Dio. And in the beginning, it was great, but it actually grew to be extraordinarily cumbersome.

And I just I hated having to like, use get hooks to, and like, you know, like, SSH into servers in order to like, get like a typo fixed. I was like, this is not going to work for me. I'm never going to use this site. So I actually moved over to a hosted solution. I moved over to Wix. For me, it's great. It's all drag and drop. And as soon as I press publish, guess what? It's live immediately. There's, I don't have to wait, you know, for things to build, et cetera. But I think we get too excited with tinkering and with the tech before recognizing like what the actual point of the blog is. You basically just want to choose a blog solution that's going to be relatively easy for you to maintain, meaning it's not going to be too cumbersome.

It's not going to be, you know, if you don't want to find yourself having to update a lot of stuff, then you might want to consider something else. Don't go for the shiny technology first. Figure out what your content is, and then like have like a for real conversation with yourself to decide how much actual time you want to spend on blog maintenance mode, because it can actually take up a lot of time. Like once you have this shiny new thing set up, oh, wait, now I actually have to maintain it. And now I actually have to, you know, work on like blog operations in addition to being a content creator. So I recommend actually sitting down and thinking about your content first before you start thinking about the solutions.

Yeah, you're right, Jared. All too often that we get stuck behind like these tinkering scenarios rather than the writing. I feel like people often get stuck behind that, but then the next step to optimize for would be how can I get an idea down first? So what is my flow for capturing an idea? Even if it's just in a to-do list with a basic fragment of an idea, how do I then take that into draft mode that isn't a writing process that I enjoy, that I can find flow in, which is a key marine science aspect to kind of get into this aspect of flow because that's what a lot of good writing comes from is, you know, sort of shying away from everything else in the world and focusing completely on this idea, getting it out, synthesizing this idea from your brain into writing, you know, so going from this draft process, this writing process to a published

process, do you believe that, you know, kind of minimizing the friction there is what a key aspect could be for many people who get stuck. I have not heard that necessarily be the issue for people like the drafting to publishing, only because a lot of devs tend to be very particular about their preferred workflows. But it's really about figuring out how to come up with ideas, where to store those ideas, and then how to actually sit down and start working on the drafting. I find that the actual like with the publishing stuff, I find that that doesn't tend to be to as much of an issue as the actual front loading of everything. Like, how do I sit down and come up with a bunch of ideas? How do I come up with a preferred cadence? People get really, really excited in the beginning when they have a blog and they have all these

ideas and you will see blog posts after blog posts after blog posts i remember working with one developer advocate who they had a screencast going on and they decided like to publish like once like every three or four days it was like an aggressive cadence but it wasn't something that was sustainable in the long term so you'll see that they'll kind of like peter out after like a few months or a few weeks, because they just like went through everything that they had in the beginning, but they weren't constantly like seeding the ideas and they weren't constantly drafting something or thinking a little bit further down the line. It's really about looking at content as a process like any other other process. Think about the engineering process. Use that as a particular

metaphor if that really helps you. If you think about things in Sprint, I work on an agile team, so we use Sprint a lot. If you think about how you break down each aspect of the task that you're working on, the same thing goes for content. You have to come up with the idea, then you have to decide like, okay, what are the prerequisites? What are the what's the requisite knowledge that people need in order for them to start working on my post? What are the key takeaways for my readers, and then there's nothing magical about outlining. If you like to work on bullet points, you can if you want to use sticky notes, you can also do that. But the point is actually breaking down content. I don't know if this notes, you can also do that. But the point is actually breaking down content. I don't know if this is the same for y'all. But I've definitely

heard from developers that they just don't know what to write about. Because there's this misconception that writing is, I don't know, you just have like, you know, like a muse or something just like, makes everything you know, like, you're just going to be inspired and you're going to sit down and the first draft is going to be the most amazing thing. I promise you everybody's first draft is really not that great. And, you know, if we all sat around waiting for inspiration in order to write a blog post, we'd be waiting for a really, really long time. A lot of people don't realize that you can and should write without like this source of inspiration or motivation behind, you know,

to kind of drive you forward. They also don't realize that you don't have to come up with what you consider to be like the most awesome idea ever. There's a lot of knowledge that you have, a lot of foundational knowledge that people are actually interested in. And you can actually reuse a lot of the stuff you have. But you know, again, like because people don't have the vocabulary really to kind of start thinking about content as a production process. I think that is really what is inhibiting people from actually getting started. If you're building out a digital store or e-commerce site, what's the one thing you have to get right? Ding, ding, ding, ding. Yes, taking payments.

That's right. I've got good news for you, though. Square APIs and SDKs make taking payments, managing orders, catalogs, customers, inventories, or even employees painless. With Square, you can build commerce apps that go beyond payments. They support iOS, Android, Flutter, and React Native for in-app mobile payments or to integrate with Square readers from your own app. Square also has payment forms for embedding a checkout experience directly into your website. Check out tutorials and explainers on Square's YouTube channel for developers at youtube.com slash square dev. You can learn about key concepts like item potency, how to take digital wallets in an online shop, or how to store and charge a card on file.

Again, learn more and get started today at YouTube.com slash SquareDev. So content is king or queen, depending on how you look at it, as we've just been discussing. And it's also the hardest part, right? Like whether it's getting the idea or putting the pen to the paper or the keyboard to the text editor, whatever it happens to be, that's where most of us fail or struggle or strive at least, right? It's the 99% perspiration that sometimes produces a blog post. Otherwise, it produces like a really rich drafts folder that never sees the light of day.

So help us with content creation. What are good ideas? What's a great premise for a blog post or a piece of content? And how do you just keep churning those out or coming up with them? What are your advice on that? Yes. So I'll definitely give away the four ways of generating ideas that I outline in the book. The first one is write down a list of ideas of things that you already know very well. So things

that you're confident talking about. Two is write a list of ideas of things that you already have. So you mentioned a drafts folder. Everyone has a drafts folder of things that they have thought about publishing, maybe they started a blog post about something quite some time ago, and they kind of dropped it. There's also the fact that we have a lot of content that we've created in the past that we don't repurpose. So if you gave a conference talk on something that took you 40 or 50 hours to write to script and to create the slides. And you gave it at that one meetup or that one conference, guess what, you can repurpose that content and turn it into a blog

post, you can take your notes and decide, you know, if you want to pull high level takeaways, or you can actually just turn your script into a blog post. I've done that in the past, actually. And it's great. If you've already done it for one particular audience or medium, there's no reason why you can't do it for something else. So if you did a screencast on something that was really interesting, maybe you want to write, you know, some of the top five things that were discussed or the top five tips to entice people to actually look at the screencast that makes for a good blog post. Something that you did on the job in the past or an open source project that you were working on. Talk about the process of how you actually built the thing or worked on the thing. So things you know, things you have. The third way of generating an idea is trying to figure out what people need.

So chances are we check out Stack Overflow or even Twitter. If you're there and you're engaging with developers in a particular forum and people say, hey, I have issues or problems or trouble with one particular thing, chances are there's probably not enough content to kind of explain how that particular thing works. So you can write the blog post or the screencast or what have you that presents the solution to that particular problem. So pay attention to the things that people need. And then the fourth way of generating ideas is to write down a list of things that you actually want to learn about. I find that there's a lot of value about writing about your learning process. So when I started blogging, I started blogging back in 2012. When I started learning how to

program, my mentor told me suggested, you should keep a blog just for yourself, where after every lesson, you kind of rehash what we discussed, you share some of your personal thoughts about it. And, you know, you kind of like you're reteaching yourself the concept, you're explaining it to yourself so that you can understand just so you can gauge your your level of understanding or where their gaps are. And it's actually really valuable for a lot of people to use writing in that particular fashion. So if you learned how to build a blog, you know, with Gatsby or whatever, hey, why don't you write about it just as a way of showing people your your learning process and your thinking process. So there's a lot of value of writing about the things that you really like,. I like the learning aspect though, because there's something that happens whenever you learn that you're almost childlike in your ability to,

in a good way, of course, in your ability to sort of like be giddy about it, to be, you know, you have this excitement. Generally, whenever you're new at learning and you've just learned something, there's an accomplishment there to share. And what often happens too is that for the person coming down the road behind you, behind that learning process, is somebody who can identify with how you discover the problem, how you begin to learn this new thing.

And in some way, whether it's literally getting to know Stephanie or literally getting to know Adam or Jared, they sort of become – they sort of know you through your writing and they almost can, you're part of their tribe. It's a big piece of being accepted is having a tribe. And it's almost like, you know, an on-ramp to community. I like that because I think to add on to that, there is an assumption that because you are writing, you are, you have to come from an authoritative position. You have to be an expert in the thing that you're writing about. And writing about something that you're actively learning about is a wonderful way of humanizing the person behind the words. We don't have to be experts for something that we create to be valid and for it to be beneficial to someone.

I even think, for example, if you're writing about using like an open source technology and you're describing your process, I think that would actually be value for a maintainer to see. Right. We always talk about that. We want beginners to kind of poke holes at our stuff to help us see what some of the usability issues are with, you know, with a particular aspect of like, you know, using your particular, you know, technology or whatever it is, then that's, I think, really good information for a maintainer. And I think it's also nice to read about people's frustration. So I actually have a blog post on my blog way back from 2013. And the hero image, so the main image is of like a two year old girl crying. And the what I roll, I think it's like, let's try this again. And I basically talked about how I was learning Rails and I was working on like an old PC that my mentor gave me.

He installed Ubuntu on it and I lost everything. Like the whole thing malfunctioned. I was really having a hard time understanding MVC. So I met up with him at a Starbucks in Midtown and I was crying. I was like, I don't know if I can do this. I feel really stupid. He was like, don't worry. He kind of like sketched out what MVC is on a piece of paper and then helped me troubleshoot the machine. And then by the end of the post, I'm like, okay, well, I'm a little bit calm now. So let me,

you know, get my app started again. And you know, well, we'll get back into it. And those things are valuable, because it's important for people to feel like they're not the only ones. Technology, unfortunately, has the effect of making us feel like we're the dumb ones, right? As opposed to we're dealing with something that, you know, is hard and something that is imperfect. It's not us that's broken, really, you know, it's just that we've come up with imperfect solutions to problems that are really, really complex. And as a result, they're kind of difficult to grasp. And that's not just, that's not on any one person. So I love those kinds of blog posts. I think they're great.

Shows the humanity, right? Yeah, 100%. One of the core reasons we are involved is we're humans, for one. And we're trying to care for or help other humans solve problems. And I think we get lost in this idea that it's just tech or it's just software, it's just this startup or just this mission that we forget the humans, the humanity behind things. We have to sort of be – it's like a back to the basics of humanity. There's also a blind spot that comes with expertise, which makes it really difficult to write well beginner content as an expert.

Because you have this gap where you had, maybe you're not the expert who created the thing, but maybe you're a person who started as a beginner and then strove for a certain amount of months or years and now are expert. Maybe you're like an expert Ruby on Rails developer. It's very difficult for that person to write in such a way

that considers the beginner's mindset enough to lead them to success, not because of a failure of the person who's writing, but because they're so far removed from being a beginner that there's so many things they don't realize they just know inherently or through experience that a beginner does not have. And so I really like the learn aspect of writing because you're really well positioned to teach somebody who follows after you because you were just where they are.

You weren't there five years ago. You were there while you were writing that blog post, right? Stephanie, something else you mentioned too was this aspect. And I think you didn't say it it but I'm going to put some words in your mouth and you can agree if you think it makes sense but this hub and spoke model Can't you disagree? It sounds like if you have this hub as an idea

and the spoke being the medium that you publish to say it's Twitter or a blog post or a talk, being able to have this big idea and synthesize it into different mediums. Can you kind of revisit the, I guess, to me, it seems like people don't often think about that. And maybe an easy analogy may be you have this big idea for, let's say, a podcast episode

that makes a lot of sense. But then from that is an easy blog post that sort of takes the bigger overarching idea and then taking a similar aspect and saying, OK, how do I take that same idea and condense it down to a single Instagram image or a story so that I can now be on these different social platforms that have their audience and audiences, you know, their own, you know, different social structures to them that bring awareness to your ideas. I love that. I agree with that completely. When you think about the amount of time and effort that is required to create a piece of content, and I like to use conference talks only because I think they tend to be, for me anyway, rather labor intensive. It takes me quite some time to come up with the idea, write the script, and then you have to have the slides., and, you know, then you spend time practicing and, and, and, you know, giving mock talks to,

to your significant other, which is what I tend to do when I try to practice. You have dedicated all of this time to that one thing, but everyone is not gonna necessarily go to that, to that conference recording if it's available. This is a pet peeve of mine with with conference talks. When people are asking for your conference slides, they're not asking for the one or two or three or 40 slides with memes and emojis on them. What they're actually asking for is the information and the content that you could convey more often verbally than the stuff that's actually in those slides. Big idea. Yeah, you have all of this information that can be used in a medium that will make it more accessible and broader to people. Not everyone reads blog posts,

which is why short tweets, like 30 seconds of video, short podcasts, long podcasts, et cetera. That's why the different mediums cater to different people. But I think when you repurpose your content for different mediums, you're broadening your reach. You're saying, maybe I know that you don't. For example, I'll use y'all as an example. You recognize that everyone won't necessarily sit down for an 80-minute podcast. But you transcribed it and you're making it available on that page to allow someone to read

along should they wish. Because for some people that might be less demands on their time, right, maybe to read than it is for a podcast. But then again, you're making it available in audio because there's some people who on their commutes to work really enjoy listening to these kinds of podcasts. So you're, you're maximizing your reach. And you're also making it accessible for folks who might not readily be able to consume the content as audio. And that, I think, is the important part is if you worked on something that you're really, really proud of, understand that there might be other ways of getting the message out there. Like, for example, me promoting my book. I shared images and I added alt text to all of my images of the table of contents. I created an excerpt of the intro and I shot that out to my newsletter list. And then I linked out

to that from Twitter because, you know, my content is behind a paywall, which is a price, right? You have to pay for my book. But if you want to get a sense of the information that's in my book, here is some of the content. Here's what you can expect to learn. I think when we start to think about that way and about broadening our reach, it actually gives our content a longer lifespan. It makes it a little bit less ephemeral and it brings new people to your content, right? So like if you wrote a blog post that was like quick show notes for a changelog episode, some people might not be sure if they want to tune into changelog, but because they see some of the pull quotes that you pulled out and some of the really interesting points and you include those in your show notes. Now someone says, you know what, as a result of that, I think I'm going to click and press play and tune into this. So I think that's the thing.

You've got to incentivize people in different ways to tune in. This is something we've been thinking about quite heavily, which is obviously why it's near and dear to our hearts and fresh. These, this aspect of this on-ramp, how do we, you know, cause not everybody, as you said,

is going to want to give the commitment in time to, you know, a 60 minute and 80 minute or even a half hour podcast if there's no incentive for them to do so. So we had actually, you know, quite, quite heavily thought about,

you know, what are some easy on-ramps that just make sense. Jared's been doing a great job of pulling out different 90-second clips onto Twitter that sort of encapsulate an idea. We've done some things around blogging that sort of take the bigger idea of a segment and pull from, as you said, our transcripts and turn that into a blog post that, you know, you may discover that as a reader. And I'll say, how often have I found a great talk because they blogged about their talk? You know, so it's the same idea. How do you not just simply stick to this one single hub that you sort of establish some spokes that says, here's my big idea, but here's some easy ways to sort of discover some nuances about it that you might like and then decide to invest more time. Yeah, there's always listing out the takeaways, like some of the key takeaways, right, is really important.

And I know y'all don't do this. You don't just drop a podcast on Twitter and say, hey, y'all, Stephanie, who is somebody you may not know, joined our, you know, like was our guest this week on our podcast. Nobody's going to want to tune into that because they don't know who I am. They don't know what we talked about. They see that it's 80 minutes. They're like, okay, that's, that's nice. You know, I'm going to keep scrolling. But in this particular case, maybe Jared posts, I don't know, some bloopers on Instagram with some funny audio. He does the same on Twitter. So that people are like, whoa, that's actually really cool. Or like, check out these tips that Stephanie gave the changelog crew, AKA the founders of a media empire, which will then tell people, like, whoa, that's actually really cool. Or like, check out these tips that Stephanie gave the changelog crew, aka the founders

of a media empire, which will then tell people, okay, well, you know, if she can do this for them, maybe she could do something for me, right? Like you tease the interesting things out, the interesting quotes, the 90 second clips to give people a little bit of color. 90 seconds is great because you can listen to that at work even, right? During your lunch break and say, okay, well, I'm going to bookmark this so I can listen to it later. But you have to be, I think what's important is that developers are clear about what the takeaways are for the reader. Why should the reader or the listener actually care about this?

We know that you as the creator care about it, but why should I care about this podcast? What is it going to do for me? And once you answer the what is it going to do for me, you put that out there. When I went to promote my book, I put like, you're going to get 100 and something pages of content, there are going to be 17 guided exercises, there are 14 worksheets that will show you how to create a content calendar, this, that, and the third, it's downloadable. Again, I put the table of contents. And I used a lot of funny images. Like I did bad Photoshop jobs of the cover of my book on like Billie Eilish's like Grammys. You know, I did some on like Rihanna and Cardi B reading a book and I had like, you know, my cover

Photoshopped on it because the humor gets people interested. You see, there's yeah, you know, you do stuff like that and it doesn't always have to be super serious. But if you do things with a way that adds your personality to it, it'll at least make people intrigued. Well, Seth Godin wrote a book called Purple Cow, I believe is the name of it, Purple Cow. And you want to stand out for once. That's what you're doing. You want to stand out. You want to sort of be in pop culture and use something like that to catch people's attention, but then throw a book that's not at all relevant to their music or their careers into the mix. That makes sense.

Something else you'd mentioned, there's this idea of sell the sizzle, not the steak. So you may want to eat the steak, but the thing that you're trying to sell is the way it smells, the way it sizzles, the way it, you know what I mean? The atmosphere. The steak is the steak. Sell the sizzle. Another correlating idea that's sort of out there is the why. Sell the why versus just simply, you know, that's a lot of what Apple does in their marketing is they sell the why you want it, not the thing that they're selling you. Yes. Yes. 110%. And I think if more folks started

asking themselves those questions, it would lead to more interesting answers, I think. So Stephanie, I'm stuck back on your bloopers idea because that presupposes that we make mistakes. And as you know, we never mess around. Oh, never. Absolutely. I'm sorry. Yeah. Redacted when I say bloopers.

So this is interesting because through this hub and spoke spoke if that's what the thing we're talking about here but really like i think repurposing of content like i take a conference talk turn it into a blog post turn it into this take a podcast you know produce these different assets you're kind of blending the two concepts of content because you're really kind of creating derivative but still unique and different content with promotion right it's it's going where the people are and repurposing the content for these different platforms which i think is very cool are there any other low-hanging fruit when it comes to promotion like you let's just take the stereotypical developer blog post you know it's uh 10 reasons why i think react is the next big thing and it was written five years ago or whatever like let's say i have

that in my back pocket, I just hit publish. Is there low-hanging fruit for promotion? Most developers send a tweet out and then that's it. They hope that it catches fire and if it doesn't, they're pretty much done. What's the quote-unquote best practices or what would you suggest? What do you do with your own content in terms of promotion? That's a good question. Social media is one thing, but I also like to think about like getting organic traction. So search engine optimization, the assumption is that a lot of people are really going to come to your posts through Twitter. And there are actually a lot of different channels that people use to happen on your content. So thinking, for example, about your titles, blog post titles, like if it's something on React, like these kinds of titles really, really great me.

But when it'll be like, you know, React Native with something. OK, that's great. What does this mean? Right. What am I going to learn? What am I going to do? People are not very descriptive when it comes to their titles. People want to know exactly what they're going to be reading and what exactly they're going to get out of it. Right. Attention spans are very, very low these days. People have a lot of demands on their time.

They usually will look at your title to glean whether or not it's something that they even want to open to read. Yeah. Believe it or not. So you might look on Twitter and see that a bunch of people retweeted your post. But then if you go into your blog analytics, if you open up Google Analytics, you'll find that like five people read it, even though you got like 20 retweets, right? And then all those five people came through Twitter.

You didn't get any traction from Google at all, which means that when some developer went into their search engine, as we know they always do, and typed in, how do I do XYZ with React Native, your blog post didn't come up. You have to think about how people search on the internet. Think about your own queries, right? Generally, like, I'll do something like that. I'll say, you know, how do I do this with that?

And sometimes you'll get like a stack overflow question being the top hit on that page. And then you won't find like the actual content related to that on the first page, it might be on the second or third or fourth page, and no one goes to the on the first page. It might be on the second or third or fourth page and no one goes to the second, third or fourth page on Google for the most part. Unless they're really hunting. You have to really, really like want to spend your time on Google in order to find that information. A lot of people really don't. So I think being intentional, you have to be specific with your titles and you have to tell people exactly what they expect to get in order for them to actually click and read your thing.

What do you think about this idea then? So if you're in this position, then you can say, well, where are people searching for the answer if they have this problem? So developers in a lot of cases hate to admit it, but Google is their friend, sometimes their best friend. And often Stack Overflow is the second best friend because Google leads them to Stack Overflow. Or they just go right to Stack Overflow's search engine and there you go. But the point is, is so often do we get this aspect of I became a good developer because I Googled my problems and found Stack Overflow posts and solved them, which is great. So the question might be, if i'm writing about this problem where would people be searching to find this google might be the best first first answer but the second might

be you know particular slack communities or documentation websites or issues or somebody's newsletter or something like what do you know about that what kind of advice do you have on that front so one of the pieces of advice that i shared in the book is if you came upon your idea while searching through particular issues people had with a particular thing and you decided to write the solution or share the solution to the thing, then go back to the community where you found that problem on Stack Overflow, but you decided to write it like in a cohesive blog post form, like you wanted to recreate what the issue was and then go all the way to documenting the solution, which we sometimes don't see in Stack Overflow, right? Like somebody will say, I tried to do one thing and then they'll paste a bunch of stuff. And then someone else is trying to figure out like how to recreate that problem so they can try to troubleshoot it. You might want to tell folks, oh, by the way, like I wrote a blog post about this particular thing and you can write that there.

You can also share that on Twitter. If somebody came to you and said, hey, I had an issue with this one thing, you might want to let them know, hey, thank you so much. Like I saw that you had this issue and I wrote the solution. If you're interested, I wrote a short blog post about it. Here you go. I'm definitely, you know, trying to get the attention of newsletters for whatever particular community that you are trying to reach with your content. I think that's always really helpful. As y'all know, I'm a big changelog fan. So I try to share my stuff on changelog only because I think that your audience is definitely the audience that I like to reach and I feel would benefit from this content. But if you got your idea from somewhere,

you can always go back and say, hey, I wrote this thing that hopefully solves your question or your problem or whatever. Using community forums, I think is huge. Sharing it on Reddit, sharing it on Slack. Hey y'all, like I came across this particular issue and I decided to write, you know,

a blog post about it. Here you go, you're welcome to share. There are many different places that we can share. It doesn't just have to be Twitter and you don't have to have thousands of followers for people to find it either. Yeah. To your point, Jared, all too often, do we just simply, and I say we is the proverbial we, we put a piece of content out there, we put one tweet out there and we walk away from the table and we're like, oh, well that sucks because nobody consumed it or read it or shared it or whatever and it's like we just tried once you swung at one pitch that was it you know and you probably didn't even choose

the right time right time right like what time is your audience actually awake what is the right time yeah like if you tend to tweet like during a specific time frame you know where people busy at work like did you try to like tweet at like 3 p.m eastern standard time and then nobody actually interacted with it. And then that's it. And then you don't actually try to send another tweet maybe after hours, when more and more people are going to engage with their content, the whole idea of scheduling multiple posts to promote the thing that you're trying to share, I think is still something that a lot of people aren't really aware that they can do, or aren't really sure how to do that. But definitely, if you spent your time creating something, definitely come up with a promotional plan that will allow you to promote that thing more than once so that you can maximize

the amount of eyeballs you get on that content. Because you might have tweeted something 8 a.m. on a Sunday and surprise, surprise, nobody read it. But if you waited until noon on Sunday, you may have gotten more people to look at it. All too often we think from our own perspective, which makes sense as a human, right? I can only understand the world as I perceive it from my perspective. So what I mean by that is we often think in our own time zones, meaning that, you know, while we may have a European audience or, you know, an Asian audience or whatever, like we've got a global audience or, you know, an Asian audience or whatever, like we've got a global

audience speaking from ourselves. And so we often only really tweet or I would say promote content from our time zones perspective. 100%. Would you agree with that, Jared? I mean, we do some after hours, but generally we don't do a ton of it. We are scheduled 24-7. We just don't have 24-7 content. So it slots in slots in right it slots into when we create it and then it never makes it through the evening because we run out of steam by nature we create during our time zone and it gets promoted within a few hours of our time zones time yeah so right we may be overlapping a little bit but generally we're not tweeting at two in the morning you know central standard time or eastern standard time unless like you were up until 2 in the morning and you wrote the thing and you want to promote it immediately.

And you're like, let me just get this out there. And then that tweet goes out at 2 a.m. and, you know, two people looked at it. Yeah, yeah. Patience is hard, by the way, when it comes to promoting content. Sometimes you create the thing and you just really want to push it out. Yeah. It's also a patience thing. I suffer from it all the time.

I would also say that promotional success is not an indicator of quality always. There are so many factors. We're always surprised at what we do that takes off and what we do that falls flat just in the Twitter sphere and the hacker news and even on ChangeHawk News. We put it on ChangeHawk News

and people didn't like it as much as we thought they would. It's easy to take that personal and say, man, I really failed at this piece of content or nobody cares about this thing. That's not always the case. In fact, we had Ron Evans on the show over the summer at OzCon and he had this great, I don't want to call it a rant. He had this great section all about Grace Hopper and what she really meant when she

said ask for forgiveness not for permission and he just I had never heard this he said it really well and I thought let's turn this little section into a blog post and I went ahead and created that for my email drawn I was like hey I just use our transcript took the excerpt turn it into a blog post I thought everybody's want to hear this this is this is awesome and so I created that post I thought it looked's going to hear this. This is awesome. And so I created that post. I thought it looked really nice. It was all polished up. Ron said, yeah, publish it with my name on it.

Cool, go ahead. We put it out there, and it was like, bleep, bloop, bleep, like nothing, like crickets. And then I think it was three or four months later, I saw a sudden spike in traffic to our website, and turned and looked and it was number one on Hacker News because somebody found it and posted it months later and it got all this conversation, it got posted to Reddit and all of a sudden I was like, okay, it was just a matter of coincidence. Timing. Timing, it just didn't work out.

It didn't mean the piece wasn't good, it just wasn't good at that time. That's a key thing to say, revisit old ideas. Because sometimes that idea will resurface a year later and have a different meaning or a different audience or a larger audience or a more captive audience. And that's a, yeah. 100%. So sometimes we, obviously through Change All News,

as you mentioned, you're a fan of that, Stephanie, we promote a lot of people's content. And what shies us away, and Jared, feel free to share your opinions as well, because I'm sure you have plenty as I do. We often find people who have great content, but just terrible blogs, either not great, not really, not so much from a design perspective, but just hard to consume. Pop-ups, banners, weird things, ads, like I'm fine with ads, but just somehow it doesn't seem very tasteful that you sometimes question their motive for publishing and sharing the content how do you

help people that if you're promoting this idea how do you help people come from a place of desire to help in this i don't want to say bad website perspective but just easily able to consume the content without getting hit with a banner ad or some sort of pop-up or some weird thing that sort of stops you or interrupts your process to consume it and become their fan. Do you encounter this a lot? What do you have to say about people like that? I think it's important for those folks to question their motivations for adding those particular steps to what I would say the user journey is. My perspective very much like I know some people, they monetize their blogs, or they're trying to build an email list and all of that. I like to

give people the content first, and then let them decide whether or not they want to subscribe to a list. I find that what that ends up doing is that it ends up frustrating users, you have to look at it from the user experience. Like we know that, you know, as the point of view of a content creator, you might want to build an email list, you might want to do you know, have a banner ad and all of that, which is great and good. But I do think that making it simplifying the process from someone clicking on your blog to actually reading it, I find that that's actually more important than building your list. And it goes back to what we discussed earlier about authenticity. If you're showing people, here are the cards, right?

Like I'm showing you everything. I'm laying it out on the table. This is my content. It's free. And I want you to read it. Then make it easier for them to read it. Now, if you want to take them to sign up for your newsletter or whatever, maybe you can have a little link at the bottom of your blog post that's not obtrusive.

And it says, sign up for my newsletter if you want more content. People might be more inclined to do that if they really like what you have to say and they want to follow what it is that you have to do. I say it's really easy to get into, frankly, some of those like web marketing gimmicks because we've seen other people do it. But what we fail to recognize is whether or not that's actually harming our reputation and the perception of how good our content is because we're adding all of these layers that really don't need to be there that you can actually add in a less obtrusive way and in a way that promotes more authenticity, in my opinion. Yeah, I almost liken it to I like to cook every once in a while. If my wife is listening to this, she's probably like, he doesn't like to cook.

He's lying to you. I do like to cook. I just don't do it as often as I want to. The point is I'm making is that I often will search for a recipe, find a great recipe website. But those sites are often just littered with just slow pages because they're just so JavaScript heavy on the ad front or tracker front. And they see – they're great. They do want to share that information. And I understand that that's slightly different. I almost liken it to a developer finding their solutions. And in some ways the recipe is the how to the, you know,

the explainer, the tutorial, you know, and it's, and we don't see a one-to-one where if I go to a recipe website, just say a individual blogger, an indie blogger blogging about recipes of whatever that website versus a developer's website of a similar recipe in terms of a program will be different. It's just crazy how it's that way. You know, like there's just so many ads out there. It is just like the web we have today. I almost don't like it in some cases. Yeah. People I think are thinking too much about monetizing their sites at the expense of the user experience. I know you've known, you've seen this with recipe sites. Sometimes you'll get on a recipe site and all you want is the recipe. They're going to give you the

backstory and then huge images. And you got to scroll for years until you actually get to the content that you came there for. The basics, ingredients, instructions. Yes. And if we add all those extra layers, all we're doing is creating frustration and people are not sticking around. They're just grabbing what they need and going. And that's fine. Not investors, I suppose. Yes. Investors by investing their time. And they're users. You have to optimize for the user and not just like trying to put somebody through a funnel or like, you know, try to get your pennies or whatever from showing them all these ads, which by the way, will lead people to leave your site and then go back to Google and look for another page with the same recipe

that has less steps to get to the thing. I will say on a personal note, if I hit your web page and you pop up a newsletter signup overlay over the content that I'm trying to read, it's an Insta close for me. I'm out. I'm not even going to stick around and try to find the X. There's too many other websites. I'll go read somebody else's. And especially on Change Dog News, Adam, you asked me to give my opinion.

It's a showstopper for me. So we love featuring people's content. I go read it and see if this is good and like shine a light. And if I'm reading your post that you submitted to Change Dog News, by the way, listeners, jl.com slash submit, we'd love to have you submit your stuff. And it throws a newsletter pop over, I'm just out. You're not going to get it because you're not respecting the reader. Like it's right for a reader. We have a newsletter sign up. We want people to sign up for our newsletter and we promote it in a way that is

tasteful and does not interfere with the main purpose of what the website is which is to serve the reader so there's lots of things I think that's the main one developers do especially indie devs tend to be less spammy than recipe sites we don't always have the best taste

there's lots of great free themes out there so that's gotten a lot better. Like the overall just readability of a website, I think a lot of developers fall back on. You know, GitHub publishes a lot of themes or like default themes you can use, which has really helped. But man, the newsletter overlay thing

is just out there in droves. And it's really disruptive to the reading experience. Well, Stephanie, you have a user experience background, so you could probably appreciate this aspect of us. But what Jared was basically saying is that when we think about linking to somebody's stuff through our news feed slash newsletter, we also not just think like, is that good content? But would our audience appreciate going to this website? Will they have the same interruptions or bombardments that we just experienced? Would we want to put our

listeners or readers through that? If the answer is no. We've all but banned Medium posts. A Medium post has to be really stinking good for us to put on Change Dog News because the reading experience on Medium, not because of the authors, but because of the platform,

has just tanked. It's completely tanked. Part of an interruption. We almost banned it all together, but every once in a while someone wrote the thing you're like this is so good i got a link to it but i don't want to i'll email them and say can you please write this on your own website i'd love to link to it that's good and they should have it on their own website anyway just because exactly you don't want all your good stuff owned on a you know by somebody else's platform you You want your own platform. So that is generally good advice anyway.

Yeah. Is that advice in your book then, this, I guess, perspective on, you know, having your own website and then syndication? Do you talk about syndication whatsoever in there? I don't talk about syndication in particular because I felt that that might get too overwhelming. I didn't want it to, like, I had to think about scope because I know that Medium and Dev.to

are two particular platforms that a lot of people like to publish on. And I took the diplomatic route in that if you want to publish on those platforms, that's great, but make sure you still have a destination that is yours, where you own all of the content. Because a platform can decide to do whatever they want and add all of these paywalls and overlays, as you described with medium, or they may decide to shut down one day. And guess what, that's all your content. And at the end of the day, what you want to do is you want to drive people to a singular destination that is all you that you know, where they can find all of your stuff. So definitely syndication is one of those things that I am very, very big on My personal preference, take it with a grain of salt listeners,

but my personal preference is that you own your blog and that Medium and other places are not your primary places to blog, that you have a blog that you own and that you choose to syndicate some posts on some of these other platforms in order to reach new audiences and maybe maximize visibility or bring people back to your site.

I definitely have opinions about the whole Medium thing, and it's really unfortunate, but I'm glad that you're looking at it that way. Because as you can tell, you care about the user experience. And as a result, people continue to come back to your site, and they continue to listen to your podcast, and they continue to subscribe to your newsletter, because you showed people that, hey, you can be an open platform that really cares about the user experience and drive people to pages that kind of also align with your mission and your values and people get good value out of that. That's really important. I will plus one your idea of having your own blog. I fully agree with that.

We both fully agree. Jared and I both do. Absolutely. Own your own content. Own your own domain. And then syndicate out. Absolutely. Own your own content, own your own domain, and then syndicate out. If you bring your content to us, we would rather you have your own space and share that with us as it makes sense

for all the reasons Stephanie just mentioned, but we always would desire for you to have your own site to link back to me. And that's the best way also to have a personal brand and to have a career path. Your own website, your own domain is sort of the linchpin of that. But Stephanie, thanks for writing this book and thanks for not giving in to your hunch of not writing this.

Thank you. It may have been a little tiny bit of imposter syndrome or something like that there with the fact that you didn't want to write it or you weren't sure because the idea might have been out there. But thank you so much for persevering resilience and perseverance is one key aspect of people that we don't often get to see enough of and i'm glad that you overcame that and wrote this book so thank you for sharing with us and thank you for your time thank you very much for having me it's been great all right thank you for tuning into the change vlog if you're not subscribed yet to our weekly email you are missing out on what's moving and shaking in the world of software and why it's important.

And, of course, it's 100% free. Fight your FOMO at changelog.com slash weekly. When we need music, we summon the Beat Freak Breakmaster Cylinder. Our sponsors are awesome. Support them. They support us. We got Fastly on bandwidth, Linode on hosting, and Rollbar on error tracking. Thanks again for tuning in. We'll see you next week. Thank you. I'm really curious, having been a first-time publisher, any lessons learned? Like for self-publishing a book, self-selling a book, what's some lessons learned you've had from self-publishing, self-selling?

Oh my goodness. Don't do it. No, I actually, I recommend doing it. Do it? Yeah, I recommend doing it. I actually pitched this idea to a publisher and before you can pitch the idea to this publisher, it's a publisher that I admire

and they make you fill out like a four page proposal with everything from like, who's the market? Like, who's the audience? Like, give us your 30 second pitch. What marketing channels can you leverage to promote this content? And I filled out the entire thing. I emailed it to them. They got back to me a few weeks later. They were like, we absolutely love this. I got on a call with them. They were like, we don't know how to promote this to our audience. But it was actually nice getting that validation from them. Because I thought to myself, it's okay if you don't think it works for your audience, but I know there's an audience for it. And what I did to validate

the book idea was that I announced that I was writing the book, even though I had like, maybe like 3000 words. And the amount of retweets and likes that I got actually validated my idea because people were telling me, I've needed something like this. I've never had anything like this. Like, where can I buy this book? Where can I buy this book? So I promote like I started saying that I was going to write the book before I actually wrote the book. And then I gave myself a date six weeks in the future, just so I could, you know, try to get it out really quickly. And it worked out. If you're going to self publish, I suggest the pre orders the pre I used pre orders on gum road as another way of gauging interest in the book. So it's like 10 people pre-ordered over six weeks.

I mean, I would have written the book anyway, but it would have told me, oh, maybe there is such a small audience that would like this book. If you get triple that in pre-orders, that tells you, wait, there's more people who are really, really interested in this. So if you're going to self-publish a book,

you validate the idea. It could be with friends. It could be with the. It could be with the external audience. Ask people if they would buy this book. You tell them what this book is and what they're going to learn and what they're going to get out of it. And then once you do that, set a date for yourself. It's really easy to say, I'm writing a book. And then you don't have a date in mind. So you kind of push it off. Listen, I had to do everything in my power because I was like, January 28th, that was six weeks in advance. I was like, okay, that means I have to finish writing the book. I wrote the

book in 11 days. I had to have somebody read the book. I had to hire people to edit the book. And then I spent myself three weeks design on design and getting the book, you know, nice and pretty for the PDF. So set a date for yourself because that forces you to work backwards and actually set a schedule and start working on things. Like I had week this, I'm going to do that. Week of this, I'm going to do this. Otherwise, you can just push it, push it off. But it has to be a date that you can meet. Now, I'm a writer, so I was comfortable with six weeks.

That might not be you. You might say, I'm going to do it in eight weeks. I'm going to actually do it in three months. But set a date that you're actually going to put it out.