FounderQuest
FounderQuest
Learn How We Run Our SaaS Content Marketing Machine
Show Notes
Links:
_why
Ruby's Exceptional Creatures
Weinberg on Writing: The Fieldstone Method
Audience OpsPeter CooperDocsketchProofHubScribendiDeltaWalkerNotion
Honeybadger Developer Blog
Full Transcript:
Starr:
I wonder if any of our listeners are too young to know what SOAP is, like SOAP?
Josh:
I'm guessing so.
Ben:
Yeah.
Starr:
SOAP is what we have before REST APIs and JSON. It was interesting.
Ben:
It was hell.
Starr:
Yeah. I dipped my toes in that water a little bit and just gave up.
Ben:
Every time I hear SOAP I think of DHHs slide at that one RailsConf early on where he had the WS-Death Star. It was great.
Josh:
Yeah.
Ben:
Because all the... I guess I should explain that. It's all of the, I guess, it was schema domain or the name space, everything started with WS, and so they started referring to the different... Because there was, I don't know, 10 or 20 or whatever, there were a lot of them, and so they called them WS-Star, to represent all of his schemas that went into that whole SOAP definition. So DHH made fun of it by calling it the WS-Death Star.
Josh:
I see.
Starr:
Oh, I get it. I didn't get that joke to begin with. And the schemas are XML schemas.
Ben:
Right. Yeah, it's all... yes.
Josh:
It's all the good stuff.
Starr:
Yeah-
Ben:
All the fun java land things that you could ever want.
Josh:
I feel like I remember having at one point to take a SOAP endpoint and build a REST wrapper for it or something so that we could interface with... I don't know, I can't remember exactly, but I feel like that happened.
Ben:
That's a special level of pain.
Josh:
It was terrible.
Starr:
Did you use to do some freelance work for the mouse?
Josh:
Oh, yes. Mickey Mouse?
Starr:
Yeah, that mouse.
Josh:
Yeah, uh-huh (affirmative).
Starr:
That just sounds like something they would have had you do, I'm not sure though. I don't know.
Josh:
Yeah. We're not saying their name just in case they decide to sue us, right?
Starr:
Oh, yeah, yeah.
Ben:
At some point, we may want to monetize this podcast, and we can't have the copyright taking us down.
Josh:
We can't have the... Yeah.
Starr:
Well-
Josh:
That does sound like something that they would do.
Ben:
Yeah, it does, yeah.
Josh:
Yeah.
Starr:
Well, today, I don't know if we've had unanimous consensus on this, but I think we're going to talk about blogging and content and I've done a bunch of paid content acquisition recently, and y'all want to talk about that stuff?
Ben:
Oh, yeah.
Josh:
Sure.
Starr:
All right, I don't know, there was a time back when blogs were the thing. You started a company, then you need a blog. I'm thinking 2005-ish, 2007, and I remember getting started blogging, I didn't know what I was doing then at all. I produced some terrible content with no real purpose, and since then I've learned a lot, like you do when you, I guess, do something off and on for a decade. Even if you don't really try, I guess you learn some stuff. Y'all had blogs too, right? Your personal tech blogs.
Ben:
Yeah. And it's sad, they're pretty lonely these days, somewhat abandoned.
Starr:
Oh, yeah, me too. Me too. I think starrhorne.com is still up, but I don't know. Don't go there, don't go there anybody. Anyway when we started Honeybadger, obviously, we had to have a blog and we just took the approach that I think a lot of people do, which is you write a blog post about what you're working on, you write a blog post and you do a new feature and you want to talk about it, or when... I don't know, just something occurs and... That did fine for a while, the main problem I found with that approach though is that everybody just gets too busy to write blog posts.
Starr:
Yeah, I feel like back in the day there was this real feeling like, oh, everybody's having blogs, it's this community thing, you'd link to your-
Josh:
You've got to have one.
Starr:
... blogs... Yeah, yeah. And you're having discussions by writing blog articles back and forth, and people don't really do that anymore. Since then, it's become a lot more, I don't know... When I look at a lot of company blogs these days, I just see, pardon me French, garbage.
Josh:
The earlier days of blogging actually were kind of cool, because everything was still... there was no standardization, everything was unique and... Actually, I didn't even have blog, initially, I had a weblog, I'm pretty sure. Pretty sure it was a weblog.
Starr:
Oh. Yeah, I don't know, it seemed much more of a discussion, because I guess there was... people weren't just uniformly on Twitter or I guess, Reddit or whatever people use these days. I don't know. I don't know what the children are using.
Josh:
The were on all those things that we talked about last episode.
Starr:
Exactly.
Josh:
Or whatever, BBS's
Starr:
Yeah, they fall in with just having everybody do a blog post when they feel like it, is that that nobody really feels like it kind of thing, because writing is hard and it's... I don't know. Plus when you're starting company, you have a billion things to do and a lot of them feel more important than writing some blog post, especially when you don't have a strategy or anything around it.
Starr:
Then, I don't know when this was, it was around the time when we started going to a bunch of conferences and stuff. I decided, okay, Starr, I'm going to write one blog post a day. And so I had a flurry of activity for about, I don't know, three, four, five months, where I just turned out tons and tons of blog content. And actually, I was really surprised, that started getting some results. In terms of people coming up to me at conferences... I'd never had that happen before where people come up to me and say, "Hey, you're Starr. You wrote this thing. That's cool." And it floored me the first couple times it happened, and then-
Josh:
That started happening to me too, by the way. Where people would come up to me at conferences and be like, "Hey, you know Starr?"
Starr:
Oh, really?
Josh:
Uh-huh (affirmative).
Starr:
Oh, my gosh. I guess I'm famous.
Josh:
Yeah. People would always mention your blog posts, still do.
Starr:
Yeah, that's amazing. Some people still reference these blog posts I wrote years ago.
Josh:
Yeah.
Starr:
So I guess the one thing I learned there is that posting frequency is really important, probably, more than quality even. I'm not going to say that, but getting stuff out there frequently is important. And I actually did some stats analysis type stuff of our overall revenue. I did this about a year ago, and showed that growth in our revenue was correlated to growth in posting frequency during at least a time when I was doing a lot of posting, which was kind of strange to see. I don't know if it's causal. Since then, we've increased our posting frequency and I'm not sure there's been that direct of a relationship, but also, the economy's collapsed since then, so it's really had to say. It's apples and oranges.
Josh:
Yeah, and we're also a lot bigger now then we were then, so to see... We're growing more revenue than back then. Like to see a large increase, at least in the chart.
Starr:
Yeah, definitely. And since then, you, Josh, have done a lot of content stuff. You got on a real big content kick for a while, didn't you?
Josh:
Yeah. I do on and off. I feel like I go between getting a lot done and getting not much done at all. But I don't know, we have the email newsletter.
Starr:
You did the newsletter, you did Ruby the Exceptional Creatures.
Josh:
Yeah, Exceptional Creatures, which was a... I don't know what to call that, it's an index of Ruby exceptions, but it's themed with mystical or whatever, mythological creatures.
Ben:
I heard a lot of good comments on that from people. They really loved that.
Josh:
Yeah, people still like it, yeah. You can go... It's exceptionalcreatures.com, you can link it up, but... Yeah, it's still there and people like it. It has every single Ruby exception that there is in it and we were writing content about each one, but at some point it becomes a little bit ambitious to try to write an article on every single exception that there is, so we covered the top ones.
Ben:
Yeah, and it makes for good reading, so you should go check it out.
Josh:
Yeah.
Starr:
One thing I really liked about that site is that it was along the lines of earlier Ruby stuff, in terms of flavor and content, and now that everybody's sold out, I feel like everybody really just yearn to authenticity-
Josh:
Mm-hmm (affirmative).
Starr:
... that we've all lost.
Ben:
If only we could bring-
Josh:
A few people compared it to _why
Ben:
Yeah, if only you could bring _why back and have him write for us.
Josh:
Uh-huh (affirmative). Yeah.
Ben:
Maybe do some Honeybadger sponsored content from _why that would be awesome.
Starr:
Oh, definitely.
Josh:
Writing is a super... The ability to write well is a super valuable skill for a programmer.
Starr:
Yeah, totally. You introduced me awhile back to what was it? The Fieldstone method? It was a book by-
Josh:
Yeah, the Fieldstone method.
Starr:
Who was the authors name?
Josh:
Gerry, is it Weinberg?
Starr:
Yes, that's right. Gerry... The Consultant Bible guy.
Josh:
Yeah, Weinberg on writing.
Starr:
Oh, look at, you got your-
Josh:
By Gerald M. Weinberg. I have a bookshelf here, so yeah, I pulled it off.
Starr:
You got your physical copy, look at you.
Josh:
I do. I often buy... I'll read on Kindle or pdf or whatever a lot, but I, also, often buy the physical copy for whatever reason, I just like them.
Starr:
You need to get a book shelf with all them behind you.
Josh:
Yeah. I should. I need more wall space in here for bookshelves.
Starr:
There you go.
Josh:
But, yeah, the Fieldstone Method is a way of, I guess, collecting topics, passively collecting topics to write about, or passively writing throughout whatever, as you have ideas and things, and then basically you can, over time, assemble ideas and little things that you've written into larger pieces of content. And it's worked out really well for us, I think. You've adopted a little bit of that technique too, haven't you Starr?
Starr:
A little bit, yeah. Not so much for technical writing, but I do... yeah, basically, the essence of the technique is that you have... if you want to build a fence out of stone, you could go out and take all the stones and bring them to the place where you need to build the fence at once, or just when you're out on walks, you could gather stones one by one and then bring them back, and then eventually you'll have enough to make a fence. Yeah, I've been doing little just bits of writing here or there. The idea is you just write these little things as they occur to you. Things that are interesting to you and you just store them away with no real intention, and then eventually, I don't know, maybe they'll coalesce into things. Maybe you have a couple running pieces that you just gradually write over the course of months.
Josh:
Part of it is just that you write more. I think my favorite thing that I took away from that book was the idea that you can pretty much always be writing. You don't have to... Writing isn't the act of sitting down with a blank page and having to write a whole article start to finish or something. When you feel like you have something to share on a particular topic, just write it down, it doesn't have to be polished. It's really just for yourself, but later you could take and it might become a paragraph in an article or something.
Starr:
Yeah, it's a really good point, because I feel like everybody, including myself, tends to think about writing as you just sit down with a blank page, but this way it's much more construction, engineering, getting all your pieces together and then you assemble them in a way that makes sense. And you use that a lot when you're starting the Leveling Up newsletter. We still have that, right?
Josh:
Yeah.
Starr:
We're still publishing that.
Josh:
Yeah, we still have it. I haven't published it as frequently as I initially hoped to, but, yeah... and actually, I need to get... I kind of dropped off adding... I haven't been adding our... Normally, I take our blog posts that we have people write and reformat them for email content and I'll probably get back to that soon. I dropped off sending emails at all during the lockdown and the pandemic, because I don't know, I just didn't feel like emailing people. We'll probably pick that back up here.
Starr:
That makes sense.
Ben:
I can tell you Josh-
Josh:
but, yeah-
Ben:
... plenty of sales people think it's a great time to email people, because I've been getting a lot of them.
Josh:
I know. That's one reason I'm like, "People are already getting enough emails and-
Ben:
We've got to give them some balance though, we've got to give them some actual good stuff that they actually want to read-
Josh:
No, totally.
Ben:
... versus hey, can we schedule a call?
Starr:
What kind of capitalists are we?
Josh:
Yeah, I do want to get back on it.
Starr:
I don't think it's a good time to email people. What? We're ruthless-
Josh:
I have a really hard time-
Starr:
... robber barons.
Josh:
I have a really hard time with... I love to write and I love to research and I love everything about it, but I find that it's difficult... I only have so much mental capacity and energy for writing and the creative process, and there's overlap with programming as well, and if I'm really doing a lot of engineering work, I find it... I don't often have the leftover mental capacity to be creative and write. That's a constant struggle back and forth for me as an engineer.
Starr:
I would say I'm-
Ben:
I think on that point this would be a good place to plug one of our friends and Audience Ops, right? That's a service-
Starr:
Mm-hmm (affirmative).
Ben:
... where they do the writing for you, and basically their argument is, you're busy, you got your mind full of other things, so let us handle the balance and content writing for you.
Josh:
Yeah.
Starr:
One thing about our set up which is a bit, I don't know, I guess it's unique, but... Our audience is developers, so if we're going to publish content for developers, it needs to be about development. It needs to be about... It's got to be programming content and it's not... We've tried doing other types of content. Lord knows we've tried doing more small business content, more... just anything that we can have a non-developer write, we've tried, but then nobody looks at it, ever. Nobody wants to read it.
Starr:
Yeah, so I guess that's why-
Josh:
It has to provide a ton of value. That's the thing, and value costs money. Even if you have small business stuff that's popular, it's usually because the author has a lot of valuable experience to share, and... yeah. It's hard to find... Go just out and find someone random that's going to go write business... Even though it's easier to find people who can write business articles, it's more rare that you're going to find someone who actually has the experience that is going to be valuable enough for people to really connect with it, I think.
Starr:
Yeah, yeah. For a long time we stuck with this just kind of doing it ourselves set up, when we could. Primarily, because of the technical angle. And then about, oh, it was, when was it? It was last year. It was as a direct result, I think, of the analysis I did that correlated blog frequency with revenue growth. I was like, "Okay, we've got... I can kind of estimate how much money each of these blog posts is making us, assuming it wasn't just correlations, assuming it was causation. So why don't we just give that to somebody and have them write a post," because it was a fair amount of money. It was thousands of dollars. Yeah, so I set out to try that, and that is how we arrived at our current set up for publishing stuff.
Starr:
If you listen to the show to the end, basically, every week I give a pitch for writing for us. If you go to our blog at honeybadger.io/blog and you look at the top, you'll see a link that says, "Write for us," and you click on it, and you'll get all sorts of information on how to write for us, and-
Josh:
For money, right?
Starr:
For money, yeah, exactly.
Josh:
Yeah.
Starr:
Exactly.
Josh:
It's always good to mention.
Starr:
Yeah, after I looked at those ROI numbers, I looked at... I reached out to Peter Cooper, who runs Cooper Press, publishes Ruby Weekly, JavaScript Weekly and a bunch of other newsletters, and he had mentioned paying some people to do content. So I reached out to him to ask, "Hey, I'm thinking about paying people roughly this figure, and does that make sense?" And he said, "Yes." And so, yeah, we arrived at this figure where we are currently paying about $500 for a blog post, and that is... There's some places out there that pay more. I think in terms of-
Josh:
Not many, I don't think.
Starr:
Not many.
Josh:
Yeah.
Starr:
Yeah. I think that we are in the high range. If I was doing it over, maybe I'd do 400. I know some people are working for 300, but honestly, at this point, I'm not sure I want to go to back to my authors and be like, "Actually, we're going to pay you less. We're going-
Josh:
It doesn't usually go over well.
Starr:
Yeah, exactly. "We're going to give you a hundred bucks less." Even though it doesn't really mean that much to us, because the principle of the thing. So we pay people 500 bucks, and I've actually been surprised. We've been able to get some really, really good content for that. We've been able to... Most of the people I'm working with, a lot of them are developers at tech companies you've heard of, and I guess, looking to make a little extra money on the side, looking to... A lot of people are publishing blog posts anyway, they want to write more, they want to do this and this gives them a way to do it in a way that...
Starr:
First of all, it gives them a little bit of money, which is nice. But then second of all, because we've been doing this for a little while, we know to promote blog posts a little bit better than most developers do, which is not at all, I guess. We do the bare minimum as opposed to nothing, so people get a bit more, I don't know, good traffic out of that, a bit more exposure. And so far, everybody's been pretty happy. I've been pretty happy with the quality of the content. We are publishing once a week, and we've got a pretty big backlog. I've got a two month or maybe even longer backlog, because I-
Josh:
Really?
Starr:
Yeah. I'm going to have to start probably, turning people down or being like, "Okay, sorry, we need to wait a little while before engaging.
Josh:
We're going to have to change the call to action at the end of this podcast to don't write for us.
Starr:
Don't write for us, no.
Josh:
I like that. All right, stop.
Starr:
Stop it, yeah. It's gone really well. I thought I would... I've been doing this over in a corner by myself and nobody really knows what I've been doing. Except maybe Ben Findley, so I thought I would just share a little bit of lessons learned in this own content, it's... I don't know, I've learned a few things setting this whole system up. Does that sound fascinating? Are y'all thrilled?
Josh:
Mm-hmm (affirmative).
Starr:
All right, so when I started doing this, I had no idea what I was doing. I basically was very upfront with everybody about that. I wrote our writer guidelines, and just threw it out into the world, and I figured people would email me, I would talk to them, and we would figure something out together. And that's kind of, more or less, how it's worked.
Starr:
One thing that we try and do differently at Honeybadger is a lot of company tech blogs they're either focused on key words related to their industry and so you get all these incredibly boring, jargony articles that nobody wants to read. I don't know who reads these, not me. And other tech company blogs tend to be very, what I call, tactical. They show, okay, here's how to build a to do list in Angular and React version 2.X.X, and in a month it's going to be out of date.
Starr:
And just, I don't know, out of... I don't really know why, but we have always done things a little bit different, we've always covered more strategic topics. We've always covered things that I think are going to be beneficial to readers longer term.
Josh:
So more evergreen?
Starr:
Yeah, not only more evergreen, but just more, I don't know, more high level, right?
Josh:
Yeah.
Starr:
We do our share of how to blog posts and everything, those are fine, but I think that's... I think overall, the things we've gotten a lot of praise for have been either deep dives into a very narrow facet of something, of Ruby or-
Josh:
Yeah, something foundational. Something that's not likely to change in the next Ruby version. It's... yeah.
Starr:
Yeah, exactly. And unlike a... You might think, "Well, I could just go to the docs for that. I can go to the docs and learn about Ruby, I don't know, Ruby string methods or something."
Josh:
Yeah, or open three.
Starr:
Yeah, yes, open three. You can go to the docs and learn about that stuff, but the docs will basically only tell you about that thing.
Josh:
So case in point, if you Google whatever, Ruby open3, all that stuff, we will come up. I know this because I routinely am programming and I need to Google something for Ruby and I go and do it, and it takes me a minute to realize, oh, I'm actually reading our blog now.
Starr:
Oh, me too.
Josh:
So it works.
Starr:
Yeah, so the deep dives that... They not only explain the one technical thing, like open3, but they give you a vertical slice through the whole stack, so here's open3, what is that actually doing, let's look up one level and down one level, and explain it. And so that's a sweet spot for us, and another sweet spot for us is to cover these big general topics. Recently, one article we did was an introduction to character encoding for Rubyist. A big general topic as applied to, historically, for us it's been, Rubyist, but we've also branched out a bit since we support a variety of languages in our product, so encoding for Rubyist.
Starr:
One of the things that I did early on that tipped me off to this approach was I did the Rubyist guide to security or something, and it basically just listed every possible security issue at that time that people were dealing with. And talked about how it applied to Ruby and Rails development, and I got a lot of positive feedback. Those are the types of things we look for, so I spent a lot of time really honing that and figuring it out, and honestly, I didn't even go into writing this guideline having a clear explanation of all this. I just had these vague, oh, well, we've published articles like this and that's done well, so what... And I really had to sit with it and think about, okay, what is it about this article that makes this us? What is it about that?
Josh:
How did you end up communicating this to the potential writers in a way that gets all that across? Because I assume our write for us page is not super long, I think it's pretty brief overview of all of this, but does that come across pretty well? Do people know what we're after? Or do you end up having to give them a lot of direction?
Starr:
I think some people get it from the write for us page. The way I communicate it there is I gave a bunch of examples and then I was like, "Here's a structure of the examples." I basically gave them Madlibs. Let me read off one, how does big concept apply to specific situation faced by readers? You know?
Josh:
Yes.
Starr:
This specific detail of a certain programming language is weird, here's how fundamental properties of the system made it that way, stuff like that. That's-
Josh:
Does anyone ever write an article and it just leave fundamental properties of the system, they forget to fill it in?
Starr:
No, not really.
Josh:
Okay.
Starr:
I'm not sure how much of this people actually read, some people have clearly read it all, some people haven't. What happens when somebody contacts me? They'll email me, they say, "Hey, I want to write for you." In the write for us guidelines, I've said, "Email me two writing samples about programming, some other information." People put that in and essentially, that email I look at their writing samples, if they seem reasonably okay, then I ask them to book a call with me on Zoom. And I've been pretty open about who I accept. If you've emailed me and you have okay, decent writing samples, I've tended to be like, "Okay, let's schedule a call."
Starr:
I may have to become a little bit more selective as we get more and more people in, but, yeah, then we do a call and I've got my structure of the call that... Essentially, the call goes over all the stuff in the writer's guidelines, just to make sure they've actually heard it and not just skimmed over it, because some people may not quite understand everything. Then after the call, assuming they act like a reasonable human being on the call... The call's basically about getting to know them, understanding the things that interest them, because, honestly, I like my authors to bring me ideas for topics for blog posts, because frankly, my own experience is limited. And they come up with much cooler articles than I would be able to assign to them.
Josh:
Yeah.
Starr:
Yeah. And you're going to write better about a topic that you care about versus something that somebody assigned to you. That call is basically just getting to know each, then I put them in the process, we send them our writer's agreement, we do that via Docsketch, via our free account that Reuben-
Josh:
Yeah, Docsketch is cool.
Starr:
... friend of the show gave us, so you all should go out and buy Docsketch. We should give them a little plug and pay them back for that.
Josh:
They're a unofficial sponsor of this episode?
Starr:
Exactly. We eSign the author agreement, which is just a standard contract, and the terms of the contract are basically what you'd use if you were hiring a programmer to do code. It's work for hire. We own the copyright of all the stuff that we buy, and I think that's fair because we pay a lot for it. But that said, we give people permission to post their own stuff on their own blog after a while and all that.
Josh:
Well, I like the aspect of it that we're trying to help promote the authors themselves, we're trying to help them get their content out there and I don't know-
Starr:
Yeah, definitely. We are... One thing I really try to do is be very author specific. Our authors aren't just... And I communicate to them, I hope, that we're not just some content mill, we are here to help them publish the things that they find interesting and useful and do that in a way that benefits Honeybadger. And we basically want to lift everybody up and be happy together. I don't know. I don't know, it's kind of crunchy, but that's okay.
Josh:
You put a lot of production stuff into that too. Everyone gets a custom illustrated headshot for example, right?
Starr:
Oh, yeah.
Josh:
Like an avatar for the blog.
Starr:
Yeah, everybody gets an avatar.
Josh:
Do we give that to them? They can use that if they wanted to use it other places even? Or-
Starr:
Yeah, I told them they could use it for their personal stuff.
Josh:
Twitter?
Starr:
I'm not sure anybody's actually done it.
Josh:
That's why everyone... There's 50 people on Twitter that have... they're all using this for their Twitter photo now, because it's so great.
Ben:
We're going to be like the Wall Street Journal, that style.
Josh:
Yeah.
Ben:
Yeah.
Starr:
There you go. We'll have to hire the gal from Fiverr to... Oh, no, I shouldn't say where i get it done.
Josh:
You just blew our source.
Starr:
I blew or cover, yeah. Now, everybody's going to get the same one done. So initially, I was using email to coordinate with everybody and just, I don't know, I figured they were writing stuff and I was trying not to plan too far ahead. And I quickly found that when you have five people working on articles, and they're all emailing you, it's really hard to keep straight, and it's real easy to forget people and forget what they're doing and all that. So that's when we moved over to a project management system called ProofHub, which I do not strongly recommend. We basically moved to them because pretty much every project management system that had the features that we needed was per seat, and I'm not going to pay $20 a month for a seat for an author who maybe is never going to write an article for us or maybe will write one a month or something, that's ridiculous. They had unlimited seats, basically.
Starr:
We've essentially just got a big kanban board that has all of our steps. We have a very set process. They do the first draft, they get it back to me, I give them high level comments, usually, that involves stuff that will make the article more approachable to people, because people tend to come to writing with their own knowledge, and they don't realize that they're assuming knowledge on the part of the reader. Once people get done with that, then they submit their second draft. This is all done by GitHub, we just markdown files in GitHub. And after their second draft, it goes into the editing process, which happens on our end, and I take a very programmery editing approach. I think most normal people who do editing tend to mark up things and send them back to the author and all that stuff. I change the files and submit a pull request, and I tell them this, it's like, "I want all of our authors to be happy with what goes out, so if they're not happy with any of the things in the pull request-
Josh:
That's cool.
Starr:
... sure we can change them, we can discuss them," but it just seem easier to do that than to try and figure out how to get them to do the exact thing that I want them to do. I'll just show them and then they can do it or not.
Josh:
So you submit a PR to their article and then have them review it?
Starr:
Yeah, and then I have them review it.
Josh:
Nice.
Starr:
And then when the PR is done and merged, they get paid pretty quickly. And for the editing process, that's changed a little bit. The editing process has been by far the most time consuming thing on my end. And initially, I edited every article to make it sound like I had written it, which just takes an enormous amount of time. A couple of the articles, I actually rewrote a lot of them, and since then, partially, owing to pandemic, because just having less time, since then I've stepped back from that and been like, "Okay." It's okay if people don't explain things in exactly the way I would or maybe the most simple possible way, that's okay. Let's just take their words, take their writing and make it the best version of itself that we can do. I'll still do a heavy hand edit occasionally, honestly, because several of our authors are overseas, so...
Starr:
Developers, in general, also, don't tend to be the best at writing introductions to things, so I rewrite some introductions, and then I send it off to this service called Scribendi, and Scribendi is essentially, it's a human editor and you send them a file and they send you back the edited version. It's a little bit hit or miss sometimes, at least in the beginning because you just send in your file and the assign and editor to it, and you hope that you get back something good. And sometimes it was good, sometimes it was just not good, sometimes people had rewritten things in ways that made no sense, technically, but I eventually found somebody on there who gave consistently good results, now I basically just pop it over them, and then when they're done, I look at the diff. I use a program which I really like called DeltaWalker. It's essentially a diffing tool that gives you really in-depth diffs where it can be like, this word was moved around inside this line as opposed to-
Josh:
That's cool.
Starr:
... to GitHub, where it's just this line changed somewhere.
Josh:
But there's no collaborative thing to it, right? It's just a tool.
Starr:
No, it's a desktop app.
Josh:
Yeah.
Starr:
Yeah. I just have to go off about this tool. It can pdfs, it can do Word documents, it can do directories, you can diff whole directories of files, any way.
Josh:
Nice.
Starr:
Yeah. Once that's done, then I do a PR, maybe I have to rewrite bits of it, if that requires it, then it's done. My overall impression of this, is this took a lot longer to get going and get rolling than I would have liked. It felt like in the beginning doing the paid content, I just kept thinking, "Man, I could write articles quicker than the stuff I'm doing to have somebody else write articles and pay them for it."
Josh:
Also, it sounds like a lot of process that you created over time.
Starr:
Yeah, there's a lot of process. But overall, now, it still requires work, but it's process work, it's mechanized work, so that, assuming I'm not in crazy limited quarantine hours, I can do it and then do some other stuff as well during the day. But you mentioned process, my favorite bit of process, which I almost forgot is that when it comes time to publish these articles, one thing that I always hated was actually publishing the article and taking the markdown file, bringing it into our static site generator and in that static site generator file adding a description to it and adding the title. Because, okay, I was always worried I was going misspell something or... And code editors don't have the best spellcheck, and it's just... I don't know, it always stressed me out.
Starr:
And then also, we had this issue where our marketing guy, who not technical, he would have to ask all these question about, "Okay, what is this article about? Who is this for? How do I promote this?" What I actually did is I came up with... it's a blog post marketing template, and I'm really, really happy with how this is turned out. Essentially, what it does is it steps you through a list of questions. Like, obviously, title, but then it asks you who is this for? Could you explain what this is about for a responsibly intelligent, non-technical person? That's our marketing guy Ben, so, hi, Ben.
Josh:
Yeah.
Starr:
So that's basically for him so he can understand what it's about, then it's like, "Okay, so what good does it do the readers? What are they going learn? When is it going to be useful?" These very simple marketing questions, and by the time I write those... Those are not supposed to be published. Those are just for internal use, so I don't have to worry about sounding cool in those. I get those written and then it's like, okay, so what's a short description for the post? And now I'm in place where, okay, it's super easy to write the description, because I've just done all my work. I've just figured out everything I'm going to say, I just have to write it into a clever description. Then since you were taking some of these blog posts for our Leveling Up newsletter.
Starr:
Yeah, you need some text to put in those emails. I started adding a long description, which essentially what it is is I take the... explain it like I'm five explanation of the article, I make it look a little nicer, and then I just append the short description to it, so it's like there's almost a formula for doing it, so it's super easy. And then also things like little quotes and stuff in the article for Twitter. All the stuff that, when I was doing it after the fact was super ad hoc and stressful, because it would be 10 things I have to remember at one time.
Josh:
Makes you want to procrastinate.
Starr:
Yeah, exactly. This actually gets done before the blog is posted. It takes about 20 or 30 minutes to fill out and then I used to copy and paste everything over to create the file for a static site generator, but I since was like, "That was dumb." I started saving everything with a data sheet in YAML format, so I wrote a little build tool that takes the data sheet and then spits out the blog post with all the images in the directories and everything, so it's pretty sweet. It's pretty slick.
Josh:
Nice.
Starr:
That was my hour long excuse to brag about my little build tool I wrote.
Josh:
That's cool.
Ben:
It sounds pretty awesome. It sounds like we could build a product that does all that.
Starr:
Oh, my gosh.
Josh:
Yeah, I was thinking like-
Starr:
Okay, everybody does exactly the same thing we do.
Ben:
Yeah.
Josh:
The content... I really liked the editing process you talked about, especially with the idea of submitting pull requests back to the author for them to collaborate on your edits. I thought that was really cool. Maybe there should be a SaaS out there that's dedicated to editors for that kind of editing process. Maybe it could have that super high powered diffing that DeltaWalker has, but also do pull requests against it and stuff and reviews. Because it's funny, I was looking at ProofHub and it looks like it has a lot of features, but at face value it also looks a lot just like a Kanban board, so it always strikes me how much... How many tools can probably be replaced by Notion these days.”
Starr:
I'm using the tool in ways that I didn't necessarily think I was going to use it when I started out, so it's could be a different tool would be appropriate now, maybe, because of the way I'm actually using it now. I just haven't gone back to it, because that would be a lot of work to change everything over.
Josh:
Mm-hmm (affirmative). Cool.
Starr:
All right. Well, I've talked y'alls ear off, so if y'all have anything to say, let me know, otherwise, I'll let you all go.
Josh:
That was great. I think we're good. Yeah.
Starr:
Okay, awesome. This has been FounderQuest, so if you want to review up go to Apple podcast and do that. I think that's what it's called now. I always forget every week. If you want to write for us, if this has sparked a fire, we hire people to do programming tutorial type content with a lot of Ruby and a smattering of other stuff as well. So just got to Honeybadger.io/blog and look for the write for us page, read the whole thing and understand it before you contact me, and I will be seeing you.
