Derick Bailey is the author of a number of Leanpub books, his latest being RabbitMQ: Patterns for Applications. In this interview, Leanpub co-founder Len Epp talks with Derick about his career, working independently as a software developer and producing screencasts and other content, his books, and at the end as usual Derick talks a little bit about his experience as a self-published author.

This interview was recorded on March 7, 2017.

The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly: http://leanpub.com/podcast.xml.

This interview has been edited for conciseness and clarity.

Derick Bailey

Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Podcast, I'll be interviewing Derick Bailey. Derick is a software developer and entrepreneur based in Waco, Texas. You can read his blog at derickbailey.com, watch his screen casts at watchmecode.net, and follow him on Twitter @derickbailey. You can also hear Derick on the Entreprogrammers podcast, amongst other podcasts you can find at entreprogrammers.com.

Derick is the author of four Leanpub books, Building Backbone Plugins, 6 Rules to Master JavaScript's 'this', RabbitMQ Layout and *RabbitMQ: Patterns for Applications.

In this interview, we're going to talk about Derick's career, his professional interests and projects, and at the end we'll talk a little bit about his experience using Leanpub and other self-publishing activities that he's engaged in.

So, thank you Derick for being on the Leanpub Podcast.

Derick: Thanks for having me. It's great to be here. I've been a long time fan of Leanpub, and I'm really quite excited about the opportunity here.

Len: Thanks. I always like to start these interviews by asking people for their origin story, so I was wondering if you could tell us a little bit about how you first became interested in software development. What was your first experience with a computer? And what's been your path to where you are now?

Derick: That's a three hour conversation in itself, honestly. For this, you've got to go back to the stone ages of computing in 1988, when my dad brought home a Commodore 64. It was, at the time, not the latest and greatest by any means. But it was basically something that his office gave to him, because they had a bunch of them sitting in a closet. And he brought it home, and I plugged it in.

And my mom found a programming Commodore 64 BASIC book. And a shoe box full of disks. She got all of this from a garage sale for like a dollar, brought it home to me, and from the moment I opened that book, I couldn't stop.

So I've been writing code since 1988, and doing it professionally since - it depends on how you define professionally. I've been getting paid to do it since the mid-90s. And then as a full time job - certainly since my first day out of college in the late 90s. But I've been getting paid to do it since the mid 90s.

Len: And what did you study in college?

Derick: Audio engineering actually. I was a sound recording technologies major. I got burnt out on computers when I was in high school, because I had taken literally every computer class that my high school had to offer. I was actually a computer lab technician. For my senior year, I was a teacher's aide, helping other students learn how to program.

I was doing self-directed studies for my classes. I was taking programming classes at my local college through my high school, getting dual credit for high school and college. And then after school, I went to a local shop to do hardware work. I was terrible at hardware, but I just got burnt out on software and computers and everything in high school because of all that.

I ended up going to college for my second passion, which was music, and really the audio engineering, sound recording technology side of things - I had a ton of fun doing that. All of my knowledge with software and computers and hardware and everything, directly played into the sound engineering and the technical aspects. And so I was pretty good at what I did.

Len: And how did that connection work - between knowing how to code, and knowing how to do audio engineering?

Derick: The understanding of electronics, basically. The knowledge of logic and pathways and the way information flows from point A to point B - it's hard to describe in abstract terms for me. But when it comes down to it, the ability to see the way software should work, and the way information flows through software, is quite similar to the way sound flows through wires.

Because at the end of the day, it's all electrons. And when you can get to the idea of, I am pushing electrons, ones and zeros through wires, you can sort of abstract that into the way sound recording technologies work. And just in general - you're dealing with technology. So if you deal with software, you probably deal with a little bit of hardware - at least with your laptop and monitor and things like that. And the ability to go into a recording studio and know - okay, this is an input, this is an output, these things connect together, and then the ability to wire things up - it starts to make sense really quickly for somebody that's already got a technical nature.

Len: That's really interesting. It reminds me of a Great Courses course I watched once on information theory, and there was a direct connection made in a way - I'm not putting it quite as well as you put it - but between the flowing of electrons and the management of sound information.

Derick: Absolutely. Beyond that though - there's a lot of theory around musicians being hardwired similarly to software developers. If you go back to the 1950s when IBM was first hiring programmers, they would seek out applicants that had some kind of musical aptitude. I don't know if they ever found what the crossover in the human brain really is between music and software, but there is a direct correlation.

