Leanpub Podcast Interview #44: Cal Evans

by Len Epp

published Jan 24, 2017

Cal Evans

Cal Evans is author of five Leanpub books, Signaling PHP, Iterating PHP Iterators, Going Pro, Culture of Respect, and Uncle Cal’s Career Advice to Developers. In this interview, Leanpub co-founder Len Epp talks with Cal about his career, his books, and his experience self-publishing on Leanpub.

This interview was recorded on September 15, 2016.

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.

Cal Evans

Len: Hi, I’m Len Epp from Leanpub and in this Leanpub podcast, I’ll be interviewing Cal Evans. Cal is based in Jupiter, Florida and has been working for the past 15 years with PHP, MySQL on OS X, Windows and Linux. He’s worked on projects of widely ranging size, including multi-million dollar applications. Cal also builds websites and is a popular conference speaker, delivering both talks on technical subjects, and also motivational speeches. And I believe he also likes bourbon, so if you ever see him at a bar, please feel free to buy him a shot.

Uncle Cal's Career Advice to Developers

Cal is author of five Leanpub books Signaling PHP, Iterating PHP Iterators, Going Pro, Culture of Respect, and most recently, Uncle Cal’s Career Advice to Developers. A little bit later, I’ll be asking Cal some questions about his books.

In this interview we’re going to talk about Cal’s professional interests, his experience self-publishing using Leanpub, and ways we can improve Leanpub for him and other authors.

So thank you Cal for being on a Leanpub podcast, and for sitting through that intro.

Cal: Not a problem, I’m happy to be here.

Len: I usually 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 became Cal Evans.

Cal: Sure. But before I say that, you listed the five that I actually have released. You skipped over the like 10 books that I’ve started, and never released - including such developer-centric books as “Oh crap, why did I do that?”, reviewing my old code. But no, back to my origin story.

I started programming when I was 18 years old. That was way back in the early 80s. I started programming, I got married the same year. You know what that means. I ain’t going to lie. I got married. I got a computer. I spent all my time programming, because I’m a geek.

I started working on a Commodore 64, and all of a sudden I discovered that people would pay me to do this - and it was surprising to me. So I started coding for a living. I’ve had various other career paths, short career paths.

I used to do live concert videos. I used to direct and edit them. And at one point, I ran a printing company - but old school, offset press. But for the past 15 years I’ve done MySQL and PHP. And for the past 10 years, my focus has been on developers, building better developers. And that is my goal, to help people become a better developer.

On one of my profiles, it says “I don’t want to change the world, I just want to help you become a better developer.” So, that’s what I am. I’m old school. As long as people still keep paying me to do this, I’ll keep doing it.

Len: And what are you working on currently?

Cal: I am the manager of training and certification for Zend. So I handle, amongst other things, the official PHPs, or the official Zend PHP certification: Zend Certified Engineer. I also manage the team that built all the training, and builds and delivers all of the online training.

And then, of course - like every good developer, I have in addition to the books, a couple of side projects. Nomad PHP, which is - we get together twice a month now, we have two meetings every month. We get developers together online, and I’ll have a conference speaker come online and give one of the conference talks, because not everybody can make it to a conference. So we get together and we do this twice a month.

And then three or four times a year, it really depends on my mood, we will do what we call Day Camp 4 Developers. I get five speakers, and we all get online and we’ll have teams get online, throw it up on a projector, order pizza. And we’ll just spend the day focusing on one topic. Recently, we’ve done modern techniques for building applications in PHP, things like that. So, those are my side hustles.

Len: And how did you get into conference speaking in the first place? I’m interested to hear about that.

Cal: The very first time I was ever asked to do a conference talk was, I believe, right around 1995, and I was doing FoxPro, and I was so scared that I actually told them no, I can’t do it. And I went on to do one the next year, but I co-presented with somebody. And then, I just kind of ignored it. It wasn’t really interesting to me, until I went to work for Zend the first time. This was in 2005, I believe, and I was the “community guy.”

We didn’t have developer relations or developer advocacy or evangelism. I was just the community guy, and I was going a long right nicely. I built a website for Zend called “Dev Zone,” and I posted on there. And all of a sudden, my boss calls me and says “Hey, in three weeks Apple is having their Apple FileMaker conference in Orlando. There’s going to be 1,500 developers there, and you’re the closing keynote.”

