A Leanpub Frontmatter Podcast Interview with Kyle Simpson, Author of Functional-Light JavaScript…

A Leanpub Frontmatter Podcast Interview with Kyle Simpson, Author of Functional-Light JavaScript: Balanced, Pragmatic FP in JavaScript

Kyle Simpson is the author of the Leanpub book Functional-Light JavaScript: Balanced, Pragmatic FP in JavaScript. In this interview, Leanpub co-founder Len Epp talks with Kyle about his background, the difference between programming and software engineering, his book and his crowdfunding campaign, his interesting experience with abandoning a popular Twitter account and the subsequent withdrawal, a surprising bonus from the practice of in-progress publishing a book about learning how to do something, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on November 30, 2017.

The full audio for the interview is here. You can subscribe to the Frontmatter podcast in iTunes or add the podcast URL directly.

This interview has been edited for conciseness and clarity.

A Note About the Leanpub Frontmatter Podcast

This summer we split the old Leanpub podcast into two distinct podcasts:

Frontmatter, which is a general interest podcast where you can listen to Leanpub authors talk with Leanpub co-founder Len Epp about their books and their areas of expertise, from data science to molecular biology, to the history of labor and management. And for those interested in the nitty-gritty of what it takes to be a successful self-published author, at the end of each episode Len asks the author about how they made their book and how they are spreading the word, and other publishing shop talk.

Backmatter, a new podcast focused specifically on the publishing industry and its latest trends. In each episode Len interviews a professional from the publishing world about their background and their insider’s perspective on what’s happening in the huge and evolving world of book publishing.

Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub Frontmatter Podcast, I’ll be interviewing Kyle Simpson. Kyle is an open web evangelist, popular speaker, writer and JavaScript teacher. He has written a number of books on programming. And you can find some of his courses for developers on Pluralsite, and on frontendmasters.com. As we record this interview, it is Kyle Simpson Week, which means all of Kyle’s courses are free through December 4th. We’re going to try to get this podcast out in record time, so you can hear about this. In fact, I believe Kyle is joining me fresh from a live Q&A with some Frontend Masters members. So, I wanted to say a special thanks for doing this on a little bit of short notice.

Kyle is the author of a number of books published by O’Reilly, and he just recently launched his latest book on Leanpub, Functional-Light JavaScript: Balanced, Pragmatic FP in JavaScript was released on Monday. I is focused on setting out a unique bottom-up, pragmatic approach to explaining fundamental concepts from functional programming — while avoiding unnecessarily heavy terminology, and in some cases, the mathematical notation that can maybe get in the way of achieving practical learning goals in a book like this.

In this interview, we’re going to talk about Kyle’s career, his professional interests, his book, and at the end, we’ll talk a little bit about his experience self-publishing.

So thank you Kyle for being on the Frontmatter Podcast.

Kyle: Thank you very much for having me, I’m excited to be here.

Len: I always like to start these interviews by asking people for their origin story. I was wondering if you could talk a little bit about where you grew up, and how you first became interested in computers and software?

Kyle: I’m based in Austin, Texas right now, but I’m originally from Oklahoma. How I got into programming was, at the age of 11 — so this is back around 1990-ish, way, way back — I was over at a friend’s house, and his dad was a programmer. He was working on some stuff in the den, and my friend and I walked in, and we’re just kind of curious, looking over his shoulder.

His dad saw our curiosity, and he said, “Hold on a moment.” And he click, click, clicked for just a moment, and all of a sudden, the screen went blue. And this — being 1990, this is pre-Windows, this is way back in the days of DOS — the blue screen went blank with blue, and then a grey box [appeared] in the middle that had my name in it. I was absolutely fascinated by the fact that in just a few moments, he was able to make the computer do whatever he wanted.

I got interested in programming from that moment, and started trying to learn. This was pre-internet, so learning meant my parents buying me used computer programming books from book stores. I tried to cobble together some sort of crazy understanding of programming.

I went through high school, and started doing some side contract work in programming. And I got into college, and did some more of that.

After college, I went into software development as a career. So one of those rare [cases] that, from a young, early age, I had an idea of what I wanted to do, and I actually stuck with it, and I still do that to this day.

I was a developer for about 15 years professionally, until about five years ago when I was thinking about how I could make a bigger impact on the software developer community. I’d done open source projects for a long time, but I really wanted to give back in a bigger and more meaningful, lasting way. I got a break actually, through Frontend Masters. The founder of Frontend Masters, Mark, called me up one day. We didn’t know each other, but he called me up and said, “Have you ever thought about teaching?”

I was sort of taken aback, because I’d done some of that in other areas of my life, but never professionally. And so he spent a couple of weeks coaxing me and coaching me. He convinced me to go try it. And so a little over five years ago, I gave my first course as a JavaScript teacher, and immediately fell in love with that, and realised that that was what I was meant to do. I wish I had learned it a lot earlier. But I figured out that that was what my passion and calling was.

So I became a full time teacher, and that, to this day, is still what I do. I travel around teaching — primarily corporate, onsite workshops in JavaScript — at various companies all over the world. Along the way, I also started writing about the things that I was learning, because people would ask me, “Hey, do you have instructor notes for your classes?” And I thought, “Oh well I guess I’ll write some stuff down.” And blog posts turned into longer form things, which naturally led to writing books.

I have published a number of books with O’Reilly, which is a big tech book publisher. Most notably, I have a six-book series with them called, “You don’t know JS” , which is probably how I’m most well-known these days.

I had a great relationship with them. But as I started thinking about the next book that I wanted to do afterwards, I started realising that I wanted to have a little bit more control over the distribution channels and what kinds of deals that I could do. And that’s what led me to start exploring self-publishing.

Len: I’ve got a lot of questions to ask you about that later on, including about your crowd sourcing campaign.

But before we move on, one of the sort of unofficial themes of this podcast, because so many Leanpub authors that I interview are into software, is: if you could start over now, or if you were giving advice to someone like yourself, who was starting out now, would you formally study computer science in university?

I just wanted to frame this a little bit, because often I don’t have much of a frame for it, but in your case, you’ve done so much teaching, and you published a blog post a little while ago about a lot of the problems with ed tech solutions, even the ones that have had lots of venture capital funding — and also the dissatisfaction that a lot of developers feel, even at a time when they have more resources than ever available. And you self-started something called DevGo. So, I wanted to give you the opportunity to frame a response to the computer science question in that richer context.

Kyle: I’ll break that down. The first question, the first layer of the question is, if I could tell myself, from so long ago, whether I should go into computer science or not. If I really could tell myself — to be totally honest, I’d tell myself to go into computer science, but I’d tell myself to leave high school early. Because when I graduated high school and went into CS, this was late 90s, tt was during the dotcom boom. And my high school counsellors were like, “Computer science is the thing. You’ll make $100,000 right out of college.” And I got all excited, and went and studied CS.

