Kyle Simpson, Author of the You Don't Know JS Yet Series

Len: Hi I'm Len Epp from Leanpub, and on this episode of the Frontmatter podcast I'll be interviewing Kyle Simpson.

Based in Austin, Kyle is an author, trainer, open web evangelist, and a popular speaker, who is passionate about all things JavaScript.

You can follow him on Twitter @getify and check out his website at https://me.getify.com, and you can find his courses at frontendmasters.com/teachers/kyle-simpson.

Kyle is the author of the Leanpub books Functional-Light JavaScript: Balanced, Pragmatic FP in JavaScript, You Don't Know JS Yet: Get Started, and You Don't Know JS Yet: Scope & Closures.

In this interview, we’re going to talk about what Kyle has been up to since we last interviewed him in 2017, current event,s his books, and at the end we'll talk about his experience as a self-published author.

So, thank you Kyle for being on the Leanpub Frontmatter Podcast.

Kyle: I'm thrilled to be back. Thanks for having me.

Len: I always like to start these interviews by asking people for their origin story - but we already covered that in our first interview in late 2017, which I'll link to in the transcription of this interview. So instead, I was wondering if you could just give us a little bit of a rundown of what you've been up to for the last couple of years?

Kyle: Mostly I've been doing the same thing I was doing before, which was focused on teaching JavaScript in various different forms. There's the written form, through books, there's the video form, through video courses - as you mentioned, my Frontend Masters courses. And I've also been doing, for the last seven or eight years, onsite teaching. I think we mentioned that in our previous conversations a couple of years back? So I've been doing that.

Although recently, that has shifted over, say, the last six to twelve months. I am still doing some of those teachings - but it has shifted towards a higher level of consulting, mostly around developer and engineering culture at companies.

In my exposure to hundreds of companies all over the world, I've had a good opportunity to see what works and what doesn't in culture and begun starting - I was getting questions from people at these companies, managers and team leaders, mostly centered around, "Hey, we're trying to hire new people, and we find it difficult to get new talent." And they would ask me, "Do you have any thoughts? What do you think works to get new talent?"

My response to them was a little more frank than they were used to hearing, because I think a lot of companies, when they ask questions like that, they want you to tell them how great they are. And my response was, "Well, if you're having trouble attracting people, it might be because you're selling a crappy product."

When you're talking about recruiting people, the crappy product is bad culture. I think it's underrated how easy it is for a candidate to sniff that out during the course of interview process and discussion. And sometimes, even just on their first few weeks on the job, they sniff those things out - and if they're not liking what they're seeing, then, of course, they're not going to bring other people with them, they're not going to stay, they're not going to take the job offer, and that sort of thing.

So I was frank with them, and said, "Engineering culture is not something that happens accidentally within a team. And a culture of excellence is not something that will happen simply because you tell everybody, 'We want you to be good, and we want you to constantly learn, and we want you to do these things.' Saying it from the top down isn't what works."

Here's an example. I'd have a company that would - every development company, every development team anybody's ever worked on - when you are struggling with a problem and you turn to your neighbor and you ask them, "Hey, I can't figure out why the thing won't move over here," Or, "Why it doesn't work," or, "It's not running," or, "I don't know what this error message means," or whatever - what's happening is that two people are pairing up, and there's going to be an exchange of knowledge - a session here for an exchange of knowledge.

But the problem is, that we exchange this knowledge in a very ephemeral way. You may get the person next to you who says, "Oh yeah, no - I saw that a couple of weeks ago. I just clicked this button and then I restarted that, and then it worked."

And then the person does the same thing that you just said, and now all of a sudden it works. Nobody has any idea why that worked - and more importantly than that, there's no preservation of that conversation. That just became this ephemeral cult knowledge that one person transferred to another - and then it's just lost into the ether. Until the next time somebody has this problem, and somebody maybe accidentally asks the right person.

And so - for me - the core problem in engineering culture is that we focus way more on the technology, and not so much on the humans, and not so much on the interchange and the exchange that occurs between humans.

I just would say to them, such-and-such company, "Tell me what you do to promote a good, healthy knowledge-sharing culture? One that is designed specifically to help everybody rise, and all boats rise with the tide, sort of thing."

I get all kinds of answers. I've had companies that boast about how great they are. They would tell me - I had a company that was talking to me about having me come in to give a talk or something. I ended up sort of saying, "No, I'm not interested." And they were basically saying, "Oh, we only hire the best. We only hire the most senior-level people, so we don't need to really focus on like them learning and knowledge sharing, because we only hire the absolute best."

That's such a naive perspective. When you consider what I've been so fortunate to see all over the world - of people really - that's not how people, and that's not how teams, really work. You cannot have a team of all just ninjas, all just guru rockstars - that's not how teams work. And so, I would push back on them and I'd say, "Here's some ideas for it."

And so from those conversations where I was just virally answering those questions, and asking some pointed questions that sometimes they didn't want to have asked, I realized that there was a need for this. That companies do need to learn about JavaScript, but they also need to learn about engineering culture. And rather than that being a course that I can teach, that's really more of a hands-on consulting thing.

So mid-last year actually, I engaged with Trivago, which is the hotel booking company. I had done traditional training through them, but they reached out and said, "We're interested in some of your bigger ideas on engineering culture. Would you come in and talk with us?" And so that has grown into now a long-term consulting arrangement, where I'm working with their organization. I go onsite, and I meet with their teams, and I ask a lot of questions.

My goal is to not come in and tell you what to do, but rather, come in and ask those questions to get you thinking along the right lines as an organization - "What do we need to create?" And so I'm embedded there. "What do we need to create that all of us - including myself - can help you succeed, and what can you own?" So, I don't create programs for them, but I rather suggest ideas, and I ask the questions, to become the impetus to start these initiatives.

What we did, was we started what we - off the cuff, I named it the Trivago Developer Excellence Program. But that ended up sticking as like, "That's the brand." It's this TDE Program that we're doing there. But the goal is - how do we get developers -? There's plenty of focus on how do you get developers to be better at developing.

That isn't my goal here. I've done that for a long time, but my goal now is - how do you get developers to be better people, that are more empathetic, and that are more focused on helping each other out ? To me, the core is through knowledge sharing. How do we build that as the ground-up culture?

There's a lot of companies that have orgs within the company for learning or education, or ongoing learning, or things like that - those programs are good, and I'm always glad when I see a company has a training org within it. I've seen companies that have full boot camp programs within the company, and that's great.

But that's very, very top down. And quite frankly, that's where most of my experience has been - is in that top-down distribution of knowledge, broadcasting knowledge through workshops.

What I'm working on now, is trying to help build that knowledge sharing from the ground up - from a peer-to-peer perspective. If two people on the team are going to discuss something - somebody's having a problem, or both of them, frankly, are having a problem. And they're going to discuss it, they're going to pair together and figure it out.

How do we make that intentional, rather than accidental? And how do we make sure that we preserve the results of that, so that other people on the team are aware that it happened, and are able to access that same knowledge? And so that begins to propagate out from two people to three, to four, to five - and the whole arc.

That's what the substance of TDE is. And I believe that it is hands-on custom consultation. But I believe what's really the nugget here, is going to be useful to orgs all over the place. And so I'm optimistic that that can be a new focus - on helping consult with companies to build good engineering culture around knowledge sharing. So that's what I've been up to lately, is trying to pivot my career a bit in that direction.

Len: Thanks very much for sharing all that. Is the knowledge sharing that you're talking about - does that involve, say, actually like recording a conversation between people? An audio, and or even video? Does that mean writing a document at the end?

Kyle: All of the above. As an example, we just launched a new thing, to try to lower the barrier of entry to things. Because what we want - my idea is that I want for this knowledge sharing to be as frictionless as possible. And when you have a very top down and formalized thing, people are often not going to do it. Even if they're aware of it. Awareness is a big problem - but even if they're aware of it, they won't do it. Because there's too much in the way, there's too much resistance in the way.

I'm trying to lower that sort of friction. So I imagined, for example - a developer having a problem trying to fix some error. And then just saying, "How about if you just click 'screen record' and then just start talking audibly to your computer as you work through this problem? And then you solve the problem, and now you have this little snippet of a couple of minutes of screen recorded stuff - where you're making mistakes, and then your audio - you're audibly talking to your machine as you talk through what you're doing, or what you're Googling, or whatever."