Okay. So I had three weeks, not only to put it together, but to get my head around the fact I was going to get up in front of people. And let’s just say I was not awesome, okay? I still don’t think that I’m awesome, but I really feel that I shortchanged these people for what they had to pay to be there. But I did survive it.

Len: And did you do any kind of reading about presenting or speaking anything like that? Or did you just jump right in?

Cal: No, no, no - I’m way too arrogant for that. I’m a developer, I don’t read the manual. So, I just figured that I could do this, and I put together a presentation. I put together a demonstration, because this was FileMaker and this was when Zend and Apple had worked together to build the gateway for PHP and FileMaker. And so I put together a little thing using the now-defunct Netflix API. And it was really fun, and I learnt my very first lesson of presenting at technical conferences. Which is, “If your presentation requires the internet, make sure you have backup slides because when I -“

Len: Oh my God, yes.

Cal: - when I did my run through, while everybody was at lunch - man, everything clicked. It was wonderful, because I had the entire network to myself, because everybody was at lunch. I get up to present, and I go in there - and there are no IP addresses left in the network, and they didn’t have a dedicated speaker network, so I had no internet whatsoever. So, I would point and describe and say “If we could see this, you’d say ‘I got to get me some of that,’” so -

Len: I’ve done a fair amount of pitching. And yeah, you learn very quickly that you need to have all the equipment with you. I think I ended up with like a 24-foot HDMI cable, because the situations that you find yourself in, are so totally unpredictable. And you don’t want to be caught unable to do what you came there to do. Somehow the tech becomes your responsibility.

I was wondering - you talk about, on your profile - about “management by walking around.”

Cal: No, no, no, no, no. “Management by walking around” was either Hewlett or Packard. That was what they were famous for. Mine is “Management by wandering around.” Vastly different, vastly different.

Len: Sorry, I got that wrong. Can you maybe explain the difference to us?

Cal: I ran a team - when I coined that phrase, I was running a team back in Nashville, Tennessee. And this was - this sounds so stupid. It was around the turn of the century. And I had put everybody in cubicles. So I had these really high cubical walls. I tried to give them as much privacy as possible. And I realized that even though I had 15 people working on three different teams, and the team leads knew what was happening, I wanted to get a feel for where everybody’s head was.

And so literally, I would wander from cube to cube. And I don’t mean down the line. I would go here, and then I’d go visit her and then him. It’s all over the place. One of my developers brought in two buckets of Legos, and that’s how they would think problems through, was play with Lego. Usually if you couldn’t find me, I was over there at their desk playing with the Legos.

But that’s what I started doing, and I learned that I can spend five minutes with somebody without interrupting their flow. Because if I see them in the flow, I’m not going to bother them. But I can spend five minutes with somebody, and if I do that every two or three days, I know where everybody’s head is, and I can take the temperature of the team.

My team leads knew the project, and knew how things were running and all that - I wasn’t worried about that. I wanted to make sure I wasn’t burning people out, that people were feeling good about the project. Things like that.

Len: In your book Culture of Respect, in addition to finding and hiring people, you talk about keeping them. I was wondering if you could talk a little bit about what you say in that book about, How do you develop a good culture? What is a good culture for keeping developers in the medium term, or even the long term in your company?

Cal: Really I talk about that? I really need to read that book! No, I’m kidding. In line with the “management by wandering around,” one of the things that I am just really huge on is - I didn’t realize there was a term for it until later - what is called “servant leadership.” I was the first person into the office most days. I was the one that fired up the coffee pot. We worked right next to this huge Target Superstore. And so, I would go over to Target once a week, spend 50, 60 bucks on candy - and I had bought everybody a candy jar. So, on Monday mornings, I would wander around. And if your candy jar was empty, I would take your candy jar, take it back to my desk, and fill it up, and put it back on your desk. And I made sure that there was always coffee made.

That team - I’m not proud of the fact - but we got to the point where we were behind the eight ball, and we worked some long hours. And there’s only so much pizza that one human can consume. So I started catering in from some very nice restaurants in the area. And my food bill was three, four thousand dollars a month, for about two months while we were doing this. But I was asking a Herculean effort from these people. It was important to me that I showed them that kind of respect.