And midway through my junior year, in the early 2000s, is when the dotcom crash started to happen. I realised that I had missed the boat by about a year, a year and a half. And so if I had anything that I could do differently, it’d be, figure out how to get out of high school quicker, get into CS. Maybe I could’ve cashed in on the boom before the bust. But anyway, I would still tell myself to do CS, and I’ll explain why.

I definitely believe that there is a difference between programming and software engineering. That phrase, “software engineering,” gets thrown around a lot. I think people have lots of different meanings by it. But I have a way that I frame the difference between a developer and an engineer. Sometimes it ruffles a little feathers, so I’ll give fair warning. It’s not intended to be an insult. It’s really intended to be an aspiration.

I think you can frame it this way. A developer seeks first to solve a problem, and maybe later understand the problem; whereas an engineer seeks first to understand a problem, and maybe later solve the problem. What I aspire for people to do, and what I hope that my writing and teachings do, is convince people that the engineering approach is the better approach. That’s the better path, it’s the more admirable path to take.

And that’s in spite of the fact that so many of us — including myself for so many years — find ourselves in that trench of, “Yeah, I’d love to do it the right way. But I have a deadline, and I just have to ship something. And my boss just wants it to work, and I don’t really have time to figure it out.” Because I lived that reality for so many years myself, it’s not that I have forgotten it, nor is it that I’m sitting in some ivory tower saying, “You should be that way,” and not really recognising the implications.

I do very much understand that challenge, because I lived it. What I also understand — and it’s really what motivated me to become a teacher — is that when you’re in the trenches and you’re basically left to your own devices to figure out somehow to make it work. You said it was going to take four hours, and you’re on hour eight and your boss is tapping their foot saying, “When’s this thing going to be done? When are you going to get it done?”

Because you didn’t take the time to invest in understanding the problem, you essentially have no hope of really understanding your solution. And even if it works, you won’t know why. And if you don’t know why something works, you have no chance of fixing it, when it breaks later. I took a step back, and I said, “I understand why pressure of deadlines causes us to cut corners, to do things that we don’t fully understand.”

But that’s the negative snowball effect — that that will cause that to happen more. The more we give into that, the more that will continue to happen. It’s a self-fulfilling prophesy. So I took a step back and said, “If — for whatever crazy reason, you’re a developer, you’re an engineer as a job: understanding what you do is the most important thing that you could invest in,” because it will directly and concretely pay off when the pressure is on. If I understand a problem, and then there’s pressure — I know how to cut out all the 40 other things that I could try that won’t work, and get right to the right solution. But if I don’t understand it, I’ll flounder. And I’ll often come up with something hacky that doesn’t work.

Taking a step back to that question of would you do computer science: there’s a vast amount of knowledge that I was taught in my CS degree, that I don’t use on a regular basis. If somebody said, “Go implement a red–black tree” — I know what that is, but I couldn’t go implement one on demand, and have never needed to in my career — implement some kind of arcane data structure like that.

But what the CS degree did do, is teach me to understand problems. I think that’s really the engineering mindset. I am tremendously grateful that I was taught that lesson early enough along, that I was able, at some point in my career, to come back and say, “How can I get that to others?”

Now, I’m not a CS professor. I didn’t go to university to do it. I tried to take the approach of, I’m going to help people in the practical way. They’re writing JavaScript for their jobs, let me help them do that and do that better.

But I still try to imbue that with that same passion — understand what you’re doing, understand it more deeply. Because at the end of the day, the thing that we’re really doing with our code is not instructing the computer. That was almost a happy side accident. At the end of the day, the real purpose of software development is to communicate ideas with other human beings, and if you don’t understand the thing that you’re doing, and you’re just hacking around until the right sequence of 1’s and 0’s just accidentally happens — you’ve completely failed at the communication of that idea.

What that means is, later, whether that’s next week or next month or next year — when somebody has to read that, and it won’t just be once, it’ll be dozens and hundreds of times when that code has to be read. Nobody’s going to understand it, not even your future self. Nobody’s going to understand what it is, and we’re going to get to the point which often happens — I ask this of people all the time, in a room of developers, I’ll say, “How many of you have ever heard the conversation, “Well it’d just be faster if I rewrote it.” You’re struggling to get something to work, and it’ll just be faster if I rewrote it. There’s a lot of churn. We re-write code all the time. And I wonder how much of that rewriting happens because somebody didn’t take the time to make sure they clearly communicated why they were doing something a certain way. The future person that’s maintaining that — even your future self — can’t remember that, can’t reconstruct it. So you just throw away all that effort.

I hear people push back when I tell them that — making code readable and understandable and communicating ideas well, that that is critical. People will push back and say, “Well it’s nice to have.” Just like tests are nice to have, and documentations are nice to have. That’s a nice to have. To me, when somebody tells me, “I don’t have time to make my code readable, man I just got to ship it,” to me it’s like, “You don’t have time not to make it readable. Because you have failed at the only purpose of that code — to communicate an idea if it’s not readable.”

Everything else — I mean the computer can almost instruct itself at this point. But what it can never do is communicate those ideas. That’s what we, what we need to be doing.

Len: That’s really interesting you say that. When I was reading your book, and when you were just talking now, you were reminding me of a woman named Janelle Klein, who published a book on Leanpub called Idea Flow some time ago.

I guess there’s one coincidence that occurred to me — I think she’s actually from your neck of the woods near Austin? And her book is very much along the lines of what you’re saying, with respect to communication, which is basically that, what happens is you have ideas in your head — I’ll put it very crudely — with developing or with programming and engineering. you have an idea in your head, and then you express it in code. And then it’s going to go, essentially, into the machine. And at some point it’s going to come out the machine in someone else’s brain, and they’re going to have to process it.

Actually you can almost think of it like the ideas move through these various brains and screens, into other brains — and then get modified. And including your future brain, which is something you talk about. “Future me will be much happier with present me, if I just take the time,” because you’re communicating with your future self as well when you’re doing this. And that’s really compelling.

Kyle: I totally resonate with that message, so I’m going to go look that book up as soon as we’re done here. That sounds great. I almost believe that at a religious level. That that is our responsibility as developers, is to leave a legacy to our future selves, and our future team members, of communicating those ideas well.

And it’s, by the way, not just the idea of the code that I wrote. Because that you can see. But there’s also the code that you thought about. You figured out shouldn’t be there, and you didn’t have any way to communicate in your code, the stuff that I thought about and didn’t put there and why that’s not there. We don’t do a good job of articulating that mental context for people to reconstruct. So I really believe that that’s the next layer, and that’s what I’ve dedicated my teaching career to.

You brought up DevGo, so I should speak to that, and how that weaves into this. I have now been a teacher for a little over five years, as I said, and I’ve primarily done so in the classroom, which is often seen as the gold standard for educational opportunities — as opposed to just maybe reading a book or watching a video. It’s a very one-way thing, and you think that in a classroom you get this two-way interaction. The unfortunate part about the classroom, is that it betrays the fundamental nature of how humans learn, which is that it tries to compress learning into a single transaction.