Or, "You're recording a conversation with somebody when you ask them that question. But now you have this little, literally byte-sized piece of knowledge. And then you can add a little bit of meta information to that. Like give it a title or a topic. Put it in a spreadsheet on a shared doc that the team has access to." And hopefully that was a very minimal barrier to entry to that knowledge sharing, as opposed to having to sit there and come up with a script and have a whole formal thing, where you just were fixing a problem and trying to capture what you were doing.

I want it to be like that. I want it to be as easy to preserve knowledge sharing as it is to fire off a tweet or a Slack thread. It's not there yet, and I think there's a huge opportunity for tooling - and I still have a lot of passion around developer education, engineer education and tooling. I think we did talk about this the last time as well, but the ideas behind the platform and the tooling that I want to create are still there - they're percolating just under the surface.

Where I'm going with this, and where I think eventually this comes out - is that we need tools that are designed specifically to optimize collaborative learning together, collaborative knowledge sharing. There's lots of tools that can share audio and video, we're using one right now. But there's not a lot of tools which try to reduce the friction that gets in the way of capturing all of that stuff. And that's really what gets my creative juices flowing, is thinking about those exact problems, and trying to fix those.

Len: Thanks for sharing all that too. It's interesting. It sort of reflects - that reminds me of some recent changes we've made to the way we do things at Leanpub a little bit. For example, we realized that - if you figure out a solution to a problem that other people are going to face, something as simple as writing it down with an appropriately-titled article in a GitHub wiki, with steps - like right after you've done it - it'll take you a couple of minutes, it'll feel annoying when you do it - but if you ever have to do it again, or if anyone else has to do it again, they'll really appreciate it.

Even adopting a simple practice like that can really change things and make things - and also, show you where the pain points are. Because if you have to sit there setting out the steps for the little hack you did, what you've actually done is you've described a - probably a fixable problem.

Kyle: Whether you know it or not, you've actually tapped into something very, very fundamental. So I love what you're saying, and I know that people bristle at that.

Nobody likes to do documentation. But the interesting nugget of what you're hitting on, is that there's something very fundamental about the way humans learn things, when we ingest information, when we're watching something, or listening to this podcast, or watching a video that is a tutorial on how to do something in Excel - or whatever the thing is that we're ingesting some kind information in whatever form or fashion - the brain is not storing that information in a fully-formed and connected sort of metadata rich way, yet.

On the ingestion path into our brain, most of that information is disorganized. It's not lost, but it's just not organized yet. And your brain is constantly searching for - when it sees a new piece of information, "How can I connect it to something that I already know?" But most of the time, the information's coming in much quicker than your brain can do that.

So we all have probably had this experience where we've been sitting in a class, and you listen for four hours to a lecturer - and there's one thing that the instructor says where you like have that light bulb moment. That was: your brain was able to organize something and make a connection. But all the other material that you got over the course of that four hours, that all came in - a lot of it, you're not going to remember, some of the important stuff you're going to remember - but it's not organized yet.

And here's what's key. The way that our brains actually create all those connections most effectively, is when we then turn it around with all that disorganized information and try to create something from it. In other words, when we try to practice a skill, our brain is forced to try to go through and make all the connections - because now it needs that information.

But even more than just practising a thing, is when we try to explain it to someone else.

So you run through a problem, and then you get a solution to it - the very first thing that you can do to make sure that you have the best chance of remembering that, is to look for an opportunity to explain it to someone else, in your own words - to reconstruct from first principles, as they say. And so even something as simple as like what you're saying - documenting something in a Wiki - is forcing you to step through those, and then realize, "Oh, I don't remember what I did between step four and step five. I don't remember if I clicked the red or the green button. Let me go back and figure that out."

You would not have realized the gaps in that connection, unless you had tried to reconstruct it in the explanation to other people. So that is right on target with what I'm talking about around knowledge sharing culture, at a very base and peer-to-peer level - what we should really all be doing. And I keep saying "engineers," because that's where my focus is.

But I don't think it matters what your job title is, what you do. I think human beings would be far more successful in what we do, in whatever that is, if every time we figured something out, our first instinct was to say, "How do I re-explain that to someone else?" There's a purely selfish motive, which is, "I want to make sure that I learned it better."

But then there's the "help your fellow mankind" sort of motive, the beneficial motive of, "I don't want to just be the only one that's hoarding knowledge. It's not a zero-sum game, where if I hoard more knowledge than you, then I'm somehow more successful than you are." That's not how it works. Actually, it works that if we get knowledge and we share it with other people, then the power of our knowledge goes further.

Len: Thank you for that really great explanation, it's really interesting. One of the things that really resonates with me with that is the "to other people" part. There's an old joke, I think it was Mark Twain wrote a letter to someone and said, "I'm sorry I wrote you such a long letter, I didn't have time to write a short one."

What he's getting at there is the sort of self-indulgence, right? Like he's not - he's sort of more or less writing for himself, rather than thinking about the other person's time, the other person's understanding, and things like that. But when it comes to the kinds of communications we're talking about - I've got a joke from looking at people doing support all the time via email, which is, "I'm sorry I wrote you such a long email, I didn't have time to write a short one."

People who write really short emails in their own shorthand are wasting their own time and everybody else's. If you just take the time to write a proper subject line - take the time to properly explain what your situation is, in the details that you know it - you're saving time, you're not wasting it.

It's so funny, people come from all kinds of different directions, and all kinds of different moods and situations - but if you think sending - if you're listening to this, and you think sending an email with just some information in the subject line and no body content means you're like a hard-charging, no-nonsense person - you're wrong.

Kyle: I'm sure there's some CEO out there who's - a startup CEO, who wrote a book where he's like, "I put all my emails in the subject line and don't waste all my time with the body." And he's probably rolling his eyes at us. But I completely agree with you, 100%, that communication in all of its forms - I mean, I talk about communication as one of the most fundamental and critical things that makes us humans. It's what separates us from computers - empathetic communication with other human beings. That's what makes us human.

And whether that form of communication is an email, like you're saying, or whether that form of communication in my space is the code that we put into a program, those are both ways that we're trying to communicate our ideas to other people, and we have to consider that human component - it is not simply raw bits of information exchange. It is that we need our ideas to infect the other person. That is a human process that needs to occur with empathy.

We need to be considering the other person. If I were receiving this, what would I want it to say? How would I want them to explain it? Because I have my own mental context, and if I don't transfer my mental context to you, then you're going to miss what I'm saying.

We've all had that experience where somebody transfers information to us through a tweet, and we don't read it in the same tone that they meant it in, or we don't understand the mental context that they had - and discommunication occurs.

Well, the only way for communication to really effectively occur, is for us to be thinking in terms of, "How do I transfer, how do I give you my mental context - so that you understand where I'm coming from, when I say the following things?" That's where good communication comes from, and it's fundamentally a human thing.

Len: Very much so. And it's not a froufrou kind of thing that we're talking about here. A lot of people have a sort of natural tendency to relate to terms like empathy as being sort of like, we're abandoning serious hardnosed business here.

Kyle: Oh yeah.

Len: I mean, we can say it till we're blue in the face, and some people will never be converted. But that's not true, this is very serious stuff about the way communication works. I mean I can say personally - I once worked a job where there were billions of dollars on the line in the decisions that were being made, and you communicated clearly and at length in those circumstances, and you were very careful about what was going on.

One of the things that's sort of frustrating once you've seen this, is to see other people tripping themselves up all the time - with no idea that they're doing it, because it's happening in language, and often that seems a little bit abstract to people. But you can see a conversation going off the rails, because people are starting to use the wrong words the wrong way - or something like that. And it feels like you're being pedantic, when you say, "Hold on a second here, we've actually started using this word the wrong way, this is going to confuse people." But it's not pedantic and it's not time wasting. Those things can have consequences down the line, and they need to be stopped at the source if you can.

Kyle: I completely agree. When I was in high school, this is in the mid to late 90s - when I was in high school, there was a phrase that my guidance counsellor used to try to motivate many of us to try to get into computers. I didn't need that motivation, because I was already a programmer. But I remember hearing this sort of phrase. And I think maybe it's time to update it, because at the time I remember her saying, "There are two types of companies in the world - those that are software companies, and those that don't realize it yet."