The way people think in music is very similar to the way people think in mathematics and in software development. You'll find that some of the best programmers out there are also really good musicians. And people that are musicians have a tendency to be very technical in nature. They can easily work with computers and figure things out.

Len: It's interesting, it makes me think of - I think one of the combinations of proclivities that programmers and musicians might share is a combination of perfectionism and awareness that you're in an imperfect world...

Derick: Yeah, very much so.

Len: ...after all, so you've got to have a certain kind of temperament and you're always looking out for something you know that's going to go wrong, even though you're a perfectionist.

Derick: Right.

Len: Actually, I wanted to ask you, in the mid-90s, what was your first full-time software development job?

Derick: Full time, if you want to count an eight-to-five job, my first full-time job was just out of college. I only have an Associate’s Degree, I never finished my Bachelors, because I fell in love, and moved halfway across the country from Denver to Dallas, Texas. And I had a choice to make: basically, finish school, or go find a job. And I decided that I was tired of school. I had been tired of school for a long time, but I loved sound recording technologies.

So it was then a choice of - okay, do I find a job in a studio somewhere, or in software development? And at that point, I had far more experience in software development. And I knew that it would pay more upfront. I'd be able to earn a better living immediately doing software, compared to do working in a studio. And after I got that first job, which was in a manufacturing company - I actually worked in the marketing department of a manufacturing company, this was in 2000, right in the middle of the dotcom bust.

So I was pretty lucky to get the job I did, because we survived the whole dotcom bust with growth in the company. It was a manufacturing company making HVAC equipment. Any kind of construction in commercial buildings basically was supporting the business that I worked for, so I didn't really have to deal with the whole dotcom bust. I just rode it out at this company.

And 2006 comes around, and I have better options at other places. So I move on. But it was a good job for me at the time. I learned a lot - being my first full time job. But I - like I said, I had three yearss full-time equivalent experience - really six years of doing it part time, prior to that, working for internet service providers doing tech support, building web pages for them, doing some stuff on my own, building small web applications for small businesses. Like a realtor agency, a couple of different band websites that I did over the years. A number of different things that I did working at a local college with their intranet back in the late 90s. So a lot of different experience, prior to getting into the manufacturing company.

Len: And are you an independent consultant now?

Derick: Yes, I am. I've been self-employed for about six and a half to seven years.

Len: And was there something specific that triggered that in you, or was it just a natural transition?

Derick: Kind of both. I didn't realize it at the time, but when I look back at my early days in the mid-90s, I realize now that I had that entrepreneurial spirit, the self-employment spirit. And I was doing that kind of work. I was - like I said - building websites for a small realty agency and for bands and for various other local businesses. And I was doing that mostly on my own. A little bit of it was done through the web ISP hosting service that I worked with. But most of it was on my own.

So when it came down to it in 2010, I think it was, a friend of mine had jumped ship from the company that we worked at, and gone to work on a contract with Ruby on Rails. And about six months into that, he pinged me one day and said, "Hey, I'm looking at bringing another person onto this project doing Rails. I know you've got some Ruby experience, not a ton of Rails. But I see that as a benefit in this case, because I can mold you the way I want you to work." And so, that was really the impetus for me - jumping off of full time employment into self-employment full time. Making all my income from that, and being able to support my family and everything like that.

Len: And how do you manage being independent? I know that everyone who works from home has this challenge, and I was wondering if you have anything to say about that? What are your routines to stay productive?

Derick: My routine to stay productive is work whenever I am inspired to work. And when I am not inspired, I have to evaluate whether or not I need to get something done anyways. Like yesterday and today for example, I've spent probably four hours - I don't have it sitting in front of me, but I spent probably four to five hours adding hardware buttons to my Playstation 4 controller, because I want to be able to use different fingers for buttons that are not easy to get to.

So I have time to do stuff like that, when I know that I need a break. When I know that I am so focused, and so intensely dug deep into something that I can't really see the big picture anymore. So it's nice being able to do that.

But at the same time, it's also a huge challenge, especially when you're talking about consulting work. Because if you're doing consulting and client work, then you're billing yourself hourly most of the time. So you're trading that time for money, and if you're taking time away from that to play video games or work on hardware projects or whatever, then you're earning less income.

I'm fortunate now in that I have far less client work than my own products and services, which is kind of stressful and difficult. At the same time, it's very freeing. It allows me to have the time to go play with PS4 controllers for a day.