If you look back over thousands of years of human history — all the skills that have ever been transferred from one human to another human have not happened through the mode of an upfront fire hose of information, and then you go on your way to go figure it out and implement. But rather, they’ve happened slowly — over time through the master-apprentice, or what we might in modern times call “the mentorship model,” where there was a little bit of information, followed by a lot of practice. And that was not self-guided practice, but rather a master guided practice.

Think about cooking. You wouldn’t just say, “Oh, I watched a YouTube video, therefore I’m now an expert cook.” You would have a master chef who sat with you and watched you bake that chicken over and over and over again, and critiqued it, and tweaked it, and helped you to get better.

Any skill that you can think of — that’s the effective way to work. But in the modern day, we’ve abandoned the notion of that relationship component of education, because we can’t figure out how to scale that to the modern workplace. So we’ll just scale content, right? Just put in a video forum, put it up online. A billion people can watch it, therefore we’ve made education accessible to the masses. But we lost that human component.

I have been watching my efforts as a teacher fail to be as deep and profound as I would hope and aspire for them to be. I kind of decided I needed to disrupt my own work, if you will. To do it a different way. So I started trying to figure out how could I scale mentorship-orientated learning to the modern work place: How can you scale relationships and make that actually work? I’ve come up with an educational model, and a way of doing that with technology that I think will work.

That’s what DevGo is dedicated to — where everyone else seems to be skating towards, “Let’s scale content.” DevGo is trying to scale the relationship part of education, because I think that’s the only thing that will actually turn knowledge into skill. Everything else is just focused on knowledge.

Len: And what model would you use to establish that relationship and those connections?

Kyle: Essentially the process at the beginning is going to be similar to what a company would do now, when they would hire me to come in and teach a one-week class. But instead, they would sign up for a mentoring service, where the material that I would’ve presented in one week, is instead presented in small chunks, say an hour a week, continually. So every week, you have your people meet online and receive one hour of content.

And then, while that content’s being presented, I am live in the same environment, to be able to answer questions immediately as they may come up, help people facilitate. But the important part is that the rest of the week, when you’re back to your job as a developer, instead of being left to your own devices to figure it out, the DevGo service enables a scaleable way for your mentors to help you along throughout the week, to check in with you, to look at the code that you’re working and help you apply those concepts to your real work product.

That is moving beyond just, “I transferred some knowledge to you,” almost to a consulting level. I’m helping you implement that knowledge in your actual job.

Len: Switching to one of your other passions, I wanted to talk to you about open source software.

When did you first develop an interest in that, and can you talk a little bit about your engagement with that world over time?

Kyle: Definitely. That will flow back into writing as well, which is a nice segue.

Back in I think 2008, I was still working as a developer, but I wanted to go to software developer conferences, because I wanted to learn more. It was starting to be a thing that there were conferences dedicated to JavaScript. Now that’s a common thing, but back then it was not common. JavaScript didn’t have it’s own conferences until around that time.

I knew some people that were involved in other conference scenes, and I said, “I can’t figure it out. How do you afford to go to the conference?” And, “I can’t get my job to pay and give me time off.” And they said, “Well the secret is, you agree to speak at the conference, and then they’ll pay for you to go.” I thought, “Oh that’s brilliant, I know how to publicly speak, I can do that.”

Then I started realizing, “What am I going to talk about? What could I possibly go to a conference and talk about, that would be remotely useful?” I realized, “Well, I’ve got this project that I’m doing at work. Instead of doing this as a closed proprietary thing, why don’t I figure out a way to make that an open source product?” This is pre-GitHub. “Why don’t I make this an open source project that I’m also using at work? That kills two birds with one stone. But once it’s a project, that’s something I can go to a conference and talk about.”

So the very first one I did of that was a thing called “Flexor” [?] which was Flash-based crossed — I mean Ajax, they don’t even matter now, because it’s obviously irrelevant. But I built a little thing, and I said, “Okay, I’m going to go talk at a conference.” And I went to this conference, and there were like four people in my room listening to me give my first ever conference talk. But I gave a little talk on this thing, and I started refining not only my public speaking, but also, I realised that one of reasons why open source was going to be so powerful, was not just that I could promote myself.

I mean, now I have to be honest — that’s part of it. I want to promote myself, and that’s part of how I pay my bills. But the bigger reason why I felt like open source was going to be so instrumental in my future, was that it embodied the idea of collaboration, in a way that I’d never been able to think about before. Every other previous time that I was ever working on something, if I struggled with something, I went out and Google searched or whatever, or asked other people. I took the knowledge that they gave me, and I brought it back, and I implemented some solution that only I got to benefit from.

I realised, with open source, the real benefit is that I put something out there, and I get other people to help in a way that then benefits not just them, not just me, but anybody else that looks in on it. It’s kind of like a ripple effect, like the pond will ripple more if you do so in the open. I began to realise that that was kind of in my DNA, that idea of collaboration. And that was before I knew that I wanted to be a teacher. But I definitely wanted to make a bigger impact.

So I started doing more and more of my work in open source, wherever I could. Every time I took a job, I said, “Hey, here’s all these open source projects I’ve got. Just so you know, I’m not giving that stuff up — that’s important to me.’ I would disclose those, and I would work on those at jobs. I would refuse jobs if they didn’t want me to do it.

I won’t say who, but there’s a huge company that everybody knows right now, that tried to hire me. When I went there, they said, “This is great, we want you to come here.” And I said, “Just so you know, I’ve got this project that I’ve gotten in the open source. A lot of people know me about it. I’m going to continue to maintain that project, I’m not giving that up.” And they said, “We don’t allow our developers to work on open source.” And I said, “Well, thanks very much, but I’m not going to take the job, because this is part of who I am.”

Len: Just to interrupt there — did they explain why?

Kyle: They did actually explain why, which is hilarious. This was just a tiny little open source project, it was called — Well not tiny, but LABjs, which is a dynamic script loader. It’s one of my most popular, longest-living open source projects.

I said, “I’ve got this Lab GS project that a lot of people use, and I’m going to continue to maintain that, just so you’re aware.”

And they said, “Well, we can’t have you doing that as an employee, because we have some patentable, proprietary stuff in the script loading space.” I was like, “What? That’s crazy that you would have a patent on this or whatever.” But that’s why they wouldn’t let me do it, is because they thought they had some kind of patent on it, or they were going to file a patent, I don’t know? So I passed on the job — because open source, I don’t think it matters.

I just want to say one more note on that whole notion of collaboration. This is deeply important to me that people take this and chew on it. This isn’t trying to be prescriptive of, “You need to do it this way.” But I want at least people to wrestle with this question: Are you using open source to simply promote yourself as a promotional channel? Are you using it as a collaboration channel?