I also sent flowers or appropriate gifts to all of their significant others. When the project was finally finished, everybody got gift certificates. I think most of them were to The Melting Pot a high-end fondue restaurant, enough to cover a nice meal for two, and things like that - to show not only them, but their family and their significant others that me and the company really appreciated what they were having to go through.

Niceties and little things like that, that’s like a having a foosball table or a kegerator - it’s not going to make the difference. But the respect - the fact that I took the time to do this. I didn’t say, “We need to go do this.” I didn’t assign somebody to do this. I took care of making all these things myself - to show them that I respect what they do.

And quite honestly, that was a team - we were running Java and Oracle, and I know a little PL-SQL, and I can read Java, but I couldn’t do their job. I couldn’t dive in and help them. So, I did the next best thing. I tried to take care of everything else. That was also the office where we had two doors into the developer area. Both of them had combination locks on it, and if you weren’t a developer or my direct manager, who was the CIO, you did not have the combo. Even the COO and CEO had to be escorted in and out.

Len: That’s really interesting. I’ve never heard of having locks like that. But what a comfortable space that probably provides for people. Knowing that you can’t suddenly sort of look up, and there’s the CEO wondering why you’re playing with Legos. And then you’ve got to explain.

I was wondering, approaching the subject negatively - can you maybe talk a little bit about the worst workplace culture you’ve seen or worked in, or - I was going to say the worst example - the best example of poor management you’ve ever seen?

Cal: It’s funny, because I’ve actually got a blog post on my blog called “Good Boss…Bad Boss”, in which I break down four of my bosses. Two of them were my mentors, and two of them were Satan incarnate.

One of them was - I was working for my parents’ company. I’m the boss’s son, so it’s obviously not a great situation to begin with. But I’m the only computer person in the entire company of 40. I’m the computer guy. And we were using an accounting system – I believe at this point we’d migrated to FoxPro system. But the sales manager kept saying, “These numbers don’t look right, these numbers don’t look right.” I said, “You’re saying these numbers don’t feel right. I can show you the line items where this data is coming from, these numbers are right.” And she looked at me in front of everybody and says, “I don’t think you’re a good programmer. I don’t trust these numbers,” and walked away.

Even though I’m the boss’s son, there’s limits to what one person can put up with. It was at that point I decided it was time to make a career change, and get out of the nest, move out of mom and dad’s company. I had enjoyed my time there, but it was time to go. That was the absolute worst, because this person had no concept of how to treat people. This person was an old-school command-and-control manager. I don’t know anything about managing accountants or sales people. Maybe that’s how you manage them? You don’t manage developers that way.

I’m famous for making enemies by saying “If you’ve never been a developer, you have no business managing developers.” And this person had never managed a developer. They didn’t understand deadlines or anything like that. And so it came through, and they were a horrible manager.

Len: Yeah. It’s interesting. I was talking to an author named Janelle Klein recently on this podcast about issues around this, at a theoretical level like that. One of the images I like to use to convey the difference - not having been a developer myself, I mean I was kind of hazed by having to internationalize Leanpub when I started - is that, a lot of management practices are actually based, since ancient times, on visual cues.

So as a manager you can just, whether it’s stacking bricks for the pyramids, and you’re working with people under horrible enslavement, or bricklayers in Victorian times, as a manager, you can stand and watch, and you can see progress - are the bricks getting stacked? But with developers, that’s completely gone.

All those ancient instincts about ways that - whether they were ever good or ideal or not, did work. All those ways of managing people, like watching what they do, just completely blows up when your “worker” sitting in front of a screen typing away.

I mean, even if you do look at what they’re doing - and I’m just sort of supporting your point - if you’ve never been a developer, well you have no idea what you’re looking at.

But there’s other things you won’t understand as well, like - say they’re on Slack. You don’t go like, “Get back to work, guy.” That’s work. Hacker News, that’s work. Facebook, that’s work. You want your developer to have a wide net of information that they’re receiving and engaging with all the time.