Len: I'd like to ask you about that in just a couple of minutes. But before we do that, I was wondering - for anyone listening who might be thinking of making a move to being an independent consultant - how do you know what to bill yourself out at?

Derick: The general rule of thumb when you first get started is to double your current hourly rate. Most people are salaried of course, so they don't know what their hourly rate is. But it's pretty easy to calculate that. Basically just take your annual salary, multiply that by two, and divide that by 1,000, and that's your hourly rate...

I'm sorry, I got that backwards, divide that by two. If you make $50,000 a year, you're basically making $25 an hour. That's right, because there's like 2,000 odd hours in a given work year, considering holidays and vacations and stuff like that. So if you're making fifty grand a year, you basically make $25 an hour. For you to have roughly the same take home income as a full time consultant, you need to work 40 hours a week at $50 an hour - instead of $25 an hour.

However, I don't really recommend doing it that way. Having gone down that path, working 40 hours a week as an independent is darn near impossible. That's more like a 60 hour work week, because there's so much overhead in managing contracts and paying taxes and dealing with the business side of your business as non-billable hours, that it really becomes untenable. When I was doing full time consulting, I tried to cap myself between 20 and 30 hours. Closer to 20 if at all possible. Which meant that I was increasing my rates even higher than that.

The highest hourly rate I ever made was like $250 an hour for some emergency part-time work over a few weeks. My average was about $175. And then for some really long term projects - I've had one client for three and a half years now, which is my only client at this point. I'm charging them $110 an hour. There's long-term stability there. I have a good working relationship with the people that I work with. They're friends of mine. It's been a way for me to have a limited number of hours, and be able to build my own products and services, but still have some cushion of client work while I'm doing that other work.

Len: Having a reliable client you get along with is actually worth a lot of money.

Derick: It is. It absolutely is. Not having to change contracts every three to six months. Not having to deal with the overhead of all of that and the time it takes. It's definitely worth something.

Len: And also, we're all human, clients are all human too, with the wonderful hothouse variety that comes with that. And you can occasionally encounter people that you don't like working with. They're basically not worth anything you're probably likely to be paid by them.

Derick: Yeah, pretty much. I've had a few of those clients, and it became pretty apparent to me how to avoid them from the get-go. They are typically the people that will nitpick and argue over inane little details in contracts and hourly rates and things like that. The people that are the most excited to work with you, and are just waiting for you to tell them what you want, so that they can say yes - those are the people that tend to be the best clients.

I've had multiple instances where I've had to say no, because I just get that bad feeling of, "Wow, these guys are really getting picky, and really getting strict." There was one particular instance where I was going to legitimately make like $15,000 for 3 days' worth of work. It was onsite training. It was going to be super simple. I had done it before for half a dozen other companies. And these guys wanted to pay me more than anyone else ever had. Which was great - until they started getting really picky about the non-compete in their contract that they used.

They basically told me in the contract that I was not allowed to be in business anymore. It wasn't intended to be that way, but they were a consulting firm doing software development for other industries, and other companies - which was my business. And their non-compete basically said I was not allowed to compete with them for any business. Well - in legal terms, they could've put me out of business just by saying, "Hey, we're going to bid on that contract, you can't do it."

Len: That sounds like nonsense. One individual operating alone, against a company that can afford $15,000 for three days of training, doesn't sound like much of a competition to be worried about, especially if they think the person's worth that much to your company.

Derick: Absolutely. And when it came down to it, I wasn't really bothered so much by that clause. I wanted them to change it, and my lawyer wanted them to change it. It's common. It's expected that you're going to have things that you want changed in the contract. But when I suggested the changes, that's when the red flags started flying.

The guy that I was working with just would not let it go. He was telling me about how my lawyer was just trying to get more money out of me, by making me do this, and talk to him more. And how they were the ones that stood to lose out, not me. Because I was only a one-person business, and they were so big. And, "No, I'm done. Bye."

Len: Switching gears, when I was preparing for this interview, I was surprised to come across something that hadn't been apparent from the beginning, which is that you created Marionette.js. Is that correct?

Derick: Yes, that is correct.

Len: I saw a hint of it somewhere, and then I saw that you wrote the introduction to a book by David Sulc called Backbone.Marionette.js: A Gentle Introduction, that's been a very successful book on Leanpub.

Derick: Yes. He's got several books on Leanpub. And they're all quite well done, and I was really happy to support him in his efforts writing those books.

Len: I was wondering if you could talk a little bit about what Marionette is, and how you got started creating it.