One of the reasons why I ask that question is because I find a lot of people telling me, “Oh well, I don’t put stuff in open source yet, because it’s not good enough yet.” I hear people say that a lot. “I haven’t open sourced it yet, because it’s not good enough.” I hear people telling me, “I haven’t written about stuff publicly. I haven’t written blogs or books, because I’m not a master at it.” I hear that a lot.

I always hear — when somebody says, “I haven’t put it out there, because it’s not good enough for others to see,” I always hear it in reverse, actually. The way I approach open source — and this has been true for years and years now — is that I will start a project, whether it be a code project or a book, with an empty file out in the open source world. And I will begin incrementally committing the stuff that I have to it.

This functional-light book that we’ll talk about in a moment — I literally committed a paragraph. If you go back to the very first commit on that history, there’s a paragraph — the very first thing I wrote. Because I want people to see my journey. And because I start with the assumption that every version that I put out of something — whether it be code or text in a book — the version that I put out is the worst possible version of that. The only hope that I have of making it better is to get other people’s eyes on it, and to get other people’s feedback and input on it.

And so, for me, to hear somebody say, “I haven’t put this thing out there. This thing of myself. I haven’t put it out there, because it’s not good enough yet” — to me, what I hear is the reverse. They don’t realise how bad it is, and how desperately they need people to help collaborate to make things better. I would never have been able to become the kind of developer I am, the teacher I am, and the author that I am, if it weren’t for open source and the collaborative nature of putting ideas out there, and having them be refined in the open with lots of people. As opposed to just me holding onto it, until I had perfected something. That never would’ve worked for me.

Len: Tying that together, the open source projects, the iterating in public — but also the concept of promoting yourself — and before we move onto the subject of your book, I wanted to talk to you a little bit about self-promotion in social media.

One of the most important tools self-published authors, self-employed consultants, and other independent content producers have available, at least according to basically everybody who gives advice about how to succeed in these areas, is social media.

Over the course of quite some time, you managed to build a pretty successful presence on Twitter in particular, with over 30,000 followers. I think as I was preparing for this interview, that’s when I discovered this — it was in early 2017 or so, I believe, that you decided to kind of drop off Twitter for the most part, and you explained your decision in a pretty moving post that you published on Medium in July.

Before we talk about why you dropped off, I was just wondering if you could talk a little bit about the story from the beginning — about how you got started on Twitter, and how did the ball get rolling?

Kyle: I was at a conference in 2009 in Berlin. It was the first JSConf EU conference, in Berlin. People will note that historically, as an important conference, in that that was the conference where Node.js was launched to the world by Ryan Dahl. And I was there, in the audience when that happened. It was a pretty incredible thing to see the shift happen so quickly.

I was at that conference getting ready to stand up and give a talk about my LABjs project, and I didn’t have either a GitHub account or a Twitter account. I saw several of the other speakers did. And so literally, about an hour and a half before my talk, I signed up for Twitter and GitHub at the same time, and I said, “Well if I’m about to go like talk about this thing, there should be a way for people to give me feedback or something.”

So I signed up for those accounts at that time. I didn’t really know what Twitter, and really the bigger question about social media — I didn’t really have a plan for how that was going to fit in. But in the initial days, it was like, “Oh, I’m going to use this as a communication channel. People can ask me a question or I can answer, or whatever.”

Over time, I started being more self-promotional. I started tweeting about the things I was doing, where I was going to go and speak. And so I began to develop a presence there. And through my conference speaking, I got a lot of followers to the Twitter account. Sometime over those first couple of years, it shifted from — I’m using it only for tech, to, “This is my personal voice. This is my Twitter account.”

Everybody knows me as @getify. And that is, that I’m a JavaScript developer.I have lots of other thoughts about stuff, and I might as well just share all of those ideas. If people are interested, great. If not, they’ll leave. But at least I’ll talk about it.

It was peculiar to me, because the more I did that, the more followers I got. I thought I would lose followers when I started talking about non-tech stuff — like if I’d talk about politics or religion or culture, something like that, I thought I would lose followers — and I got more and more.

It was peculiar after a while, because it felt like everything that I did that should lose followers, made them. Everything that I should do, that should gain followers, I would lose. It was very counter-intuitive. I didn’t have any well-articulated strategy around it. But it was almost like, do the opposite of your intuition, and you’ll get more followers.

It felt, at the time, that getting more followers was the success metric. “If I have more followers, than that means I’m more successful.” Upon reflection, I would say I probably should’ve followed my instinct and not just tried to seek after the metrics. Because as I allude to in that post, by creating a big following in social media, I converted myself from being a person, to being a personality. And with that comes some responsibilities that I was not cognizant of, and not prepared to shoulder.

It didn’t come right away, but over time I developed that persona, that personality — that people expected of me to be the contrarian. They expected me to be the one, when everybody else is saying this, go to @getify, because he’s going to give you the different perspective on why you should do it a different way, to start debates and — not really stir controversy, but to not just accept the status quo. That became kind of my brand.

I followed that brand beyond tech. I had the same thing with culture and religion and politics and everything else. I didn’t realise that people are tolerant of that brand when it’s about JavaScript. But they’re much less tolerant when that brand is applied to say, for example, religion or politics. And in the heated culture of the last couple of years, it’s gotten a lot more difficult to speak your mind in the open.

I was way too deep in my addiction, over being able to stir those debates up on any topic, to realise that I was leading myself down that path. That’s what that blog post was about — I got in too deep, I got too addicted to hearing my own voice and feeling too self-important about my own voice. It wasn’t on purpose, it was just little by little, tweet by tweet.

Len: I wanted to say that, I think, for the purposes of this conversation, your Medium post is so articulate, we can probably bracket some of the personal experience you had with addiction and things like that. I would just recommend people go to the post to find out about that experience.

Given that the conversation on Twitter is something a lot of people are preoccupied with — there’s something there that’s more of an abstract sort of philosophical, cultural issue that you invoke — that I wanted to ask you about.

You say in the post, “Those who understand a conversation’s full context, when they discuss such publicly, practically beg others to come in without that context and yet be co-equal participators.”. I know I’m quoting at you something you wrote many months ago, but if you could recall what you were getting at with that — that struck a chord with me, because that’s something I think about quite a bit myself when I’m going on Twitter and reading replies and things like that.

Kyle: There’s multiple layers that you could analyse the emotions behind that statement. One obvious layer is a critique of the Twitter platform itself. The short form 140 characters, the pretty primitive threading that’s involved, the ability for anybody to chime in — it could be a critique of the technology and the platform and the user experience. I think there’s a fair bit of that involved.

But I think the bigger question — it kind of goes back to what I said about open source. When you do something in the open, you’re asking for collaboration. You don’t go do something in the open and say, “Hey, here’s me and this other dude that are going to talk about it, and you all just listen.” You do it in the open because you want them to be part of it. If you didn’t, you wouldn’t do it in the open, you’d just have a text message conversation, a private phone call. You’d meet at a coffee shop.