So the idea was, the whole world - every single industry is going to become driven by software. And there are those that understand that, and there are those that don't yet figure that out - but they're going to become that way. I think in the year 2020, I think we can say - every company in the world, every company on the planet - whether you're like a little plumber shop in some random town, you still do your taxes online - or whatever. Every company in some way, shape, or form, has been touched by software.

And I think it's time to update this phrase. Because we all now know that software is a part of our everyday life. But maybe we could say that, "There are two types of companies in the world, those that understand that they're people companies, and those that don't yet understand that," and they will. Because I really believe that that is - the direction that we're headed is that - the software thing, that is a freight train that's not going to stop. And we're headed more into it, with AI and all these other things.

But what's going to distinguish the ability for a company to continue to succeed, and for a company to continue to make money, is not this commoditized drive towards less humans. It's actually the opposite. Which companies capitalize on humans better?

Len: Speaking of the whole world in 2020 and the direction that we're heading, it's been tough - I mean, this has been a great conversation so far - but it's been 25 minutes or so that we've been talking, and who knows how much the world has changed in that time?

Kyle: I'm almost scared to open up my Twitter feed at this point.

Len: Yeah. I've never been one to watch like the Dow or the oil price, but I have been lately.

It's nuts. Sorry, I already forgot if I mentioned it - but we're recording this on March 18th at 1:40 in the afternoon. Things are changing rapidly, and I would just like to take the opportunity to ask you - well, I like to ask people about what's going on in a place where they live. So if you could talk a little bit about how things are going in Austin right now? And then a little bit about how all of this has been affecting you? Because I think, in many ways, you represent a lot of typical Leanpub authors, and readers, even.

Kyle: I said earlier on my - I sent out a tweet, "Running out of adjectives." And that's kind of what life feels like right now, is that I've - I pride myself on being a communicator and a teacher and an exchanger of ideas. And I'm literally running out of the vocabulary to use to communicate the level of feelings that are happening right now. And I'm sure people that are listening - this is maybe a few weeks lag between when we're recording this and when we're listening, I don't even know what the world is going to look like.

But I know that it's scary. I know that's what it feels like right now. And there's a lot going on that I don't know how to process, quite frankly. I do live in Austin, Texas. And as of this moment in Austin, Texas, we are on, essentially, mostly a lock down of the city. Yesterday they announced that all restaurants and bars and everything else - are all closed, only to take out. And everything else, other than restaurants and grocery stores, is closed. There's no more gyms, there's no more golf courses, there's no more table tennis club - which I love, playing table tennis.

All of it, it's all shut down. Schools are indefinitely shut down. My wife and I are literally transitioning to, "What does it look like to home school our kids for an indefinite period of time?" And we're looking at all these fantastic resources that exist through the Khan Academy and others like that. I mean, we've already started doing that - as are many of the other people in our neighborhood. Because our schools are closed for at least two or three more weeks - but the rumour is, they're likely going to be closed throughout the rest of the academic year, the semester.

So we're facing at least four to eight weeks of a totally different world than we could've imagined. And it was weird to see - even in a week like last week - from day to day to day, how quickly those things changed. We went from like a Monday, where I was having a conversation about, "Yeah, I'm worried about this," to a Tuesday, "This is a lot more real." To a Wednesday, it's almost like the world changed in the span of the 24 to 48 hours.

Personally, there's a significant additional context around the timing of what all is happening. As you said, "Today's March 18th." Tomorrow is my 40th birthday. And in the lead up to my 40th birthday, I had a lot of plans for how I wanted to like celebrate, and not have the sort of mid-life crisis thing. I wanted to celebrate what I've been doing in my own personal life, in terms of health and fitness. Over the last 14 months, I have worked really, really hard and I've lost almost 100 pounds.

Len: Oh wow.

Kyle: By running and - I just decided that by my 40th birthday, this was a really important thing to me. I wanted to get my health in order. And so I've worked really, really hard over that period of time. And the culmination of that was my 40th birthday. And shortly after, I was supposed to - I was going to run in my first ever 10k race. Which has been cancelled now.

And I had a birthday celebration - we had a family vacation planned for Las Vegas. And that was cancelled. I had restaurant and golfing and other plans for my birthday, and all of it - it's literally all cancelled, and I'm going to be sitting at home tomorrow, reflecting on how, just two or three weeks ago, the world looked entirely different.

I don't say all those things in sort of like, "Oh, poor me," or whatever. There's a lot of people that are facing some really harsh realities. But it is hitting me in some very specific ways, just because of the timing around a birthday. There's a lot of symbolism around a 40th birthday, and what you've done with your life. And I'm looking at how the world is literally being rewired as we speak.

This is not a temporary disruption, and a month from now things will go back to the way they were. We're talking about - this is the early birthing pains of a new society that none of us really wanted or foresaw. And, so yeah, there's a lot of personal meaning and - I said just a moment ago, "I'm running out of adjectives." The one feeling that I keep coming back to - ironic, given that I'm planning to do a fair amount of enjoyment of alcohol tomorrow, since that's about all I've got. But the one adjective or the one description that I'm feeling - is that this is sobering, in a way that I never would have expected.

Len: Thank you for sharing all of that. Slightly in advance, happy birthday. I hope you and your family find a way to - I mean, alcohol is a good way of doing that when you're stuck at home - but to try and celebrate in some way. But yeah, I think it's important. I mean, of course we should all be thinking about people who are suffering real sort of tragedies of many kinds - health and financial and family and things like that.

But we're all facing the day-to-day things. The celebrations that are cancelled. The vacations that are cancelled. The things that give enjoyment and pleasure to life are important when they're gone. I think it's important to express them to people.

And so - professionally, you do consulting, and you were talking about doing onsite consulting and things like that. Has your consulting work been affected so far?

Kyle: I would say the word "affected" is not a good enough adjective, unfortunately. I spoke earlier about my hopes and my dreams for the pivot of work to consulting and to being onsite, and all of those sorts of things. The reality is, that essentially all of my work for the foreseeable future has been cancelled.

Every event that I had booked, it's all cancelled. From trainings to conferences. I personally have already seen the elimination of about 30% of my expected annual income this year - its gone, and probably more is going to get cancelled and eliminated. And that is - as I said, it's sobering to think about the financial impacts of that.

As I've reflected over the last couple of days on what is happening, it's not surprising - and I'm sure everybody listening here is probably thinking, "Oh well, this is the time for the Skypes and the meetup.com's of the world to shine. This is the time when everything moves online." And I've gotten that question a million times. "Well, won't you just move all of what you do online?"

The unfortunate reality - and I don't know how any of it will play out, I can only say what I'm guessing or wondering at this point - but I haven't enjoyed the idea of travelling for a long time. I've got young kids that are nine and seven, and I'd like to be home more with them. I coach their baseball and softball teams - or at least I did, until the seasons got cancelled. So I would like to be home more with my kids, and not travelling.

So it's not the first time that I've contemplated, "Gee, I wish I could do my work but not have to travel to Germany or India or Australia." I've seen a lot of great places in the world, but I've travelled for eight years nearly non-stop. And I would love to have a work that didn't require that. The problem is not me not wanting to do it, and it's also not necessarily a lack of some kind of tool - and I'll come back in a minute to tooling - there are tools, like the ones we're using right now to record this - there are tools where people can have conversations over the internet, obviously.

The problem is actually perception. And I don't know what society's going to do with this. I don't know how long it's going to take to rewire this kind of perception. But the clients that I've worked with - for years, I've brought up the topic of doing through tooling, doing internet based meetings and trainings and consultations and all of that. And the clients that I've worked with - big, giant companies to tiny companies, and everybody in between, there is a perception that onsite person-in-a-desk sort of thing, is where the most value comes.

And I suspect that it's similar to how a lot of companies in the world prior to this virus pandemic - they had no concept that they would ever even remotely broach work from home, kinds of things. They want warm bodies in chairs, and that's how they manage their resources and their people. But there's a societal perception that in-person is the gold standard.

And so, if you're talking about teaching - an onsite workshop is the gold standard, and it's also the one that costs the most, right? So I can charge the most for that kind of service, because that's where the perception of value is the most. I didn't create that perception, I'm just part of that. And if you're a speaker - speaking at the conference on the keynote stage, is a whole lot different than sending in a recorded video of that exact same talk. Because the presence matters to people. As a human, the presence matters.