Derick: So the same contract that launched me into the independent life - I was working with a good friend, and we were writing absolutely terrible JavaScript for browsers. Just garbage. Neither of us could stand it. It was just a jQuery spaghetti mess. And so one day he comes to me, and says, "Hey, I'm going to spend the next week looking at three or four different JavaScript frameworks, so that we can write better code."

And at the end of that week, he came back and showed me Backbone.js. This was 2010, mind you, so this was the early days of Backbone, like 0.3. It was in use, people were talking about it, but it wasn't super big yet. And so he shows me Backbone.js, and I almost instantly fell in love with it, because I recognized the potential for building the same types of code patterns that I had been writing inside of WinForms applications in .NET for years. So the idea that I could do this in JavaScript, in the browser, and have objects that represented views and forms and user data and all this kind of stuff, and be able to coordinate it, was very appealing.

And so I started writing a lot of Backbone code. And as I do, with anything new that I'm learning, when I figure something out, when I have an idea, when I see something successful, I blog about it. And so I was writing all these blog posts about Backbone and answering a lot of questions on Stack Overflow. And that got the attention of a lot of people that were looking for Backbone consulting. So I was able to effectively double my hourly rate from that contract to the next contract, in order to do pure Backbone.js work, getting out of Ruby entirely.

And it was in the second contract, which was a property rental, vacation rental service that people use for really high end luxury vacation rentals - through that contract, I started to recognize the repetition of what I was doing in Backbone. Like, hey, I literally copied and pasted this code three times across three different Backbone views. I wonder if I could build a simple abstraction, so that I wouldn't have to do this? And just recognizing those abstractions that I was constantly using and looking for, or the patterns that I was constantly using.

Looking for ways that I could build abstractions on top of Backbone is what really led me to create Marionette. I very intentionally kept the Backbone philosophy of being a small library of useful pieces that you can put together yourself, which made a lot of people really happy, and made a lot of people really confused, because I gave almost no guidance on how to use all of these pieces. I just gave you the pieces as if you had a box of Legos, and no real instruction set to follow.

Len: And how did you build a community around it?

Derick: That kind of happened organically through Stack Overflow and my blog. People kept finding what I was writing and what I was building. And I started seeing the growth on GitHub stars and GitHub issues and feature requests. And eventually it turned into something incredibly large, something that I wasn't really able to manage on my own, and I had to start getting help from people and start pulling in additional ways of managing the community in terms of what a pull request should look like, and what features should and should not be included. And how to build and test, building a website, and getting the logo designed. And all the things that are involved in running a legitimate project, instead of just some hobby thing that I am doing for my own client work.

Len: And at a certain point, you decided to start producing content - books and screencasts, you've got email courses, you've got a webinar coming up. You do a lot of podcasts.

I wanted to talk to you about that as a single issue, because this is a big move, a big decision for someone to make in their career. What was it that inspired you to start doing this kind of thing?

Derick: It was really Backbone. It was the experience that I had in blogging, and working with Backbone. I've been blogging since 2004. Those old blogs from years ago don't exist anymore, so I don't have any verifiable evidence of that. But I can talk about the kinds of posts that I was writing back then, and the garbage that I wrote. But through the years, I developed my own voice in my writing. I was able to get some speaking gigs with various conferences in the 2008-2009 era, which led to some magazine articles which went to an actual editor. And I improved my writing style and voice and everything else.

And through all of this, I just kept taking things one step at a time - this really organic growth to the content that I was writing - until I came to, I think it was 2010 - I'm sorry 2011, maybe early 2012, when I realized that I had all of this knowledge of how Backbone and Marionette worked, and how they were built. And why I built things the way I did. And I wanted to share that knowledge with pretty much the whole world.

So I started writing what became, Building Backbone Plugins my first publication with Leanpub. I wrote a few chapters. I had a basic outline. I shopped it around to a few publishers, and didn't get a whole lot of interest. But I had a ton of interest from the community. People kept asking me the "why" questions. And I really wanted to answer those why questions on Backbone and Marionette.

So eventually I was basically just sitting at my computer one day, looking at these five chapters that I had written like a year and a half ago, going, "I either need to publish this, or just toss it out there for free for anybody to get as blog posts." That's when I found Leanpub actually. I was like, "Alright, there's this thing called Leanpub. I've seen it a few times. People have said really good things about it. I think I'm going to give it a try. If I can get a few people to buy this crappy five chapter version of this book, maybe that'll be motivation enough to finish it."