Cal: I had another manager when I was working in Nashville that - this was my last FoxPro job, and he had been a FoxPro programmer. But if you don’t know FoxPro - FoxPro started off as a procedural language, and morphed into an object-oriented language. It’s a wonderful way to learn object oriented concepts. Because I already knew the language, I could control the concepts. He considered himself a very good FoxPro programmer, but I was an object-oriented programmer, and he considered me just a little better than him.

Well, he gave me this task to do, and it took me about two weeks, because this was some deep stuff, it was a compiled language - we did nested inheritance, and all this. Because you didn’t pay any penalties for it at that point.

And so, I was digging through this legacy code, and rebuilding it. And he came up to me one day, and he’d just had enough. It was a Friday. He needed to blow off steam. So he yelled at me for two hours.

Because he asked me “When’s this going to be done?” I said, “I have no idea.” And so he yelled at me for two hours. And I went back to my desk totally energized, okay? Because I was feeling the burn at this point. And I finished it up about an hour and a half later. I finished the project up. I didn’t know that was the point. But he had no concept. Even though he was a developer, he was the old command-and-control, “You do what I say, work harder.” That kind of stuff. Of course, I left that company. And I was told that six months later, he was escorted out of the building by security. HR had him escorted out, because he explained to a female business analyst that he could train a German Shepherd to do her job.

Len: Oh my.

Cal: Yeah. We all got a kick out of that. We got together for a developer reunion one day, and we all got a kick out that one.

Len: Wow. I guess it’s easy to judge from a distance, but if people have one flaw - I mean we all have flaws - but if a person has one kind of flaw that manifests itself in aggressive behavior, they might have others.

On that note, actually in the book Culture of Respect, you talk about building a character sheet for potential hires, like you would playing Dungeons & Dragons, and I found that really interesting. I was wondering if you could talk a little bit about that idea and what the division is between what you call soft skills and hard skills.

Cal: You know, it is like Dungeons & Dragons. I’m so deep into marketing, that these days it is a persona that you build. But no, it’s a D&D character sheet that you are building. And this forces the hiring manager - not HR, okay? I’m not a fan of HR. In my entire life, I’ve met one person who works in HR that I did not absolutely hate–and she did get on my nerves sometimes. But the hiring manager has to sit down and think through, “What do I really need this person to do? And what are the skills I’m looking for, and what are the traits I’m looking for?” Because there’s a huge difference.

Skills are hard. Can this person code in Java? Can they do C++? Can they do PHP? This kind of stuff. Traits are: Can they communicate their ideas with others? Can they have other people communicate their ideas to them? Because I’ve worked with developers who could tell you exactly what they were thinking, in ways you could understand. But if you explain to them that they’re off base, and you need them go this way - they would go ballistic on you.

So those are the differences, and I urge managers to sit down and think it through. Because if you don’t, what you end up with is what we call the “kitchen sink” job ad. “You need 15 years’ experience in PHP 7.0 or better. You need Photoshop, you need HTML, you need to be able to stand up your own Linux server.” All of this stuff. Which sounds real great - but really all you needed somebody to do, was to manage this application that you’ve got running on a server - or maintain this application.

So, think it through, don’t ask for everything and - I rail against HR, because HR usually likes to add things in. “This job requires Photoshop.” Well no, it’s a developer. He’s working, she’s working in a command line. There’s no Photoshop equivalent of the command line. So no, we don’t need this person to be able to do Photoshop. “Well it’d be nice to have.” No, not really, it wouldn’t. It’s just going to limit the candidates you get.

To those people - honestly, if you’ve got a kitchen sink ad - you’re not going to cast a wide net and get everybody. What you’re going to get is those people who will apply to anything. Because the people that you actually need, see all of that and understand you have no concept of who you actually want, and so they just pass over.

Len: I’m curious about your thoughts about interviewing people. Once you’ve got the ad out there, the proper ad, you’ve managed to fight off HR from corrupting the process - and there you are in the interview with the person. I was just curious about what some of your thoughts are, about what to do and what not to do.

Cal: There used to be a site, a long time ago, called Freshmeat. It was a sister site to Slashdot. I hope people still remember Slashdot. I actually wrote an article for Freshmeat one time called, “Nerd Herding” - it’s now up on my blog - and I talk about this very thing.

My process is this. I put out the ad, I do work with HR. We get the legal requirements covered, but I don’t let them add things like skills and traits and all this.