The fact that you do it in any forum on social media — and that goes from Twitter to Facebook to Instagram or whatever, pick your channel — when you do it in the public, you are asking people to not just listen, but to provide their feedback. The problem with that, is that they are providing their feedback with very imperfect context.

Imagine that you and a friend have had a months’ long discussion over many, many coffees about something. And you have lots of deep context about that person, and their history, and their background or whatever. And then just one day at a coffee shop, some dude is overhearing you, and you say something. And he turns around and he’s like, “I think that’s totally wrong, and here’s why.”

That injection of information is completely without context. And yet, because we do this on social media, we’re basically saying, “Every tweet is equal to every other tweet.” Your tweet, without any context, it has just as much weight on the topic, and just as much reach on the topic as my tweet that I’ve spent months or years thinking about.

Len: That’s the part that really struck me, in a different dimension, but they sort of intersect. Which is, for example, what you’re talking about is you and someone else, or you yourself in your own tweets, may have developed this rich context over time. And someone just dives in and sees one thing, and starts talking about as though they know the whole context.

Another version of that, that happens on Twitter is — let’s say you subscribe to Foreign Affairs, and you study political science in school, and you study abroad, and you work for the State Department for years, and then you can come back and write a book. And then you’ll tweet about something, and somebody will just go, “The Iran deal is terrible. I just heard about it from my buddy down at the bar.”

I think there’s just something interesting — ormally I’m very sceptical about claims like, there should be establishment of authority on the internet, and stuff like that. But to me it really is interesting, that to a certain type of person, the fact that they visually see themselves as equivalent to whomever else they’re interacting with on Twitter — they’re certainly not challenging themselves, to hold themselves to a higher standard. But they don’t get challenged to hold themselves to a higher standard. I really do think there is something about the platform that discourages people from engaging in that kind of questioning.

Another version of that which you encountered, I think, was people telling you what to say and what not to say. “I wish you’d just stick to JavaScript.” I follow a few celebrities on Twitter, like Ron Perlman and Vincent D’Onofrio, and they’ll constantly get people telling them — just someone randomly, like I mean on their couch — starts telling another adult human being not to talk about something, because they personally, sitting there on their couch, don’t want to see it in their timeline. I don’t really know what I have to say about that, except I agree with a lot of your assessment, just from a slightly different perspective.

Kyle: Two points on that. First, what you just said about people policing the content producers that they listen to — if you’re an individual person, and some other individual person says, “Hey individual person B, I am A and I don’t like what you’re saying, that’s ludicrous, right? But at some point, an individual person might cross the bridge from just an individual person, to some sort of public persona or brand or expectation, where the same kind of free-form thought is maybe not as acceptable.

This is what I didn’t come to terms with — that at some point, by asking so many people to follow me, by trying to benefit so much from my larger voice and my bigger social media presence or whatever — and just so we’re aware — this is 30,000 followers, I’m not like President Barack Obama with millions of people — but in my little world, 30,000 is a decent following.

But by asking people to follow me, there was an unspoken contract that I would give them the kinds of things that they would be appreciative of. And the more I solidified that contract by creating a public persona, the more I restricted what I should and shouldn’t say, maybe? That’s the part that I didn’t really think about and come to terms with. And I still don’t have an answer for it. I’m not even well articulating it now.

But another thing that you said, on terms of internet authority — I know that’s a very dodgy topic, because we now live in the age of fake news, and who can even know what is or isn’t real about a thing that you hear or see, and technology is making that even harder.

If you imagine — I’m being a bit more old school and dating myself — but some people may know the name Henry Kissenger, who is, in most respects, a historical figure. You would say of Henry Kissenger, “That guy knows foreign affairs,” whether you like the politics around Henry Kissenger or not, that’s not my point — but if Henry Kissenger had a Twitter account — and maybe he does, maybe he doesn’t? I don’t know? [Note: He doesn’t appear to — eds.]

But if he had a Twitter account and he went on and he said something about the Iran deal, and he said, “This is missing this context” — maybe he praised it or he critiqued it or something, and then some random person walks by on Twitter and says, “Well what do you know, Henry? Like what do you know?” That’s an essence of what I’m getting at here, is that he does know what he’s talking about.

And yet, at that moment, those two are co-equal in the social media sphere. It’s almost unfair to expect another person to subjugate themselves to his authority. Both of them have gotten into a medium that reduced them both to the same level. And that’s part of the reason why a meaningful, substantive conversation on a foreign affair could not happen in there, because you can’t bring in the context appropriately. You just can’t. And that’s not a critique of Twitter. It’s really a critique of the notion of conversation in social media.

Len: One of the reasons I wanted to talk about this, after talking about some of your open source projects and things like that, was, you were explicit in your Medium post about the price you paid. That once you gave up this platform, you could do a lot of work on projects, and they just wouldn’t get the traction that you could be quite certain they would’ve got otherwise. I imagine the same is true for everything you do.

One’s platform online is what one uses to get the word out about one’s work. And if you’re not fortunate enough to have a whole organization putting three-story billboards of you up in Times Square or something like that, it’s all that work that you put in over all that time, that helps you bring attention to your new work.

You wrote that post a few months ago — are you confident you made the right choice, given that consequence?

Kyle: That is a very tough question to ask. I would have to answer that by saying, if I review the kind of person that I am today, compared to the kind of person I was back in January right before I left, when I was in full on rant mode, I think I’m a better person. I think I understand myself and others a lot better, and I think I appreciate the nuances of persona and expectation a whole lot — universally better than I did back then.

I also think that I have been able to check one of the worst parts of my own nature, which was that addiction to my opinion on anything mattering. I was addicted, as I said in the post — because I could see any conversation going on, and because I had some established authority, that meant my opinion mattered. So I could show up in any conversation and say, “Well @getify says this.”

I was addicted to that ego boost that I got every time I got every time I got to chime in and be the contradictory voice in some debate or whatever. I loved when people would write me a tweet and say, “Hey @getify, what do you think about this?” And I’m like, “Well let me tell you what I think about this, because I’m so smart.”

I have cured that addiction. Not quickly, but I’ve cured that addiction now. Mostly by giving myself the freedom to not respond when people write me stuff. I left the platform entirely for six months, and then I wrote that post, and I decided to kind of ease my way back in, but mostly in a read-only mode.

I’ll illustrate that by reading you what my current Twitter profile says: “This account is a passive protest of everything that used to matter to me about social media.”

There’s contradiction in that, and I am fully aware of that — that almost hypocrisy of contradiction there. The fact that I participate in social media is because I’m still struggling with the fact that, like you said, I need to have a presence to be able to promote myself. But I also need to be able to keep it enough at arm’s length, that I don’t suck myself back into those old temptations.

And so I don’t have a good answer for how to do it. I’m not operating off of some good playbook, and no one listening should think of my path as a path to emulate. But I try very hard to use Twitter more as a read medium than as a promotion medium. And I only promote things when there’s a very clear objective.