And so I published it through Leanpub, and I put it up there for like $5. And I blogged about it, and talked about it on Twitter and whatnot. And it started selling. And it started selling, and it started selling. And that was incredibly motivating. When people started giving me money for what they knew was only five poorly written chapters, that right there was a sign, "Hey, I really need to put some effort into this." And so I spent another year and a half or so actually finishing that book, and learning how to market it and sell it.

And from there, kind of as a result of that, I got connected with Pragmatic Programmers through a friend on Twitter. They contracted with me to produce screencasts on Backbone.js. I'd done audio/video production previously with college and everything, so I was familiar with how to get it done. So I went and bought the microphone that I'm currently using, which has been a beast of a microphone, lasting all these years, and sat down and made a lot of mistakes, and had to record the material three times over for various reasons.

I pushed that out there, and started selling stuff through Pragmatic Programmers. And that was really what got me started with WatchMeCode - it was the realization of, "Hey, you know what? I've got all these other bits and pieces of JavaScript and whatnot that I'm building, and I bet people would really like to see the problem that I just solved in a screencast. Let me see if I can record this, edit it, and put it up for sale on my own."

Len: That's a really well told and interesting story. I find it's often hard to get such a clear narrative from people. I find often, if someone has become say a famous film director, you're like, "How did you do it?", and they're like, "Well, I worked really hard, and then one day I was famous" - is often how the story comes out.

But I once came across Quentin Tarantino's story, where he says - normally you would think, "I was working at a video store, and then I was the director of Reservoir Dogs" - but what happened was, he had a friend whose wife had a gym membership, along with, I think, Harvey Keitel's partner. And so he gave his screenplay to his friend, who gave it to his wife, who took it to the gym, who gave it to Harvey Keitel's girlfriend - as I remember the story - who then gave it to Harvey Keitel, who then got in touch.

So it's interesting when you actually get the straight story. In your case, it's like you had built Marionette, and then you made a book that was published while it was in progress, but you realized there was a real need for the information that you had. And then you got contacted by the Prags, and then moved on to screencasting, with all the experience you had in audio engineering in the past to back you up. That's a really good story.

I've got a question about that. But before I move on, there's a blog post I wanted to ask you about, because it's so great, the story, called the obvious answer. You talk about the experience a first responder fire fighter friend of yours had releasing a child from the bars of a patio?

Derick: He had his head stuck between the bars of the railing on the patio.

So the story goes: my friend was an EMT worker. He was called out to a house one day with a child stuck in the railing of the patio. And he and his EMT crew get out there - the fire department had already been there for quite a while. They were just about ready to use the Jaws of Life to bust apart this fence, in order to get this kid out safely.

They had spent several hours attempting everything they could possibly think of. They poured oil all over the kid's head. They used industrial strength grease. They had people trying to pry the bars of the railing just far enough away, so that they could actually get the kid's head through. Nothing was working. They really didn't want to bust up the railing, because it's an expensive railing on this patio, and they would have to pay for it, essentially.

But they didn't really feel like they had a choice. And so my friend is looking at the situation, thinking, "There's got to be a simple solution for this. How did this kid get his head stuck in here?" And when he started thinking from the opposite perspective of how to get him out, and started thinking about how did he get in, it clicked, and he turns to the group of fire fighters and EMT workers.

And he says, "Alright, 50 bucks from each of you says that I can get this kid out in the next two minutes - without damaging anything, without pouring anything on him." And they're all laughing at him, going, "Yeah right, whatever." And so they're all like, "Yeah sure, okay - you're on." And so he walks over to the kid and says something like, "Hey, I have one more thing that I want to try, before we break out the Jaws of Life and tear apart the fence to get you out of here. But before I try this, I need you to turn your body sideways and step - push your body through the railing, so that I can try what I'm going to do."

And so the kid turns his shoulder down, puts his shoulder through the railing. And oh look, his head's not stuck anymore. What had happened is, the kid had tried to go through the railing to begin with. He got his body through the railing, but his head was too big to fit. And so he was struggling, pushing against the rail, trying to get his head through, and freaking out, because his head was stuck. He couldn't get his head through. And so in his panic, he didn't realize that his body is what fit through in the first place. He thought his head was stuck.

And so his mom calls 911, and EMT and fire department and everything come out. And in reality, it wasn't that he couldn't get out, it was how he got in that ended up creating the solution.

Len: That's just such a great metaphor for something that - I don't know what it is yet, but, you see the kid with his head stuck, and you just naturally think, "He's stuck, he got his head through there." Instead of, "He backed in. He got his body through there."