I get the ad out there, I get the resumés unfiltered. HR can’t tell the difference between Java and JavaScript. I need to actually see them. And I’d filter through them - I was hiring one time out in California, and I’d get 150 resumes a day, and I would pick 20 - and this was just posting on craigslist. I’d pick 20 out of that, that seemed reasonable, and I would fire off an email. I don’t go for trick questions, but I’d go for questions that cannot be easily answered. They’re going to require some thought.

I would say, “Hey, I got your resumé. Thank you. Why do you program?” - things like that. I would look for some insight to the person. Honestly, if they gave me anything at all, that would usually warrant a phone screen. So, that would usually filter about half of them. So out of that 150, I got 20. Out of 20, I got 10 people that I would sit down and call. I would talk to them on the phone for five or 10 minutes, and just get a feel for the person. I already know that the person has the technical skills - or at least is saying that they have the technical skills. And I know that they are a little bit insightful, because they responded. I just want to talk to them.

But out of the 10 people that I would talk to on the phone, eight to 10 of them would usually end up in an interview with the team. At that point, I turned it over to the team. I told everybody I hired, “I don’t have to work with you, I just have to manage you. These are the people you have to work with, they’re the ones that you’re going to have to impress.”

So we would do the team interview. I would call everybody into the room. This is a very expensive way to interview, but it’s still less expensive than making a bad hire decision. I would bring everybody in, juniors up to my architects. We’d sit down in the room. I would not say a thing after I introduced the candidate. And they would go around the table, just asking questions. As long as it was legal to ask the question, there were no filters that I put in place. And they would ask until they got finished. I didn’t stop them.

I think the longest one was an hour and half, and we were literally interviewing a rocket scientist. He worked at - what is it in Huntsville, Redstone? Anyhow, he worked at the NASA Center there in Huntsville. He was literally a rocket scientist, and it was fantastic. We ended up hiring him, he was great.

Then I would thank everybody. I would escort the candidate back out the front. The team would stay there, and then we’d sit and talk. “What would you think?” You think this, you think that. And then we would take a vote, right then. While it’s fresh on everybody’s mind, I’m going to take a vote.

If I had one person say “no,” then immediately, that candidate is no longer viable. Now that seems very harsh, because you’ve got junior programmers that have the same weight as my architects, and the juniors had to go first. I didn’t want them “me-too-ing” one of my senior developers. So we went around the room, everybody got a vote in hiring over 50 people in this way. I had two that we just walked away from, because somebody voted “no”. Because by the time you get to that point, everybody is either “yes” or “no, this is not going to work.” When I say I had two we walked away from, I mean we had two we walked away because we had one vote “no.” Usually, it was pretty obvious by the time I got back to the room, the mood of the team, and whether this was going to be a viable candidate or not.

I built some great teams using this methodology, because by the time the candidate got on board, they already knew everybody. The people were comfortable with them already. We had already started that break-in period. And so you get right down to getting to work, and building those bonds, that esprit de corps that is so vital on a development team.

Because when you have to work with someone on a project that is overdue - I hate to use the analogy “death march,” because that kind of minimizes what a death march really is, and what we’re doing is long and uncomfortable, but it’s not really a death march - but when you get into one of those situations where you’re working long hours, you’d better be comfortable with the person in the next cube or two cubes over - or tempers are going to start fraying. And I never had that problem.

Len: That sounds like a really fascinating process. I mean I can just imagine the impact it has on people, if they see someone that they’ve all endorsed, maybe having difficulty; they might be more motivated to help than otherwise, knowing that you’ve got a kind of collective buy-in.

Cal: That was the thing. The team had buy-in on each hire. So the team was committed to each hire. I did not bring people in and say, “Here’s your new team mate.” Other than the very first person. The first person on any team, I’m the one that hires them. After that, it’s a collaborative effort.

Len: In your latest Leanpub book Uncle Cal’s Career Advice To Developers - which I gather is the text of a talk?

Cal: Yes, the text of a keynote that I gave.

Len: You write about how - I guess is more from the individual, rather than the team perspective - you write about how the job will never love you back, and I was wondering if you could talk a little bit about what you mean by that?

Cal: This was advice given to a friend of mine, Samantha Quiñoes, up in New York. he said her high school counselor gave her this advice: “The job will never love you back.”