For example, we mentioned the Kyle Simpson Week. Well, I had to get my mindset into, “I’m going to be on Twitter a lot this week, and I’m going to be promoting myself a lot this week. And that’s going to invite a lot of feedback, both good and bad. I need to make sure that when I see a tweet that I disagree with, I literally just shut the laptop and walk away, instead of feeling like I need to fire that off.”

I didn’t even do that perfectly. I got into some debates this week, which I probably shouldn’t have, on some topics. But to me, as I say in that post, the healthy level of Twitter is almost zero. It’s not zero. I didn’t completely close the account. But to keep it at a minimum is the only healthy way that I know how to do it.

Another way that I’ve solved this is I’ve now got multiple Twitter accounts where I’m doing different things with different accounts, so there’s not as much mixture. For example, I have one specifically for the book. So anything about the book, I’m going to use that account for. I’m trying, but I don’t have it all figured out.

Your bigger question of, “Did you make the right choice?” I’m a better person, and I can’t imagine that any choice that makes you a better person is a bad choice. But it wasn’t an easy one, and it hasn’t been easy to figure out.

Len: Thanks for talking about it, I really appreciate that you did that. And so frankly.

Moving on to your book, which is — other than talking about you, the ostensible reason for this podcast episode — the book’s called Functional-Light JavaScript. I wanted to ask you to first talk about this concept of lightness. You also talk about deepness and other things along these lines as well, and the difference between that, and “advanced” and “beginner.” I was just wondering if you could give us your thoughts along those lines?

Kyle: In the GitHub repo read me for this book — I guess we should’ve been more explicit about this earlier. In addition to doing all of my code in the open source, I also do all of my book writing in open source. All of the books that I’ve ever written, I’ve written them on GitHub, they’re all publicly available. Because I have the same perspective on book writing than I do on code writing.

So in the read me for this Functional-Light JavaScript book, I have a statement that basically says, “Just FYI, you might think of the word ‘light’ and have that imply intro or beginner or easy guider, or something like that. I want to just say right off the bat, I don’t think that’s what I mean by that word. What I mean is, specifically narrow in scope. But that doesn’t betray the depth of the material that needs to be explored.”

I think of lightness in terms of — every time I’ve ever tried to approach functional programming, the scope of material that comes at you is so broad — so many different terms, so many different concepts, so many different symbols and notations — that I find that breadth to be overwhelming, and I very quickly get overwhelmed. For me personally, I need a smaller scope, with a deeper dive into the why.

For example, if you think about almost any other functional programming work — a book or something like that on functional programming — that in the first chapter or two, they’re probably going to start talking about monads. That’s probably going to come up pretty quickly, pretty early on. I basically said, “Well I don’t want to talk about monads until literally Appendix B. I don’t even want to mention that word until then.”

It’s because I want you to understand all the concepts that make a monad useful. Whereas, most of the functional programming material other than this book, just simply state all of those as assumptions. Like, “Hey, we all know exactly how this works. So here’s what we do, we’re going to make a monad.” And I’m like, “No, we don’t all know how this works and why. We don’t all fully understand function purity and all that stuff.”

That’s something that should get covered more. I don’t really mean that to be intro, but it’s like the backstory that we keep assuming people have; I’m going to fill in the backstory, because I didn’t have it. I thought, “If I don’t have it, maybe there’s others that don’t have it?”

The metaphor that I use, both in the book, and also in my teachings is, it always felt to me like I was coming up to the foot of a mountain with a very steep cliff face in front of me. And I could see up on the top of the mountain, people that had already climbed — who were articulating very, very clearly, the benefits of the climb, to the point where I very much agreed that the climb was worth it — that it was going to be difficult, but the climb was worth it. So it wasn’t that I didn’t agree that climbing was useful.

It wasn’t that I couldn’t tell the benefit of this. But it was that they were saying, “Well just use that pile of climbing equipment over there, and just climb up the mountain.” And I looked over at this pile of climbing equipment, and I said, “I don’t know what that stuff is.” And they said, “Oh just use the rope or the carabiner, and you climb up.” It was as if the person on the top of the mountain had forgotten what it was like to not know what a carabiner was, forgotten what it was like to not know how to tie a knot in a rope.

I’ve asked this, both my own self and anecdotally of others, “Have you ever stopped and wondered about a thing that you know now, and compared that to how you used to think about it before you knew how it worked?” Like any skill, whether it’s woodworking or whatever — you used to not know it, and you had a different way of thinking about it than you do now, once you know it. It changes you.

I felt like the problem, from a lot of functional programmers, was that they would forget what it was like to not know about the carabiner and the rope, and be unable to articulate that detail. They were already at this different level, which is, once you already know those climbing, just climb the mountain.

I wanted to come along and say, “What would it take to explain functional programming, from the perspective of somebody that doesn’t have any of those assumptions yet?” And I did something on purpose, which I have a little anecdotal story about.

I decided — as I said before — to incrementally write about these things. Rather than waiting until I had that topic fully congealed in my head, I wanted to write about it as I went. I essentially wanted the book to tell a story of my journey to understanding the climbing equipment — not only through the commit history, but also through the voice as it changes throughout the book.

The story that I have about this, which was very interesting to me — several months back, probably three or four months ago now, I was in a class and somebody asked me a question — I was teaching functional programming, and they asked me a question about one of these topics. And I said, “I have a really good section in my book, chapter two or three or whatever, let me just pull that up, and I’ll just show you some examples from that section.”

So I pulled it up, and I was reading through the text that I had written. And there was a narrative going on in the back of my head as I was reading it to the class. I didn’t let on to them, but there was a narrative going on in the back of my head, where I was thinking, “That’s interesting the way I said that, because that’s not how I would describe it now. I would describe that technique in this way, and yet I said it differently in the book.”

My instinct was, “Make yourself a mental note, you should go back and edit this. Go back and improve this text in the book, because you now understand this thing better. You’re more of a master of that technique, so articulate it in a different way.” And so I made that mental bookmark, and then I went back after the class and looked at it. I looked at the commit history. And it turns out that section was one of the earliest sections that I had written. It was one of the few that hadn’t really been updated much throughout that almost year-long process of writing the book.

I began to realise that what I had done, almost unwittingly, is I had captured a moment in time, by writing incrementally and writing in the open — I captured a moment in time that I could not today recreate. I couldn’t have taken that topic and described it in that way, because my brain has already been trained to think about it more formally.

But because I chose to write about it as I was going, I documented a path that others may get some benefit from. Because I benefited from it. So I actually chose to leave in the more, maybe you would say, naive explanation of that topic. Because I think that is a more useful way to speak to somebody that doesn’t have all the assumptions that I have already started to pollute my own abilities with.

Another way of saying this is — Douglas Crockford, who’s a well-known figure in the JavaScript world, he wrote, JavaScript: The Good Parts and he’s a polarizing figure, but well-known nonetheless, we owe a lot of JavaScript to him. In a talk that he gave back in, I don’t know, 2012 or something like that, he said, “The curse of the monad is that once you understand it, you stop being able to teach it.”