Derick: Changing perspectives like that is that is incredibly difficult to do, but often so important. If you can ask the question from the opposite perspective - not, "How do we get him out?" but "How did he get in?" - and then the answer can become obvious in some cases.

Len: In philosophy, there's this idea of looking for the necessary conditions for the possibility of what's in front of you, which is one way of approaching problems. How did this happen? What has to be true in order for this problem to exist in the first place? Another way of looking at it too is, what would have to be true in order for me to be able to solve this problem?

Derick: Yeah.

Len: And so you can actually start with the answer, rather than starting with the problem. And that's another way to get to a solution.

Another interesting post you had, was where you talk about the purpose of the job interview. This is a subject that generally comes up on this podcast from time to time. I was recently interviewing an author named Erik Dietrich, who wrote in his book about the origin of the modern job interview.

And it was from Thomas Edison, who didn't like the fact that so few of his employees shared his knowledge of trivia, which he sort of generalized into, they're bad employees. So he created a questionnaire. And then people found out about this, and that's what morphed into the modern job interview, including riddle asking and stuff like that.

I was wondering if you could talk a little bit about what you say about what's going on in a job interview - what your real goal should be when you walk into one?

Derick: The gist of it is - every job you have is not there because you were the most technically skilled person. More than likely, you're not getting the job because you are the most technically skilled, most qualified person from a technical perspective, but because the people who did the interviewing with you, who talked to you and who you sat with - those people felt that you would be a good addition to the team.

Now there are going to be other cases where they literally just need the most technically skilled person, and they hire that person no matter their personality. But most of the time, you're dealing with human beings. And human beings deal with relationships. They don't deal with technicalities in a team environment. So when it comes down to interviewing - yeah, you need some technical skill for whatever the job is, but ultimately, the point of the job interview is not to convince the interviewer that you have the skills necessary from a technical perspective. The point of the interview is to convince the person doing the interview that they should call you back and continue the conversation.

It's similar to marketing, quite honestly. If I'm sending an email - if I'm launching a book, let's say - and I want to get across five different points about what's in this book, I don't send a single email with five bullet points of, "Here's the things in this book."

Instead, I send five emails at least - probably more. I send at least five emails. Each email will talk about one major thing from the book, one of those five points that I want to get across. But the email will be set up in a way, so that by the end of the email, the person reading it will not only know about the thing that I wanted to tell them about, but they will also have been introduced to the next topic, in a way that makes them curious, in a way that makes them want to read more. So that when I send the next email, they will be more likely to open it, and continue reading it.

And the same thing happens in a job interview. You are essentially marketing yourself. And you're marketing yourself to the company that potentially wants to hire you. So what you need to do in these job interviews, is not go in there with data sheet after data sheet of all your technical skills. Yeah, you're going to need that in your resume. But what you really need to do is go in there with personality and experience and stories and relatable, understandable humanity, so that you can get yourself ingratiated with the team. And the best way to do that is to become friends with the people that work at this company, long before you actually go in for the interview.

Len: You reminded me of something. Speaking of email and marketing, and relatable humanity, you had a recent experience - I was listening to a podcast from the Entreprogrammers podcast, where you sent out an email blast that included a free coupon code or something, that you sent to everyone, rather than a specific segment.

At Leanpub, we send out email blasts too. And everyone who does this has that moment where the hand shakes before you click. And you had an experience where you clicked, and it merited a bit of a shake.

Derick: Quite a bit of one.

Len: If you could talk a little bit about that, just so those of us who are engaged in this kind of activity, we're on a similar boat -

Derick: That was less than a month ago, or approximately a month ago at the time of recording this. I was putting on a webinar, and I had three segments of people that needed to know about this webinar.

The first segment was my general segment in my mailing list, of people that should pay to get in. The second segment was people that had bought the pre-release of my upcoming ebook. (Which, by the way is also published on Leanpub - not yet published, but in-progress, will be published on Leanpub.) Those people should get in for free.

And then the third segment is the annual subscribers, annual members of, WatchMeCode. My annual members get everything for free. Anything on the site anyway. Sometimes I do live stuff that they have to pay for. But as soon as it goes up on the site, the annual members get in for free.

So I sent out this email with all of this crazy, awesome, whiz-bang, liquid template code inside of my email, using getdrip.com. My email service provider, my mailing list service - I spent like two hours formatting this email perfectly, with all of the right code in there to make sure that the right people saw the right information.

