The Leanpub Blog: On Writing, Publishing, Self-Publishing and Ebooks
Leanpub Podcast Interview #44: Cal Evans
published Jan 24, 2017
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.
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.
Leanpub Podcast Interview #43: Thad McIlroy
published Jan 16, 2017
Thad McIlroy is an author, speaker, and publishing industry expert who blogs at thefutureofpublishing.com. In this interview, Leanpub co-founder Len Epp talks with Thad about his wide-ranging career in the publishing industry, the state of the publishing industry today, whether self-published authors should submit their books to subscription services, some recent controversies in the book publishing world, and the future of publishing and book publishing startups.
This interview was recorded on January 13, 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.
Thad McIlroy
Len: Hi, this is Len Epp from Leanpub, and in this podcast episode, I’ll be talking with Thad McIlroy. Thad is an author and consultant who writes and blogs at thefutureofpublishing.com. His consulting work and experience reaches into many aspects of publishing, from print and the origins of desktop publishing, to analysis of the latest tech, digital book publishing, and supply chain optimization and other areas.
In addition to consulting, writing books and blogging, Thad is also an accomplished speaker, who has spoken at hundreds of events, from conferences to corporate meetings.
In this interview, we’re going to talk about Thad’s career, his interest in tech, and his recently published report, An Authoritative Look at Book Publishing Startups.
So, thank you Thad for being on our podcast.
Thad: Thank you Len, glad to be on board.
Len: Thanks. In these interviews, I normally like to start by asking people about - what I call their origin story. You’ve got a great one, that ranges widely across the publishing industry, and I was wondering if you could tell us a little bit about how and why you first got interested in publishing, and an overview of your path to where you are today?
Thad: Sure. I can go back centuries - I’ll only get briefly into that. But I came out of, well, a literary family. I mean, not that highbrow a literary family, although Kenneth Grahame is one that I can point back to. That’s fairly literary, but my father was–
Len: The Wind in the Willows, right?
Thad: Yes. We have a very direct lineage. And my great uncle, who is also an author, he spent time with him as a boy. That was Lawrence Hill Grahame, who wrote a number of books for young adults at the turn of the last century, which were best sellers, and award winners at the time, and totally unreadable today.
And then my father was a novelist and had two novels published, he was working on a third one when he died. He did a lot of radio work at the Canadian Broadcasting Corporation, which you well know, the CBC. And so that’s sort of the milieu in which I grew up. My father always said to me, “You’re not the creative one in the family, you’re going to be an engineer. It’s your sister who’ll become a writer.” And she does write, but she’s not published.
But my interest gravitated to book publishing. Where I really started in the industry was as a book seller in Toronto in the ’70s, and working for independent book stores and then working for chain stores. That’s where I fell in love with the book industry, and that’s really what’s launched me forward to today.
Len: And did you grow up around Toronto?
Thad: Yes, I was born in Toronto, and lived there for the first 30 years of my life, then moved to San Francisco.
Len: I’m curious about your first entry into the publishing industry. You worked for a bookseller, and I believe early on you edited a book about a Canadian Prime Minister as well?
Thad: Well, that was after I started my first publishing company. So in the third or fourth year of my book selling career, I had gone down to San Francisco. It was for the annual convention of the American Book Sellers Association, which is now the one called BEA [Note: It appears they have rebranded themselves as BookExpo - eds.].
And in those days, it was a huge hall, where all kinds of publishers, all shapes and sizes, would display their wares. And I was there with a friend at the conference, out of interest. And saw all these small presses with nifty books, where it’s like, “Oh you can’t get those in Canada.” And then it’s like, “Well maybe I could start a little company and distribute some of these small presses?”
And so I did. I started what I called Virgo Press, because my partner and I were both September babies, so Virgos. And we started this as a distribution company out of my bedroom, basically. And then a friend came to me and said, “I’ve got this amazing idea. I think it’d be a big best seller. How to Win Canada’s Lotteries was his idea.
And this was when they were still pretty new. They were [a phenomenon]. It was still something that was fresh and exciting. They didn’t have them every single place. They didn’t have 27 different kinds of tickets you could buy, and so on.
And so we published that book, and it was a bestseller. We wrote it pseudonymously. He, I and one other person wrote various chapters for it. And then I toured on behalf of the book. And so that was my first self-publishing experience. It launched what became Virgo Press, which ended up being a trade publisher of some substance. We ended up with 15 staff, and about 60 tittles published over about a three year, four year period.
And then ran into a situation where the bank decided they didn’t want to be financing us anymore and called in our loan. I couldn’t replace the financing, and went bust. But I had had this wonderful four year experience in my early twenties running a fun, small general trade publishing company out of Toronto.
Len: Wow, I didn’t realize it was that early on in your career, that it was in your twenties that you were founding a company and writing bestsellers already. That’s fascinating.
You mentioned the Book Expo America, the BEA Conference, was originally in San Francisco?
Thad: No, it used to travel around more, before they settled on New York much more recently. And then they tried Chicago last year, and that didn’t work out. In those days, they would move it around, as most conferences used to in those days, where it would be West Coast one year, East Coast one year. Then its centre would be Chicago, usually one year. And they’d just circulate that way. So it just happened that year was a San Francisco year.
Len: For those listening who might not be into the minutia of publishing conferences, there are currently two big conferences in the United States - the BEA conference and the Digital Book World conference, which is actually just coming up in a few days after this interview - and where Thad will be giving a couple of talks [The talks are “5 Tools You’ll Wonder How You Lived Without” on Tuesday, January 17, and “How to Thrive in an Era of Constant Change”on Wednesday, January 18 - eds.]. But the reason I asked about San Francisco is that these conferences tend to be focused around New York, so it’s interesting to know that there was a West Coast presence for the big, big players at a certain time.
I think I read on a bio about you somewhere that you may have been one of the first people to publish a book that was created entirely with desktop publishing software tools, and I was wondering if you could talk a little bit about that experience.
Thad: Sure. That was great, great fun. And I stumbled into it. It was not like I had a vision and thought, “Ah, I see what’s coming here, and I’m going to be the pioneer.” At the time, after my publishing company went bust, I became a freelance journalist, and on the side, with a couple of partners, we started a small book packaging company.
To call it book packaging … from the industry, they’re the people in the space between being an author and being a publisher. Instead of just writing the manuscript, you also contract for all of the editorial design and illustration for all of the books you do. You deliver what we’d call camera-ready copy to the publisher, so it just goes straight to press on their side.
They don’t have any of the developmental expenses, you take that on yourself. So you get a higher royalty, as a result of their lower overhead, and it gives you control of the project where, in many cases, because of the particular nature of the book, you want that kind of control. You don’t want to give that up. So I was working on books of political cartooning - it was fun, I’ve always loved political cartoons, and I edited two books, one on Pierre Elliott Trudeau, and one on John Diefenbaker, where I told their life stories with a focus on their political stories, in cartoons and in words. And so on one page would be a famous cartoon, usually I would have about 30 cartoonists in each of the books, with representative cartoons at each stage of their career matched up against quotes, either from one of those Prime Ministers or about them. It was a really fun way to go through and get a history lesson, without having to read a big long text.
The Diefenbaker one - as American Presidents have their own Presidential libraries, Diefenbaker has his own library and centre in Saskatoon, in the spot where he’s buried. It’s a great institution, if you’re interested in John Diefenbaker and in Canadian history, and that’s where I tracked down the cartoons.
While I was there, the Director of the centre said, “Next year, the embargo on his personal papers is ending, and they’re going to be open to researchers. But very few researchers know that. So Thad, you’ve got an opportunity where you could edit John Diefenbaker’s personal correspondence with his wife, with his brother, with his two wives, with his mother, and do a volume.” So I ended up doing a volume called, Personal Letters of a Public Man.
But most of his letters were handwritten, and in those days, to get something from handwriting to typesetting, meant [you had] to hire at great expense a typesetter, who was willing to take the effort to decipher the handwriting, and put it directly into the typesetting machine. So it was a very expensive per hour cost.
However, that year was the release of “DTP”, [Desktop publishing](https://en.wikipedia.org/wiki/Desktop_publishing. The Macintosh was maybe a year old, the first Mac.
Len: So this was about 1985 or so?
Thad: ‘85, yeah. Aldus PageMaker came out, Adobe released the first Adobe fonts that would work on the LaserWriter, on the laser printer. And it could be manipulated through a Mac.
It came to me as a suggestion to get hold of a Mac, which I did, and type up all the letters myself, with the notion that I would then give the disk to the typesetting company, and they would translate it into their machine language for the typesetting.
As it turned out, I didn’t check whether that actually worked. And when I got all these letters typed, there were hundreds of pages, and I went to the typesetting companies we knew in Toronto at the time, they’re like, “We don’t know how to read one of these diskettes. We don’t have any way to translate it. Sorry, but if you want this book published, we’re going to have to do what it was in the original thing. We’re going to have to retype them all on this Linotype system, or this Compugraphic system that they were using.
And it was like, “Oh man, all of that for nothing.” But my art director, who we worked with on this project, said, “I was just reading in Popular Mechanics that you can actually output from Microsoft Word version 1.05 directly to this laser printer. If we do that at 125%, and then condense it, shoot it down to 80%, that’ll tighten up the density of the type. And we can use that instead of typography, instead of a traditional typographic machine.
Len: Wow.
Thad: And so we did, and the book was published. Doubleday was the publisher, and we showed it to the editor and my art director at Doubleday, without telling them how we’d done it. We showed them a page spread, and said, “What do you think? Is it okay - running heads, folios, the typography?” They were, “Yeah, fine, sure.”
And so out came the book, with a little credit on the cover page saying, “This was produced with the LaserWriter, and on Microsoft Word,” because PageMaker actually wouldn’t be out at that time. That was just a few months before it appeared.
And when that was published, Apple heard about it and they called me, they got in touch with me and said, “Do you realize what you’ve done?” And it’s like, “Well, no. We just did this and–” “You’re the first ones who have actually done this. We were hoping that this would happen, but it’s never happened.”
And so we got together, and they ended up connecting me with a company that was going to become Canada’s largest reseller of this equipment and technology. I became the product manager for this line, and so converted from being a journalist, a publisher, into a tech really - but a tech in the publishing industry. So that’s where my career transitioned into where it is today, where all of the work I do is at that intersection of the culture of publishing and the technology of publishing.
Len: That’s a really fascinating story. I’m very surprised to hear it, and it’s great to hear that Apple found out and were aggressive and watchful enough to see this, and reach out to you.
I wanted to ask though, what did Doubleday do when they found out?
Thad: Nothing. They didn’t know what it meant. They were fine with it.
Len: And you ended up in Vancouver at some point, and I wanted to ask how that happened?
Thad: I went to San Francisco when I turned 30 and lived there for 15 years, wanting to be closer to Silicon Valley, and also get away from the damn winters. And it seemed great. The city’s fantastic, and it was so close to all of the technology of publishing. I thought that would be a great opportunity. I’m a dual citizen, because my father was born in New York.
And so that was a great move, and I was there till early in the new millennium. And then my mother got cancer. She lived in Toronto, and I moved back to Toronto to look after her for what ended up being three years. And then found myself like, “When will I go back to San Francisco, or what am I going to do now? I don’t really like Toronto. I got away from here, I don’t really want to be back here.” And a friend had an opportunity with a house in West Vancouver, right on the ocean. And so I moved out to Vancouver, and I’ve been there since. Very much in love with the city.
Len: Thanks for that answer, it’s great to learn how all these things connect from the past to the present.
Thad: You’re in Victoria.
Len: Yeah, that’s right - I’m in Victoria, British Columbia. I’m sort of relatively new here. I’ve learned that all winters in Canada are not bad.
Thad: Right.
Len: Just 99%.
Thad: Where did you move there from?
Len: I moved here from Montreal. I’ve moved around a bit myself as well.
Thad: Plenty of tough winters there.
Len: Yeah, and before that I was in England for a few years, so I’ve seen a little bit. The joke I tell to my American and British friends is that I now live on a Canadian island in the Pacific Ocean. Just something most people haven’t even really heard of.
Thad: Right.
Len: Your latest book is called, Mobile Strategies for Digital Publishing: A Practical Guide to the Evolving Landscape, and it came out, I believe, in 2015?
Thad: Yeah.
Len: I wanted to ask you - we don’t need to go into it in depth, but what are some of the mobile strategies for digital publishing that you write about in the book, and what’s your general opinion about the current state of affairs? I guess that is a big question.
Thad: The core kernel that is most important on this topic is this: that everyone has to recognize that the smartphone is no longer an adjunct, it’s no longer sort of, “Oh I have a smart phone as well.” Or, “I work on a computer, and I have this smartphone for when I go out.” They have to get their mind around the idea that people have smart phones, and then on the side they have tablets and computers. The smartphone is the centre of the universe for an ever-increasing majority of the people that are owners of electronic devices.
And so, for publishers who have always seen the smartphone as some kind of globally adjunct, to be, at best, accommodated. My message is: No, start by thinking about the smartphone. When you’re developing content, you should be thinking, “How is this going to display if someone’s reading it on a smartphone?”
And then you can figure out what it’s going to look like as a printed book. Because you know how to do that, you know how to make printed books. You’ve been doing that throughout your career. But do you know how to make something optimal for a smartphone? Of course they don’t, and they’re still not getting their mind around it fully.
At the time there was this distraction around apps, and we all thought that maybe the way to go, the way to embrace the space was via apps. And that hasn’t turned out to be true. A lot of companies have done some interesting innovative things around that space, but that hasn’t been the answer. And so is it in a browser? Or do we just accept that the default apps - Kindle app, Kobo app - that that is the interface by which books are communicated on smartphones?
Well, as of today - yes. Is that the way it’s going to be over time? I don’t think so. There’s a lot of transition still to take place. But my overall message to book publishers is start with the phone, and work backwards from there.
Len: And do you think publishers are heeding that message?
Thad: No, not at all. Not at all.
Len: And why do you think that is?
Thad: Publishers are - I don’t - there’s a - I’m trying to say it nicely. Publishers are not known to be technology-adept. It’s not been a technology industry, even though it is now a technology industry - which is a big argument I try and push to people. And in one of my presentations next week at DBW, I’m trying to convince the audience, in the same way you should be thinking of mobile first, you should be thinking technology first. You should be thinking of your publishing company as a technology company that also does this interesting artistic craft, these cultural artifacts. But this has to take place via technology.
But publishing companies are not in that mind space at all, to their great detriment, because they’re losing market share to self-published authors who are technologically adept. That’s not the only reason they’re losing market share, but that’s a significant part of it - until they get their minds fully around technology, they’re going to continue to be losing sales, as they’ve been doing over the last few years. And they’re going to continue to be outclassed by newcomers.
Len: That’s really interesting. It reminds me of an experience I had at the BEA, Book Expo America conference in New York, I think it was in 2013, when there was this panel of grand eminences, including the CEO of one of the Big Four, Big Five - do we say Big Four or Big Five publishers now?
Thad: Big Five.
Len: Big Five still, okay.
Thad: Yeah.
Len: I’ve heard both. So, a CEO of one of the Big Five, on one of the “Top 50” lists of the most important people in America kind of thing, was on the panel. And there were the heads of some other organizations. And I remember, the CEO or sort of higher-up of one big company actually picked up an iPad that he had sitting in front of him, and like turned to his right and waved it in the face of this big CEO, and said, “These things are real. It’s not a science experiment. They actually exist.” And there was, nonetheless, this wall, just this wall between him and the CEO of the big publishing company that was not penetrable. It was amazing to just see it. I mean it’s one of the things we all know, but to actually see it happening, in front of a big crowd as well, was pretty amazing to me.
Thad: I can well imagine. Yeah, they still see them as toys. It’s unfortunate, really unfortunate.
Len: It’s interesting what you say about technology as well. I mean, I’ve got this theory that there’s sort of two big cultures in corporate America right now. One is the sort of old time-y one, you might say, where domain-specific expertise is not necessarily required, or might even be frowned upon. And so an executive is supposed to be an executive. They’re supposed to be good at business, and it doesn’t matter what the business is. They have these universal skills that they can use, mostly networking and influence peddling and things like that. Those are important and powerful things.
And on the other hand, you have the domain-specific expertise leaders. A classic example from right now would be Elon Musk. Someone who is actually not afraid of typing and doing work, and literally getting hands-on. He doesn’t just go to the factory to put on a decorative hat and intimidate the workers, but actually really knows what’s going on.
It’s a really interesting question with software eating the world, as Marc Andreessen famously said - is it possible to succeed in business with no domain-specific expertise at the top anymore?”
Thad: No.
Len: You don’t think so?
Thad: It’s not. No, not at all.
To me it’s like - forget it. If your senior management are not technology-adept, if they’re not comfortable and fully aware of what technology can do for them, then they’re not managing the company anywhere near it’s full potential, period. I don’t even want to argue with you about that. And not you - with any of them.
Len: I understand.
Thad: It’s unequivocal at this point, from my point of view. They are losing competitive advantage every day they fail to put that expertise in at the highest levels of the company.
Len: And I imagine that as a consultant with technical expertise, this must be something where there are lots of people out there who I’m sure are aware that this is something they require, and that they need to find that expertise somewhere.
Thad: Yes and no. As someone who’s been consulting now for 30 years, it’s never been so difficult, it’s never been so challenging to get clients because of these problems where the easiest way to deal with the fact that they’re not technology adept, is just to ignore it. And so to ignore it, is to ignore that there’s consultants out there that can help them. I’m very fortunate that I am keeping busy. But it ain’t easy. It’s certainly not like they’re lining up outside my door.
Len: That’s really fascinating. I mean, the years keep ticking away, and the big publishers keep not responding.
I was wondering if you wouldn’t mind talking a little bit about some of the big news that’s been happening in the publishing industry - at least for insiders, the big news over the last, let’s say year and a half or so, about data and the analysis of ebook sales versus print sales?
One thing one hears from one side, is a celebration of declining ebook sales. And one hears from the other side no celebration because, first of all, on the other side, people like ebook sales, as one would think publishers would. But also, there is no decline in ebook sales, is what some people are saying.
I was wondering what your much more informed than my own position on that issue might be?
Thad: It’s a great question, and a complex issue. Let me try and give a really short answer, which is hard for me to do. But I’ll try and do that, otherwise I could sort of head off for 20 minutes on this. But you can then ask for some clarification.
Short answer: Yes, ebook sales are declining for the Big Five and for, as it turns out, a pool of about 1,200 publishers, who are measured regularly by the Association of American Publishers. There is a measurable decline. The factor that seems most certain to be the reason for that decline, is the fact that the prices have gone way up, as a result of a legal thing that went on between Apple and the publishers, and the Department of Competition in the US.
So they gave the publishers the ability to up the prices, and they did. And ludicrously so, in my view. But they did, and coincident with that, the sales have gone way down…. There’s one other issue, but that seems to be the biggest one.
At the same time, self-publishers are growing, growing, growing. They’ve reached some kind of a plateau recently. But the growth has been enormous over the last decade in self-publishing. And so all of that, 97% of self-publishing activity is digital, not print. And so all of where the big publishers are saying, “Our sales in ebooks are down,” while these other people who really are your competition, and you’re then….
Part of what they can’t get their mind around is that, “Well this little person, this little self-publisher, they’re not my competition.” Well, en masse they are your competition, and there are tens of thousands of them. Hundreds and thousands of them. And they are succeeding where you are failing.
And how are they succeeding? Both in pricing, of course, but also in understanding the technology, and where the technology intersects the marketing. They understand that far better than the large publishers.
And so that’s the real story of ebooks. No, they’re not declining overall.
Len: I watched an interview with you on YouTube, it might have been with Joanna Penn… where you talk about - there’s a kind of irony where, Amazon is obviously gigantic, and is a pre-occupation of publishers and self-publishers. But actually books - which it was known for initially - are a very small part overall of what Amazon does, and so the irony is that although books and ebooks, they’re a smaller subset of book publishing generally, are, to the rest of us, a huge industry - the book publishing industry is like 150 billion dollars a year worldwide, it’s bigger than other forms of media - but for Amazon, they’re so big that books are a small part of what they do. And yet, they somehow just effortlessly dominate all these other companies. And these companies have become almost entirely reliant on, or existentially dependent upon Amazon doing its job well.
I was wondering what your position might be - if you were CEO of a Big Five publishing company, or if you had been for the last 10 years, what would you do with respect to Amazon?
Thad: Yeah, that’s the huge elephant in the publishing room. There’s a lot of antipathy towards Amazon, and understandably so. But forget that. Almost all of my clients, Amazon is now their largest single customer, and growing. The numbers suggest that Amazon controls about 75% of ebook distribution in the United States.
So most of my data - I’m very US-focused, even though I’m Canadian-based - my career was built in the US. So you’ll forgive me that my figures generally are US-referenced. In some cases, I’ve also got Canadian data. But generally speaking, as we’re used to the publishing industry, in Canada it pretty much mirrors the structure of the US company, with some very significant differences. But anyway, to use US data is not to greatly mislead about Canada….
Len: We’re based in Canada, but basically our we have the same issue with our audience.
Thad: In the US, [Amazon has about] 75% control of ebooks - about 50% control of all book sales - physical and digital. So it’s like, the contest is over, Amazon won. And you can cry about that all you want. But it’s not going to help you at all. Amazon won.
A colleague of mine, Ted Hill, who’s running the DBW conference next week, has a lovely way of putting it, where he’s able to provoke a response or a thought about a response. “What if Amazon was not merely your biggest customer, what if they were your only customer? How would you run your publishing company if they literally took over the rest of the market?”
Which - in fact, I mean, if you track the trend - at some point, that’s not a completely ludicrous thing. But as a brain exercise, it’s really important to think through if there is only one distributor, and that distributor is Amazon. And we know how they behave. What does that do to publishing?
Well it’s not all negative, because Amazon’s a fabulous marketer. And you’re suggesting in what you say - yeah, books are an insignificant portion of their revenue. But part of what makes Amazon so awesome, awe inspiring, is that markets they don’t even care about from a fiscal perspective, they run them as if that was the only thing they did. And so in book marketing - they continue to be incredibly innovative, incredibly aggressive.
And it’s not getting any easier to work with Amazon in the same room, because you have to pay attention to every little movement they make. All of which are designed to sell more books. But also for Amazon to sell them at the expense of any other company.
They’ve decimated Barnes and Noble. Barnes and Noble, it’s just a very sad last few years for them. One can be critical of Barnes and Noble, and there’s lots of reasons to do so. But if you or I were running Barnes and Noble, we would’ve run it into the ground too, because competing with Amazon is a mug’s game, you just can’t do it.
However, from a publisher’s point of view, it’s like, embrace the beast - you’ve got no choice. And for the future of your company - you’re not single-handedly going to stop them. If anything stops them, it’s going to be a groundswell - a very innovative groundswell that none of us perceive at this point. But it ain’t going to be you trying to single-handedly work against them.
So for all of my clients, I say, “Embrace them wholeheartedly. Put on a big smile, even though you don’t feel it. Because these are the people that are selling your books better than anyone else in the world.”
Len: That’s a great, and in my experience, pretty original answer. It’s just so fascinating - you mentioned Barnes and Noble, and the Apple and the big publishers controversy from before. I mean it’s just - it really is in it’s own way, a kind of fascinating comedy. I remember reading a quote - I think from the president of Barnes and Noble, blaming declining sales on the election in the US, because people are afraid, and they’re just staying at home watching cable all day.
I mean, of all the things…. I think there was an article in Publishers Weekly, where they referred to the price fixing scam that was happening at many levels of the publishing industry as - I think it was “a government imposed price reduction.”
Thad: Yes.
Len: The willfulness of it is the thing that really fascinates me, because it it indicates that underneath, people kind of know what they’re wrong about, and why they’re wrong. But there’s something about what’s happened in the last 20 years to publishing that a certain type of person just can’t face up to. And what’s interesting is that it’s not like some kind of deep economics that you’re watching, or like business strategy. It’s something psychological, even at positions of prominence and responsibility. It’s down to some personalities, and their own preoccupations and, I mean, what to you is like something you accidentally discovered, which was the empowerment that comes from new technology, to other people, was Armageddon Day.
They just see the things that they associate with publishing, which were material. Like your typesetting, and stuff like that falling away and falling away and falling away. And they feel like - I think at least my view is that they feel like we’re losing literature, or we’re losing knowledge, because we’re not doing things on paper anymore, and -
Thad: It’s preposterous.
Len: Yeah, and there’s this really interesting conflation of the subject with the material.
Thad: The artifact. Yeah. We have to get away from the artifact. From the concept of the artifact. We have to look at each medium, however we like to do that, as an enabler. As one more opportunity to get the word out. To bring in new readers, to bring in new opportunities. These things are enablers. They’re not artifacts.
One thing you’re saying there reminds me of something a colleague told me 25 years ago. He said, “The only sustainable, competitive advantage is understanding and adopting technology faster than your competitors.” And the point of that with book publishers is, business is debugged. We know how to run book publishers in the traditional way. There’s nothing left to discover there. There’s nothing you can know that your competitor doesn’t know.
The only thing you can know that your competitor doesn’t know is how to, for example, use metadata more strategically than they do. How to maximize the efficiencies of the EPUB format better than they do. Understanding the supply chain, and how metadata informs the supply chain, faster than they do. Aside from that, you have no competitive strength. And that to me is sort of the summation of where we stand as an industry. Technology is the only thing that’s going to save you, let’s put it that way.
Len: On that subject - moving from the big to the small, I suppose - you very recently - just three days ago - released a report called, An Authoritative Look at Book Publishing Startups in the United States. I was wondering, it’s a very long list of companies that you’ve compiled there, and some of them are failed companies. Some of them are plugging along. Many of them were at least attempting to innovate in one way or another technologically. And I was wondering if you could talk - I mean, to begin with - a little bit about what the origins are of this report, and why you were interested in writing it?
Thad: Sure. About five years ago I was on this panel at Tools of Change on the topic of startups. And I was the contrarian on the panel. And the four other people on the panel were all like, “Thad, you’re just being very, very negative. These are amazing opportunities. These are some amazing companies. And they’re going to flourish. And the book publishing industry is fertile ground for startups. Your negativism is completely incorrectly placed.”
I can be a negativist. And so I was a little bit stung by that. But it got me to thinking, “Well, why don’t I go deeper on this, and really find out what’s going on here?” And it turned out to be quite an interesting rabbit hole. I found 900 companies, and started sort of hoarding, collecting.
Over the next five years - every time I heard about a new startup, I would download the information on that startup, if it came out of a blog post or something in Publishers Weekly. Or someone would tell me about it, I’d go to their website and get their mission statement, and add that to the spreadsheet. It kept growing - 300, 600. I did an interim report when there were 600. Then now it was up over 800, it’s like, “What am I going to do with this?”
Well, I decided in the end - I’ll distribute it freely to the industry so they can get a look at what the startup scene is. And I did some quantitative analysis of the data, to try and understand what areas these startups were working in. What kind of funding they got. Whether they’ve had any mergers. Whether they’ve been acquired. A couple of them had gone public. How many had gone out of business? About a third of them have. So that’s the knot of what’s in this report that came out earlier this week.
Len: Speaking of your negativity on that panel five years ago, I looked at your slide deck related to that talk, and I was curious - have your views changed about book publishing startups in the last five years? How would you characterize the current state of affairs facing startups?
Thad: Good question. As I was doing the report, the cynical side of me was reminded - some of these startups are so goofy. And not only is this startup number 231 goofy - that’s just a number - but then you find out that startup number 427 has got the same idea, and launched six months later. And so we have one goofy idea has not made this company successful, and another company’s coming in with the same goofy idea, and they’re going to try and do it too.
And so there’s a lot of that - as I was building this list, I’d find out about a new one, and I’d think, “Oh a new start up, going to add them to the list. Oh my God, their mission statement is the same as 23 others of these startups, a third of which are already out of business.”
So what I saw going on there, is - there’s a cult of startups, right? - that I’ve pointed out a little bit in the report. But we know it, right? I mean the media - whatever newspaper or website you’re on - as long as that company can say, “We’re a startup, and we’re looking to disrupt this or that,” the media eats it up, because the public eats it up, because there are so many glamorous stories around the magic billions that could be made out of thin air six months after startup.
I understand what the allure of that is. But people have to get down to earth a little bit more, and realize that just because they said they’re a startup, just because they’re enabled by the web, just because Mark Zuckerberg exists, doesn’t mean this is a good idea, or that this company’s going anywhere. So that’s the downside.
On the other hand, what you’ve got is a lot of smart people - committed, willing to put their careers and their livelihood on the line, to try and bring some real innovation to the publishing industry. And that’s a great thing. And that’s something that I keep reminding myself of. That bottom line is like, “Thad, forget about the dumb ones, focus on the interesting ones.”
And so I’m hoping in the months ahead on my blog to profile as many as I can that are the most innovative, the most intriguing. Even if they’re very, very small. There’s some that really do have some nifty ideas, and I’d like to spread the word about the best of them.
Len: One example of a type of startup that was backed by really smart people, and run by really smart people - and had talented staff, is Oyster.
I bring them up, not to pick on them, but because their particular approach was very interesting. It was a subscription-based model. I mean, in the end the end they had a book store, but primarily, their business was aimed at people who they believed would pay a monthly fee to have access to loads of books. There’s other examples. Scribd had something similar with romance books, that sort of went belly up. Oyster’s team - just for those listening - got acquired by Google, I think. Or many of their team, or some people on their team were.
Now the example of a subscription model that appears to be working is Amazon’s Kindle Unlimited, although that’s a very curious piece. I was wondering what your opinion is? Looking back on the last couple of years, do you believe in book subscription models? Do you think they’re something that can succeed for a business? And on the other side, do you think it’s something that a self-published author should put their material into?
Thad: Right. To me, at the time - it’s easy now retrospectively, because they have failed to say why it wasn’t a good idea - but at the time, before they failed, there was a lot of hype surrounding it. And I was thinking, like - subscription model, all the books that you would want to get hold of, isn’t that called the public library? And I think I’ve already got that, and I don’t pay an annual fee, and if my branch doesn’t have it, they have inter-branch loans.
So the only thing that made sense on the subscription model to me was, it’s kind of instant-access, not having to go through the queue at the library, or, for the popular books, you have to wait a couple of months if you want the ebook version, until it becomes available. Or even for the print version, sometimes you’re on a list for a couple of months.
So for instant gratification, a subscription model made sense. Except there too - it fell apart because no matter what, they were going to be missing some of the books you wanted. Beause they– Even if they had the Big Five, which they didn’t - but let’s say all the Big Five agreed to it, that’s only 50% of the trade books published by established companies, leaving out the self-published authors. Only 50% of the books published each year in the United States, come from the Big Five. So it’s another several thousand publishers that you need to sign up if you want the other 50%.
So it was never going to be a place where I could say to myself, “Oh, I’ll just go onto Oyster, because I can get it right away.” I can go onto Amazon, and I can buy it right away. So that’s already available to me, and it’s only a few bucks and I can have it instantly. So the subscription model to me was never a profoundly smart idea.
And what Oyster ran into was a particular problem, whereby they couldn’t get the publishers on board. And so they had to pay way too much for these books, which was not economically feasible, and hastened their demise. Scribd is still in business for various reasons. But virtually all the subscription ones that are on my list have gone out of business. And so to me, that was a combination of the publishers undermining them.
But also, the primary value proposition had not been fully developed. It wasn’t that compelling. I mean, is it our manifest destiny, as Kevin Kelly would argue, that every book is going to be online and available to us on a subscription model eventually? That somehow we’ll figure out the way to have one source. But would it be a public source? I don’t know. Will it be Amazon? Who knows?
But our manifest destiny, or the way it would best work for people is - yes, you could access any book at any time - in the moment that you’re interested in doing it. You don’t have to purchase it. You can have it, borrow it, with some sort of funded subscription model, or whatever it would be. That makes sense to me over time. How we’re going to get from here to there, I don’t know.
Len: And if you were advising a self-published author, or a group of self-published authors, would you recommend to them that they try Amazon’s Kindle Unlimited?
Thad: That’s another tough one. Go ahead.
Len: I was just going to say - yeah, for those who are listening - one of the interesting things about this service is that if you’re a self-published author and you put your book on there, Amazon imposes some restrictions on you, on what you can do with your book, and where else you can sell it, and how much you can sell it for, things like that. But also, as I understand it, the money for a subscription service just goes into a big pool. And an inherent and inescapable part of the process then, is that you have to decide how to divvy up the money, and that calculation is entirely up to Amazon. I think their latest way of doing it is to look at how many pages have been read in your book.
Thad: Yeah.
Len: And then this is something that immediately a lot of enterprising characters began taking advantage of. By figuring out, for example, that Amazon wasn’t actually counting the pages that were looked at. It was just looking at the highest number page that had been looked at.
So what people were doing was, basically, putting up more or less fake books that were hundreds of pages long - let’s say - and then having a link at the beginning of the book to the last page of the book. And then that would be sending the signal to Amazon that someone had read all 580 pages of “cat cat cat cat.”
And so there’s this inherent murkiness to what goes on in a subscription service like that. And you’re also susceptible to change. In the same way that internet companies can be screwed over by Google changing it’s algorithm for search results - like one day you can see your ranking fall dramatically. Similarly, you’re exposed to Amazon just deciding one day to count differently, and divvy up those funds differently.
Thad: Yeah, it’s a hornet’s nest, absolutely.
So let’s think of the downside of it. The biggest downside is they demand exclusivity. You cannot distribute your book outside of Amazon, if you want to be part of Kindle Unlimited. That’s a big restriction. And for certain authors of certain genre fiction, to get that extra boost just through Amazon, can offset the potential loss of sales from other distributors.
But if you’re an author of substance - if I can use that as a broad rubric to suggest the more committed fiction writers, and all of the non-fiction writers who are trying to produce books that really add to the canon - it’s an unacceptable restriction. There’s too many other ways that you will miss being able to connect with readers, if you stick with that restriction. So it works best for genre fiction. And it is a chunk of change.
I mean they put 15, 16 million dollars a month into that fund. So in fact, if you think about it on an annualized basis, it’s upwards of 200 million dollars, of what amounts to royalties that are going to the self-published author community. Economically, it’s very, very significant.
But the bottom line for me as a self-published author is - as well as all these other things - the books I have that I self-published, my books are technical, they’re not exciting mysteries. It’s out of the question that I would use Kindle Unlimited. It would just restrict my audience far too much.
So then, who are the audience for Kindle Unlimited - they do have to pay a subscription fee. In the old days, when there was only romances, where the only really consistent genre was, like Harlequin in those days, they would publish weekly, get a new book every week. There was a defined audience of people who wanted a new romance per week, and they weren’t particularly fussy as to which author. They liked a particular sort of sub-genre within romance.
Well that’s spread now, where there’s a lot of people who feel the same way about certain kinds of mysteries, certain kinds of thrillers. They like to get a book a week, or even more than a book a week. And this fulfills that. There’s enough good stuff in KU, that it’s cheaper to be a subscriber to that, than it would be to buy those books individually. But that’s a pretty narrow use case.
And KU, Kindle Unlimited gets a lot more press than it really needs to. I guess it’s become sort of emblematic of Amazon’s power, and ruthless use of power, and ability to - as you say - change the rules according to their whims, and to be exposed to scammers. So it is a very visible thing. But in terms of, really, its significance as a phenomenon for the book publishing industry, it’s much less than meets the eye.
Len: Looking towards the future, in a recent blog post, you wrote - and I’m going to quote you here: “Central to the future of publishing, is understanding where AI intersects with traditional book publishing.”
I was wondering if you could talk a little bit about where you see artificial intelligence intersecting with traditional book publishing and why you think that might be a powerful feature of the future?
Thad: The starting point for my interest in AI and book publishing - well it actually goes back a few years. Let me try and give a short answer and see how that works.
There’s a category of publishing technology that has to do with expressing the meaning. Rather than just saying - if we have a whole paragraph describing a politician’s education, just the education of that politician, and we’ve got 400 words within a much larger biography of that politician, that talks about her time in high school and college and the education that she gained, well, the abstraction of that is semantic. It would be xyz politician - education, college and secondary education. So there’s that abstract layer, in which we describe the meta meaning of a type of content. And so, when you get at that meta level, you have another layer at which you can process content. Where you don’t have to regurgitate every single word in the book.
And so we can get it to the point– Like if we can abstract it to that level, well then someone who’s interested in the education of politicians can do a search of everything that’s been classified at that semantic level, and be able to much more quickly find [what they’re looking for], because it’s not a whole book about that; they could find all of the sub-sections within all of the published literature to cover that particular topic.
And so it’s a potentially very powerful way of classifying this enormous, uncontrollable, multi-billions of words that have been published, and remain in print - from books that have been published over the centuries, literally now. And this then starts to suggest that there are data mining methods that might increase our access or understanding of published work. That was a starting point for me - trying to understand the semantics and how that would intersect with book publishing.
The next thing that happened is Google, Yahoo and Yandex … in Russia came up with a standard called schema.org, which is based on semantic representations of content, and allows those search engines to understand content better.
If you make the effort to explain what the content is at a semantic level, those search engines can do a better job of locating your content. So that put a big impetus on the publishers to start to get a handle on semantics as well.
So then, the next thing that happened that triggered me, was this book that you would’ve seen on my blog, where I reviewed it in a couple of posts, The Bestseller Code. The Bestseller Code is a fascinating book, where the two authors are both scientists.
It’s not just an exploitative look at some secret little method that they came up with, that’s the magic bestseller code - no, these people have done some very extensive analysis of the patterns of the words in bestselling books, of the sentiments that are aroused within, by those words, types of characters, the plot - all those sorts of things.
And they have come up with a formula, a code - the “Bestseller Code” - that identifies the commonalities in the books that have become New York Times bestsellers. And while they aren’t willing to offer it as a prescriptive - i.e. “Do this, your book will become one of those best sellers” - their interim report is really what the book amounts to, where they’re able to say, “We have in fact come up with a scientific quantification of books using the techniques that we now put under the broad rubric of artificial intelligence.”
Things such as sentiment analysis, text mining - you know what I mean. There are a whole set of secondary technologies that are thrown under the umbrella of artificial intelligence. And so this was the first really big, obvious use of the tools of AI towards a specific outcome.
And certainly as a publisher, you just have to start scratching your head and saying, “Okay, so could I use some of this text mining, sentiment analysis to evaluate incoming manuscripts and be able to make some kind of a qualitative assessment.” Based not just on human reading of that. Maybe you could? These are some of the questions that are posed by that.
So coming back to the question that you’re posing to me. What my feeling is, is that the science of artificial intelligence is coming forward by leaps and bounds. The publishing industry has enormous amounts of data in the form of text. And there is an intersection point between those two things that we’re just beginning to get a look at, but which I think is going to be quite profound in the years to follow.
Len: That’s a really great answer. It was sparking in me thinking about Netflix. Netflix is well known for having highly detailed metadata around its shows. It can be like, this person likes movies that are kind of like Quentin Tarantino movies, which have characters named Joe, who dies in in act three, when something falls on his head. And they could categorize the same show many different ways like that.
What people talk about, is how they’re actually using all that viewer information, both to encourage the discoverability of things that people will want to watch, but actually also to create new shows. They base their decisions for what to do, what shows to choose, and perhaps how they should be written, what should happen to the characters in them, based on this information that they have about people’s viewing habits. And it’s a fascinating future ahead of us, where that kind of data can be used to make decisions, and put it in front of people, and then iterate on it and see - well did that work, or did that not work? You can follow the experiment through and look 10 years ahead to what you want to do.
Thad: Yeah. The Netflix example is a particularly good one to spend some time with. My brief comment on that would be, I was initially quite thrilled to learn about what Netflix has done. And you’ll probably remember the Netflix Prize, where they offered a million dollars to a team of scientists that could improve the accuracy of the recommendation engine by, I think, 10%. So it’d get 10% better at successfully recommending a next viewing product to customers.
There’s a whole separate story that is a fun little story on how it played out. But it points to what you’re talking about. At Netflix, they have a lot of scientists on staff looking at how these things can be solved, towards the ultimate task of - can we develop shows, whole shows - where we plot them, develop the characters - which kind of actors are we going to hire? What’s the plot arc going to be? And can we create successful series on that basis?
House of Cards was the first poster child for that outcome. What I point out to people these days is, get a listing of Netflix series that have launched in the last three to five years, and find out how many of them are still being broadcast. They’ve had a lot of failures.
And but people keep talking about their successes. They’ve had a lot of failures. And this is no slam on Netflix. It’s only a reminder that this technology is still very much in flux, and that people are not robots. So you cannot predict with 100% dependability or anything near that number, using science. But you can get closer to it. And so the smart, the best users of the technology are those who fully understand its limitations.
Len: Thanks for that - on the note that people are not robots, it’s something I very much agree with, and it’s an optimistic thing - although I do like robots, too.
I just wanted to say, thanks very much for a fascinating interview, and for giving me and all of our listeners the time. Good luck at the Digital Book World Conference in New York this week, and all the best from me.
Thad: Thanks so much. I enjoyed chatting with you. You are better informed than anyone I’ve spoken to in the last several years, in terms of preparing for the interview. I’m really pleased, because it just made it a lot more fun that you’d taken the time to look at things and ask such smart questions.
Len: Well, thanks very much – and I’m going to leave that in.
Thad: Okay.
Len: Okay, thanks Thad.
Thad: Great, my pleasure.
Leanpub Podcast Interview #42: Tonya Mork
published Jan 10, 2017
Tonya Mork is the author of Refactoring Tweaks: 7+ Easy Wins to Make Your Code Better & Increase Your Profits. In this interview, Leanpub co-founder Len Epp talks with Tonya about her career, her book, and her experience self-publishing on Leanpub.
This interview was recorded on September 8, 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.
Tonya Mork
Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub Podcast, I’ll be interviewing Tonya Mork. Tonya’s a tech leader, software and electrical engineer and educator who has been involved in high-tech engineering since the mid 1980’s. She’s worked on multi-million dollar systems for the world’s big manufacturers - and started her own engineering company in 2002. Through knowthecode.io, Tonya focuses currently on helping WordPress developers become awesomer, by writing and teaching about code construction, programming, and how to think about code.
Tonya is the author of the Leanpub book, Refactoring Tweaks: 7+ Easy Wins to Make Your Code Better & Increase Your Profits. It is being sold as part of a bundle on Leanpub, along with the Refactoring Tweaks Workbook.
In this interview, we’re going to talk about Tonya’s career and professional interests, her book, and her experience self-publishing on Leanpub at the very end. Please note, you can follow Tonya at @hellofromTonya on Twitter. and she’s got a great blog at hellofromtonya.com/blog.
So, thank you Tonya for being on the Leanpub Podcast.
Tonya: Well thank you Len, I appreciate being here.
Len: As you know, I usually like to start these interviews by asking people for their origin story. You’ve got a particularly interesting story, with the history of work in lots of different areas and a lot of personal adventure, and I think people would really like to hear you tell your story in your own words.
Tonya: Sure. I do have an interesting story. I think those who tell stories need to also have an interesting story. Mine’s unique.
I’ve been in engineering since the mid 1980’s. I used to work - and I’m going to say used to, and we’ll talk about why here in a moment - I used to work in the high-tech manufacturing sector. If you think about anything that you use - your computer, your car, your refrigerator - all those things that you purchase and use, those are manufactured, they’re mass-manufactured. They’re put together with very sophisticated, high-tech automation equipment, such as robotics, instrumentation, quality control, those types of things. That’s the world I used to belong to.
So in that, I was a tech, and then I worked my way up into project management, engineering. I became a manager, and then an executive, and had my own engineering company. Those are things that I used to do. And then something happened.
I got sick. I had an engineering company, we were doing very well - very profitable. And this illness that I had was so rare, that basically the doctors told me, “There’s nothing we can do for you.” You’re just going to have to protect yourself.” Because when I would get ill, it was life-threatening. And the environment around me affected me. Imagine being in a car, watching a bird fly - being with family, too many people talking at once. The noise, the chaos. Those types of things would send me into a seizure, and make me so ill that it was life-threatening.
And so, what we had to do is lock myself away and be able to protect myself - control the environment. That went on for quite a few years. Quite a few years. I was in a dark, deep hole of depression, obviously. My whole company was ripped away from me. You’d watch people come and take away all the stuff that you built - your whole career, all of it. Your home, your savings - everything. My company - the families that were counting on me lost their jobs and had to start over again. My clients. So it was very devastating.
Somewhere along the way though, I said, “That’s enough. I’ve got to get back to me.” And I’m a happy person. So I found a way to be able to say, “Okay, I can’t go out into a manufacturing space and help people to be more profitable, and do better with your automation. I can do something virtually to contribute in this world.” And I started teaching and helping. “I have all this experience in engineering - how can I help people?”
And I ended up - first I started a non-profit, to help people like me. And then I ended up in this space. This WordPress space, this large community of people that stepped into the world of programming, without a programming background. And they are asking very elementary questions. Things that I could help them with, and they accepted me into their community.
What I do now is - I’m in the third chapter, and I focus on teaching programmatic thought, troubleshooting - all of those things that developers and seasoned software professionals take for granted. Those are the things that I’m teaching, and helping people in the WordPress space become, as I say, be more awesome.
Len: And you’ve got a particularly interesting moment of recovery as well in your story.
Tonya: Yeah, I do. So towards the end of this saga, my body failed. The doctors were throwing different medicines at me, trying different techniques to help control me - and my body just gave up, and I passed away. I got a miracle. And when that miracle came, I decided, “I need to change the trajectory of my life, and move into helping people and being in a service mode.” And that’s what I do. I’m on this mission, and it’s a real mission. It’s a mission that was given to me, because I got another chance in life. And I’m here to help other people, and that’s what I’m going to dedicate this part of my life to.
Len: In your wonderful essay, “Finding your purpose in life”, where you talk about your journey, you write about the way that, in the engineering world, in your first career, everything was proprietary and closed off, but you found something very different when you joined the developer community that has grown around WordPress. I was wondering if you could talk a little bit about that experience?
Tonya: Sure. So the world that I came from previously - when you’re going to go into things like robotics, and you’re going to build machine learning systems and those types of systems - that information is going to be proprietary. It’s going to have to be owned, so that companies can protect their interest, their knowledge, their profitability. Well, when you’re doing those things, that means people are protecting their little silos of information. You can’t just go out into a community and say, “Hey, I’m building this cool little reasoning engine, I need x, y and z. And it’s got to be able to work, and do these types of things.” Well, that just doesn’t exist. That doesn’t happen.
Then I found this community. This community is completely different. Everybody will give of themselves to help each other. It’s open source. And you’ll find that when you get into open source communities that the communities themselves will reach out and help lift up somebody else. If you’re having an issue, it’s not, “Well that was a stupid question.” Yeah, you can get that, but for the most part, it’s, “Let me see what I can do to help you, and give of my knowledge to make you better and help solve your problem.”
Len: Yeah, that’s really great. I really enjoyed reading how you described that experience. I mean, it’s such a contrast. It reminded me of Elon Musk releasing all kinds of information about the stuff that he’d done recently [Well, in 2014 - eds.]. Which was for all kinds of crazy - well not crazy, but like all kinds of complex reasons. And I was wondering, do you think that world - the world of patents and protection - has changed? Or is there just one or two well-known outlier situations, but really it’s all the same as it used to be?
Tonya: From my experience - now obviously I was out of the market for a while, being ill - but from my experience, from what I see right now, I don’t see that much of a change. I still see companies - and with good reason - being able to say, “I need to protect this knowledge. My team developed it. It gives me a competitive advantage. I need to protect that.” So there are times when you can say, “I can give away this knowledge for free. It’s for the betterment of the community.” I can see that, [but] I can also see instances where [you] can’t give that away. You’ve got to give away your trade secret. So yeah, I can see the differences from a leadership point of view, and a business point of view, where you need to have those two separate approaches and strategies.
Len: I recently interviewed another person who started out in the very high stakes world of programming and engineering around manufacturing. And I really enjoyed reading your recent blog post, in which you talk about firefighting and being reactive, and how much you dislike those approaches.
Tonya: I do.
Len: I was wondering if you wouldn’t mind talking a little bit about that experience that you had, and what firefighting is, and why it’s so bad.
Tonya: Right at the very beginning of that particular article, I tell you I despise of reactive strategy. I do, it’s too costly. And then I go through, and I tell you a story of one of my favorite projects that I did. That was to transform a company from this reactive strategy of firefighting to a proactive approach, and how they went from nearly having chains on their door, and everyone losing their jobs, to flourishing.
Okay, so how do we do that? Well first of all, what is reactive? Reactive is something’s already happened, and now everybody drops everything, and comes running to fix the problem. That’s what firefighting is. “Oh my gosh, we’re in crisis mode, something has happened,” some event. A site’s gone down, a line’s gone down, a customer’s complaining. And people can relate to this, right? Because that’s how we do a lot of our customer service. We think about, “Oh okay, I have a help desk, and I have clients call in. Well they’re calling in now, because they have a problem,” right? That’s reactive. It’s already happened.
The proactive approach then, is to change that strategy. It’s to think about how to ask the question, to prevent that from occurring - putting systems in place to prevent it from occurring, changing the dynamics of your team, to be able to say, “Okay, yeah stuff’s going to happen. And yes, there’s going to be a reactive model to certain things. But our business structure and our strategy should be, we need to anticipate what those things are, and put systems in place, and have leadership from the top down be able to drive that. Hey, we’re proactive. We solve problems before they happen.”
And one of the things that I talked about was, in this particular company, they had the engineering department set up, where the systems were so complex that the engineers had to drop everything and run out to get the lines back up and running again. That’s wrong. Engineers are too expensive and too valuable. They have a role. Their role is creating new products, and coming up with more efficient ways of being able to do things, right?
So we need to have them not be our firefighters, and enable our maintenance department - our technicians, those folks that handle service and support - enable them to do their jobs better. So that was some of the things that I talked about in that article. All the way to the point of, just the culture, how can we shift the culture to think more in a proactive mode, versus a reactive?
Len: I was very interested in your description of the culture. There were two twin aspects of it. One of which was, as I gathered, the managers around the facility thought that their presence during moments of crisis would kind of increase responsiveness.
Tonya: Yes.
Len: Just their personal being around would would increase the pressure on people to perform. And you also mentioned that you had a really funny moment, where you talk about how like, if you show up to a boardroom, and tell the board they’re making mistakes, that won’t work.
Tonya: Yeah, you’ll get kicked right out of there.
Len: And so you need to show up with proof. And that latter point is really good. I just wanted to ask you, was that true generally in your experience? That personality was so important that on the one hand, even if you were right and you went in with true statements, the interpersonal nature of a board meeting makes it impossible to just be direct? And at the same time, you have managers in an expensive, valuable facility, who have an ego problem. I mean, is that just part of the industry?
Tonya: Absolutely. It’s not just the industry, I think that’s just human nature, the higher up the echelon that we go, even in engineering - engineers have egos, right? People have egos. Now when I step into a board room, there are some big personalities in there. I’m a big personality. There’s a lot of big personalities sitting in that room. They got to that level, because they’re visionary. They have some sort of path behind them, that says, “Hey, I have the experience, the ability, the vision, the leadership to be able to sit in this room.” So you’ve got to then walk in and say, “Alright, there’s a problem. You’ve hired me to come in and solve a problem. There’s a problem. You know there is,” okay?
I can’t just walk in here and say, “You guys are part of the problem.” Because if I do that, those big egos are going to march me right out the door. And it’s true, if it’s a boardroom, if it’s an engineering room, if it’s a meeting - any meeting whatsoever. I find it’s much more productive if we walk in and say, “Okay, here’s the truth. There’s a problem. Here’s a solution. And here’s the proof to back it up, here’s the data.” Now there are things that we can’t just yet prove in our plan, but we can put metrics in place, to be able to say, “Alright, you can put a short leash on me now, and measure me - and say, “Okay, this plan is going to reach this pinnacle, here’s some sort of metric to be able to measure that.”
So what I talk about in the article too is, one of the problems was leadership did feel - and this is true in a lot of companies that I’ve been in it doesn’t just have to be the top leaders themselves, it can be a manager, who feels like, “Okay, I put more pressure on people if I stand there over your shoulder. My presence being here lets you know this is important.” That’s wrong. To me, you’re either a spectator, or you’re part of the solution. And part of the solution is not putting more pressure on people. People don’t perform well under pressure, right? It’s sending the wrong message.
So the message that the leadership was sending was, “This is a crisis, everybody drop everything and come running.” And literally, I would see the IT manager out there on the floor. Sometimes there were secretaries out on the floor. Because it came from the top echelon, to say, “Everybody drop everything, there’s a crisis.” It was so reactive, that everything stopped, okay? Well there’s lots of tasks in a company that need to get done at the same time asynchronously. And if everything’s going to come to a grinding halt, well that’s a problem.
Len: And the solution that you came up with, the long term solution that brought this facility into a much better position within its company, was to refocus the engineers away from that firefighting and reactive role, and onto proactive situations. Where a) they were doing the innovating that engineers should be doing, and b) they were doing the kind of predictive kind of work that they should be doing to prevent problems from happening again, rather than fighting them.
Tonya: Right. It was a culture shift. What we said was, “What’s everybody’s role in a company? Alright, go do that role.” So then the question had to be asked, “Why do the engineers need to be on the floor?” So part of the total transformation was, management get off the floor, stop coming out. Let’s enable our people, and trust our people to get their jobs done. And if they’re not getting it done, then ask the question, “Why aren’t they capable? What systems aren’t in place to make them capable of doing that?”
And what we saw was, things were too complex. The equipment was too complex. So we started simplifying things. Okay, we needed more training. Well let’s put some more training in place. We needed a system that would help people that, when something goes wrong, how can we have the system tell us, “Hello, I might be going out of my threshold, something might be coming?”
And so part of the transformation was to build a system. It was a machine learning system, that then did predictive modeling, to be able to say, “Alright, this area is starting to go outside of its parameters that you’ve defined. I’m going to alert you that something might happen.” And then we put a system in place that walked you through the steps of how to resolve those issues.
Maintenance departments have those anyway. They’re usually some sort of document that says, “Okay, do this, then do that, then do this.” Well we just automated it. We put it into a software package, developed that. We even looked and said, “Okay, do we have the parts and system?” “No? Well then send a message off to purchasing. We need to order this. This is where the parts are at. Here’s how the shop order is to build things.” So it was a total transformation, of shifting the culture, the equipment and the processes to be proactive.
Len: It’s interesting, I think I might have noticed a bit of a thread in your work about getting to the fundamentals of what’s going on and understanding them. And you talk in a video at knowthecode.io, your website, about teaching people the building blocks of computation, and knowing the essence of code.
I was wondering if you could talk a little bit about what those important building blocks are, when people are doing their own development, and maybe in particular, what people should learn when they get into WordPress development, which is part of the subject of your book?
Tonya: Sure. I’m working in the WordPress world. But here’s what I try to tell people - and I’m actually putting together a presentation for a WordCamp that I’m going to be going to, on this subject, which is that programming is not hard. It’s not, if you understand programmatic thought and troubleshooting, problem solving.
If you understand those things, here’s what people don’t understand is - I don’t care if I’m building a robotic system, a machine learning system, or a simple website. They’re built with the same building blocks. We just put them together in different ways. And we incrementally put these little building blocks together, that come together to form incredible different systems that we can do - from banking systems to security systems, to sending something up to the moon.
An if is an if is an if. A while is a while is a while. All of these different types of instructions and code are the same. I can go from Python, I can go from C++, I can go from C, I can go to PHP. All of these things have the same different, small building blocks. And once you understand those, all of a sudden you’ll be able to build anything in code. Because now it’s just, “Okay, I understand all the different little building blocks of code. I can read it in different syntax, because it makes sense. I understand that there are looping instructions. I understand that there’s decision-type instructions. I understand that I need to break up my code into subroutines.”
And now we start to learn about different design patterns, and quality coding. How do you make things to be more reusable, or more modular, more configurable, more readable? I try to focus folks on readability, if I can read the code, because code should be human readable. Without inline comments, I should just be able to read it, and it tells me a story. If I can do that, right there, I’ve made code more maintainable. I’ve reduced the cost over its life cycle, and those are the types of things that I talk about when we get down to the basic building blocks.
That’s the bigger picture. But it all starts if I’m a new person coming into programming. It all starts with the fundamentals. First of all, what is programmatic thought? What is problem solving? What are some of the big blocks that you’ll see in every single language? What are those? How does data move around? What does it mean to be able to move by reference or by value? What do those things mean? Those are the things that I teach - I break it all the way down, so it’s very tiny and small. And then we start to put together more complex things.
Len: And do you think things are easier nowadays to get started, than say 10 years ago? If one wants to get started, as a self-taught programmer?
Tonya: Yes.
Len: Okay. I guess it was a loaded question, but -
Tonya: How is that for a big question. When I started back in the mid-1980’s, there wasn’t the internet. We didn’t have email, we didn’t have cell phones, we didn’t have the internet. So it basically was - you put yourself with a person who is better than you, and you scarf all the information you can get off them, and they help teach you about this profession. You can go to college, you can go and get your computer science degree. But now step out into the real world, and add value on day one in programming. There’s a gap there, right? That doesn’t happen, okay?
So what we have now though, is the ability to go to all these tremendous sites. To be able to share information about how you put systems together. Not only that, but we can share different frameworks, we can share different starting blocks - and we can take all this great code, and we can pull that in to save ourselves time. So we’ve got resources for training, we’ve got resources for building blocks to start with projects, to reduce our time. And then we’ve got different experts around the way, that are sharing their knowledge - either through books or blogs or presentations - or all of it.
So there’s lots of information. There’s also a lot of bad information out there. And learning how to disseminate what’s good and bad - well, that’s a different skill set, of being able to learn the basics from someone who really knows their stuff, and knows how to transfer that knowledge out of their brain to yours. It becomes adaptable for you.
I talk about adaptability a lot. I can teach you how to build one website, well yeah, whoopee. I know how to build this one thing, but I want you to make it your own, so you can go build something else.
Len: That’s a really interesting issue. It’s one I encountered indirectly in an interview a couple of months ago, with a couple of network engineers. But they were talking about how - what you really need to do, if you want to succeed in this world is to first think and learn, and truly understand what you’re doing - rather than fall for the very seductive trap of just Googling for little solutions every time you run into a problem.
Tonya: Absolutely.
Len: Because one of the consequences of having such powerful, and so much information available for programmers nowadays is that, every time you hit a road block, you can just kind of Google and then copy/paste a solution. I mean that’s putting it sort of crudely, but -
Tonya: It’s very true though.
Len: And is that something, when you’re teaching people that you - is that another thing that you have to teach them?
Tonya: Absolutely. Part of what I teach too is, to think about the cost of what you’re doing. So every single hour you put into a project, is impacting the cost of that. Code has a life cycle to it. It has a cost to it. So I try to come up with ways to teach people to think, not only about the profession of building, the actual building of code, but how can you build it more efficiently, more effectively? There’s a cost to that. Now if I was spending my time out searching for snippets of code, how productive am I being? I’m looking and I’m trying to ascertain - does this work for me, does that work for me? And then you go and you pull it in your code, and it has a side effect. It wasn’t built for your solution, your use case.
So you put it in, and if you don’t understand the why of it - all of a sudden, you may get this side effect that pops up. And maybe it’s popping up somewhere else, and you’re not understanding why. So then we end up with little band-aids all over the place. “Okay, I squashed this bug, and oop, it’s going to pop up it’s ugly head over here.” So I’m a big proponent of not spending your day out there Googling for solutions. I’m more into - understand the why of it, understand the intent of it, understand the fundamentals of it - and then get down, put your head together, find a team, work within a team. You have ideas to be able to share with other people, and bounce ideas off - and start writing that code.
Len: Moving on to the subject of your book, which I think is related to what we’ve been talking about, it’s called, Refactoring Tweaks, and I was wondering if you wouldn’t mind talking a little bit about who that book is for, and what it is that you go about explaining in there?
Tonya: Sure.
Len: I really like the in-depth argument about refactoring.
Tonya: Refactoring is the process of taking code that’s working, and making it better. You’re improving it, you’re cleaning it up, right? You’re going to put in the steps that do this. Make it more readable. It makes it more reusable, and it makes it more maintainable. Those are the key factors of what you’re trying to do when you refactor something. You’re just improving your code. Improving code is going to lower the cost of that code over its life cycle, wo that we can then turn around and reuse it again.
If you can picture that - okay, if I’ve got this code, and let’s say I have a function that’s 200 lines long. Well, first of all I’m going to tell you, it’s probably doing too many things. But if I’m looking at that, and a bug happens - I wrote it, but I’m typically not going to be the person that maintains it. So it gets passed a long way, a bug pops up - and it’s taking too long for people to be able to go in and fix these problems. And maybe it’s impacting something else. We all know these horrors if we’ve been in software long enough.
What the book is about is this: you can go and read a technical book, and I’ve got some great ones right here in my library - on refactoring. They’re very, very technical. They go into big words, and big descriptions. And code that maybe you’ll use, and maybe you won’t. Well what I did instead was, I tried to make things more relatable. I start where you’re at. And I say, “I don’t care about big words. I want to get down to the nuts and bolts. Here’s a problem. Why is it a problem? Let’s talk about why. Why is this the way it is? What’s the intent of it?”, and walk through a thought process. And what Refactoring Tweaks does, is it gives the simple solutions that you can say, “Okay, here’s some clues that tell you, you might have a problem. And now here are seven different - and I actually threw a couple of extras in there - seven different things that you can go do right now, in your code. These are simple, easy, they’re going to make it better.” And then the workbook then takes that, and I say, “Okay, here’s a code challenge.” There’s going to be seven of them.
And then there’s a total solution, where I walk you through the thought process. I want you to hear from the way I think about code, to be able to say, “Okay, step one: Do you see this? Well why? Why is it like that? What can we do to make this better? And then we step, by step, by step, we walk through the process of the why, the how, the when and the what.
Len: With respect to process, I’m really interested in asking you about the process of making the book itself. It’s a beautifully formatted book. You used our “Bring Your Own Book” feature to upload it to Leanpub’s bookstore. I saw in your book that you mention you had five collaborators on it, including a cover designer, editors and proofreaders. I was wondering if you wouldn’t mind talking a little bit about that process of making the book with a team of people, and, how did you assemble your crew?
Tonya: Well my crew has been with me since I started really out there teaching in the WordPress space. These are volunteers. If you can believe it, WordPress people give of their time to help other people. These people have been here with me. They give of their time. And then I give back to them. I help them with their projects, I teach them, I help them to be able to be better. So it’s a give and take.
I came to Leanpub, because I buy books from Leanpub. I like the idea of ship early, ship often. It fits within that. But there’s also - with Leanpub, you can use the tools that are built in, to then do a minimum type of publishing. It’s a very lean process. Well, I shifted that model for myself. And I said, “Okay, how can I use the platform then for me? For my purposes?” I like things to be visually pretty. Something that you want to pick up and read. It’s not just a white page of words. Instead it has color. I can then callout sections, and be able to emphasize those to say, “Hey, here’s a master tip. Here’s a what if.” And I can pull those out, and add some color to them, to make them pop as a sidebar. So that visual sense in my mind, that user experience.
The total platform’s not going to work for me. But you guys built it in a way that I can still ship early, ship often - get the content out as I write it, get feedback. But then I can produce it the way I want to produce it - which is well-edited, beautifully-designed, and bring my own book to the platform. I’m still within what the intent of the platform is. I can get the information and the ideas out. I just twisted it to fit my needs and the way I like to work.
Len: As I said, it’s a really beautiful book. There’s one page in particular that I really love. On the top half, it has an image of a kind of really dilapidated and risky-looking suspension type bridge, like an Indiana Jones-style bridge across a chasm, or a river I guess in this case. And you say something along the lines of, “It looks like it works, but do you trust it?”
Tonya: Right.
Len: And I thought that was a great metaphor for looking at code. I imagine - I mean, I’m not a developer myself, but I can imagine you look at some code, and you’re like, “Okay, I know this product works, but my God - venturing out onto this thing is going to be much more challenging than another one.” You can just look at it and see the difference.
Tonya: Yeah, and that was the whole point behind that page. I use that in talks that I do too. There’s code that just works. That doesn’t mean it’s quality code. And that picture right there brings that point to mind. It’s a bridge. There are boards. “What do you - when a problem happens, do you want to be the one to step out in the middle of it, and fix that board?” Well I know I wouldn’t want to. And then it shows you a picture of a beautifully engineered bridge that’s safe, secure, and does the same thing. They both do the exact same thing. They’re both working bridges. And that’s the point of refactoring.
Len: The workbook that you’ve published, along with Refactoring Tweaks, I believe is about 70% finished?
Tonya: Yes.
Len: I’m sorry I don’t know the answer to this, but did you publish, Refactoring Tweaks before it was finished also?
Tonya: Yes. I actually went through the process of, I think at first was maybe 20% that I put out there. And then as I went along, I think there were maybe four different releases to that one - if I remember right. And then the workbook itself will have a couple of different releases to it. It’s actually - the biggest chunk of it’s off in editing right now, and then we’ll be releasing that later this week.
Len: And have you been incorporating feedback from people? Are you inviting feedback from readers?
Tonya: Absolutely. Each person that has signed up for it, they’ve been very kind with their time, to come back and tell me what they think. I always tell people that, “You don’t need to blow wind up my skirt, just tell me like it is. If there’s something you like, great. But I’m more interested in those concepts that didn’t quite resonate with you. Maybe you didn’t quite understand it, because that means I need to go back into that and do something a little bit different - to make sure that it resonates with everybody. That it’s explained well.”
Len: And how do people communicate with you?
Tonya: There’s multiple different ways that people can reach me. I have a Slack group that people talk to me on. They can get me there. They can get me on email. They can get me from the different contact forms. I make myself very, very accessible to people.
Len: I’ve heard this from two or three people now, with Slack channels that they have set up around book development. Which is just such an interesting shift from the old “write in stealth mode, and then release the finished doorstopper” method, to having a live Slack channel, where you can interact with the author, and where they can see what people have to say about their books.
I guess the last question I have about your book is - I believe it’s the first in what you’re planning to call, “The Little Green Book Series..” I was wondering if you could talk a little bit about that? We’re really interested in promoting series of books on Leanpub.
Tonya: Oh sure. Green is my favorite color. But green also means money. And so what I do is, I try to help you to go out and be more profitable. Make more money. That’s the whole point of what “Know the Code,” is. It’s a profession. If you do it well, you’re going to make more money. So, “The Little Green Book” series is this. They’re very short books. They’re 100 pages or less. Somewhere around the 100 page mark. They talk about a specific topic, they’re easy to digest. They get rid of all the jargon and stuff that makes it less consumable. Beause then you have to go and explain - well what does the jargon mean? What’s this, what’s that?
Instead, it just gets down to the points. And the whole premise of these are this: We’re going to teach programming, and we’re going to teach business skills, to say - okay, I ran multi-million dollar companies. I’ve run big, huge projects of tens of millions of dollars of things. There’s a process there, so I can teach people in that space too, to be able to say, “Okay, this is how you market yourself. This is how you do this. This is how you do that.” And give them discernible skills that when you read the book. “Do this chapter, I read it - and now I have a skill set from that. I can go and apply it right now.”
That’s the whole point of “The Little Green Book Series.” Quick, easy, and something that you can pull into your workflow, your business, your work space - and be able to do it right now.
Len: That’s a really, really great idea. I’m looking forward to seeing all the forthcoming books in the series.
I was wondering - just very selfishly - the last question I ask in interviews is always - if there’s anything we could build for you, or fix in Leanpub, if there was any one thing you could pick, is there one thing you’d like us to do or like us to fix?
Tonya: Well I think that some folks would love to have more styling control over things. The ability to be able to add anything in. Even, like I said - just to have the callout. So there are sidebars that you put in, to be able to emphasize something that’s not within the direct workflow of what you’re talking about. It’s a sidebar, it’s more information. The ability to be able to have those sidebars in there, because you can do information, questions - those types of little blocks. But they don’t really pop off the screen as well as they could. If there’s a way to put some sort of styling around - a little background, a little border - some way to be able to differentiate that this is outside the flow of the content. I think that would help a lot of people.
Len: Thanks very much for that suggestion. I loved the callouts that you did in your book. You’ve got a lot of really fun icons, and they definitely pop. I think there’s one - a coffee mug, which I really liked. Thanks for that suggestion.
That’s something we always try to think about. One of our basic approaches to publishing - that’s why we’re called Leanpub partly - is formatting is procrastination while you’re writing. But it’s definitely not when you’re ready to finish your book. And it depends on everybody’s individual process as well. But your book is so nice, and I think we might take some inspiration from it.
Tonya: The callouts are something that even when you’re in the process of writing, you know that this is a callout, right? It’s a separate side bar of information. So something like that, in somebody’s eyes as they’re reading it too - it would be nice to just have a way to be able to discern that, “Oh, okay - this is extra information, and not in the content flow.” I can skip over it if I want to.
Len: And as I understand it, that’s a well-established convention in programming books, right?
Tonya: Yeah.
Len: Alright well - thanks very much for telling us your story and for telling us about your book, and your approach to teaching, Tonya. And thanks for being in the Leanpub Podcast, and for being a Leanpub author.
Tonya: Oh thank you. I really love Leanpub, guys. Get out there and buy more books.
Len: Thanks.
Tonya: Thank you.
Leanpub Podcast Interview #41: Victor Savkin
published Dec 20, 2016
Victor Savkin is the author of Angular 2 Router: The Complete Authoritative Reference. In this interview, Leanpub co-founder Len Epp talks with Victor about his career, his book, and his experience self-publishing on Leanpub.
This interview was recorded on September 7, 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.
Victor Savkin
Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub Podcast, I’ll be interviewing Victor Savkin. Victor works at Google, and is an Angular core team member, and the main contributor to the Angular router. He also has interests in functional programming and client side applications. When he’s not working on Angular, Victor enjoys playing around with eclectic programming tech, and he has a particular interest in fonts and keyboard layouts.
Victor is the author of the Leanpub book, Angular 2 Router: The Complete Authoritative Reference. In his own words, the book “goes far beyond a how-to-get-started guide and talks about the library in depth. The mental model, design constraints, and the subtleties of the API - everything is covered.”
In this interview, we’re going to talk about Victor’s professional interests, Angular, his book, and his experience writing and publishing.
You can read Victor’s blog at vsavkin.com, and follow him on Twitter at @victorsavkin.
So, thank you Victor for being on the Leanpub Podcast.
Victor: Thank you Len, thank you for having me.
Len: As you may know from listening to a couple of our podcasts, I usually like to start interviews by asking people for their origin story. I was wondering if you could tell us how you first became interested in doing the kind of work you’re doing now, and how you came to work for Google on Angular?
Victor: Sure. Originally I’m from Russia, from a city called Vladivostok. So I went to college there, and I studied maths there. As a teenager, I was really interested in two things - programming and productivity. So I was playing with computers, like books and games and small apps, as everyone does - when I was a teen, I guess, fifteen, right before I went to college. At the same time, I was reading a lot about productivity - lots of books, articles, podcasts.
The reason why I was really interested in this topic of productivity, is that, I grew up in a small village near Vladivostok, and I went to a very mediocre school. So I thought, “If I apply myself and if I like manage my time well, manage myself well, I will be able to perform well with like kids from better schools - from excellent schools.”
So in a year, I wrote my first professional app, which was a productivity tool - the most convoluted and over-designed to-do list you can ever imagine. It didn’t sell really well, so it wasn’t very successful. Then I had my own startup, which failed super quickly. I’ve been through a bunch of companies working as a programmer, doing lots of different things. Like back end, front end, middleware.
Then I moved from Vladivostok to Toronto, Canada, and after a few years, I got this opportunity to work on Angular - to join the Angular team at Google.
Angular is an extremely successful open source project. I think over a million developers right now are actively using it. It’s a framework developers can use to build rich apps in JavaScript. So this opportunity was really exciting to me, because I knew that I can sort of get back to what I liked as a teenager - which is making people more productive. But here, instead of helping them manage their time efficiently, I can help them build their apps more efficiently. So I jumped on this opportunity, and moved to San Francisco, to live and work on Angular.
That’s basically what I’m doing right now. I’m trying to make [developers] more productive. Trying to make their life easier, less painful. And I do that by like making Angular.
Len: I’ve looked into this space a little bit myself, and I was wondering if you could explain a little bit about what your to-do list, what your app was all about?
Victor: Oh the first one. Oh boy, oh boy. I actually liked the space a lot. And the first app - I think I had a few core ideas. The first one is, instead of having the single, regular list, I had different views to look at the list. So you can have different perspectives per se. One would be like a tree-like structure, where you can organize complex projects and complex ideas - and link connections between them. Then you can project that complex tree like structure into a bunch of flat lists, so you can actually execute it and like sort of check it off one by one.
I also had an idea about eating frogs, doing unpleasant things. So in the app, you could mark certain things as unpleasant, because the app will force you to do unpleasant things first, like in the morning. So the rest of your day is not as painful as the first like one or two hours, when you did all the unpleasant things.
Len: I was going to say, that’s a really fascinating aspect of productivity. I was interviewing someone recently named Janelle Klein. Part of her approach is measuring pain. One of the things she does in her analysis is to have developers describe - like they just click one of three buttons, about the type of work that they’re doing, and she’s done a lot of really interesting work on that aspect of how to analyze productivity, and maybe change people’s work practices.
Victor: It’s actually one of my main interests even at the moment. I measure my productivity from morning till night, and I schedule my work based on where during the day it fits. For example, the first couple of hours in the morning, I find I’m the most productive. After I woke up, have a cup of coffee - usually like four or five shots of coffee - for three hours, I’m like a machine. I can do a lot of coding, I can think through complex problems. And then the productivity goes down, and I do more mundane, simple routine tasks. It’s interesting, if you’re organized, you work in this way, how much more you can accomplish, having the same amount of time.
Len: And what was your first startup, the one you mentioned briefly?
Victor: I was a teenager, like a lonely guy. A little bit nerdy, and I was lonely. So it was a startup for lonely people who wanted to talk to each other. It was called, “Let’s Talk.” Basically the idea was that you’d go on the startup, like go to a page, and you type in something like, “I want to talk about this.” Like let’s say I read Hemingway, “I want to talk about this book, a lot. To someone who is around my age. Someone I can relate to.” And the app would match you with someone who has this interest at the moment, and also is active, like online right now - or who was recently active with his interest. So hopefully you can connect within a day, and you can connect with a person to discuss this subject you deeply care about. It failed, mostly because Russia is just crazy, and super hard to get money. And I was very young too, so I didn’t play my cards right.
Len: I was going to ask - I know you’re in the United States now, and you were in Canada for a while before that, but what’s the culture like around startups in Russia? Is it something that is part of the popular awareness? Is it niched, or is it something that’s growing?
Victor: I think it’s very niche, even at the moment. A few companies appear and disappear from time to time. But at no point you can get money as easily as you can get here. I think here if you have a good idea, and have a bunch of engineers who are talented - most likely you can get some amount of money to work, let’s say, for half a year. That is almost impossible [in Russia]: you need to have friends or very personal connections with someone who has money. And I think it’s a little bit frowned upon. In general, Russians don’t take risks as much as, let’s say, Americans or Canadians. So it’s not part of the culture. Russians value safety a little bit more - and as a result, startups are not as common I guess.
Len: And is there a, I guess, what you might call it, a STEM culture for people who are thinking about what to do for, say, university studies in Russia? Is there a culture of approving of people who move into science, technology, medicine and things like that - as opposed to other types? I know it’s a very broad generalization that I’m asking you to make. But, for example, if you’re interested in computers, is there a cultural pull towards certain types of things rather than other things? Especially given there isn’t maybe so much of a startup culture there.
Victor: I don’t in general engineering culture is as dominant in Russia as it is here, especially in California. There are obviously a lot of programmers who are talented and successful there too. But I don’t think - at least I didn’t feel I was part of the engineering culture at any point. I was just a programmer who managed to do some programming at a company I worked for - a bunch of companies actually. But at no point [did I feel that] connected to my peers, peers in the broader since, as I do, for example, here or I felt in Canada.
Len: And how did you make your way to Canada? Why Canada?
Victor: In general, Canada has a very straightforward immigration system, that’s part of it. You can fill in a form, there is no lottery. Once you get enough points, you have a good education and good experience, you’re very likely to get the PR card, which is basically like a green card in Canada. And I like Canada a lot. I’m a lot more left-wing, in terms of my political views, so I think the way Canada functions and runs as a country, is a lot closer to me, than for example the States. So Canada is still my favorite country. I just happen to be in California.
Len: And I have to ask - how was your first Canadian winter? Was it totally familiar?
Victor: It was basically the same as Russian winter, so I wasn’t surprised at all. It actually felt good. The day, it’s about the same - it’s super cold, your phone doesn’t work outside because it’s that like super cold. I think there is an element of. “Huh, I am again to nature.” It’s so cold - the wind, the snow. For a couple of days, it actually feels really good. Then you get tired of it.
Len: Yeah, I know exactly what you’re talking about. And so you eventually made your way to the west coast. Did you apply to Google, or did they approach you?
Victor: Google approached me. I joined Google because they approached me.
Len: Just very generally, what’s it like working at Google? I’m sure there are people listening who’ve worked there themselves, and people who have thought about it, and would like to.
Victor: I really like Google as an employer. I think it’s a great company to work at. It’s very comfortable. A lot of day to day stuff I had to take care of before, prior to joining Google, I don’t have to worry about at Google at all, as it’s taken care of by someone else. So I can focus on engineering and chatting with my co-workers and friends and whatnot. I think it’s a great company if you want to do engineering, and you want to delegate all this extra stuff to someone else. I think Google is a good place. There are a lot of interesting projects. Food is free, but I don’t think the food is free is the main thing. It’s just an example of - when something’s taken care of, you don’t need to worry about it, so you can only worry about your project.
Len: That sounds like a fantastic environment. I mean, for an employer to deliberately take away that stuff, for psychological reasons.
Victor: Exactly.
Len: Is a really interesting move, I think something that’s often misinterpreted - especially by perhaps grumpy people from generations who didn’t enjoy what they see as perks, and sometimes can’t see [them] as the hard core productivity moves that they are.
Victor: Yeah, I think it actually affects productivity a lot. Even though sometimes, I miss going to restaurants - previously when I lived in Toronto I would go to a restaurant for lunch, or like a fancy coffee shop. And here like, well, it’s still good, but sometimes not exactly the same. Slightly less hipster.
Len: So on the subject of Angular, let’s imagine not everyone who listens to this podcast is in tech. If you were to explain to someone what Angular is, could you give it the two minute or five minute description?
Victor: I would say Angular is a set of tools and libraries you can use to build a client side application. Like, let’s say Gmail Inbox, this kind of application. And this application’s all interactivity. You can build it using Angular fairly efficiently. I think it’s probably one of the best tools, if you want to get started and build something quickly, like within a few weeks. You can use Angular, and if you have some programming experience, most likely you’ll succeed at building something that actually works. It gives you the sense of - I do it right now, in a day. Something actually runs, and I can click around, and the application functions, which is a very rewarding experience, especially for a lot of developers who are new to the industry. They’ve just started, and they want to feel this immediate feedback of, “I tried it, and it works.” So Angular provides that.
So I think with Angular 2, the newest implementation of the framework, we tried to keep that feel of “it just works”, but adapted it so it works for larger projects and larger teams. Because Angular 1 was known to work excellent for smaller projects, but sort of miss a few things here and there when your project grows to about, let’s say 50,000 lines, 100,000 lines. You have like 20 developers working on it at the same time. Suddenly there are a few things that were not designed sort of exactly right for the situation. And I think Angular 2 solves this problem a lot better.
Len: You write about something called “dead code elimination”, which, I gather, is to help efficiency. I was wondering if you could explain a little bit about what dead code elimination is?
Victor: The idea is that, if you are consuming a lot of JavaScript libraries - let’s say you consume Angular itself - and all the other components from different libraries, If you don’t use dead code elimination, what’ll happen is, you’ll have to shape all this code to the client, to the browser, for the application to run, to bootstrap. And it can be a lot of code. So if you’re on mobile, and you have not a very good connection, it may take a lot of time just to deliver the code. And then to run it, actually. To scan it, to parse it and whatnot.
So dead code elimination looks at your code, and sees which parts of your code can not be reached in principle. So let’s say it looks at a component, or like at an ES6 module, the JavaScript module, and this module is not used at all in your app. It happens to be a part of the same library, but we can statically deduce - like analyze a code, and statically decide that it’s not used - so we can then remove it from the production bundle. We can drastically reduce the size of your application, so you can ship it quicker to the phone of your user.
Len: And is this something that’s happening continuously? Or is it something that you do periodically?
Victor: I think it happens, like it depends on your sort of dev stack. So it happens before you ship to production, essentially. So during development, you can still do it. For all sorts of reasons, maybe for performance analysis and whatnot, before you ship to production, you run a special tool that will remove code that we know for sure is not going to be used. And we’ll minify the rest of the code, optimize it. So the deliverable is smaller, and they can ship it quicker to your customers.
Len: Could you explain also a little bit about what the router is that you work on?
Victor: Router is the latest project I worked on. And I can talk a little bit about what routers do in general. Because the word router is so generic, it may mean a lot of things. I think that a big part of any application development right now, is trying to manage state, and manage state transitions. And doing this is actually very hard, especially on the web, because on the web we want to ensure that the state of your application - at least a substantial part of it - is reflected in the URL. So you can copy and paste, and the back button works and whatnot.
If you want to provide a good web experience, the URL has to match the state of your application. This synchronization is nontrivial. In addition, we often want to split your application into multiple chunks that we call bundles, multiple bundles, so we can ship only the first bundle to a customer in bootstrap. And then we can load lazily, the rest of your application. So the bootstrap time - the time to the first interaction is a lot quicker. Doing all this transparently, is actually like fairly hard. And that’s what the router is doing.
So using the router, you can declaritively specify the states in which application can be. You can manage state transitions, and the router will take care of synchronizing your transitions with the URL. So the URL will always match, and the router will load other bundles on demand, in a transparent way. So you as an application developer, you don’t need to worry about it too much. It sort of happens. While the user is navigating through your app, more and more code will be fetched from the server, and different parts of your application will be bootstrapped.
Len: Specifically you write about the concept of a route state, and I was wondering if you could explain a little bit about that as well?
Victor: A route state is - it’s somewhat nuanced. As an application state, it can include a lot of things. You can for example have the state of your UI component - something can be highlighted, something can be scrolled, like a particular button can be in a particular state - and that’s one part of the state. The other part is what’s actually being shown. Let’s say, if you go to an inbox, or a mail app - what you can see is a particular message is being opened. Or if you open contacts, you are chatting with a particular person. What exactly you’re typing in transiently - it doesn’t really matter. But what matters is, what message is open - who you’re chatting with.
So that part of the state, the system state, is what I refer as the route state. Because it’s captured in the URL, it’s part of what router deals with. You should be able to copy it, paste it, and send it to your friend. And if friends open it, the friend should see the same message being opened at the same chat window or whatever, being opened. Even though some details of where it had been scrolled to, or what was selected, ia not represented, it’s good enough.
Len: And Angular 2 has a particular focus on mobile, if I’m not mistaken?
Victor: Yeah.
Len: I think I read somewhere, maybe it was on your blog, that you optimized for mobile first before say a web application or a native app. Is that correct? I was wondering if - I mean, it’s probably pretty straightforward, but what’s the argument for designing something like this to be mobile first?
Victor: So I think that mobile puts a lot of constraints onto what you can do. The main constraint is how to fetch large resources from the server, because your connection is usually spotty. So as a result, things like tree shaking can matter a lot. Or things like lazy loading, when you can ship only like 20% of your app right away, and it boots, and you can interact with on your phone already - while we’re getting more and more stuff from the server.
Whereas on desktop right now, we have very powerful connections. You can ship like megabytes within like half a second. So I think the size of your app, after all the manipulation is done, the size of your first chunk of your app we need to ship, is what makes a lot of stuff mobile-friendly.
And the second part, which makes it mobile friendly, is the ability to work where there is no connection at all. That’s when your at subway or whatever. But the router doesn’t deal with that. There’s other parts of Angular, and other parts of the infrastructure take care of that.
Len: That’s really interesting, and a really powerful argument. Was there push back from the community when this mobile first focus was first launched?
Victor: I don’t think so. I think most people would realize at this point that most consumer apps or consumer websites have to work on your phone. And so it happens it’s much harder to make it work on your phone very well. So a good experience on your phone is a lot harder to achieve. If you can do that, then making it work on desktop is usually fairly straightforward.
Len: That reminds me about a story I heard about another company near you, that would throttle internet speeds to its own employees, to give them the experience of what it was like accessing from a network, in a place with bad connections, and how that was meant to really drive a focus on the efficiency of how everything worked - and being sympathetic to that experience as well.
I was wondering if you wouldn’t mind talking a little bit about the future of Angular 2, and what can - is there anything you can tell us that people can be expecting to see in the short term?
Victor: Alright so, the future of Angular 2. The first thing we are focused on right now, at the moment is shipping final. So we are very close, and hopefully within a few weeks we’ll be able to ship the final version of Angular 2, at which point we will sort of freeze the API Note: The final version was released on September 14 - eds.]. The API will be stable for at least half a year. We’re going to, of course, make adjustments, fix bugs and whatnot. But you will be able to rely on the framework and build your apps knowing that nothing under you will change. So everything should be only better during this period. The framework should be faster. We are going to work on our compiler, to make the deliverable smaller. We are going to improve the router for example, to handle some of these cases we do not handle right now very well. But overall it will be stable. It’ll be a good platform on which you can build your applications.
Len: You mentioned in the introduction to your book, that you’re going to keep it up to date with future releases of Angular 2, and changes to the router. I was wondering if this is the reason, or one of the reasons you chose to publish your book on Leanpub in the first place?
Victor: Yeah, it’s a good question. So there are actually, I think three reasons why I picked Leanpub over a traditional publisher. And that was one of them. One of them is that because I work in open source, I got fond of the idea of publishing early, and publishing often. So getting something out there, which is like 80, 90% ready can provide a lot of value to many people. And then you can get feedback from those people and improve it. It’s a good way to make your product or your book a lot better. It probably won’t work well for fiction, but it works great for tech books. It’s just perfect for tech books. So that’s one reason why I chose Leanpub.
The other reason is, I read a lot of books that are published by Leanpub. And many of them had very, not narrow, but they were very focused. They are about one thing. So you buy a book, and it’s just about one topic which you care about. Often if you buy a book from a traditional publisher, not half, but maybe 30% of the book is filler. And I respect my readers’ time a lot. I want them to spend the least amount of time they can reading my book, and extract everything they need.
I know I’m not Hemingway. They’re not reading it to enjoy the language. They need to extract value from my book. And if I publish via Leanpub, I can make the book as short as I want, and just cover one subject, which is the router. I don’t want to have some nonsense chapters about how to set up npm and whatnot. You can find online already, in other places. You probably already know. That’s why I picked Leanpub.
And the last reason is that, as a programmer, I’m very happy with the tech side of things on Leanpub. I have my own GitHub repo, which I push my updates to. My friends and my co-workers can comment on those. We don’t need to send each other any documents. Basically, the best practices I am accustomed to as a programmer, I can use while working on my book. Which is version control, diffing tools and all that stuff.
Len: That’s really a fantastic point is about filler. One thing I think a lot of people who aren’t so familiar with the publishing industry don’t know is that a book store is basically a physical competition for space, and for visual space in particular. One of the reasons books can sometimes be so fat is that they’re squeezing out other books from the book shelf, and they’re displaying their spine, or even their front if they pay for that privilege. And so books literally get bigger, because the book itself is an advertisement prior its being purchased. Tt’s a sort of a weapon against the other books.
I wanted to ask you about the process of publishing in-progress. Your book is currently marked at 95% complete, I think. I was wondering what percent complete was it in your mind when you first published it?
Victor: I think it was about 80%. So I was planning to write I guess about twelve chapters, and I had about ten. And a few screen shots here and there were missing. And the examples were somewhat correct, but were not exactly right. So I would say, you could still read it, and learn almost everything about the router at that point. I could still provide a lot of value to many people. That’s why I published it so early. But it wasn’t done. And right now, it’s 95%, because I’m finishing the last chapter, and I just want to make a few things here and there slightly better - then to do 100%, and to be fully complete. But afterwards, I can still improve it. I can still publish new versions, like adapt the book to the new versions of the framework or the router.
Len: I was wondering too how you incorporated feedback. So for example, you say you had actually people doing comments on your GitHub repo. Did you invite people to do that, or did people just find it through your book?
Victor: So a few people, because I am part of the Angular core team, a few people were very interested in making the router successful. So I asked them to look at my book, to look at my pull requests and make sure that they are coherent, that I convey my information in a succinct way, and somewhat correctly. But a few people approached me from my readers, and asked, “Hey, I found a few issues with your book. How can I give you feedback?” And I just gave them access to my repo, so they can comment and whatnot.
Len: We’ve got a few authors who do that a lot, also somewhat surprisingly, given the power of GitHub. For a lot of people email works quite well as well. They can even start little conversations.
I mentioned in the introduction, and from what I read about your self-description online - that you’re into keyboards and fonts. We are in our own way picky about writing tools and things like that, and I was wondering if there’s anything that when you were using Leanpub, you would like to be picky about and maybe give us a suggestion for a way we could improve it. I mean, we let you use your own tools, obviously, and we’re sort of as broad as we can be on that level. But if there was something in our process that you think we could improve, or something new we could build. Do you have any suggestions?
Victor: I’m thinking about it. It’s hard to come up with a suggestion on the spot. Because I think the process was actually very good. It was fairly easy to get started. It took maybe half an hour to set it up, super quick.
I think it’s actually pretty good already, much better than I expected, because I heard so many horrific stories about publishing. How hard it is, how much pain you have to go through. And it’s probably the case with traditional publishers, but my experience with Leanpub was very pleasant.
Len: Not to disparage anyone, but there are just structural things about the conventional publishing process which is still historically all sort of around print. There are lots of timelines and people on a team who might not necessarily seem all that necessary to other people. And I guess I’m going to say it, in 2016, there’s lots of legacy in the process.
In particular, I think that people who are used to writing - who are technical, and who are used to writing about technical things - they don’t want to have to get in a fight to get a typo changed or updated. They just want to be able to like make the change, and get it out to people.
I wanted to ask you another question. Looping back around to the beginning of our discussion before we go. As someone who’s into productivity, what’s your opinion of Slack?
Victor: I actually use Slack, and I think it’s a good tool. Comparing to other tools in the market, I think Slack is a great tool. I use it a lot to chat with my teammates, and to interact with people from different teams who use Angular. In general, I find asynchronous communication very hard to get right. I think it’s obviously useful, but it has to be a part of your team’s culture more than any particular tool. And I think in our case, a huge part of our culture is actually being in the same room, like 20 of us in the same room. So it’s very hard to ignore that, and always use Slack, when you can just turn around and chat with a person. So I think Slack can be more useful for other teams. I think it’s useful for Angular team, but may not be the most important tool for us.
Len: The thing that I get preoccupied with when I think about Slack, is the fact that it doesn’t have replies yet. And so, there can be three conversations going on in the same channel amongst many different people, and it seems to me to quickly degrade. And what people do in practice, is they end up - whether it is just turning around or getting a meeting room. They end up having to diverge away from it anyway.
But of course, it’s so well designed, and it’s so easy to use, that that makes up for a lot of the disintegrating conversation issue, which I’m sure they’re probably thinking hard about and taking their time to solve, because they have it.
Well, thanks very much Victor, for doing this interview. I really enjoyed hearing your story about Russia to San Francisco - Vladivostok to San Francisco via Toronto. And I wanted to say thank you for also being a Leanpub author.
Victor: Right, thank you. Thank you for having me.
Len: Thanks.
The December 2016 Leanpub Book Sale!
published Dec 15, 2016
We have decided to invite Leanpub authors to add their books to mid-montly sales every month going forward. Below is a list of the books participating in the sale for December. The sale lasts to the end of Monday, December 19.
Have fun checking out these great deals!
Authors often announce sales and promotions on social media. Follow Leanpub on Twitter for a better chance of discovering new authors and new books!
– Posted by Len Epp