That was a funny joke line that he got in his talk, but I’ve really always attached a lot of profound meaning to that. Once you understand something, do you stop being able to teach it to people who don’t understand it? I’m very cognizant of that, I’m very aware and cautious of getting so far down the road on a topic that I’ve forgotten what it was like to not know it. I think that’s important for beginners and advanced people as well, to be able to see that journey.

Len: That’s a really interesting account of one particular value of publishing as you go. In the prescriptive non-fiction area of publishing, which is what books like this are, a lot of people — when Leanpub started a long time ago, there would often be people quite sceptical about approaches like the one you’re describing.

“Why would I want to read a book before it’s finished? Why would I start publishing a book before I’m at the end?” In particular, where you’re trying to teach something, actually letting people see — and this is something I hadn’t considered before — giving yourself the opportunity to see where you were in the past, can be really, really instructive.

Could you talk a little bit about what the functional-light programming paradigm is? If it’s something beyond what you’ve just been describing?

Kyle: The subtitle for the book, as you mentioned is, “Balanced Pragmatic FP and JavaScript.” That is an attempt, not in a critical way to disparage other functional materials — I drew upon a great many resources in writing this book, of other peers of mine, and they all have their other approaches, and those are great, so I don’t mean to disparage that — but one of the things that I think they often do, is elevate the formalism of of functional-programming above the, “Okay but I just need to improve this one line of code. Is there anything I can do to make this one line?” “No, no, no but you have to understand that you have to re-architect the whole flow of data through your app to do it.” Tthat’s too much for somebody to ingest and be able to do anything practical with.

So what I wanted to do was take you on a journey, where you started to see small little incremental changes that you could make to your code — that each one of those small incremental changes in and of themselves have a benefit to the code. The bigger picture is that at the end of that, you’ve gone quite a ways up the mountain. You’re not at the top, you’re not a functional — I’m not, for sure — but you’ve gotten quite a ways up the mountain, before you even realize that you were climbing the mountain.

That’s really what I wanted people to have. Is — can on day one and on the first couple of dozen pages of this book, is there something, before I even fully understand what functional programming’s about, can I start to improve my code?

A lot of times, I’ve had functional programmers tell me, “Functional programming is an all or nothing proposition. It’s either all functional programming 100%, or 99% is as good as 0%, because that 1%’s the part that’s going to kill you anyway, so it’s not even worth the effort, unless you go all in.”

I just think that’s totally bogus. I think if you can take 10% of these ideas and apply them to your code, they’re better.

But you can’t take a traditional FP text and do that. They have this holistic way of talking about type and category theory and data structure, organization and the flow of data and all — they have this very holistic approach, that it’s all or nothing, very much so.

I think you can get there incrementally. And I hope that JavaScript developers, maybe even more so than any other language, can find the benefit in that. Because JavaScript is uniquely capable as a multi-paradigm language. Not the only one, but it has some very unique characteristics that enable it to be very powerful.

Multi-paradigm, by the way, doesn’t just mean that you could either do a class-oriented program or a procedural program, or a functional program or any of the other paradigms. It doesn’t just mean that. It means that you can mix and match those paradigms in the same program. I think JavaScript is almost unique in its ability to do that.

So I chose JavaScript, not only because I like the language, but because I think it’s a really good vehicle for telling that story. Write an imperative program the way you’ve always done, and then change this one line of code to be a little bit more adherent to the spirit of functional programming. You mixed, you have an imperative program with some functional principles, and the program’s better as a result. And then tomorrow, do a little bit more of that. And tomorrow, the day after, do a little bit more. So fuctional-light is really about incrementally applying the concepts of functional programming to pragmatic real-world JavaScript, that’s really what it’s about.

Len: One thing I wanted to ask you about — I’m not often shocked, like my jaw drops open, by things I read in programming books. But you have a line in there where you say, “The global average for a programmer’s line of code written per day is about 10”, and I was like, “Wow.” I was wondering if you could just explain what it is that I’ve been so ignorant of, to be shocked by that.

Kyle: To be honest with you, those kinds of statistics — there’s that statistic that I informally cite, and then another one that I informally cite, which is that it’s estimated that developers spend about 70% of their day reading code, not writing code. So both of those statistics are ones that, if you try to find a formal citation for them, you’ll probably come up empty — or at least I did.

But they’re things I’ve heard anecdotally for years. When I wanted to cite them here, I went looking, and what I find from people is — for example, to your question, where does that “10 lines of code” come from? I used to say five, because I remember in my computer science class, I had a professor say that to us. And this is 20 whatever years ago now.

But I remember a professor saying that to us. And that stuck in my head, five lines of code. “My God, he wants me to write 400 lines of code in this app, and yet I can only do 5 lines a day, I don’t have enough days.” I just remember that stuck in my head from back then. And so I had for years cited five as that number. And then I started searching and I saw more people saying 10. So maybe we’re a little bit more effective as programmers now than we were 20 years ago.

But where that number seems to come from is kind of similar to what we talked about earlier. When you factor in that somebody writes a piece of code, and then has to go back and rewrite all or part of it the next day, and then rewrite all or part of it the next day — the incremental change to the code base is not the 50 lines of code that you literally wrote, but the 10 new lines of production code that you were able to get in there. And having rewritten the previous 40 lines from the day before.

That’s really where that comes from. It’s the overall context, not just literally raw lines of code written, but lines of code added to production quality code. The net of that is a lot less than we would expect, because we spend so much time doing all these other things with code.

Len: Moving on to the nuts and bolts of putting a book together. You found 738 backers, I believe, for your book through a crowdfunding campaign. You mention this in the dedication to your book. I was wondering if you could talk a little bit — just for the benefit of anyone out there who’s thinking about doing a similar thing. How did you go about doing that campaign?

Kyle: I did that funding campaign for this book because I had done a funding campaign for the, You Don’t Know JS books four-plus years ago. I actually had already had practice at crowdfunding a book project, which is good — the more you can do it, the more you can get practice, the better.

So initially, way back when I did that, I wanted to test whether or not people would like the book idea. And I wanted a mechanism by which I could qualify a buyer — if you’re not familiar with sales, that means that you know that that person is actually going to pay, not just that they say they will, but you know there’s a strong likelihood that they can and will pay. So I wanted to qualify my audience.

I wanted to know, how many people would pay for this? Not just how many people would read it, but how many people would pay for it? This was before having written that whole series of books.

And the traditional publisher route with O’Reilly was, “We’re going to pay you $10,000 or $5,000,” or whatever the advance is. “You’ll spend hundreds and hundreds of hours of your time writing it, and then we’ll see whether or not people want to buy it. And if you’re lucky, then enough people will buy it that you’ll pay off that advance, and then maybe a couple of years from now, start to get some cheques from us for royalties” That was the theory.

And I said, “No, that is broken. I’m not going to spend 500 hours of my time guessing whether people like this idea.” I needed a way to get a better sense.