It read perfectly fine. Everything was great when I sent the preview emails to myself.

What I didn't check was the actual link that I included in each of those three segments. And I had mistakenly copied and pasted the link with the 100% off discount coupon from one of those segments into all three of them. So I sent out an email to 7,900 people, telling them about this webinar that I was going to be doing, and giving every last one of them free access - instead of just the two segments that should've had it.

Len: And then when you sent a correction, that -

Derick: Yeah, it gets better...

So, I'm a little bit OCD when it comes to sending emails. I read every email that I send. So I opened up my email, I clicked on the link. And I immediately saw the mistake that I had made. So panic ensues. I try to think of what can I do to mitigate this situation, and I realized the best course of action is to disable that discount code. So I hop onto my website, disable the discount code, immediately go back over to Drip and send an email to the two segments that should've been able to get in for free.

Correction - to the one segment that should've been able to get in for free using this discount code. And I tell them, "Hey, sorry about that 'bad link' in the previous email. Here's the corrected link." And I screwed up the corrected link. So I sent out a second email saying that there was a bad link, but it was wrong. So that means I had to send a third email going, "Holy crap, I'm an idiot. I can't email to save my life. If you get to the sites with this link, and it still doesn't work - just put in this discount code."

Len: I think we've all been there, at least in our imagination or our fears.

Derick: Everybody fears doing it, that's for sure. And I'm the guy that did it.

Len: I wanted to ask if there's anything you've changed in your process since then? I mean, maybe you haven't done it again. But what do you think one can do to mitigate email risk like that?

Derick: There's a couple of different things. First off, make sure you check every last link that you send out, if you're including things like discount codes. Just verify - have a checklist. Build that checklist. Like, I wrote the email, I included the links. Now I am going to send myself a preview email, and I'm going to click the link, and I'm going to email the checklist of things you need to do to make sure that it's correct.

A friend of mine also recently launched a service called Send Check It. His service essentially allows you to send your preview email from MailChimp or Drip or whoever you use. You send it to a special email address at his service, and it will do a lot of the error checking for you. It'll make sure that your links are actually going to a valid page. It'll make sure that you don't have, "Hello star bar f underscore name bar star," the kind of templating tags that services use. It'll check for missing images. It'll check for a swath of different errors that are very common in emails.

So between my own very checklist-oriented mind now, making sure that I have the right link for the right segments, plus using Send Check It, it turns out to be not that difficult to prevent these errors. I'm also changing up the way I do my marketing for my webinars, and I'm not giving people free access anymore. So that also makes that specific scenario a little bit easier.

Len: Normally the final thing I like to talk about on these interviews is your experience self-publishing and using Leanpub. You've already described a little bit about that within this book, and I was wondering if you could talk a little bit about marketing? This is something that all self-published authors are interested in. I mean, I know that you've spoken at conferences, and you've developed something on your own called Marionette. What other things do you do to increase your profile and get your books in front of people?

Derick: The number one thing that you need to do, if you think that you're going to have something you want to sell five years from now, or if you've already built it - well you're a little behind in the game. But if you have something to market, or you know you want to market something at some point in the future, the number one thing you need to do is build your mailing list. You need to have a way to get people's email addresses into a mailing list with getdrip.com or MailChimp or whatever email/mailing list service you want to use. But that is absolutely 100% the most important thing to do.

Because those people on your mailing list - those are the people that have already told you that they want to know more about what you're doing. And those are the people that are going to be the most likely to buy whatever product or service you happen to be selling.

Beyond that, marketing is the biggest challenge that I have in my career right now. I am terrible at it, in spite of the successes that I've had. More often than not, I've stumbled into success, instead of engineered success. I'm working to correct that, constantly improving what I'm doing in my marketing efforts. But unless you have that mailing list, you're going to have a very hard time selling products.

Len: Actually that reminds me - you had another post recently, speaking of challenges one faces in what one's doing, especially when one's very independent. You had an issue with focus, where I think what happened was, you started to really question what you're doing, just generally. I think we all face that from time to time.

In your situation, you've chosen this very independent path. And so a crisis of focus can be perhaps more difficult. I don't know? Maybe easier, but it's unique to be independent and then facing a crisis of focus. I was wondering if you could talk a little bit about what that was like, and how you came through it?