I’ve worked for San Francisco startups. I’ve worked in that culture, I’ve worked in the, “We’ve all got to pull together and do things.” And the team I was building in Nashville, we were working so hard on - I was there, almost the entire time. I like to be the first one in. I hated to do it, but I wanted to be the last one out. Now we had some people working till two, three in the morning.

I let them stay. But I was there literally 14 to 16 hours a day, towards the end there. And the COO would walk out at two o’clock to make his tee time. And you’d see the sales people wander in, and wander out for early lunches and stuff like that. And it didn’t hit me until Samantha and I got to talking at a conference one time - because we get to hang out with each other at conferences - and she said that, and it just struck me - that’s the problem. Everybody tells you, you’ve got to love your job, you’ve got to give everything towards the company. Well, the only people that’s actually going to make anything off this company are the founders and the investors, okay?

You’re not going to get anything but your paycheck. So when it comes to your career, you have to be a mercenary. You’ve only got so much time to trade for money. So you’ve got to make sure you’re trading it for the most money you can get - money and benefits. And if you love the company, and you think it’s wonderful - hey, that’s great. But if you think that the company is going to love you back, it’s not. You’re not family, and if you want to put that to the test - be the slack-ass cousin who doesn’t work for two weeks, and see if you’ll still get the paycheck. Not going happen. You’re not family. You’ve got to treat it like a business.

Len: That’s a great lead up to my next question, which is - you’ve got a great line in the book where you say, “Some days, I’ve been the windshield, some days I’ve been the bug.” I really like that image, and I was thinking a little bit about it. Then I realized, in this context, this might be an interesting ambiguity there, that I’d like to ask you about, especially if you’re working in start-up land. You can interpret that as being, “Sometimes you’ve got to do really unpleasant types of work.” And this is actually a part of being responsible in your role. Is that what you meant, or were you talking about something else?

Cal: Actually that comment is much more of a day-by-day comment. Some days, you’re going to knock it out at the park, and some days, the bat’s just going to hit you. I have a version of that, that says, “Some days, you’re the windshield, some days, you’re the bug. If I’m the bug today, let me be an armor-piercing bug.” Because I want to blow through.

But you’re right. There are times when you just have to power through it. And I have another talk, which I believe is actually one of the books, called “Going Pro.” And in it, I talk about a similar topic, in that there are times when you, as a team member just cannot find your happy place on that team. For whatever reason - they’ve made a technical decision, you can’t get along with your manager - whatever reason, you can’t find your happy place. As long as the paychecks are clearing, you’d be an adult. You give your 110%.

But you start looking. Because if you’re not happy - you owe it to yourself, and to that team - to go find another job. You are not doing that team any favor by hanging around if you’re pissed off. Because if you’re pissed off, you’re not happy. It’s going to affect your work, no matter how much you think it’s not. So, you give your 100% while you’re there on the job. You don’t slack, you don’t, “I’m going to goof off today. They’ll never know, what are they going to do, fire me?” Well, no. You’re an adult. Do the right thing. But start looking around, and as soon as you can do it - exit gracefully.

And I don’t mean get so pissed off that you rage quit. Rage quits feel really good for about a day. I know, I rage quit a McDonald’s one time. The most pointless gesture I’ve ever made. But rage quit feels really good, until you call your buddy who - you knew it was a sure thing, because they’re looking for somebody just like you, and then your buddy says, “Yeah, my manager was talking to your previous manager. You kind of left them in a lurch. We can’t talk to you anymore.” All of sudden, that rage quit don’t feel so good anymore. So be an adult, do your job. But if you’re not happy, you owe it to yourself, and the team, to find you something else. Don’t be the bug everyday.

Len: I just love that image.

You mentioned it at the beginning that I left out of my introduction your unpublished books on Leanpub, and I was wondering if there’s one in particular that you’re more focusing on now? Or if you even have a plan for what your next book might be to release?

