Developers building a software business on our own terms.
Ben: Yeah, hopefully, my neighbor here won’t be too much of a problem for us. I might be muting more than usual. He's a lawyer that apparently was raised, at least part of his life, in Panama. So he’s bilingual and does a lot of international kind of law. So he's working with people down in Venezuela, whatever, that want to do import export stuff.
And it's kind of fun listening to him because the walls are thin, right? And so I can hear his calls. And he just blends between English and Spanish all the time. You know, he'll say one phrase in English, then one in Spanish, then back to English. It’s—I wish I could be like that. That's pretty cool.
Josh: Yeah. I used to have a bail bondsman as a neighbor and he would play talk radio all day long on a actual—like it sounded like a detached boom box or something like that. It was pretty great.
John: I'm always impressed when people can just switch back and forth like that. That's mind blowing to me that their brain is just fine with either language. Even the times where I learned another language and for a little while could speak another language, it—my brain just doesn't work that way.
Josh: That's cause you’ve tangled it all up with programming languages.
John: It's very true. And even there, I'm like single language. Now, I don't even barely do JavaScript. So—
Josh: I know. Yeah.
Ben: I've been doing a bit more Go lately, speaking of. And it's been a lot of fun. I don't really love the friction of getting into Go, you know, coming out of Ruby. Like Ruby is so easy, you just, you express whatever you want. And it basically works, right? Because it's so fluent as a language and Go it's like, “Nope, can't do that. Nope. Can't do that. Nope. Can't do that.You really got to do it this way. Not that way.”
But the end result is. It's pretty fast. That's nice. And, if you never have to touch it again, well, who cares, right? You went through that pain and now it's super fast and typically there's one good way to do it.
I know like Python, there's one way you should do it and Go is similar in that it's like, this is the happy path, and you should probably stay on this path unless you have really good reasons not to. And then, your code looks pretty understandable. So, I guess it's kind of like the Rails conventions, you know, where things are where you expect them and things behave like you expect them to and Go, the language is like that.
Oh, okay. And it behaves this way. You should look this way and it's pretty familiar.
Josh: It's kind of nice to have those guidelines and it also can enable language features and ID things. Gofmt is like one of my favorite things—was my favorite thing when I learned Go. And that was back before, like, we had good Ruby formatting tools. I think at the time it was, like, Elixir and Go were the ones I was jealous of for their formatting tools.
But it's one of those type of languages, you get that benefit of extra completions and things. I liked how I could like just write terrible Go code and then save the file and it would just be—it would look like your code, basically.
Ben: Yep.
Josh: I heard somewhere that John has done some Go. I don't know where I heard that. but back in the day, I think it was a big secret.
Yeah, speaking of John: John Nunemaker is back on the pod with us. I just—we didn't mention that. So the third voice you're hearing, if it sounds familiar, it's because you heard him last week and he's back for more. I guess you like punishment.
John: Yeah, I'm just tagging along as often as I can, you know, so,
Josh: Well, we're glad you're here.
Ben: So John, speaking of Go format, I got a question for John about formatting in Ruby. So I know we've kind of standardized on Standard here at Honeybadger, how about you? Have you found a linter formatter that you love for Ruby?
John: No, I don’t—well, my current mechanism is basically just fix everyone who does it wrong. And so it's, yeah, it's literally just John linting standard. I don't know. I've definitely—I used RuboCop for a long time with defaults and then slowly started tweaking them and stuff like that.
And that was okay. And then I just got tired of making commits that were like, fix the linter, fix the linter. And so finally I just ripped it all out of Flipper. I did recently though, because I don't know if it's the Ruby LSP or VS code or what is the thing that I'm using, but if you have a formatter installed and you're using VS code on save, we'll do, like, go format wood and stuff like that.
And I was like, “Okay, I'm going to try this on a new project”. So I tried it on a new project that I was working on and it was life changing. It was really great. I mean, I had to tweak a few things that I was like, no, I do not, you know, tab in if to match, and when I had do assignment on an—if like, I want it just to flow and not be that way.
So I had to tweak a few things. And so learning that, you know, before it was really painful. Now I got a little AI programmer sitting right there beside me. So I would just be like, “How do I do this in RuboCop? “And it would be like this. And I was like, “This is great”. And so now every time I save everything is formatted perfectly.
It was really nice. So I would say I'm a fan. I just—I haven't went back and historically applied it, you know, to stuff that I actually spend the most time working on. So at some point I will do that, but—
Ben: I never was able to get into a RubuCop at all. The rules just weren't doing it for me. And I think Josh convinced us to start using standard, because Josh was always about linting and having the format and I was kind of the rebel amongst the crowd. I was like, ah, I like my style. I don't want anybody else's style, but standard is pretty close to the style that I had.
So I'm good with standard. The only thing that really bugs me about standard is the insistence that you do not indent the private and protected. I like that. I like the extra indentation after private or after protected because it really stands out to me. I'm in a big block of private code, right?
And not having an indent and like, “Oh, all right, I can give that one up for the team", you know? But yeah, having VS code and have the format on save. Love it. Just love it. Now I can just type whatever I want and it just does it for me. And like, perfect, that's great.
Josh: Do you all remember when, basically, you weren't a true Ruby programmer until you had, uh, like whatever your GitHub handle slash style guide or whatever we call them, your personal Ruby rules, preferences for writing Ruby code? I wonder if mine, mine might still be on my GitHub.
I have to go check that later.
John: Yeah. And your dot files, had to install them as well.
Like if you didn't, yeah, like you had to, yeah. If your dot files didn't install them, then that was bad.
Josh: I do recall. I think I definitely used to prefer single quotes and standard pretty much—I pretty much gave up on all my personal preferences. And that's why I love standard so much. Because it's like I just don't want to think about it anymore. I spent way too much time thinking about all that and it's nice just not to have to worry about it, and I definitely don't want to argue over like RuboCop rules. So I'm happy to let Justin Searles decide for me.
Ben: Yeah.
John: Does it change other things in your life? Like, do you wear the same t-shirts now, or?
Josh: Oh, yeah, totally. I've got the closet or, you know, the drawer full of the black t-shirts, and yeah, socks and underwear, all that stuff.
Ben: Well, that reminds me, I have to rant about something, regarding standards and why is it now that you cannot actually buy clothes by the size? Like, I know my waist and I know my inseam, right?
And it's been the same for a long time, and I go to buy a pair of pants and they don't fit because the waist is too big or the inseam is wrong, and it's like, what is the deal—and even—I wear jeans, Levi's, all the time—and why is it now that 505s have a different waist or a different inseam, and it's different based on the wash, like, different washes have different cuts, I don't understand. Why can't we standardize the pants? Sorry, that's my rant.
John: I will jump on this rant as well. It's not necessarily Levi's for me, but I have run into the same thing with different, even just—I don't want to get too personal about underwear—but even just the color of the underwear, it gets a different texture. It's just like t-shirts of different colors have a little bit.
So I'll literally—I’ll only buy like black. Because I know, like the grays, they're just going to be a problem. I can, I totally understand what you're saying. Definitely TMI, but.
Josh: On the flip side, it is nice to have variety in the world. And I think standardizing everything like down to the clothing has been tried in the past and it didn't work out too well at, like, society scale. So, it's nice to have all this variation, even though it can be extremely frustrating at times.
I like that about Ruby though. Ruby is kind of the language where if you want, you know, anything you want to do, you can do it your way. You don't have to use standard. I've chosen to pick a tool that will format it for me. But, if you want to have opinions in Ruby, you can certainly do that.
Unlike Python or Go, as much.
Ben: So you're saying it's like the Burger King of programming languages, right? You can have it your way.
Josh: I guess, you can have it your way. Exactly. Yeah, I like that. I like that the choice exists now inside of that framework. I'm very happy just to not have choices. I guess that's your freedom to have.
Ben: I've forgotten about the single quotes. That was my other thing about Standard that I didn't love. Because I do prefer the single quotes. Because who wants to shift every time you type a quote mark, right? That's just ridiculous.
Josh: Yeah. Well again, so like, the formatting was what? Turn me, like, change my mind about single quotes, because interpolation works in double quotes and it works everywhere. And once you have format on save, I can just write—I still write single quotes and I get double quotes, so I don't have to worry about the shift.
And as long—you can train yourself to do that.
John: It is a little weird to train yourself at first, because you still find yourself wanting to format and think about it and all those things. And what actually sent me down this route was VS code was struggling with when I paste—it could not get the indention right ever. It just never did it right.
It was always wrong. I installed plugins that were only about indention on paste, I just couldn't get it right. And so finally I was like, “All right, I'm just going to set up something to format automatically”. I tried standard and I was like, “Eh, I don't know”. I just couldn't quite do it.
But eventually, I got RuboCop basically doing what I wanted with not too many tweaks—and again, Copilot told me what I needed to do to change it. It was pretty easy and you don't even have to get it right. You don't have to, like, Google accurately. You can just throw random stuff in there and they're like, “Yeah, we know what you're talking about”, and they fixed it for you, which is kind of nice.
Josh: Copilot, like, AI assistants are really interesting. I think for just environment configuration and setup, that's a use case that I hadn't really thought about until recently, but it seems like that's a great use case for them, and potentially gives people more options because now it is more feasible to have your own RuboCop configuration where you just kind of tell it what you want, that's what you got.
Ben: I was surprised recently, I mean, I've been using Copilot a lot for the past, I don't know, year or so—whenever it first came out in beta, I started trying it and I quickly fell in love with it.
But I was really surprised using Copilot with Ruby tests. Like, in my Rails project, I've got a controller that I just did or whatever model—I just added a new method—now I'm going over to my test, because I don't do TDD anymore—I fell off that bandwagon—but now I go to write my test and I start typing the, you know, whatever the spec, and within four characters, Copilot auto completes the rest of the test. And oftentimes two or three more tests.
I'm like, “Yes, that's exactly what I wanted to type. Thank you”. You know, autocomplete, done. And now it's writing 80, 90 percent of my tests for me. It's just—it blows my mind.
Josh: I was wondering where all those tests were coming from.
Ben: Thank Copilot.
Josh: I love it. Yeah. Thank you. Thank you, Copilot.
John: Have you actually selected a class yet? And then said, “Write the test for me”? I did that the other day. That was pretty wild. I mean, it literally—it did every permutation that I would have wanted. And I was just—this is another one of those where you just kind of raise your hands and slowly step away and you're like, “Okay, this is cool.”
Josh: Yeah. Are you both—I know Ben's VS Code user now—are you a VS Code user, John?
John: I am. I am all about standardization, obviously, other than standardization of standard RV, I need to just do that as well. Because even across projects, I like to use the same gems, the same methods, all that kind of like everything can—that can be standard. So I'm definitely for that. And so everybody uses VS Code.
It feels like a large percentage. So I just—I gave in and then I use the Adam key binding so that I didn't actually have to switch. So that’s the—
Josh: Nice.
John: only thing that's different for me.
Josh: Yeah. I use the Vim. It has a great Vim plugin or extension that I use when I use VS Code. I'm still—I’ve been in NeoVim still lately, but I'll jump back to VS Code or between them occasionally. But I've been using the GitHub—the Copilot chat plugin for NeoVim lately. I tried it in VS code and it's great.
And I wanted to try it in NeoVim and there's a plugin that someone wrote—and I think it's a third party one—it’s not official from GitHub, but the way they did the interface was really interesting, because they took a very Vim-like approach, like using the paste buffers.
So basically you can yank, like, a block of code and then I have a binding to bring up the prompt to chat and I just ask a question about it and it uses that buffer that the copy goes to—or the code goes to—and it sends that as the context to GitHub Copilot.
And then it opens up a split buffer where it puts out the response. And then I can just, like, literally go over to that buffer and continue chatting at the bottom of the—you know, just writing texts in a buffer, basically, like as if it's a file. And then it listens for hitting the return key and it chats with me, like in the file.
So that it's a very different interface from what the VS Code interface is. It fits into the NeoVim or the Vim workflow really well.
John: That's neat.
Josh: Yeah. Interesting that, depending on the IDE you use, the user interface is different, or it can be like a unique experience with some of these tools.
John: Yeah. I'm realizing now as I pair-program with people how often I use AI. I didn't notice it. And then I've been helping one person on our team with learning some Rails stuff, more frontend person, and I was like, “Uh, well, I'll just go to AI”. And I'm like, “Oh my goodness.”
As a senior, I've been doing this for 20, whatever, almost 20 years, whatever. And it's funny to catch myself how much I go over and use the generation and stuff like that. And I wonder what—I should just ask him, like, “What are you thinking when you see me doing this all the time?”
Like, do you think, “Oh, that’s smart and that's the right way”. Do you think, “I'm surprised he's using it that much”? But I've gotten lazy, because I'm like, why would I type this all myself? If it doesn't automatically complete, I just go straight to the chat and I type everything in there. I just had a two week period where I forced myself to not use Google, and now, I very rarely do.
Josh: Are there collaborative, like, is there a workflow for pair programming where the AI becomes a third person in the room or an assistant that is more collaborative? Because that seems like it would be useful.
John: Yeah, I feel like I need to watch some more YouTube videos because I see a lot of people talking about their, you know, but I don't know if they're just talking about actually interacting with it or if it automatically gets involved or—it’s not clear to me
Josh: I could see it being pretty interesting. If they, once they have, like, multiplayer, for code assistance in your IDs and things, and if you can like, you know, remote into someone else's VS Code and—or yeah, use Tuple or whatever—but have the assistant as interactive both of your inputs.
Ben: Yeah, with the recent announcement from OpenAI about their new Omni—and of course, stealing Scarlett Johansson's voice and all that aside, uh, it can be pretty cool. Like, having a—can you imagine like an avatar in a Tuple chat? So you got your three way chat going on and they're just sitting there, or maybe even you just pair with this person, right?
It's like a pair buddy without having to have an actual buddy. It's like, okay, for all your friendless developers out there, you can have an AI person in chat with you, going over your code. That'd be pretty awesome.
John: Especially if they suggested things, because I'm like—as you type, you start to get an autocomplete and that's fantastic. I love that. I don't even use the autocomplete in the editor anymore. But, as you're saying that, I'm just thinking of it literally starts talking to you.
It's like, “Bro, you're doing this the way nobody does it this way anymore. Like you do this. Oh, I noticed you're using a single quote. Can you just install standard? Like, come on, let me show you how this works”.
You know, like that would, that would be, I Sign up for that.
Ben: Yeah, I want my avatar, my buddy, to be Mr. T persona. That's what I want. “Hey fool!”
Josh: That'd be cool if you could have personas. Yeah. But you know what—you know what that kind of reminded me of, as you described it though, is Clippy
Ben: Yes, exactly. I was thinking the same thing.
Josh: It's like, pops up, like, all right, have you seen this thing? Like, have you thought about writing this method using this pattern?
Ben: Clippy enters a chat. He's like, “I see you're writing some authentication code. Have you considered using devise instead?”
John: Yeah, exactly. Yep. The downside of using Mr. T—I love that idea—but you'd have to, you know, get a “whoop!” or something and watch your stress levels because I feel like they would go up. Because like, I thought it would be hilarious back when the screaming goats were really popular to make my phone the screaming goat.
And this was back when I still have my ringer on—you know, obviously, I'd never turn my ringer on now, but I was—like, my ringer started going off and literally the cats would start growling. It scared me every time. It was not a good idea. I thought it was, it was not.
Josh: And your family really loved it too, I bet.
John: I'm sure they were, yeah, definitely not fans. I was instructed at one point by my wife: it was time to change the ringtone.
Josh: It's pretty good. I—yeah, the—all the ringtones back when like custom ringtones were the thing. I—
John: When you paid for ringtones.
Ben: Yeah, 99 cents per ringtone.
Josh: I know you can, you know, you can still pay for ringtones in iTunes or whatever it is now. I saw that the other day. I don't know why, but.
Ben: So John, you mentioned you'd like to standardize all the things across all your projects. So have you standardized your approach to blog post writing? Because you have consistently good blog posts.
John: I do. You know what? I—I actually thought about it a lot today, in preparation, just in case that question came up and I do have some standards. I didn't realize it until I like wrote out and then I was like, “Oh, I actually do the same thing every time”. And it is kind of a process but I just hadn't ever formalized it or like wrote it down.
So, yeah, I actually do a little bit. So, I mean—I can go through some—
Ben: Heck yeah. Lay it on us, man.
John: So, uh, I wrote out like a whole bunch of stuff. I figured like first, I was just talking about the way I go through, when I got a blank screen and I'm like, “Okay, I want to write an article”, which cause usually—like for you, Ben, you mentioned several weeks ago, you had this article you wanted to write.
And I feel like it's like food at dinnertime. The longer you wait, the worse it is to eat. Cause now it's cold. That’s, yeah, that's like the first tip is the second you feel like “I should write it”. You just stop what you're doing, swallow what you're chewing and start writing.
That's like, the best way. There's no better way to describe it than just barf it on the page. I'm just—like get everything out—and I don’t, you know, judge myself. I don't think about the title I don't like a lot of people start with the title and the hook and all this other stuff I've seen that from famous people and I'm like, I just can't I can't think that way I just have to like just get it all out.
So that's my first pass and usually about halfway through is where I'm like—I’m starting to see some headings, like some idea of these things could be sections and stuff like that, because my whole goal is you start with like—uh, this is funny—I didn't think about it—
I’ve never been an artist. I've never done clay outside of like, maybe a pot for my mom in second grade, but something where you start with this block and you're like, constantly reducing it down to this thing that visually is pretty, because that’s—I feel like it's weird to say that my blog posts are pretty or something, but that's really something that I focus on a lot is scannability because not everybody reads it.
And the more scannable it is, the more easy it is to read for the people who read it as well. And so that's the first step is: just get all the marble or the clay onto the page. The second step is: start reducing it into more scannable sections and things like that.
So usually about halfway through, I noticed the—oh, you were going to say something. Josh, go ahead.
Josh: I just wanted to reiterate, like, I think this whole idea of getting it on the page as soon as inspiration strikes, or as soon as you have the idea, is really key. I was talking to Chris Oliver at RailsConf, actually, and he was talking about a very similar process that he uses for GoRails, like with his videos, so, if he's like, hacking on Hatchbox or whatever, you know, uh, some Rails code or something—Jumpstart maybe, he said that as soon as he sees something that's interesting, he like, stops and he records the screencast like, right then.
And I thought that was really interesting because my approach would be to like, you know, keep like a backlog of ideas for things that are interesting that I could go write about.
But it really makes a lot of sense when you have like the energy, you know, when you're excited about something that you just learned, like that's the time to get it out.
John: Yeah, 100%. And that's a really good way to put it because I feel like, again, I used to do the backlog thing as well. And I can tell you everything that I've put on the backlog is still on the backlog. Like, I don't think I've ever written a post that I put in a backlog. The posts that get written are the ones that I just sit down and I get inspired and go to town.
Josh: Yeah.
John: Yeah, that's a really, that's a good point.
Josh: The best things I've done have been like that too. Where you just, yeah, get it out at least the first draft.
John: Yeah. Yep. So that makes a huge difference. It's just, like, have the idea, start writing it. And then the whole time I'm writing it, I'm trying not to judge myself at first at all. I'm not worried about typos. I'm not worried about things. I'll put like, almost outline stuff in, you know, so I'll be like, “Well, I know I want to talk about these things in this order.”
So, I'll just make a bulleted list and then I'll start with the first, and that kind of thing. And the structure starts to come in. I know I'm always going to have a few headings, break things up, you know, sometimes a couple of subheadings. Because. you don't want—like some people do this and I don't know how they do it, but they'll do this wall of text and I still read it.
And I—but I can't do that. I feel like if I write this wall of text, people are just like, this is boring. So I can't do it that way. I have to break it up and give it structure and stuff like that. So that's usually the first pass is like, just get it all in there as much as I can. And then after that is the editing process, which, who was it that hates edit?
It was Ben that hates editing.
Ben: Yeah, I'm the wall of text guy. I will dump it all down there and just have this big, huge, long thing. And Josh is like, “I can't read this.”
Josh: I take it and I give it the structure , and I like that, and I agree with you, John. I think the scannability is really important. I like to even use some formatting, like bold and like, you know, like setting up different sections or, you know, try to keep the narrative flowing between headings.
And yeah, so, I think that the structure is really important, especially like on the internet, like I appreciate the wall of text in some case, like there's some topics that you just need to like really dive into and you like, you know, it's maybe it's like a book or something and you're not going to have hundreds of headings, hopefully and on it.
Like actually now that I think of it, I don't like the books that are formatted like blog posts, where they have that style. I much prefer the more meaty content in the book, but when I'm reading like a blog post—and especially if it's for like, content marketing and for mass audiences—people just are not—they don't have the attention span to sit down and read like five dense paragraphs.
So I try to—I’ve taken some inspiration from Amy Hoy. She does—I really liked the way she writes and others like that. Seth Godin is another good example of like kind of short—
John: Yeah.
Josh: —and well structured thoughts.
John: He just guest starred on Billions. I watched an episode that's from, like, a year ago. Yeah. And I was in—he’s in a boardroom and he's like, “Well, you know, it's this and this”. And I was like, “That's Seth Godin!” And my wife was like, okay, whatever. She's like, I don't care.
Josh: Yeah. Well, I'm excited for you, because I’m a fan. You know, he replied to—I emailed him something I wrote once and he read it and he replied and commented on it and that was really nice .
John: Awesome.
Josh: That's the kind of guy he is.
John: That's the best feeling when that happens. But yeah, it's that—and like you said, the scannability to me is like the slide. It’s, like, the goal—people always talk about—in marketing and stuff like that—they’re like, you hook them, you know, with the headline or the title, and then the next paragraph hooks them for the next paragraph, which hooks them for the next paragraph.
And the whole goal is just to keep them sliding down the article. And I feel like that's what scannability and structure do is they just give the reader permission to skip some spots instead of leaving. So, it might be like, okay, well, this is going to be a lot to read. So, I'm just going to leave, you know, whereas if you have scannability, they can be like, “I'm kind of fading out”, and “Oh, now you're pulling me back in.”
To me it's like an engagement thing. I just know more people will engage and enjoy it and get more value from it. If I spend a little bit of time on it and it also gives it like a little design aesthetic and stuff. So I feel a little bit like a designer. And so that's the other kind of fun part about it.
And the whole time I'm doing it, I try to keep the same voice. And that's part of the reason why I try and write it when I'm like excited, because then, you know—I heard this quote and I think I just—I think it might've been on another podcast, but it was like, “Content is the transfer of energy.”
So, like, when you are writing, the person reading it—they receive energy of some sort from that, and so, like, even just at RailsConf, Jesper, who we met—it was the first time he had met me and we were about like 10 minutes into knowing each other. And he was like, “You know, I've read a lot of your posts, but we've never met before. But now I've met you and completely understand your writing style now.”
He's like, you're just the exact same, like writing on your blog, as high energy, ridiculous, like, whatever kind of a thing. And, I thought that was really fascinating to hear because I'm like, that's the almost kind of the state that I work—that I'm in when I write the post, like I don't write when I'm really bored and unhappy.
I write when I'm inspired and I want to tell somebody how awesome something is or something they can learn. And so I think the state that you're in contributes to it. And then thinking about , that same voice as you go, , so if you started and you weren't in that state and this is kind of meta, but you know, you're writing almost like a boring article.
And then at some point you get excited and you start writing it. A lot of times I'll go back up and edit the first part to be like, nope, this is too lame, my vibe has changed and this is the vibe that I always want is high energy and silly and enjoyable and stuff. Those are the first passes for editing and stuff like that.
I think that comes across, like at least one person got it. That's all that counts for me. I'm going to take it as a win and say that it did.
Josh: Yeah. That's a huge compliment to hear from someone, by the way, that your writing style matches your voice in person. That’s also—that’s a great tip. I love the tip about, if you find the energy at some point in the post, go back and bring it—hoist it basically, to the rest. Yeah, that’s great.
John: Especially, because sometimes, it doesn't happen right away. So, like, you might not start with all the energy, but then you get a little ways in and you start getting just kind of silly and excited. And so then it's like, well, you got to bring that from the beginning. They're not going to make it to that part. So you have to go back and edit it.
Josh: Yeah. Especially on some of the articles or things where it's more of an exploratory project where I don't know exactly what I'm writing yet. I think that that could be really useful because you start out—you’re playing with things and experimenting.
And then sometimes I’ll, like, actually figure it out and I start to get into a groove and figure out what I'm trying to say, and then, of course, I'm editing after that, but if you find that energy at some point in that process, you can go back and bring it back up.
Ben: So, I found when working on a code, like a big PR or something, a big change, I found if I open the PR and then go away for like a day or two and then come back and look the code again, then I can feel, you know, I feel something different about it. Either I feel more confident, like, “Okay, yes, this is right.”
Or I'm like, “Oh, you know what? I missed this bit or whatever”. So I'm curious, do you have some sort of gap between your initial content writing and then your first or second pass of editing? It's to give you that time to bake it or you just knock it all out at one time.
John: That's a super good point. Because I also have that with code. I don't do with writing at all. I forced myself to basically—because if I come back to it later, I've lost the state and I almost have to start all over. It's like when you're working on something programming wise, you've got all these variables in your head and stuff, and then you get interrupted and it goes away and you got to start over again and reload it.
And usually there's not a lot of time to write. And so I try and force through it. So, sometimes I don't do enough editing passes. And I'm just okay with that. I just know it's better to get out what I did, then have it be perfect. So, I definitely do not—I try and get it out all in one—one sitting.
And so typically, it's an hour or two, sometimes it might be three or four hours, but it's usually with like almost—I would say most of the time it's one to one to three hours would be typical for any size posts. Okay. That I ended up writing. But yeah, that's a really good point that there is. But again, it's like, you don't want it to get cold once it gets cold.
Ben: Right.
John: It's easier to come back to it if you've written out a lot. So, once in a while I will, but.
Josh: Yeah, I like to come back—I agree that it's better just to get it shipped when it's good enough versus trying to sit and edit it forever, but I do like to come back and a lot of times, I'll usually write a lot more than actually goes into the final product.
So, I'll just write a bunch and then delete. A lot of my editing process is deleting. Like, Ben probably can attest this also when I'm editing other people, it just makes the article better to delete half of it. In most cases, that's at least—that’s my experience.
I'll usually come back to it and do like a pass of that, and then maybe it might inspire some new idea or something that I further refine. Bu try not to do too many passes of that, but yeah, just a few.
John: Yeah, I think a lot of times editing is the part, like, people will either get stuck on or not do it all. Like, it seems a lot of posts out there—it’s just, like, they had a thought, they write it all up and then they hit publish and walk away. And it's like, well, you didn't think about the other person, like, who's going to read this, who's going to receive this and what would they want, you know?
And I think a lot of times—like you're saying the reduction, like if I had more time, I would have written you a shorter letter kind of style. Like, if the reduction is what makes it better. But then what you can also do is you can add more, like you talked about. So, like—and this is a common thing that I do as well—which is, put in headings, subheadings, put in, you know, code snippets, put in pictures, diagrams, like anything that I can do to support the text that isn't just more words to make it hit home a little more.
That's almost my first editing pass is, what does it look like? and then my second editing pass is okay, now it looks nice. How can I reduce the text more and look for errors and things like that. And so that's the second pass.
And then how I know when I'm done is usually I'm just—I’m sick of editing and that means I'm done. Or like, each time you reread it from the beginning, if you're only editing like a few lines, to me, that says you're done. If you've read it a couple of times and you've only changed a couple of lines, you're probably done.
If you're changing a lot of lines still, then maybe you're not getting your message across, right. But if you're only changing a couple of things, I usually feel like, okay, that means it's time to go and just hit publish and fire in the hole.
Josh: Yeah. There's definitely a trap you can, like the—just the fine tuning that you can do forever. Just like, “Oh, I don't know. Should I say it this way? Should I say it that way?” It's like, if it's a 50/50, just pick one and be done with it.
John: And I try to like, just like you said, look at it from a visual standpoint and say like where—I don't want to bold every pair in—inside of every paragraph. I try to not bold more than like three or four words and I try to only bold like, the keywords, and then I try not to go two paragraphs in a row because then ot's really—it’s like driving a red car, it's going to stand out, you know, like bold is something you kind of just very calmly add, same with headings.
You don’t—if you have only have a heading and then one sentence, that's not enough. You got to have, like, a few paragraphs in there just again. So that, visually, it feels like it flows and pulls down.
Josh: Yeah. One of my favorite bolding or formatting techniques—and this isn’t original, I don't know, I learned it from someone—but, uh, you basically don't bold the actual content that you want people to read, but bold the content right before it. So, if there's a paragraph that I really want people to pay attention to, I'll write a shorter paragraph that sets up what I'm about to say, and sometimes it'll have a colon at the end, so it's like really clear, like, this is the next thing, here's the thing that you should care about.
But that oftentimes gets people to read the setup, which makes them want to read the actual paragraph.
John: Yeah. Like a lot of times the first paragraph, first, like, three or four words in a paragraph—that’s important. That's what I'll highlight, just because it's saying—it’s funny cause I didn't write that down. I didn't think of that, but I definitely do that. I think that's a very effective way to do it.
I edit from the top to the bottom every time. If I do a significant amount of rewriting, I'll start over at the top again. I won't even keep going down, just because it's about the cohesiveness of the whole article, not about the sections. And so I try not to edit the sections individually.
Like, I try to make it re-experience, which is part of the reason why editing gets so tiresome because you're starting over and these things feel very common and fresh, but it's basically just, you know, it's like, make it more clear, reduce the number of words that you're putting in, make sure that your voice and your personality and that is in there, dad jokes, puns, that kind of stuff—ff that's your thing.
If it's not, I'm sorry that you live a boring life. So once I'm through like the second time, I just do one last visual thing that's like, “Okay, how do I feel? How does this look? I think this is good.” And then the real thing starts because you've written it.
But now who cares if you wrote it, it's about marketing it, you know? And, I know as developers that always feels terrible, but it's that dopamine thing. And you said something earlier that got me thinking of that, of—it was something I think Ben said, “Do you leave and then come back?”
And the reason that I don't leave really is because I want the dopamine hit of publishing it.. That’s all I'm looking for, is that I want somebody to engage with it, to like it, to ask me a question. And I want that critical feedback. I love feedback. And so, if I wait, then it's longer for me to get the feedback.
That's my reasoning to basically get it out as fast as possible, is get it out, get the feedback, get the dopamine hit. I immediately open up Plausible. I start watching my analytics and stuff like that because I'm like, I want to see that people got interested. And if they don't, then I'm like, “Man, I just spent three hours on this and nothing happened.”
But what I've started to learn now, is again, marketing is not always a one time thing. Like you guys were talking about last week or. A couple of weeks ago, like sometimes it's a seventh time someone sees something that it really hits them. And that's the first thing, is put it on Twitter, put it on Mastodon put it on LinkedIn.
All that kind of stuff. Think about an Open Graph image, before that, so that you can like—when people paste the URL somewhere, it'll have a preview that gives you like an idea of what the article is going to be about. If it's a code thing—again, we're all developers. So, that’s what I would recommend, is make the open graph image code. Not even close, that has been the most successful thing engagement wise for me.
If I use like a picture of myself, it's whatever, and if I use a picture of an AI generated thing, those all just look the same now, you know.
Josh: Yeah.
John: But if you put in, like, this is the key code snippet, people will be like, “Ooh, okay”. They're going to go down the slide
Josh: Yeah. They want to read the code more than they want to read the article.
John: Exactly. There's a tool called Carbon, that will make you a nice code image and stuff like that. So that's what I usually do. I'll copy the best piece of code in there that will fit in like a rectangle open graph image, and then I'll make one with Carbon and then I'll drop it. And I use ghost for editing and I'll drop it in there. Yep.
Josh: Carbon too. I like that one. So it makes it pretty easy.
Ben: When I'm looking at the Twitter feed or the Mastodon thing, and I'm seeing these images for blog posts, I know that those code snippets actually catch my eye, because a lot of times, you can see, “Oh, that’s what he's talking about”, from that code snippet, you can, it's actually, clear enough, you can see, “Oh, he's talking about this thing”, and I can say, “Oh, yeah, I'm interested in that.”
Right. Uh, you know, it's, it's a Ruby thing or it's a Terraform thing or whatever it is, versus like, well, if I saw a snippet of Java code, I'd be like, “Okay, scrolling right on past that. 'cause I don't care.”
Josh: Do you ever consider introducing a, typo or anti pattern into the code? Just for the Open Graph image.
John: Clickbait.
Ben: Nerd sniping,
John: I just—I leave invisible characters on and I put tabs in it, for the rubies. That’s—that's what I do.
Josh: Yeah, that’ll get you some engagements.
John: That's funny. Yes. Yeah. So like Open Graph images and then it's like you, you gotta—um, that’s a common place where people share links. You can very easily get, you know, 20, 30 views from there.
Start picking up some new readers, have a system where you can allow people to subscribe to updates via email. I know everyone’s, “Oh, I don't want another thing in my email inbox”, but it's not true.
People—if it's good content that they like, they want it and they want it right there in front of them. They don't want to go find it. And they don't want the algorithm, to send it to them. They want to receive it. So make that easy. Reddit Ruby is actually pretty good. For whatever reason, Reddit Ruby is more links and Reddit Rails is more like a forum.
Like, I'm struggling with this. I don't know how to do that. And I just have noticed that over the time Reddit Ruby will get reactions, Reddit Rails won't.
Josh: I think I've noticed that too. And I've noticed that it's really important to understand each distribution channel, down to the subreddit level because you're right, subreddits do have their own cultures and rules, they—everything is unique on Reddit. And so you want to make sure you're engaging each community on its own terms in a way that it expects and prefers.
And so, I've even noticed that the Rails subreddit that prefers more of the discussion forum style, like, you might want to write a little synopsis about the article and start a discussion that then links to the post that can, you know, oftentimes that'll get more stuff, more things happening in the comments and more upvotes.
And then versus on the Ruby subreddit, you might just drop the link and that's enough. And if it's a good article, it'll rise to the top. But, I think that's important. I think that's like, part of what we're talking about here is just having a distribution strategy for your content, which is really important.
And that changes depending on the type of content that you're putting out there as well. Like, you might have a different distribution strategy for a long tail SEO type article that’s—you have the purposes to get into the search engines, maybe you don't put, maybe you don't drop that one on Reddit because Reddit is just going to tear it apart anyway and say it's too surface level or specific or something.
Whereas if you have like, actual, like deeper—I call it—in our notion guide for this, I call it our deep cuts, but like the—like you were talking about last episode, like, the deep content that really gets people excited and engaged with it, that’s where you're taking it to communities and introducing it to them, whether it's Twitter or Reddit or a Ruby Flow.
Ben: I think sometimes too, the distribution can be different for the same piece of content, right? So, like, I wrote this blog post about Insights and we were launching that. And it’s a relatively fluffy piece for the technical crowd, because it didn't go into a lot of detail, right? But when I posted a link to it on Reddit, I said, “Well, this is the blog post, but here's some of the details behind the system”, right?
We use this and did that. And that was interesting to the people on that subreddit more so than just that—here’s a link to the blog post about our product, right? So, I think there's a little bit of wiggle room there. You can say, okay, maybe this could be—it’s not a direct hit on this audience, but if I give it some color or some background or something, then it's a little more interesting to them and it makes it more relevant to that community.
Josh: Yeah, I like that. You can reframe it for that community and it gives you a reason to talk about it.
John: Yeah, that's definitely something that I have done. I’ve even changed the title of the link—I’ll post the link in and they automatically fill in the title based on whatever title you use And I'll have, like, a less clickbaity title on my site Because those people are just gonna get the email and they're gonna read it or they don't but I might do something that's like a little more mysterious. Click on it either way because I'm like, look, I know this is good for you.
It's vegetables and—but you're going to like it. So just here's a clickbait, but it won't be a clickbait that doesn't deliver. I'll deliver for you, but I'm going to clickbait you into at least clicking on this. But I've noticed like audience adjustments also—like Lobste.rs. Like, you—you have to be more careful on Lobste.rs.
They're a lot stricter community, you know, Hacker News. however that works. I've definitely, you know, long time ago, had posts do well there, but generally, lately, like no one cares about Ruby there. So, you don't expect stuff, over there as much. So some of those things are good to notice.
Like, even Lobste.rs, if I post like a blog-dot-flippercloud-dot-io blog post—I could post the exact same post on johnnunemaker. com and, like, Lobste.rs community would love it. If I post it as flipper cloud, it sometimes it'll get taken off. Because they're like, “Nope, you're just promoting the product.”
Josh: Reddit does that too.
John: Yeah. So, I haven't had it happen with Reddit. I've heard of that, but it hasn't happened there. They've been more accepting. But yeah, I've definitely had it happen on Lobste.rs. You just got to know, like you said, the culture, the community, what are they okay with?
Like, don't just go in there posting all your links, get the vibe for a little while first and then it gets a little easier to—and again all of those can add up to—I mean if you're just starting out and you want the dopamine and you write an article and only your mom subscribed, you’re not gonna get a lot of dopamine, you know.
Like, but those are places where you can throw stuff in and you can get 30 views, 100 views and sometimes more and then you start to feel like okay, somebody has seen this. This wasn't pointless to spend three hours writing this up.
Josh: . Also, email newsletter, like Digests or another place—a lot of times we'll pull from those sources—so if you can, get it onto the Ruby or Rails subreddits, then Ruby Weekly picks it up if it was a good article and you get more—you kind of get some residual effects.
And I think, like, newsletters are another great distribution channel that you can actually—you should have an intentional strategy around these things if you're doing content marketing anyway—so, like, getting it picked up in newsletters is like, the next step.
John: Content marketing can be for yourself. Like, it doesn't have to be for an app or a product. It can be for yourself. One of the points that I have is, like, every good thing that's happened to me in my career is all because of my early Rails tips days and stuff like that, where—I was curious and 2006, seven, eight, I wrote 160 posts.
And so you're talking like, almost one post a week for like, three years. And I guarantee I don't become friends with Chris and PJ and Scott and them without having done that. And then also going to conferences and stuff, but it's perfectly fine to just write those things, put them out.
It's not for a product. It's just for yourself, because you might at some point work somewhere or need a better job or have a product to sell or whatever, but like, if you have people that are aware of you that know you, it just makes everything easier. It makes it easier to go to the conferences.
Because then people are like, “Oh yeah, I know you, you wrote this or you wrote that”. Same thing with open source gems and stuff like that, but I thought that was kind of interesting, to go back and look at like, the number of posts that I wrote at the beginning, like, it's easy to just not think about that and be like, you know, but that was literally almost a post a week for like, three years.
And Chris Oliver, I mean, he's a video a week for a long time, you know? And so that kind of consistency—it’s not easy, but it's very straightforward to build an audience if you consistently put content out there for a long time. It will reap massive rewards in the end.
Just don't start a business based on that, you know, like, have something else and do that on the side until that is big enough to be your thing. I think it's interesting too, though, that like, content marketing can be for you or it can be for your product or whatever. It doesn't have to be bad or thought of as just a product thing.
Josh: Yeah. Yeah. You are the product in the case of a personal blog and there's nothing wrong with that.
Ben: Yeah, I did a lot of blogging back in the same time period, 2005, 2006, and you know, people get to know you, get to know your voice. And when I then jumped into freelancing 2007, it was relatively easy to convince people I was worth hiring because like there was this whole history of, “Oh, this guy knows what he's talking about. He's been writing all this.”
And then when I started having products to sell, it's like, “Oh, well here's an audience that's already been around and they know me, they know the quality of the stuff that I've been talking about”. And so, that was easy. And then that just kind of snowballed into, “Okay, now here's a new product I'm working on and I already have this.”
I don't love the whole hustle culture, you got to build your audience kind of thing. I don't necessarily agree that you have to do that, but if you enjoy writing, it's a great way to build some reputation in the community. It's great way to build connections. Like you said, with the GitHub crew, just knowing people and opening up that opportunity for luck to happen, right, increasing that surface opportunity for those opportunities to come your way is fantastic.
Josh: Well, you know, I mean like that's how I initially met you, Ben was through your blog—I emailed you when you made a blog post about looking for contractors. But I was reading your blog because I was a reader of your blog. So, you know, we not might not be here recording this today if it weren't for your early content efforts.
Ben: There you go.
John: That's awesome. Yeah. So those are like the main things. It's just like, you know, get it on the page, edit it, slim it down, all that kind of stuff. Consistency goes a long ways. And then, there's tons of books—I mean, like I read a lot of marketing and story and copywriting books as well.
I don't read a ton. Like my wife will read a book a day. I'll read 15 minutes before I fall asleep. Usually when I dropped the Kindle on my face the first time, because I fell asleep, I'll read for like five more minutes. It's just to like, get rid of the searing pain. And then I put the Kindle down and I just drift off.
And that works for me. So there's like story worthy, like My Life in Advertising by Claude Hopkins is an old one. Oh, Gilvey on advertising, the Boron letters. It has some, you know, questionable stuff in it, but it's got a lot of really good things on like how to write, how to influence—Neville Medora has a book that's called, This Book Will Teach You to Write Better.
And that book was super simple and exactly like the title. I really like it and then there's some other ones, like, AdWeek Copywriting Handbook and Copywriters Handbook. There's a few of those that are interesting to look at too, but just find other people that are either writing about it or stuff like that, and that's an easy way to get better.
Like all the information is available to us, or just ask chat to your Copilot, how to be a better writer. Copilot might say no, but.
Josh: Reading is a great way to be a better writer.
John: And it's another easy way to build consistency. The more consistency you have in your life, again, like you said, Ben, the bigger your surface area for luck is, because it's the more days that you'll be out there and someone will have a chance to interact with you, or you'll have a chance to learn something, whether it's reading or writing and stuff.
Ben: Yeah, great stuff. Well, thanks, John. Dropping those knowledge bombs. Appreciate that.
John: Yeah. It was funny. You could just like, mentioned it and I was like, “Oh, maybe I should prep just a tiny bit”, and so, then I just literally just sat down for 10 minutes and I just wrote everything out. And then I was like, “Dang, that's kind of cool”. Like I was glad I did that.
I wish I had done it a while ago.
Josh: You're gonna have to drop a blog post now to go with this episode. You know?
John: I was thinking the same
Josh: I'm excited to do some writing now too.
Ben: Yeah. you got your outline for your blog post now. Yeah.
Josh: That's cool. I will say I did the same thing before this episode and it’s—that's one benefit of having a well documented Notion, is that we have content distribution strategies, you know, document that we’ve—that I've worked on.
And so I pulled some of those things and give us some talking points too.
Ben: So, one last thing about the combination of Notion and writing, when you're in the moment, like just this morning, I had a thing where I did this thing yesterday and no one else in the team knows how I did this thing because I was just doing it on my own. And so, I hopped into Notion, copy-pasted my commands from the terminal that I did, and here's how now, if you want to go do this thing, here's how you go do this thing, right?
And now it's documented. And if I would have waited a few days, I would have forgotten about it. That never would have been documented. And people would be like, “How'd you do that thing?” I'm like, "I don't remember. Go figure it out.”
Right? So that's another great—if—even if it's not external, even if it's just internal writing for your team, it's still great, because people want to read for your internal stuff, just like they want to read for your external stuff. They want to read something interesting, something that's crafted, something that's you have passion and interest about, and that's been well written.
So yeah, all these tips can be used even if you have no audience except your teammates.
John: It's a really good point. We had that at GitHub. We had an internal—and actually I miss not having that internal blog now. I'm sure it's not updated anymore. It's long dead, but I was, like, I still wrote while I was at GitHub. It was just more internal on PRS and on docs and stuff.
And all that writing was lost when I left, for me. I would want to go back to it. So yeah, that's the other thing that I guess to think about is like, write it internally, but then whatever, put it in a private gist for yourself or something as well. Just so you have it, if you need to get back to it, because that is a really good point.
Josh: And next time we'll have to talk about note taking and research apps. Can't get into that now. We are already at almost an hour, so.
Ben: Yeah, we got to wrap this one. This has been fantastic. Thanks for chatting with us, John.
John: Yeah. Thanks for having me. It was fun to talk about. And I love you guys just have great points every time. I feel like every time I talk with you guys, I'm like, “Oh, that's a good idea”. I got some notes here. So—not in a note taking app though.
Ben: We'll do it again.
Josh: Cool. Well, this has been FounderQuest, find us at FounderQuest podcast-dot-com and go give us a review and a rating in your podcast platform and we'll catch you next week.