Derick: It's an incredible challenge, the focus. Because as a software developer working for a company, you really only need to care about what's the next feature that the project manager told me to work on. Or, what's the next bug that I'm fixing? Or what's the next framework that I need to be researching, so that I can implement these features? It's a very singular-minded focus. It's all the technical, the implementation details. The software side of things.

But as a self-employed person, now I need to focus on the implementation details. Because I still write software. But I also need to focus on the features. Because now I have to gather requirements from my clients. And now I need to focus on the business. Because I need to make sure that I am going to actually get paid, that I'm going to have another contract when this one ends. That I'm going to have all these different things.

And now I am selling products and services on my own. Well okay, great. Now I need to introduce marketing to the list of things that I need to focus on. And when I wrote that post on focus - I think I was running three separate businesses. I had my consulting business, I had my WatchMeCode business, and I had a podcast hosting business.

Ultimately, I ended up shutting down the podcast hosting business. Not because it wasn't viable. I still believe that it was a viable service. And I have seen a lot of great podcast hosting services pop up in the last year or so. And so I know that it is still a viable business. But I had to choose where I was going to place my focus. And I chose to drop the podcast hosting, so that I could grow WatchMeCode, and grow my business as a singular thing, instead of being ripped apart in three different businesses, which each have six different concerns that I need to deal with.

Len: And did you have colleagues, people who've chosen a similar path to yours, that you could consult with during that time? When you were thinking about, what should I do?

Derick: That's the Entreprogrammers podcast. That is our mastermind group. If you're not familiar with the idea, a mastermind group is basically entrepreneurs that get together virtually or in person, usually once a week, sometimes less, sometimes more. But typically once a week, to talk about their struggles and bounce ideas off each other. And just generally to be a support network. And I just happen to be fortunate enough to be able to broadcast my mastermind group to the world, through the Entreprogrammers podcast.

We are all very open about what we do, and the struggles and triumphs. And that's really the unique angle that we have for our podcast, is we share everything about our business with the world. Success and failure and struggle and otherwise. We're not just there to talk about the happy path, and how things are great. But to really show people what the entrepreneurial life is like.

Len: My last question is, if there were one thing we could build for you, or one thing we could fix on Leanpub, what would that one thing be? Is there something missing?

Derick: That's a tough question, honestly. I think the one thing that might still not work correctly, from seven years ago when I started using Leanpub, is backmatter.

The backmatter tag doesn't work, to the best of my knowledge. I would really like the backmatter tag to work.

Len: And what would you like it to be doing specifically, so I understand?

Derick: Well, frontmatter gives me the ... introduction. And it uses Roman numerals and things like that. Then there's the mainmatter, which is your chapters and sections and stuff like that - chapter one, chapter two, chapter three, with actual page numbers. Backmatter is typically your index and your appendices. And I want the appendix A, appendix B, appendix C - the typical numbering of back matter.

Instead of continuing Chapter 37, appendix A. It should have its own numbering scheme, which is what I thought back matter was supposed to do, back when I first started working with Leanpub. But there was a bug or an undefined feature or something. And it just never worked. I don't even know if it's documented anymore. It used to be documented, and it was a known problem.

Len: If that's not working as documented, then that is something we will definitely look into fixing.

Derick: I honestly don't know if it's still documented. Maybe it was a feature that Leanpub decided to kill?

Len: No, no it's still there in the manual, so thanks for pointing that out. I mean, whether it's been fixed or not, there's obviously something at least about messaging that we need to fix with that.

Derick: Yeah.

Len: I wanted to say, thanks for a great interview, Derick. We covered a lot of ground, and it was really interesting to hear about your path, and how you've got to where you are. So, thanks very much for being on the Leanpub podcast, and for being a Leanpub author.

Derick: I really appreciate it. I absolutely love Leanpub. As I said before, I've got the four books published there. I don't mind sharing my numbers. My Backbone Plugins book alone brought in more than $20,000 in revenue for me. That's after fees and everything else that goes to Leanpub. That's a phenomenal amount of income over the years, where that book was really a viable book in the marketplace. I'm working on my next ebook, which is going to be about developing Node.js applications in Docker. I'm expecting that to do really well on Leanpub.

My two RabbitMQ books are extremely popular these days. They are widely considered to be two of the best RabbitMQ books out there. And I'm extremely happy to have published it through Leanpub, because Leanpub makes it so incredibly easy for me to write and publish these books.

Len: Well, thanks for the kind words, and best wishes on success with your new book, and all your new projects.

Derick: Thanks for that. And thanks again for having me on the podcast.

Len: Thanks.