And so, the problem that I have is that - there are lots of ways to get the raw content that I have through my books. Which - not only do I sell my books, but I literally put out all my books in Creative Commons for free on GitHub. So you can literally read every word I've ever written, for free, on GitHub. And buy my books, which I hope you will do.

But, you can read my books for free. And you can also listen to podcasts that I'm on for free, and listen to my thoughts for free. And you can also, for really cheap - not free, but cheap - get access to the videos that I've put together of my courses on Frontend Masters.

So for $40 a month, you have unlimited access to their entire library - including my 10 or so courses. And you can watch my courses for free.

And so there's a perception problem that these clients have always had - which is there's a giant gap between, "We'll pay for the gold standard to have you come onsite," which has been basically my business model. To, "Well, we don't need you onsite anymore, and that's not even practical to bring you onsite. So why don't we just pay one one-thousandth of the cost, and just access your free stuff or access your videos?" There is no business model in between.

And so, right now where I'm reeling is - most of these clients that are cancelling, it's not like what occurred to them was, "Oh, well let's just have you do it over Skype." What occurred to them was, "Well, we can't have you in person anymore, so we'll just do the other stuff. The stuff that we don't have to pay you for." And so I'm reeling right now, trying to figure out how to reinvent a business model. Because four weeks ago, I could never have imagined a world where people didn't value the onsite gold standard proposition. And now they don't.

And so I don't know how long it'll take for businesses to move to a mindset that says, "Having somebody live in a Skype call," or whatever the case may be, "That will be just as much value as we used to have when we had him onsite." I don't know how long it's going to take, if ever, for that to rewire itself. But it isn't going to be overnight. So my business is definitely in a precarious position, if you will? Where I'm having to figure it out and reinvent it as we go.

Len: Thank you for sharing all of that. There's a lot in there that I hadn't thought about myself. And we all of course wish you the best of luck, and everyone else out there who's facing changes like this.

It's - one of the things I think we're all reflecting on, is this physicality. So for example, I think LA - a lot of companies in LA are now working from home. I just read about this specifically. Because they typically - LA was famous for its traffic. And now the freeways are pretty much empty, because Sony and everybody's working from home. I wrote a blog post about this being kind of snarky, because I've always been a work from home evangelist type.

But when people suddenly find themselves back in traffic, are they going to be thinking, "Hold on a second, I could be at home working right now. What is all of this?" And so thinking about it from that perspective, it can be easy to be like, "Oh yeah, we should all shift to working from home." It'll be a huge revolution in all kinds of ways, and there'll be all kinds of winners - like maybe Skype or something like that? And all kinds of new tools and practices, and stuff like that.

But people build those freeways. People maintain those freeways. People have gas stations, people have electric car charging stations. At the other end of it is parking. That all needs to be maintained, that people are paying for and that people are receiving money from. There's lunch counters. There's all the barbers and all the other kinds of businesses that happen around office buildings, and stuff like that.

And so, if people realize that they can get things done much more cheaply, that means that all that - that's going to be good for the bottom line in some senses, internal to the organization. But there's just this whole world around these practices. These in-person practices that - as you say - right now we don't know if it's going to come back ever, in the way it was before.

Kyle: Yeah, I mean, you're absolutely right. And that's part of what is so profound about this situation. Because there are people - and I'm sure there's people listening right now, who are thinking, "This situation is over-hyped, people are over-exaggerating." And I just want to go on record as saying, as frustrated and confused and scared as I currently am about the situation, and even in a very, very selfish way - the fact that essentially most of my birthday plans are completely ruined as a result of this - and that's super like surface and selfish for me to say. But like even with me saying that, we're not overreacting - as a matter of fact, we're probably still underreacting. As a society, we're not recognizing just how profoundly this is going to change.

And like what you're saying - I saw yesterday a famous chef, Tom Colicchio, being interviewed, saying that he's already laid off a significant amount of his staff. First time he's ever had to lay off staff. He said that, "Within the year, 25% of all restaurants globally are going to be out of business." So what is going to happen to the restaurant industry? It may not ever be a thing that we humans go eat in packed dining rooms at restaurants again. That is profoundly different. That is not just like, "Oh, we waited a little while, and we were a little bit inconvenienced. And oh, us in our ivory towers are -" This is a different world. I have family members that work in the food industry, who might be out of business. They might be out of work. There might not be work for them to do.

So you're right. Like - yes, there might be a perception that this can be a good thing, to solve a lot of our traffic problems. And yes - maybe with traffic problems reduced, then there's fewer deaths on the road. There are silver linings, there are positive things that may come out of it.

But there will not be a zero impact. There will be a very non-zero impact to a lot of the other parts of the world. There may be whole industries that currently have driven our society, that don't exist 24 months from now. There will probably be industries that haven't been invented or conceived of yet, that will exist 24 months from now. We're talking about a large scale rewrite of society.

One of the things that I'm concerned about, frankly - is similar to what I'm talking about with, how will the perception go? Will there be some way for there to be a business model around what I do, that doesn't have to have me onsite? That doesn't have to have people gathered together? Is that a thing that we can get to?

It's a trailing indicator, right? Because by the time I can make that into a business - that would have already had to be very prevalent among a lot of different clients and a lot of different people, at a lot of different levels of leadership. And the corporate budget has to be accounted for, and all of that. That's not something that happens in a few weeks. It's something that happens over a couple of years. So this a long scale question, of, how does that rewire?

One of the things that I'm worried about, is that as more companies do embrace this idea of, "Okay, sure you can work from home," the positive side is that we would hope that all of them would say, "We're going to pay everybody exactly the same, or maybe even more? Now we don't have to pay for office buildings, so we're going to put all of that in."

But the negative side of that, that will happen in some parts of every industry, is that those companies are going to eventually look at this as an opportunity to cut costs. They're going to say, "We can pay people 50% as much as we used to pay them. They'll still work, because they all still need the money. But now we can pay them 50% as much." Or, "We can hire twice as many people, and pay everybody half as much."

And all of that can be driven from the perception that they're trying to minimize their risk. "If I don't have people in the seats where I can manage them, and if they're out - then that means that they're going to be less productive, and so I have to spread out the risk over more people." These are all things that are going to happen at some level.

So I'm thankful that we're going to get a chance to try this big experiment. Because without something shaking us up, we probably wouldn't have tried. But I do think it's going to be rocky as we figure it out. I think there's going to be a lot of taking advantage of the situation. So there'll be people that win, and there's going to be a lot of people that lose - and I'm sad about that.

Len: Yeah. Just one thing I've been thinking about on that note, is that there are - one thing I think a lot of companies are going to realize, is that there are a lot of positions and practices that only exist because people work physically together.

And I mean, like high level - like white collar management types, and even executive positions. That, just, companies might realize -

Kyle: "Why do we need that anymore?"

Len: Yeah, "We don't need that anymore." And they're going to be motivated to cut, and it's going to be dark times.

So, thank you very much for talking about this. I mean, we could talk about it probably for hours.

Kyle: I'll come back on anytime, I've got all the time in the world now, any time you want to talk about it, let's come back on.

Len: It's interesting even mentioning that. I've actually been thinking about maybe increasing the cadence of our podcast. Partly because there's so many more people who are at home and have time. And the podcast exists - in part - to help promote the platforms of our authors, and help them reach the readers that can be helped by the things that they write and produce. And so maybe dialling it up a little bit might be the right thing to do right now.

For anyone who's still here with us, let's move onto the next part of the interview.

Kyle: Let's move on from the doom and gloom -

Len: Yeah.

Kyle: That's a heavy, heavy set of topics to discuss.

Len: ...to talk about JavaScript and then your books.

Preparing for this interview, I saw a really good video that I'll put a link to in the transcription that you did online a little while ago, called, Keep Betting on JavaScript. This is a really excellent talk. Just as a matter of like creating a talk, in the abstract - it's a good example. And there are a couple of really interesting things in there that you talk about. I guess - before we go on, just very briefly - could you talk about what JavaScript is?

Kyle: Yeah, absolutely. It's not the Java programming language, let's just get that out there. JavaScript is a wholly separate language that just, for marketing reasons in the early days at Netscape, took on the name, "JavaScript." But it's a whole separate language.

It started in 1995, embedded first in browsers - and then in the last decade or so, moved way beyond the browser.

