The Leanpub Blog: On Writing, Publishing, Self-Publishing and Ebooks

Leanpub Podcast Interview #43: Thad McIlroy

by Len Epp

published Jan 16, 2017

Thad McIlroy

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

by Len Epp

published Jan 10, 2017

Tonya Mork

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.

Refactoring Tweaks: 7+ Easy Wins to Make Your Code Better & Increase Your Profits

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

by Len Epp

published Dec 20, 2016

Victor Savkin

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.

Angular 2 Router: The Complete Authoritative Reference

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!

by Len Epp

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!


Exploring Mac App Development Strategies: Patterns & Best Practices for Clean Software Architecture on the Mac with Swift 3 and Tests Author: Christian Tietze
Book: Exploring Mac App Development Strategies: Patterns & Best Practices for Clean Software Architecture on the Mac with Swift 3 and Tests
Regular Minimum Price: $7.99
Sale Price: $5.00
Discount: $2.99, 37%
Link: https://leanpub.com/develop-mac-apps-clean-architecture-swift/c/XMAS
Cognitive Productivity: Using Knowledge to Become Profoundly Effective Author: Luc P. Beaudoin
Book: Cognitive Productivity: Using Knowledge to Become Profoundly Effective
Regular Minimum Price: $15.99
Sale Price: $5.99
Discount: $10.00, 63%
Link: http://leanpub.com/cognitiveproductivity/c/Xmas-Sale-CogZest
Painless Tmux: A Sane Person's Guide to Command Line Happiness Author: Nate Dickson
Book: Painless Tmux: A Sane Person's Guide to Command Line Happiness
Regular Minimum Price: $4.99
Sale Price: $2.49
Discount: $2.50, 50%
Link: https://leanpub.com/painless_tmux/c/midwinter
Painless Vim: A Sane Person's Guide to the World's Most Powerful Editor Author: Nate Dickson
Book: Painless Vim: A Sane Person's Guide to the World's Most Powerful Editor
Regular Minimum Price: $5.99
Sale Price: $2.49
Discount: $3.50, 58%
Link: https://leanpub.com/painless_vim/c/midwinter
The Developer's Edge: How to Double Your Career Speed with Soft Skills Author: Zsolt Nagy
Book: The Developer's Edge: How to Double Your Career Speed with Soft Skills
Regular Minimum Price: $14.99
Sale Price: $9.99
Discount: $5.00, 33%
Link: https://leanpub.com/thedevelopersedge/c/InterviewSeasonIsComing
ES6 in Practice: The Complete Developer's Guide Author: Zsolt Nagy
Book: ES6 in Practice: The Complete Developer's Guide
Regular Minimum Price: $12.99
Sale Price: $6.99
Discount: $6.00, 46%
Link: https://leanpub.com/es6-in-practice/c/LaunchDiscount
The essentials of Object Oriented PHP: Learn, practice, and apply Author: Joseph Benharosh
Book: The essentials of Object Oriented PHP: Learn, practice, and apply
Regular Minimum Price: $4.99
Sale Price: $2.99
Discount: $2.00, 40%
Link: https://leanpub.com/the-essentials-of-object-oriented-php/c/rPxdhu0cbrYd
Learn Ruby on Rails: Book One Author: Daniel Kehoe
Book: Learn Ruby on Rails: Book One
Regular Minimum Price: $9.99
Sale Price: Free!
Discount: $9.99, 100%
Link: https://leanpub.com/learnrubyonrails/c/Pt9leMATqGFx
Presenting for Geeks Author: Dirk Haun
Book: Presenting for Geeks
Regular Minimum Price: $3.35
Sale Price: $2.00
Discount: $1.35, 40%
Link: https://leanpub.com/presenting-for-geeks/c/MidDecemberSale
Applied Electronics for Bioengineers: A first (and possibly last) course in electronics Author: Kevin Karplus
Book: Applied Electronics for Bioengineers: A first (and possibly last) course in electronics
Regular Minimum Price: $3.99
Sale Price: $3.49
Discount: $0.50, 13%
Link: https://leanpub.com/applied_electronics_for_bioengineers/c/2016-Dec-sale-PpGjRr4LSjrr
Java 8 Programmer II Study Guide: Exam 1Z0-809 Author: Esteban Herrera
Book: Java 8 Programmer II Study Guide: Exam 1Z0-809
Regular Minimum Price: $11.99
Sale Price: $5.99
Discount: $6.00, 50%
Link: https://leanpub.com/java8-programmer-ii-study-guide/c/avnN5BJ05hRO
The BPMN Graphic Handbook Author: Esteban Herrera
Book: The BPMN Graphic Handbook
Regular Minimum Price: $6.99
Sale Price: $3.49
Discount: $3.50, 50%
Link: https://leanpub.com/thebpmngraphichandbook/c/TvP3zL8FiVX2
Programming for Kids Author: Peter Armstrong
Book: Programming for Kids
Regular Minimum Price: $19.00
Sale Price: $5.00
Discount: $14.00, 74%
Link: https://leanpub.com/programmingforkids/c/December
The Aremac Project Author: Gerald M. Weinberg
Book: The Aremac Project
Regular Minimum Price: $6.99
Sale Price: $2.99
Discount: $4.00, 57%
Link: https://leanpub.com/thearemacproject/c/K3nfLNOwvQZl
Make Money Outside the Mac App Store: How to Sell Your Mac App with FastSpring, Secure It With License Codes Against Piracy, and Offer Time-Based Trial Downloads Author: Christian Tietze
Book: Make Money Outside the Mac App Store: How to Sell Your Mac App with FastSpring, Secure It With License Codes Against Piracy, and Offer Time-Based Trial Downloads
Regular Minimum Price: $19.99
Sale Price: $10.00
Discount: $9.99, 50%
Link: https://leanpub.com/sell-mac-app-fastspring-cocoafob-license-trial/c/XMAS
Practical Data Cleaning Kit: 19 Essential Tips to Scrub Your Dirty Data (and keep your boss happy) Author: Lee Baker
Book: Practical Data Cleaning Kit: 19 Essential Tips to Scrub Your Dirty Data (and keep your boss happy)
Regular Minimum Price: $15.00
Sale Price: $7.50
Discount: $7.50, 50%
Link: https://leanpub.com/practicaldatacleaning/c/hIs2BiOePbWH
High Performance in-memory computing with Apache Ignite: Building low latency, near real time application Author: Shamim Ahmed Bhuiyan, Michael Zheludkov, and Timur Isachenko
Book: High Performance in-memory computing with Apache Ignite: Building low latency, near real time application
Regular Minimum Price: $19.00
Sale Price: $17.00
Discount: $2.00, 11%
Link: https://leanpub.com/ignite/c/1RuSb45Zz5I8