Cal: I am almost finished with my next book - I don’t know if it’s on Leanpub or not. My wife actually handles all of that now. Used to be, I did it, and that’s why I did Leanpub. Because Leanpub is easy enough that even I can concentrate on writing, and not have to worry about the book production. It’s a wonderful platform. But I don’t know if she’s put this one up yet. I have full intention to put it up there. It’s called Spin a Good Yarn, and it is everything developers need to know to build presentations. I don’t build slide decks, because my slide decks suck. My slide decks are white backgrounds with black text. And I upgraded on my last one, and actually put a picture of myself and a picture of one of my books. I mean, that’s a graphical upgrade for me.

But everything else that you have to do, from coming up with the concept, to writing the abstract, to getting a title, that will actually convince the conference organizer to bother to scan your abstract. To the practice, to how you do all of this. And then what do you after you present? How to be a good speaker for a conference, and not just a good presenter.

I will never ever do this again, but I recorded an audio version of it. And oh my God. Editing audio - I grew up around audio, but having to edit an hour and half worth of audio and take out - it just seems like I take these huge breaths on the microphone - having to edit all this out is a pain. But I got the book, the audio, five or six videos to go with it and all of that, and I’m putting it up. It’ll be at - and this is the worst URL I could find - spin-a-good-yarn. Or you can just go to my blog, and there’ll be a picture of the book up there.

Len: You’ve partly answered it already, but why did you choose to self-publish on Leanpub?

Cal: Well, that’s two questions. Why did I choose to self-publish? I have actually published through a traditional publisher before, and I got 20% of my book sales. And I just felt like I deserved more. One of the reasons that Culture of Respect is not on Amazon is, because of the price, I would only get 35% royalties. No. Amazon doesn’t deserve the 65% royalties. They didn’t do anything worthy of that. So, that’s only available on Leanpub, because you guys have a good platform and it’s fair. But the reason I self-publish is, I know I can probably sell more. I don’t know that I could make more, and I just like the control.

Why did I use Leanpub? I got to researching what it would take to do it. And I actually had systems set up, and I was playing with them - on how to create a Kindle [Note: Cal means a MOBI format ebook file - eds.], because that was my focus. I wanted to create a Kindle book, okay, and it was just a pain in the rear end. And yeah I’ve got KindleGen, and I’ve got all this other stuff. And I can edit the XML - what is it, the OPF file, or whatever it is - by hand. I can do all this stuff. But that’s not what I want to do. I want to write books.

And then I came across Leanpub, and I don’t know if I found you because of Google search, or somebody introduced me. But about the time that I found you, all of my friends found you also. For a while, I thought all you published was computer books, because every time I turned around, somebody’s publishing a computer book on Leanpub. I’m like “Okay, this is the platform I need. And I have published - I think you said five - I’ve started three or four more, and I have plans for at least three or four more next year.

I have looked at doing my own thing. while Leanpub is a wonderful platform, I want a little more control over things like stylesheets for PDFs. Where possible, I want to make it look really nice. And my wife’s a graphic designer, and she says, “Well this is all we can do in Leanpub.” And so I looked at several other platforms. I’ve even got a droplet out on DigitalOcean that has Pandoc installed. And, yeah that took a weekend, and some PHP code…. I can publish the Markdown, and it will– I’ve got stuff that’ll convert it to HTML and PHP, that will create the OPF. I’m like, “This just isn’t worth it.”

Leanpub gives me most of everything I need. I can either figure out the rest, or live without the rest. I don’t have anybody screaming at me, “If only your PDFs were a little more colourful, I would buy them.”

Len: That’s a really interesting challenge for self-published authors. To what degree do you focus on - in the end, after you done writing - on formatting? Or do you just go ahead and start selling?

One feature we developed, we launched a few months ago was, upload. So one way you could use Leanpub is to write your book in-progress on Leanpub, and then when you’re done, we have an InDesign export feature that you can use, so then you could take it, and then get it to your book designer. And then you can actually switch writing modes to the feature that we launched a few months ago, which is, “Upload your book,” so you can actually upload a PDF and/or a MOBI, and/or an EPUB file that you’ve made yourself.

We’ve got quite a few very good-looking books that people spent a lot of time, working even with teams of people, to get them to look really nice. And then they can upload them to Leanpub. And they can do that as many times as they want. And then they can take advantage of our high royalty rate, and a lot of our other features. Like email the author, email your readers - coupons, bundling - things like that, that aren’t really available on Amazon.