It's now, I think it's pretty fair to say, the world's most ubiquitous programming language. Because it's in light bulbs and refrigerators and TVs and robots and computers and phones and watches and glasses - and who knows whatever else? It is definitely everywhere around you. It's the programming language driving a lot of that. It is a - to throw in a few buzz words that people are always hearing about languages, it is - even though it says "scripting" in it, as in the name "JavaScript," actually most of us refer to the language as "JS," rather than as "JavaScript."

But JS is a language that is compiled just in time by the JavaScript engine, and then executed in whatever environment it happens to be in, whether that's your browser, whether it's a node on a server, or whatever. So it's not like what people used to think about with scripting languages, sort of line-by-line interpreted. It's definitely a full compiled language. It's multiparadigm, so you can do object-oriented, you can do functional, you can do all sorts of different kinds of things.

And what I like about JavaScript is that it has this unique mix of the multiparadigm and the dynamic typing, that gives you a tremendous amount of flexibility to make the right choices in one part of your program, and make an entirely different set of choices in a different part of the same program. Instead of being an all or nothing, you can be all functional or all class, or whatever. You have a lot more choices.

And so, for me, JavaScript is ultimately the most pragmatic language I've ever experienced. I've seen a lot of languages, but I picked JS because it's so pragmatic. It's just sits there and helps me do what I need to do, without being in the way of that. And that's the reason, ultimately, that I like the language.

Len: And in this talk I mentioned, you talk about how JavaScript is a lingua franca, and how that term doesn't mean what people typically think it means. So could you explain a little bit about what you mean by that? What lingua franca really means and how it applies to JavaScript?

Kyle: Yeah, that's actually one of my favorite little tidbits. I'm glad you called that out. So a lot of people have - many people have heard the phrase, but not a lot of people really know exactly where that comes from. And so, just a sort of a background on that - so lingua franca is not just a common tongue or a common language. I think that it's almost used pejoratively in that sense. Like, "Oh, it's just the common tongue."

If you think back to like the medieval ages where you had the high languages like Latin, that only the most academic people spoke, and then you had those common, raw, coarse, unrefined languages - a lot of people think of lingua franca in that sort of context.

That's not at all what this phrase is referring to. It's actually referring to a really important thing that has existed within human language for a long time. It's the idea of bridging between disparate languages.

A lingua franca is a bridge language that allows two other disparate languages to communicate more effectively. So in essence, it's almost like taking the best parts. It's not really this in a mechanical sense, but it's like taking the best parts of these two languages and molding them together into this third hybrid language, that allows someone who speaks the original two languages to communicate.

So that's the idea behind lingua franca. Again, it's a fascinating study to Google the importance of that throughout human history.

That phrase is thrown around when we talk about JavaScript, and I use that phrase very intentionally. Not in the pejorative sense, like this low brow or unrefined - but in the sense that JavaScript has served this role of bridging many, many gaps that people don't really fully realize. It serves in the truest essence of spirit - this role of lingua franca. Because what it is doing, is it is allowing - through the web platform, I think is the best embodiment of this. But it's allowing "someone who speaks," and I'm using that phrase with heavy air quotes here.

"Someone who speaks the language of Go, for example. And somebody who speaks the language of Rust, and somebody who speaks the language of Python - it allows those people who are speaking very different and disparate and not compatible languages, to actually communicate and to collaborate in a space of the web platform.

JavaScript is that bridge. It is that way that that occurs. And I think it's very underappreciated how important that role is being served, nd the special needs that that - and the requirements and conditions that that places upon a language.

Because there are many other languages that, from a marketing perspective, would love to have that role. They would love to be seen at the center of the web. But I don't think that they necessarily want the burdens that come with being at that center, in that center position. Because the burdens on JS have been tremendous.

And in many ways, the complaints that people may have about the language from a syntactic perspective - a lot of people don't realize why those choices are made, that many of those choices are almost not choices at all, because of these constraints, because of how many different constituencies JS has to serve.

I think it's fascinating, I think it's important. I'm not necessarily a historian or a historical buff, but I think it's really important that we know our roots, if you will? And knowing the roots of where JS is, and what role it's really serving in that, is important if you want to think philosophically about where the web platform is, and where all of software development is now - and where it will be 10 years from now. I think it's absolutely inextricable that JS is right in the middle of that, and playing a really key role.

Len: Yeah, and speaking of the different constituencies that are being served in the future of JavaScript - you have this great metaphor in the talk of, "Imagine, you look up into the night sky and there are two distant galaxies right next to each other, and imagine if we sent off a mission to one and a mission to the other. For a long time, they would look like they were travelling in the same direction. But ultimately, you would find that they have very different destinations."

And sometimes when you're in the moment to moment, or as you say in the talk, "baby steps," you don't necessarily see that these fundamental divergences have started to happen.

How does that - just for our audience, how does that apply to the current and future situation of JavaScript? I believe it actually is - I might get this wrong - but the distinction is between serving people and serving machines.

Kyle: Yeah. That's the ultimate punch line, if you will, of the talk - is that what we have right now is a JS that has been developed over the last 25 years, since 1995, in a very baby steps, incremental way. And when you do only baby steps incremental evolution of something, and you don't ask the bigger picture, you often end up in a very different location.

And so I set up at the beginning of this talk, a historical perspective on how the United States, NASA, programmed in the 1960's. How we went from never having put a man in space, to setting man on the moon. How that happened over the course of approximately nine years. And that didn't happen by accident, it happened because the people there had a very healthy perspective on not only taking incremental change through all of the different little missions that they did, and all the experiments and improvements that they made, but also that they had this bigger picture idea that, "I'm going to do something now that I don't even need the results of for another couple of years. But if I don't do it now, by the time we get there, it's going to be too late. I've got to be planning for it." So they have this perspective both in the small baby increment, and in the big picture.

And what I'm basically saying, is that a lot of technology evolution does the small baby steps evolution thing really well. We have this agile thing really, really down, right? We're really, really good at, "Oh just quickly increment and quickly evolve and quickly iterate." But we don't always step back and say, "Where is that going to end up leading us?" And so as you said, just like two rockets fired off at two different galaxies, would from our perspective look like they were heading in the same direction for a really long time - eventually, they're literally going exactly opposite from each other. Because they're going hundreds of millions of light years in opposite directions from each other.

And what happens is that if you wait until that moment, you don't realize it. If you wait until the moment that you look back and you realize, "Wait a minute, they're out my rear view mirror - they're not out my side window anymore." Then it's too late.

And so I'm asking those sorts of questions in this talk about the divergence between a JavaScript - a JS language that has been so good in this lingua franca sense, at allowing people to communicate, allowing people to express ideas. I believe fundamentally, that's what code is. It's a communication of human ideas.

So it's been so good at that, but it's also - by serving all these different masters, it's doing all of these other things where it's serving the machine. And we see that playing out, most notably right now, the talk points out - with the advent of web assembly.

Web assembly is a sort of an end run around some technical challenges in JS, specifically around how long it might take to parse the textual code of JS. And so it's a technical end run that allows other languages to get into the JS engine at a lower level with pre-compiled, optimized, ready to go instructions.

And actually that's a really great thing. That's a really great thing for the web. We need more programs. We need more performance and efficiency and all those things. That's actually really good.

But the direction that we're headed, it asks some really important questions about, "Will we eventually not have a JS that is this lingua franca?" We'll eventually not have a language whose job it is to express human ideas. And more, it's job is just to be the efficient transformation of zeros and ones from one part to another - where it's serving the role of the machine, more than it is serving the role of the people.

I just believe very much that if we get to that future, we're going to look back and say, "I wish I'd been on the other rocket. I wish I'd been headed in this other place." And so I was just really trying to ask with this talk, the choices that we make. And really, the big one that it comes back to for me, is, for me and for so many other people - the way that we got onto the web, the way that we understood what it meant to be web programmers and to build things - is "view source."

That sounds like a very quaint idea with today's modern approaches, and so much complexity in the ecosystem and the toolchains the developers affront and use these days. But the way people onboarded to the web before, was they saw somebody do something cool on a webpage, and they clicked to view the source, and they copied their ideas and made them their own. A whole generation of people came onto the web, and the web was really born because that was true.

Are we getting to a future where there is so much abstraction and so much complexity there that there is no more "view source?" And what does that mean for how my kids and my kids' kids onboard onto the web? Because I wouldn't have been able to get where I am, if I couldn't have learned from "view source." What's it going to mean for how they learn the web? That's the question that the talk leaves you to ponder.