– Posted by Len Epp


Leanpub Authors: How To Include Your Book(s) In Our Mid-December Sale

by Len Epp

published Dec 14, 2016

After the success so many Leanpub authors had with our Black Friday-Cyber Monday sale last month, we’ve decided to run a sale in the middle of every month. During the sale, we’ll list all of the books that are part of the sale on our blog and we’ll promote them on social media and through our reader newsletter, which makes its way into thousands of customers’ email inboxes.

This month, the sale will run from Friday, December 16 to the end of Monday, December 19.

If you’re planning on participating in the sale, all you have to do is create a coupon link customers can follow to buy your book (or books!) at a discount and email the link to us at hello@leanpub.com with the coupon link and a short description of the deal before 2 PM Pacific time on Thursday, December 15.

All coupons should be set to run from December 15-20, so there’s no confusion around time zones (our coupons are all set to the UTC time zone). Like we did last month, we’ll edit the dates of any coupons that are submitted that do not cover these dates, so that they match the requirement. (If you set your coupon to last beyond December 20, we will not change that.)

Sign up for our monthly author newsletter!

If you haven’t already done so, we suggest you sign up for our monthly author newsletter by logging in to Leanpub and going here: https://leanpub.com/user_dashboard/email. That’s the best way to find out about things like planned sales, new features, and more!