I just wanted to actually address that point that you brought up at the beginning of that great answer, which was that, for books that are priced higher than $9.99 on Amazon, they drop the royalty rate from 70% to 35%.

For people who aren’t familiar with it, there’s a whole discourse around ebook pricing. And there’s been a controversy since the Kindle came out, basically around this. But Amazon - it’s at a complex and evolving sort of position. One way of describing their position is, ebooks should not be priced higher than $9.99. They want that idea in people’s heads. And when I say people, I don’t just mean readers - I mean authors and publishers as well. Which is partly where the controversy comes in.

And so, if you’ve got a book that’s worth $9.99, and you’ve got a book that’s worth $11.00 on Amazon, you’ll make more money from the book that’s worth $9.99 per sale, from the book that’s worth less. So, it’s an interesting strategic move on Amazon’s part.

That’s one of the things that does make selling on Leanpub different. One of the reasons Leanpub is popular with people who write technical books, is that they are often books that ought to be worth more than $9.99.

I mean you can imagine - if reading a book gives you skills, that means you can now command a higher price for your consulting per hour. How much is that book worth to you? Well, lots.

And we’ve actually even got one book right now - that’s about getting a technical certification, that’s got a $200 minimum price. And people are buying it. This is a book that’s got no DRM, a self-published ebook. But it’s worth that much money to a lot of people.

Cal: Well, I fully support authors being able to charge whatever they want, and I fully rail against Amazon’s control of the market. But, I’m happy to put my $9.95 and below books up there. I’ve got series of books called, “Learn One Thing Books”. They’re short books; specifically, technical books. They focus on a single topic, and they’re $9.95. And what I do is, I publish them on Leanpub - take the MOBI, and shove it up on Amazon. It’s nothing deep or anything. I don’t recreate it just for Amazon. I take what you give me, and just put it up there. But I did not know that you had the “upload” thing. That’s really cool. I’m going to have to start doing that, because my wife is a designer.

I usually start in Google Docs, because that’s what I’m most comfortable in. And [my wife will] take it, and she’ll start breaking it up into text files, and putting it on Leanpub. But now that she can produce it, I think she will start using that. That works a whole lot better, and I don’t have to fire Pandoc. Because yeah, I got friends that use Pandoc, and they love it - but, that’s not what I want to do. I don’t want to manage yet another system.

I thought about actually writing my own, and I’m like, “Oh my God, why?” Just more code to maintain.

Leanpub is not a perfect platform - I’ve had disagreements with you all, although that was early on - and I think you’ve resolved most of the issues I had. It is not a perfect platform. It is a platform that has served me very well. And I’m very pleased with the service I get from you guys, and will continue to publish my stuff on Leanpub. And hopefully, help put a few pennies in your pocket, so that you can keep doing this.

Len: Thanks, I really appreciate that. And we appreciate you being a Leanpub author. I think you’ve been around for quite some time in Leanpub’s lifetime. so we really appreciate that.

My last question is about self-publishing. Is interacting with readers something that you do? Is it important to you to get emails from readers, or get communications from readers with questions about your books, or suggestions, or anything like that?

Cal: I don’t get a lot of interaction with readers over email. Occasionally, I will get tweets. I love the fact that you put a tweet in the front of the book. “Tweet off that you’ve bought this book.” I’ve had people do that, and it’s awesome. But, I go to a lot of PHP conferences, and most of my audience is PHP developers. Even for my non-technical [books], that’s mostly who reads it.

And I get to sit down at lunch and talk to people. And they say “Okay, you said this, but what did you mean?” I get to talk with them, and they gave me feedback. I had somebody write me today. “I’ve got one of [your] books,” and he gave me a long list of - the book is on creating brown bag lunch programs. He says, “I like your book. It has a lot of good points. But here’s how we’re doing it, and I think your readers could benefit from that.” And so, I’m about to go - hopefully in October - go into a revision cycle, produce a new version of that - based on Jeremy’s feedback.

Len: Thanks it’s interesting. I just love to hear about the different approaches that people take in the way - that publishing books can be part of a wider kind of environment that you’re operating in. Talking at conferences and things like that.

Well, thanks very much for your time today, Cal. I really appreciate it. And thanks for being a Leanpub author.

Cal: Hey, thank you for the platform.

blog comments powered by Disqus