Len: Just for those listening who might happen to not know what "view source" is - if you open up a web page, you can right click on it and go "view source." And then you can see the code behind it. And what Kyle is talking about is how sometimes - if you go in a certain direction with the way the things work, you can click "view source" and just see very little.

Kyle: You can see a lot of stuff that is not even representative of the code that was written. Because it's gone through so many transformation steps, so it's almost undecipherable at that point. And that creates that - again, we're going back to this - it creates that barrier of entry that I lament. I don't think that will be a healthy move for us. So while I like the good parts of where we're going with the web, I want the web to succeed. I don't want us to lose our roots.

Len: Speaking of learning, I'd like to move on to talk about your latest book projects. You've got a couple of books that are reaching a lot of people on Leanpub right now, You Don't Know JS Yet: Get Started, and You Don't Know JS Yet: Scope & Closures. I was wondering if you could talk a little bit about who those books are for, and actually if you could talk a little bit about the origin of the "You Don't Know JS," which - for our non-English speakers, there's a saying in English which is, "You don't know jack shit." And so this is - Kyle's sort of brand is this wonderful, wonderful pun on that.

Kyle: Yeah. It is a pun, there's a lot of different meaning behind it. So as a quick little refresher - back in 2014, I started a series of books. It was going to just be a few short books, and it turned into six books. So a little over 1,100 pages total. And that book series is called, "You don't know JS."

The first edition of those books I wrote and published through O'Reilly in 2014 and 2015. I've sold a little over 150,000 copies across those six books. And probably another several hundred thousand people have read them for free in other places, or whatever. So it's a very widely read series of books.

Most JavaScript developers have heard of it. Some love it, and there are plenty that don't like it - and that's fine. But it's a household name, if you will, in the space of JavaScript books. So I'm tremendously blessed. Because at the time that I was starting to write that book, I literally was like, "Maybe I could sell 2,500 copies?" That was my goal. And it's just - I'm unbelievably blessed at how widespread and how useful those books have become.

The title, "You Don't Know JS," it obviously has several levels of meaning. The first meaning was a play on the pun of, "You don't know Jack," as Len said. But there's a deeper set of meanings, and I've pointed to this many, many times. The idea really behind that title - oh, let me back up. There's a second meaning there.

Which is - I interviewed at Twitter in 2011 or 2012 for a job, and ended up ultimately getting rejected for the job - even though I was already a pretty prominent figure in JavaScript. And the interviewer basically said to the HR person that that I didn't know JavaScript very well.

And in that moment when I got that feedback from the interviewer, the book series title was born. So there's a meaning there.

I'm actually grateful. Whoever that interviewer was - if you're out there, if you're listening - thank you for telling me that. Because the whole rest of my career has been shaped by that challenge that was laid down.

Anyway, the third meaning - I think most important meeting behind, "You Don't Know JS," is that I don't think it's actually a thing that somebody knows a language. Something as complex as a programming language or a spoken language is not a thing that somebody masters. And I've said this many, many times. So people will probably hear this and think that it's sort of a broken record effect.

But knowledge, mastery and knowledge, they're not a destination, they're a direction. So the idea of, "You Don't Know JS," is you don't know - you don't even know that thing. You just get to know it better.

I'm trying to challenge people. Instead of thinking about JavaScript, or any programming language for that matter, as a thing that you master and then move on - that it's to adopt a constantly evolving, "I constantly have to learn, I constantly need to work more to understand that thing."

That's what these books are designed to do, is - on the surface, I'm teaching you about JavaScript, but underneath, what I'm trying to really teach you, is that you have to adopt a constant learning approach to it. That you will never actually know all of this.

I don't know all of it. I've forgotten significant portions of the stuff that I put in my own books. So it's not possible. Brendan Eich, the creator of the language, does not know JavaScript in the sense of he has everything mastered and he knows it all and he's some like sort of god-like -

And that's not how people work. We always have something more that we can learn about the thing. So "You don't know" means, "You don't know, because nobody does, but you can know it better." And that hopeful part that I just added on there, the "can know it better," was lost a little bit on people in the first edition. Some of the push back that I received when I titled them that, was that people took that phrase, "You Don't Know JS," as an insult.

I have had many people that have told me, "I saw that, and I was like, 'Well who's this guy? How does he know I don't know JS? Of course I do.'" And they took it as a personal challenge. Some people validated themselves by reading the first couple of pages of my book and saying, "Oh, I know all this," and they discarded it.

Other people took it as a challenge, and then after reading the books came back and said, "Actually, I didn't know it, thank you for pointing that out." Actually the guy who wrote my forward for this, "Get Started" book, he said literally that. And he said, "I know JavaScript." And he read the book and he's like, "Ah, actually I don't. And there's more to learn, so -"

Some people took it as this challenging or sort of pejorative insult. And that was not my intention, but it did ruffle some feathers. So the second edition series that I'm now writing - I'm not publishing with O'Reilly, I'm self-publishing - which is why it's happening through Leanpub.

The second edition series, I'm rewriting the books from scratch. It's been five years, a lot's happened in JavaScript. A lot's happened in me. I have a very different perspective on the language. I'm much more mature - and seasoned experience around it.

And that's what is coloring how I'm talking about and explaining things differently and much more in-depth now. So I'm rewriting the books from scratch, each one. Some of them are getting the same title, and some of them are - the title is changing.

The first book and the first edition was, "Up and Going." This one's now called, "Get Started." Because I get a lot of people saying, "Where do I start? What should I read first?" Well, now I've got a book called, "Get Started." So hopefully the question self-answers itself.

But the book title series for the second edition is called, "You Don't Know JS Yet." I added that word on there - not only to distinguish the second edition, but also to point out that this is not about saying, "You can't know JS." It's about saying, "We don't have it yet, but we can always move closer to it." So I hope people will just, in that sort of subtle way, I hope they'll get what I'm really trying to go for here.

So that's what I'm doing, I'm rewriting these books. And we have the first two of the six out, Get Started and Scope & Closures, those two are out now.

Len: And do you have landing pages up for the other four?

Kyle: I do not have the landing pages up on Leanpub yet. I mean, I can create those. I don't have those landing pages yet. But I do have - on the GitHub repo, where I do all the writing - there's placeholders for all six of the books, yeah.

Len: Okay. I just bring this up, because, for those who don't know - when you create a Leanpub book, we automatically create a public landing page for the book, where people can sign up and then be notified when their book comes out. And that doesn't necessarily - by the way, for those who are worried about getting on lists and stuff - it's up to you whether you want to share your email address with the author. So you can safely sign up. And - yeah, so if you do set those landing pages up, Kyle - just let me know, and I'll make sure that links get into the transcript for this episode. [The landing pages for these new books will appear here - eds.]

Kyle: Yeah.

Len: Thanks very much for sharing all of that, and best of luck with the series - the two first books and, "You Don't Know JS Yet" have been pretty popular so far.

For the last part of the interview, we like to go into the weeds a little bit, for people who are either self-published authors themselves, or who are thinking of becoming self-published authors. Has your writing process changed since your first series of books came out?

Kyle: Well that's an interesting question. Mechanically, not that much. The very first time I wrote on the very first of the books, in "You Don't Know JS" books back in - like I said, 2014 - the very first thing I wrote in the book, I had already determined that I wanted to write in Markdown. I did not want to sit in Microsoft Word or some other BS program and try to deal with all the proprietary nonsense of that. I wanted to do it in a very sort of low-level way. I knew I wanted to write publicly.

So I wanted to do it on GitHub. I wanted to have my whole process out there. And so, even when I was talking to O'Reilly and working with their editors and things - when we had our very first conversation, I was like, "Well, we're not going to deal with this stuff over email. You're going to give me feedback by way of filing GitHub issues and pull requests against my writing, because I'm doing everything in the open." So mechanically, that is actually still exactly the same process as I do today.

Ironically, I still work with the same editors - they just don't work for O'Reilly anymore. I still hire the same via contract - content editors and copy editors and technical editors and things like that, to go over my book.

What is different now, is that I'm doing all of that, instead of having a publisher do it. So that has significantly changed. I'm now managing all that, and I have learned - so, this is my third book to put out through the Leanpub platform. Functional-Light JavaScript was my first, and now these two in this series. I've now done it three times on Leanpub. And I'm learning the ropes a little bit better as I go.