So what I did was, I went to O’Reilly, and I said, “Here’s what I want. I don’t want you to pay me any advance at all. I’m going to do a crowdfunding campaign. I will use the funds of that as my advance, if I’m successful. I’ll do a crowdfunding campaign. And all I want you, O’Reilly, to promise is, if I’m successful, and if it gets funded, that all the books that I promise to my backers, that you’ll fulfil those.”

So in other words, “Your advance to me, is not an advance of money, but an advance on promises of print and digital copies of this book.” Their risk then is less monetary and more, if I reached every single potential reader of my audience with that crowdfunding campaign, and never sold another book, then they would lose in that deal. But if I didn’t do that, then they would stand to make sales eventually.

So that reduced their risk. Substantially reduced my risk. Because I knew that if I didn’t get enough backers or enough money pledged, then maybe this wasn’t the right audience. Maybe I didn’t have the right voice for that, and I shouldn’t waste my 500 hours. And it reduced risk for my readers, because they weren’t buying a book that was never going to happen. They were only committing money if enough people said, “Yes, let’s make it happen.”

So I thought, “Hey, this is a great idea. Let’s reduce the risk for everybody involved and do it this way.” So I pitched him on it, and I was blown away that they actually agreed. They’re like, “Yeah, it sounds great — let’s do it.” So we did that, and that turned out to be very successful, that we did get the campaign funded, and actually exceeded the funding goal, which was pretty great too.

In the process of writing that book series, the initial plan had been, “Let’s do three short 50-page books.” The eventual series ended up at six books of 1,100 pages total. In retrospect, I should’ve tried to raise a lot more money, because the money that I raised was for a much smaller book series than what I ended up writing. But nevertheless, I still consider it very much a success.

So fast-forward to this new book. At this point, I wasn’t really trying to judge the demand, because I’d already built up enough of a reputation that I kind of knew what people would buy and not buy. This is a more niche topic, but I still kind of have a pretty good sense that people will buy it. But here I had a different goal. Here my goal was: Will people like this book enough to give me the money that it takes to make a professional quality out of it?

I could write all of this stuff in blog posts. But there’s editing and art and a lot of those expenses. Is it worth it enough to people? Of I tell you what it’s going to cost me to get this book off the ground, do people like this book enough to really make it a book, versus should I -? To me, I was already going to write it. But am I going to write it as a bunch of blog posts or just on GitHub? Or do people really value this information enough to fund the process of making it into a real, quality book?

So that’s what that was testing, was, do people care enough to get this in book form, versus a blog. And again, thankfully people did. They did care, and we exceeded that, so -

Len: And did you use Kickstarter, or did you use something else?

Kyle: So Kickstarter was for the first campaign, the one for, You Don’t Know JS, way back. For this one, I did Indiegogo, mostly because this one — I was kind of already sure that I wanted to do it. In other words, it wasn’t like really fully testing.

With Indiegogo, they give you the option of the flexible funding, meaning you get the funds, even if you don’t meet your goal. Whereas Kickstarter, it’s all-or-nothing. So I kind of knew that even if I only made 50% of the way there, I’d probably still do the book. But with Kickstarter, if I hadn’t gotten 100% there, I’d have gotten nothing. And so, that’s why I chose Indiegogo this time.

Len: We’re nearing the end of the interview, which is now when I get to ask one or two self-interested questions.

The first one is: Why did you decide to go with Leanpub for this book?

Kyle: I guess the first answer to that, or the most important answer to that question was — I determined that self-publishing was better for me, because I really wanted the control of distribution. What I was impressed by, was so many other authors that I knew, and that I respect, having chosen this, and then being able to distribute their books in so many other ways other than just on the one site — in other words, I chose Leanpub, because I saw many other authors find Leanpub not to be a closed, walled garden. That was the very opposite of what I wanted.

I didn’t want to create another place where my book was locked up in some specific way, and not be able to put it in Humblebundles or give it away for free someday if I feel like it or whatever. I wanted that freedom in case I wanted to go that direction. And I’d seen several other authors be successful at starting on Leanpub, and then taking it more broadly, and that was attractive to me.

So it wasn’t even really a question where I researched other ones and said, “Well you pay better royalties,” or anything like that. It was really just the social proof that I’d had several other authors that I trust and respect had been able to do the thing that I wanted to dom which was get a good publishing platform and then expand. And that was very attractive.

Len: My last question is — and I might know the answer to this one — if there was one thing we could build for you, or one thing we could fix for you — what would that one thing be? If there’s anything you can think of?

Kyle: Well, at the moment, there’s lots of little things that I’ve learned, and would like to improve. I’ve already peppered your support staff with a number of those emails.

But at the moment, I have found an interesting thing with my books. I’m not even really sure why, but more so than most other authors, people seem to like print copies of my books. Not really getting too much into the details of my deal with O’Reilly, but probably 40% of my book sales of You Don’t Know JS are still print copies, or have been until recently, print copies of those books. That’s a phenomenally high number, compared to most publishers and most authors.

I have some theories about why that may be, that may or may not hold any water. But nevertheless, I have demand for print copies of my books. I’m already getting several dozen questions about this book. “Hey, are you going to make this in print?”

I’ve researched that I’ve found on-demand printers for that. But it seems to be that that direction is like, “Well, we can do that if you want to sell on Amazon.” Which — Amazon has pros and cons. But since you asked, if I had some way to click a button and be able to integrate with CreateSpace or whoever — to be able to do print-on-demand through Leanpub, for me, that would be beneficial, because people seem to like the print copies of my books.

Len: We’ve had people ask us about that before. What we do have, and it’s pretty battle-tested, is a print-ready PDF export option. I don’t know if you’ve come across that. And for a very heavily formatted book, it might not be exactly the right thing. But for many Leanpub authors, they’ve reported back that they can just click the button, upload it to Lulu or CreateSpace or whatever, and they get what they need.

Kyle: I’m totally planning on that. I’m relying upon that. But it would be awesome if, instead of me telling people, “Well if you want the print, go to Amazon,” I’d love to be able to tell people, “Just keep coming to my Leanpub page, and click here and be able to buy it.” I’m glad for the stuff that you all have, and I like the platform, and I made a good decision publishing here, and I’m going to keep doing that. But I would love to be able to keep serving the desires of people, which is that they still want print for some reason.

Len: Thanks very much for that feedback, that’s very clear. We always listen very closely to things that people say, especially people who — I shouldn’t say especially anybody, but if you’ve published many books with a conventional publisher, and you’ve got data like that, that’s very useful for us to hear.

Well Kyle, I wanted to say, congratulations on launching your new book, and good luck with Kyle Simpson week over at Frontend Masters. And thanks for being on the Frontmatter Podcast, and for being a Leanpub author.

Kyle: It’s an honour to have been here to talk. Thanks for listening, I appreciate it very much.

Len: Thanks.

Originally published at https://leanpub.com/podcasts/frontmatter/kyle-simpson-04-12-17.