I sort of divide out the process as - there's the writing portion, which is what gets a lot of attention from people, and that's actually - the biggest barrier to entry is people feel intimidated by writing. So I've tried to have that whole process out in the open, to kind of demystify and hopefully inspire more people, that you can write, you can put your ideas down in written form.

But there's this other part of the process in the middle, that I didn't have any line of sight on before, and that's the production process. There's a difference between, "I wrote something," and "I got a book polished and really ready to consider a book for sale."

I'm not suggesting in any way that if people don't go through that production process, they haven't written a book. That's not what I mean.

But what I mean is, that there's a lot of stuff that happens in production - quality control sorts of things, that I didn't realize happened.

And so, when I first got onto Leanpub, what their tools do so well - is they take your written form in whatever fashion, whether it's Markdown or whatever you've got - they take it, and you get this nice, shiny-looking PDF out of the deal.

And you're like, "Wow, I have like a published book." I was wide-eyed by that. I was like, "Wow, their tools did all of that. I didn't have to like figure out how to line up all the margins. Their tool just does it, and it does it so well - and that's awesome."

But as soon as I finished that, and I started thinking of, "What's the gap between what I just outputted there from their tool, and what - for example - I was seeing and buying from O'Reilly?"

Where I thought that gap was kind of small, it turns out that gap is rather large. There's a lot to it, and - that goes into content editing, where somebody's helping you figure out, do your ideas make sense and flow? To copy editing. Do you have typos? To typesetting. This is an interesting one, because the Leanpub tools don't give you a lot of control over typesetting.

And for those of you that aren't nerds in the book world - I've had to learn this. Typesetting is the process of making it look good on the page. Making it so that all the words are - there's things like justifying the text. That's obvious. But like, not having the first sentence of a paragraph on one page, and then a whole separate page where the paragraph continues. Like, just moving that sentence onto the next page and stuff. And so their tools do sort of part of that job automatically, but not all of it.

And so what I have had to learn how to do, and I spend a significant amount of time now with each title, is basically - sort of reverse-engineering the typesetting, by tweaking the words that I'm using, and where I'm placing figures, and all kinds of different things. So I control through the content, and then click the "regenerate" button, and look at what was produced by the tool. And then I do it again and again and again.

And so I go through that whole process, and it was - on my most recent book, it was well over 10 hours of just tweaking all of that stuff so that every single line - there weren't any overflows on lines, and the figures weren't in weird places, and they were just perfectly sized. And there was page breaks where there needed to be.

That's a ton of work that I had no idea went into books. I've figured that out now, and so I - I literally, actually through my publisher imprint - if you will - I'm a publisher at this point called GetiPub - I offer consulting for other self-published authors that want to do those sort of quality level control production things, but don't know the first place to start.

Just like three years ago, I had no idea what I was doing. Well, now that I do know something about that, and I do understand it, and I do understand the tools that we have available, I feel like I can help people do that. That process is radically different. Because I'm doing all of this stuff that I've never done before.

And I mentioned too - so there's writing, then there's production. And then there's distribution and fulfilment. And this, again, was something that I didn't realize, because my publisher just took care of it. But now that I'm doing it on my own, I have to figure out - where do I want to sell my book? Yes, I want to sell it on Leanpub, but is that the only place? Do I want to sell it elsewhere?

A big channel for distribution for most people is Amazon. So, what does it take to work with Amazon? How do their tools deal with what I'm getting out of Leanpub? And so I literally have to take the EPUB that the Leanpub tools generate, and I have to go in and edit the markup that is created there - to get it just right for what I import over to Amazon. So I've got this whole process where I decompress the EPUB, mess around with all the markup, recompress the EPUB, and upload it to Amazon.

And then I'm just now, actually - starting to learn. I'm working with a publishing company as a distributor. They're going to try to get my books distributed through all of the other bookstore channels. So, print and all of that other stuff. So I'm learning about all of that. Print, by the way, is a whole other thing. Learning how to get your stuff. Not just to look good in PDF, but how to get it to look good on the printed page.

So all of that - the production and the distribution fulfilment, all those other things. Those are all things that three years ago I had no idea. I mean, I know abstractly that somebody did it. I had no idea what it was. That's all now stuff that I spend - and I budget a significant amount of time long beyond the last word that I wrote in the book, there's all of that work to really go to the next step, so -

Len: Thanks very much for sharing all of that. One of the things about Leanpub, is that - because we're so much focused on encouraging authors to publish in-progress, one of the things we say is that, "While you're writing, formatting can become a form of procrastination."

And people who find themselves writing, often become perfectionists. And so they might be trying to get everything perfect. And sort of one of the battles we fight is like, "While you're writing, you might not want to worry about that so much." Particularly -

Kyle: I completely agree, by the way. Absolutely. Don't worry about that until the end, for sure.

Len: Yeah, and then at the end - of course, I mean, this is something that people are more familiar with now than they were sort of 10 years ago or so. But when someone opens up and ebook that's not in a PDF, but like in an EPUB or MOBI format in an ereader - they can do things like change the font size and stuff like that. And so, a lot of the conventional issues that people producing books for print face - like you talked about, widows and orphans.

For those who don't know, this is when, for example, you've got the first line of a paragraph at the bottom of a page. It looks gross. Or when you've got the top line of a page is the last line of a paragraph, it looks gross. And there are tools out there that can help you deal with this in a more automated way.

So one of the things that we do, is we try to - when someone's done - like done, done - we provide an InDesign output option if you've got a Standard or a Pro plan. And that way you can then - you can either do it yourself, as Kyle has learned how to do. Or, you can send it off to a professional book typesetter, and they can get it ready for you. We try to do as much as we can. Well, we try to do a lot for people who want to get their books on things like Amazon.

So we have a button you can click to do "Print-Ready PDF" output. That gives you the kind of PDF that you often need. But if you really want to get it right, that probably won't be good enough for you. If you've written a novel, it's probably good enough. Because there won't be any images or figures or anything in there. But if you've written a technical programming book - for most people, actually - there are extra steps, and those are the kinds of challenges that Kyle has taken on to deal with himself.

Kyle: Yeah, I just want to state for the record - in no way shape or form was I criticizing their tools, they are fantastic. Leanpub's got a really amazing toolset. I just didn't realize how much even beyond the tools, humans have to be involved in thinking about and tweaking and polishing for quality. And so, I - there's no other platform out there that I would use. They have a great toolset. It just, there are additional steps that you can take if that becomes something that's interesting to you. And it was just something that I had to learn the hard way, to go into those steps.

Len: Thank you very much for saying that. Also for the record - insofar as Leanpub is a good platform, it is largely due to complaints and criticisms that we've received from authors over the years. We've been very fortunate to have people who build software products be the users of our software product. So that's really helped. And we are open to criticism, and we love all feedback - including negative feedback.

So on that note - the last question I always like to ask - and I think I know what your answer might be. But the last question I always like to ask Leanpub authors in these interviews is, if there was one feature we could build for you, or one problem we could fix for you, and time and resources were not an issue, what would you ask us to do?

Kyle: Well, let's see. The great part about what Len is saying, is that they are absolutely some of the friendliest and most on top of feedback and responding. I mean I write some feedback - and you normally expect when you throw some feedback over the wall at some company, that you get a form letter response or whatever. And no - I get like a personal email back from like the founder of Leanpub, saying, "Thank you, we're working on this." Or, "Did you try that," or whatever. So they are really fantastic to work with, and they've listened very patiently to a lot of my feedback over the last three years. So I love that.

The thing that comes top of mind to me right now is that, because it is so much extra work for me to go from the digital publication to the print publication, there are a number of settings right now that are appropriate for the PDF output, and not appropriate for the print output. And so literally what I do whenever I make a change to the - I fix a typo, is that I have to go and open up five tabs with each of these settings pages, change them for what I need on the print, and then just queue up the change to change it back for what I need for PDF.

And then, so I have these five tabs open. I export my print, and then I go through and I just click the "submit" button to reset all the settings back or whatever. So it would be nice if there was a way to have just like every setting underneath a profile. And instead of having every setting have a different tweak or whatever, I just - it would be nice if there was literally like a profile, a dropdown, where I said, "This is my PDF, and I'm going to do all my settings. This is my print, and I'm going to do all my settings." And then I literally just was changing a dropdown. That would be nice. I know it's probably really hard, but that would be nice.

Len: Thank you for sharing that. That - it just finally clicked with me what probably the requirement is here. Which is - so we have a Book Theme page, where you can set a bunch of global settings for your book. And at least as a first step, if we were to try to address this issue, there should be an ebook and there should be a print output book theme for each book. And so, if you click the button to like preview or publish, that would be for the ebook, and it would use the current book theme global settings. But if you went to our Print-Ready PDF output feature and pressed, "Create Print-Ready PDF output," it would look at the alternative settings for the book.

Kyle: Yeah.

Len: Okay, thanks very much for that. That's really great. It'll really help us when we - if and when we get around to doing that. Because we definitely, like - you mentioned you're using another service to try and get your book out on other platforms. And like, there's this whole thing in the self-publishing world, that I won't go into, about - should you put your eggs all in one basket, or should you put them in many? There are arguments on all sides. Typically on Leanpub, although you're almost certainly going to get a higher return on each sale from a sale on Leanpub than you will from another book selling platform, Amazon gets way more eyeballs than we do. And so we encourage -

Kyle: It's actually advertising more than anything. I actually think - although there's no way for me to prove it and track it, but my Leanpub sales go up whenever I'm on other platforms. People will find it, and then they'll tweet me. And they're like, "Who can I buy from where you, the author, get the most money?" I'm like, "Well obviously Leanpub, please go buy it from Leanpub."

So for me, the distribution is an eyeballs game. It's not about, "Oh, I want to undercut sales or whatever." I have price parity across all of them. Leanpub has this great thing where they've got the flexible pricing thing. So people - they can choose to pay more, depending on how you have it set up or whatever.

So I mean, those are all great. But I don't put them on Amazon and others to cannibalize my sales. I actually put them on those other platforms to drive more Leanpub sales.

Len: Thank you for sharing that. We definitely recommend - have your book as visible as possible in as many places as possible, that is the best practice.

Just very briefly, a little while ago, I interviewed a woman named Ricci Wolman, who runs a marketing company. And her mom had self-published a book, or was going to self-publish a book. And so she , having a marketing background, was like, "Huh, I wonder how this book marketing thing works?"

And so what she started doing was, she made an email list you could sign up for, for like "Today's bestsellers in romance novels on Amazon." And after a while, she started getting emails from authors saying, "Hey, my book sales went up on Amazon, and I linked it back to your newsletter."

Kyle: Wow.

Len: And so now she's got this thriving business of these newsletters, where people actually pay to have their books on the newsletters.

And so that's just an example of how like - having your book out there, or your course, if you've got an online course on Leanpub - having it out there in as many places as you can, on as many lists as you can - things like that, is really key to getting visibility and getting eyeballs.

And yeah, it's definitely the case that like - maybe if you're worried, "Oh but I'll get a lower return from each sale on Amazon than I will on Leanpub." Well, people do actually discover books on Amazon and then search for them. They might even be searching for a deal, a discount or something like that. And then - although you can't - as I understand it - Amazon will find out if you try and sell your book for less elsewhere, and will stop you from doing that. But people will sometimes find your book on Leanpub after finding it on Amazon, and pay for it there.

On that note actually - just before I let you go, if you're willing to talk about it - you had a bit of a negative experience with getting your latest book up on Amazon, as I understand it?

Kyle: Yeah.

Len: If you're willing to talk about it for a few minutes - I've heard directly and indirectly about people getting kind of hammered by Amazon. One guy was my brother's partner's brother-in-law, or something like that, was making 100 grand a year selling like werewolf erotica on Amazon. And then one day poof, they kicked him off." And that was it, he couldn't get back on, unless he invented an entirely new pen name and account, and bank accounts and stuff like that. So people can get in trouble.

And so if you could - if you would be willing to share your story, that might be really helpful.

Kyle: Yeah. So thankfully mine is not as bad as some of those people. And Amazon's certainly not the only platform where this has happened. There's a lot of people on YouTube, for example, that make their entire living off of the ads on their platform. And they wake up one day and their platform's been taken down, and their account's been shut down. And they have no reason and no recourse.

I have lamented this on many occasions in my Twitter feed, that it feels like at some of these companies, there aren't any humans working anymore - that it's just all algorithms. I sort of was joking about it, but it would not actually be all that surprising to find out one day that Amazon doesn't actually employ that many people, and that actually most of the company has just become algorithms at this point. Amazon does a lot of great things, but that doesn't absolve them of the negatives and the downsides.

So in my particular scenario, where I'm caught in a problem from an algorithmic perspective - it has to do with the fact that I published the first edition of these books through O'Reilly, and they were sold on Amazon. So Amazon knows about, "You Don't Know JS" as a book series. And you have to think about - what they know is like a string of characters. They know the string, "You Don't Know JS." And they know the string, "O'Reilly Media." They don't know anything about the relationship. They don't understand, apparently, the concept of writing a new series of books or whatever.

So essentially, the problem that I have, is that even though I legally have the right to write these books, I have a contract from O'Reilly that lets me write the second edition books and all of that - that's not something that Amazon is set up to automatically handle. So every time I - each of the two times that I've tried to put out this book in the new series, their content review has immediately flagged it as "You don't have the rights to do this. Send us your documentation to prove that you do." So I immediately will send the contract and an explanation, or whatever.

The first time that that happened, I caused a big stink, because I was really upset about it. It took about three days, and they approved it, and then the book went up. I was annoyed that there was a three-day lag, but whatever. The second one - I didn't cause a stink when I got it, because I'd worn myself out - and also the Coronavirus was really a lot more on my mind at the time.

So I put it up there, the second, the Scope & Closures book, and then got the notice, and sent them the contract. And I said - two or three days lag, and I'm sure they'll approve it. Well, two or three days became four or five days, became seven or eight days. I'm hearing the stories of Amazon sending all their people home or whatever. So I eventually - after one week, I reached out - and I said, "Hey, what's going on? Why has this been a whole week that my book isn't coming out?" And I got a form letter response from their algorithms and stuff of, "Such and such is out of the office and we'll get back to you," or whatever.

So basically, a whole 'nother week went by of every day me emailing them saying, "Why isn't it out? Why isn't it out? And I kept getting the response back of, "Well, there's a technical error and we have no ETA on fixing it." I don't know what that means, I don't know how there's a technical error blocking the book. I think basically they're overwhelmed and have no people working and the algorithms have no way to handle things as complex as - I guess I'm the only author in the world that's ever self-published a second edition after traditional publishing a first, or whatever. Or other people have done it, but haven't done it through Amazon. I don't know? But anyway - so literally, about an hour before I got on this call to record this podcast, I finally got an email saying they've decided to go ahead and publish that second book.

So this is two weeks to the day from when I submitted it to them, that I've had to go through this nonsense of - this arbitrary content review. It's all associated with the algorithms. And if you don't match up to the algorithm, then there's no people involved.

Like speaking of Leanpub, when I have a problem I email Leanpub, and Len emails me right back. I have people that I can talk to. When you deal with an entity like Amazon, and especially their content review - I'm convinced there aren't people in this department. But when I try to contact Amazon customer service, they say, "Oh that department doesn't talk to customers." There's no way for you to talk to them. There's no manager. There's no way to escalate to somebody and have - "No, sorry. You just have to wait." And we're - society has moved in that direction, because it's cheaper or whatever, but it's tough on independent people like me. Because that's two weeks of lost sales that I didn't get. So it's frustrating.

Len: Thank you for sharing that. And congratulations on - I'm glad to hear that although it did take two weeks, that the book is finally up. And I hope people go and buy a copy and learn from it.

Kyle: I hope they buy it from Leanpub though.

Len: Well, I mean - so do we. But I'm glad to hear it got up and you got through that.

Well, thank you very much Kyle, for taking the time out of your day to do this and for being so forthcoming about your own situation and prospects for your own future. And I really do wish you the best for your 40th birthday tomorrow, and hope you and your family manage to have a great time.

Kyle: Thanks Len. Everybody stay home, stay healthy. You too, and it's a thrill and an honor to be part of it. Thanks for creating what you've done. You've given me the opportunity to get my voice out there - not only with this podcast, but just with Leanpub in general. I owe a big chunk of my career to that opportunity. So thank you very much for that, I hope you keep doing it.

Len: Thanks.

And as always, thanks to you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.