An interview with Nate Dickson
00:00
00:00
  • August 15th, 2018

Nate Dickson, Author of Painless Git: A Sane Person's Guide to Distributed Development

00:00
00:00
44 MIN
In this Episode

Nate Dickson is the author of the Leanpub book Painless Git: A Sane Person's Guide to Distributed Development. In this interview, Leanpub co-founder Len Epp talks with Nate about his background, a little about politics and religion, working on Mormon websites and the sophisticated online outreach of the Church of Jesus Christ of Latter-Day Saints, what it's like doing an MBA as a writer and tech professional, finishing Breath of the Wild, his books, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on August 3, 2018.

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.

Transcript

Painless Git: A Sane Person's Guide to Distributed Development by Nate Dickson

Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Frontmatter Podcast, I'll be interviewing Nate Dickson.

Nate is a writer, programmer and blogger based in Salt Lake City. He's also the author of three Leanpub books, Painless Vim, Painless Tmux, and his latest book, Painless Git: A Sane Person's Guide to Distributed Development.

You can check out Nate's writing on his website at natedickson.com, and you can follow him on Twitter @PogiNate.

In this interview, we're going to talk about Nate's background and careers, professional interests, his books and writing - and at the end, we'll talk a little bit about his experience self-publishing.

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

Nate: Thank you, it's good 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 technology and programming, and in writing as well?

Nate: I was born in Utah. I was born in Provo. I spent my life everywhere. Most of my childhood, I grew up in Idaho. Since then I've lived in Kentucky, Texas, Alaska, the Philippines - just kind of all over the world, before settling back down here in Salt Lake City.

I started writing forever ago. I remember in fifth grade I had a teacher who wrote me a little note and was like, "There are good writers, but you are a great writer." I was a fifth grader, I doubt I was a great writer. But it kind of got me moving on that path. I was like, "Oh cool, that's something I can do." So I kept doing that. I thought that was going to be where I'd end up professionally, writing and stuff.

In fact when I started my undergrad degree, I started as a linguistics major. And when I met my wife, she said, "I know four unemployed linguists. I don't want to be married to a fifth." That's kind of what empowered me to look for something that might be more employable.

About that time, I was taking a class that was called, "Computers and the Humanities", and I found the computer side really, really compelling.

I'd always dabbled with computers. My father worked for Radio Shack for years. But this was the first time I'd really looked into programming to any serious extent. And it was fascinating.

So I was like, "Okay, I can do that. I'm going to switch to IT." That was about the time we moved to Alaska, so I was doing online computer classes, and from there it just grew.

I wanted to get back into writing at some point. I'd never really stopped. I don't know if I can just stop writing, it's kind of built in.

I got interested in tech writing about the time I started writing Painless Vim. So, like I said, in the introduction to that book - when I was learning Vim, I was kind of frustrated by the state of Vim education and training. A lot of the most popular books start with, "Here's 30 years of history about the Vim editor. And before that, it was the Vi editor. Before that it was a line editor."

I'm like, "I don't care, I just want to know how to save a file and then get out of it without having to shut down my computer." So I looked around a lot and I bugged a guy I worked with a whole lot, to get him to help me out, because he was pretty good with Vim. As I was doing this, I thought, "It'd be really good if somebody wrote something that focused on the things you want to know when you're starting out. So that's what I wrote. From there, I've just kind of kept going with these.

Len: Thanks a lot for that, that was a really great story.

You mentioned that you moved around, you've moved around a lot in your life. Is there a reason for that?

Nate: My dad is a vagabond, is most of the reason. He just loves traveling. It's always been in his blood. Most of the places we lived, were just because my dad was in retail. People always ask, "Are you military?" "No, retail." My wife and I lived in Alaska after we got married, because we found that that was a good place to make a lot of money quickly. If you can handle Alaska, there's a lot of opportunity up there.

Len: And what is it that you have to handle about Alaska?

Nate: A common excuse for being late to work in Anchorage is, "Hey, I can't come in right now, there's a moose standing in my driveway." You have to be able to deal with the wildlife and the weather. You get used to snow banks that are taller than your house.

It's interesting to me what you say about the snow. I grew up in the province of Saskatchewan in Canada, where a common excuse for being late was, "My car wouldn't start because it was frozen." I'm a little bit familiar with that. Not so many moose in souther Saskatchewan, but a lot of snow in winter.

You mentioned that you were taking a course called "Computers and the Humanities." I'm a little curious about that. I studied English literature and philosophy in university, and I remember - this will date me, but in the mid-'90's when I was doing my undergraduate degree, I was taking some courses that were starting to relate technology to the humanities. I was wondering if you could talk a little bit about what your course was trying to get across by connecting computers and the humanities?

Nate: I was really lucky on that front, because I was there the first semester that my university was doing that. I took three or four of the classes, and they were a mix between beginning programming and - actually that was most of it. They were mostly programming classes for people who were non-technical.

And so we had one that was Visual Basic. We had one in a language called "Revolution." That was basically someone trying to remake HyperCard. And we had one that was Excel. It was doing Visual Basic for applications in Excel. They were all very gentle introductions to what you can do with programming. But it was enough to make me say, "There's something I really like here."

Len: Speaking of Excel, I read on your blog that you're doing an MBA right now, and you're writing posts under the title A Novelist in Business School. I wanted to ask you a little bit about that. What led you to decide to do an MBA?

Nate: I've been a programmer now professionally for about 10 years and a bit. It's enjoyable. It's something I like doing. A big part of what I like about my job is the time that I get to spend training other developers. This is kind of the same thing that makes me want to write these "Painless" books - I like the part where I get to help other people in their careers.

On one of my previous teams, I was the designated trainer, because I was the one who was like, "Hey, I want to do that." So I spent a couple of days every sprint - like every three weeks I would prepare some trainings, then I'd get to present them. I realise that was the part I liked the most. I enjoy development, but what I really want to do is lead people and help people with their careers.

It's where I started looking at an MBA. It helps because right now I work for the University of Utah. We get some help with tuition for being an employee, and that makes life really nice. the MBA program's right here on campus, and that's really nice. So I just figured it'll be a good way to go from a career in general, and hopefully I can stay connected to technology but start participating more in the human side of the equation.

Len: Are there any other programmers in your MBA course for you to pal around with?

Nate: There are a couple, yeah. There's a lot of accountants. It's interesting how similar our fields actually are, and where they overlap in the MBA stuff. Like you look at what accountants are doing in spreadsheets, and you're like, "This is just code, but laid out strangely. If you just took the logic that you're putting into these Excels in a spreadsheet - I could drop this into a Python file, and it would do the same thing." It's just a different way of writing it.

Len: It's interesting you mention that. After I finished my doctorate in English Literature, I became an investment banker and started doing a lot of financial modeling. It wasn't until I actually joined up with Leanpub, which is largely a tech company, that I realized that what I'd been doing was actually kind of programming.

Nate: Yeah it really is. The skills definitely can transfer if you open your mind to say, "I'm not going to be afraid of the blank programming screen. I'm just going to dive in." The same logic applies.

Len: Similarly, one typo, and the whole thing breaks.

Nate: Very much that, yes.

Len: My next question might be a little bit out of left field, but one of the fun things about this podcast is that I get to talk to people from all over the world and ask them about issues, people may heard about where they're from, but don't normally get to hear a well-informed local talk about. So, I've spoken to people in Spain about separatist movements and things like that.

You mentioned on your website you're LDS, or a member of the Church of Jesus Christ of Latter-day Saints, more popularly known as the Mormon church. You also mentioned that you're not a Republican, which makes you an oddball.

I wouldn't be asking you this question if you didn't also say in the same place, that you love to talk to people about everything. So I wanted to ask you why Mormons are typically Republicans?

Nate: I think where that comes from, I think the intersection there is in conservative family values more than anything. One of the things that the LDS church definitely emphasizes is the family is the central unit of a society. For a lot of the history of the American political system, the Republican Party has been more pro-family.

Now again, I'm not Republican, I don't really agree with most of the Republican platform. I'm also not a Democrat. I think my political party right now would probably be classified as angry, more than anything else. But yeah, I think that's where that comes from, is the emphasis on keeping the family being central to society, and just traditional family values.

Growing up, even in my church life - one of my scout leaders actually, when I was growing up, called himself a loud and proud Democrat, and kept trying to explain to us that there's nothing sacred about the Republican Party. There's nothing that we should say is actually part of our faith.

That's one of the things that Mormons are known for, and that musicals get made about - is we send our, our missionaries out around the world. I think that serves a couple of purposes. One is to spread the message, but the other one is - you get these white boys from Utah and Idaho, and you expose them to a completely different part of the world, and a completely different way of thinking, and a completely different way of interacting with people. You start to realize that your little hometown values - not all of them spread, or, not all of them fit around the world. So you have to open your mind and start to see how other people think as well.

Len: Actually, that leads me to my next question I wanted to ask you. Where did you go on your mission?

Nate: That was the two years I spent in the Philippines. That was an amazing experience. I loved the Philippines. It's been 20 years now, it's dating myself, but I got to watch them go through a lot of things, and I'm just pulling for a country on the other side of the world. I just don't know what I can do to help, but I want to.

Len: I saw on your LinkedIn profile that you speak Tagalog, so I was guessing it was the Philippines that you'd been to.

I'm a little bit curious - not to go on about this foreverm but how was your place for your mission selected?

Nate: The way that works is, you submit all of your paperwork, your application to go on a mission. It all goes to church headquarters, and there's one day a week where the leadership of the church - it's usually the President of the church and his councilors - they've got a room set up with a projector, and it will put up an image of a missionary and some information about them.

Then they decide - our faith is that they decide based on revelation, that this is where this person should go. So they put that into the computer and it sends it on through the system.

I actually worked for the LDS church for a couple of years. I was never directly involved in that system, but I knew some people who were. It's really interesting just how quickly that moves, and it seems to work.

Len: What was the work that you did for church? I've read a little bit about it on your profile and your website, I believe. If you could talk a little bit about that, I think people would be interested to hear what kind of programming one does for a religious organization.

Nate: The LDS Church has - we say that we've got four main missions. Our missions are to perfect the saints, because we're absolutely not perfect; proclaim the gospel, redeem the dead - which is basically doing work for people who weren't able to partake of the Gospel of this life - help the... I've forgot the phrasing now, but it's basically help the impoverished. It's our welfare organization.

So each of those four missions has a website, and a lot of work goes into it. So like - perfecting the Saints, that's basically everything that members of the church would want on the internet. So that's the lds.org website. That's things like easy access to the scriptures and easy access to lessons and all that stuff.

What I worked on a lot of my time at the church was mormon.org, which is our public, not-a-member-of-the-church-facing website. It's more of our missionary website. That's answers to questions that people have about our faith, and things people want to know.

A lot of people know about FamilySearch, which is our genealogy-facing websitem which is more taking care of getting the whole family, all of humanity put together.

Then we've also got a couple of websites that are focused around our welfare efforts.

So like I say, most of my time was spent in the missionary part of the organization. I did a lot of things with some of our online teaching programs, like the way that people can chat with missionaries online, the way they can request people to visit, or request a copy of the Bible or the Book of Mormon, or whatever they like. That was all stuff that I was working on while I was there.

Len: Has the church embraced social media? Pardon me for being so ignorant, but is the church a social media presence as well?

Nate: Yeah, definitely. When I was working for mormon.org, I was there for, I think, three Christmases, and they always do a big Christmas campaign, where there'll be a big Facebook campaign. Things like, "Light the World." I think last year one of the things they did, is they set up - that was after I - not working there anymore - but what I saw was, they set up like vending machines where you can buy say a chicken for somebody in a third world country, some one that could use some help. So all it is is like, you put in some money and it drops a card. Then we say, "Okay, we're going to donate that money to a relief effort in whatever country you assigned."

They'll generally do a big Instagram campaign around the same time. Usually another one around Easter. A lot of Facebook. When I was working there, we were just starting to look at Facebook and Twitter integration, and seeing what we could do with that.

But yeah, they definitely are interested in just any way that people can bump into the message - without having to have someone come and knock on your door, is a good thing.

Len: I promise that we're going to move on to talk about your books and your writing very soon. But before that, I have a very selfish question to ask you.

You wrote a post about finishing Breath of the Wild, the video game. You had a somewhat similar experience to mine, I think around the same time in June, where you kind of wandered in to fight the boss accidentally, then regretted having finished the game.

Nate: Yeah.

Len: I wanted to ask you - I actually hadn't played video games for years, and then found myself, like I couldn't wait until the time in the evening when I could have a glass of wine and go to the Hyrule kingdom. I just wanted to ask, because it was this very specific kind of connection, what was it about that game that you liked so much?

Nate: To me, Breath of the Wild was such an art piece. It was so integrated between the very minimalist sound design and the very plain air, very clean art design that was sparse, and yet it was not unpopulated. It was very engaging. It was very easy to get drawn into a world where you could feel connected to it. That's kind of the feeling I got. I liked going to Hateno Village, and I liked running around.

I loved just jumping off a cliff and popping open my para-sail and just going anywhere. It's kind of the reason I was never very good with horses in that game, because I'd be riding a horse for a while, and then I'd see a cliff that looked interesting, and I'd just go, "Bye horse." I'd go jump off a cliff and go somewhere else.

I think it's just so well integrated. Every part of it fits so nicely with everything else. It felt so organic.

I played a lot of that on the train to and from work. We've got a local - it's called, "TRAX", our local light rail here in Salt Lake. That was the one thing that kind of screwed me up, is - in some of the shrines they have motion controls. I can just tell you that motion control things on a moving train don't work so well. I had a couple of shrines where I'm trying get this ball through a maze, and because of the way the train's moving, the maze is now upside down. "Okay, I'll do that later."

Len: It's funny you say that. I've actually never played it on the Switch device itself. I've only ever played it by docking the machine and on a big-screen TV. When I started playing it, I was getting used to the way on the Switch you can detach the little controllers and hold one in each of your hands.

I loved that. But it was really, really hard to use things like Magnesis. Because everything was jumping around, and I thought, "Well, that does make it more challenging, but that's a pretty arbitrary way to make the game harder." Then I realized, it thought that because the controls weren't connected to the device, it thought I was like twisting it, like the device was stretching up and down and stuff like that.

So, when I finally realized what was going on, I was like, "Oh, now I could actually use these things and shoot arrows."

In any case, thanks for that great description about what's so compelling about that game. I think I enjoyed a lot of those same aspects myself.

I guess seguing from there, one thing you write about, with respect to your writing, is that you enjoy interactive fiction.

Nate: Yes.

Len: Which is a lot like games. I was wondering if you could talk a little bit about what interactive fiction is, and why you like it?

Nate: Interactive fiction - a lot of people call it text adventures. That's the name it has from clear back in the 80's, when these games first started coming out. If people know nothing about interactive fiction, if they know one word, the word they'll know is Zork. Which was an infocom game from clear back in the 80's.

It's your typical - you go into a dungeon, get the treasure, get back out. But it didn't end there. That's the part that interests me, is that people are still making new and very innovative interactive fiction these days. They're doing a lot of things with just words. There's an amazing amount you can do. There's an amazing amount that you can portray. I am not a good artist, but I can spend time writing, and start to get an image across to somebody through words. So if I want to make a game - and occasionally I might - this is a way I can do it.

The language that I found when I was first looking into interactive fiction, is called Inform. They're currently on version 7, and as you might expect from an interactive fiction language, it's not moving all that quickly. But version 7 is really fascinating to me.

One of the reasons I like it, and one of the things that first got me interested in it, is the fact that in Inform, every statement you make is also a valid English sentence. So it's a programming language that is a subset of the English language. That makes it a very interesting challenge to try and mix my linguistic brain and my programming brain and do the same thing, like try and mix them into the same place.

I've played around a lot with Inform. It's cool, because you can just write things like, I don't know? "Office is a room. In the office there is a desk. On the desk there is a computer. The computer has a keyboard." I'm just describing a room, and you understand exactly what I mean, but so does Inform. If I ran that through the parser, then it would give me a pretty little map that says, "Okay, I've got one room called 'Office', that room has a thing called 'the desk.' Since you told me something's on that desk, I can say 'a desk can support other things.'" It builds its internal picture of the world, based off of just English sentences.

Just to challenge myself once with Inform, I thought I would try and make a very small, simplified version of the game Portal). In Portal, you've got a gun that you can shoot a portal in one wall, and a portal in a different wall. Then you can move between those two portals. So you can have one clear across a chasm, and one right behind you - and just walk through those, and you've crossed the chasm without getting over it. I was like, "Can I do this in text? Can I do this without images?" I spent, oh, probably 40 hours working on this pointless little tech demo. Yes, you can - you can totally do it with just text.

That sounds really fascinating trying to do something like Portal in text. What a great project.

Moving onto your books, one of the reasons I was looking forward to interviewing you, is that one of the themes of this podcast, since so many Leanpub authors are programmers, is that people can use these interviews to learn about the way everything in our world is being built now, because everything is being built with software. So, because of the nature of your books, I get to ask you to explain the tools that programmers are using.

I was wondering - you talked a little bit about it before, but could you explain a little bit about what Vim is, and how programmers use it in their work?

Nate: Vim is a text editor which, for a lot of new programmers, you would basically define as a minimalist or a stripped-down integrated development environment. So, it's just you and text. What makes Vim both difficult to learn and very powerful, is that for most of the time when you're in Vim, if you press a button on the keyboard, it doesn't put that letter on the screen. That button is doing something else.

For example, the famous, or the most popular four keys for a Vim programmer are H, J, K, and L. Because those move you up, left, right and down respectively. So when you're working in Vim, what it's all about is making you faster. But to do that, you've got to learn a whole different way to work. So like if I want to go from line to line, I'll press J or K to move up and down to the line I want to be on. Then I can go into what Vim calls "edit mode," which is when you press a key on the keyboard, it actually puts that letter on the screen.

For a lot of people, they're like, "Why would you mess with this? Why would you waste your time doing that?" The answer is that the people who've been working on Vim have spent decades now being professional programmers and knowing what sort of things you want to do really quickly as a programmer. In Vim, you can go to the beginning of a line, press two keys, highlight the next three lines, and then edit the beginning or the end of every line all at the same time. If you know the magic keys to press, this becomes really fast and easy.

It's gotten to the point where, if I'm working in an editor that doesn't have Vim style controls, I start to get really lost. I have to go and try and find the arrow keys on the keyboard again, and remember how to use those. I will type random strings into the middle of my text because I think it's doing something else, but it's just typing - and it kind of bugs me. It's like, "Well, D is supposed to delete things. It's not supposed to put a string of D's on the screen,"

Again, that's why I wrote Painless Vim. I kept hearing people tell me, "Once you learn Vim, you'll never want to go back to anything else, because this really is the fastest and easiest way to get around a long text document. I was like, everyone can't be crazy. These people can't all be wrong. So I'm going to try and figure out why they're right.

I spent probably eight months just getting deeper and deeper into it. I was working a lot with Sublime Text, which has a really good Vim emulation mode, as well as IntelliJ, which has an even better, in my opinion, Vim emulation mode.

It was kind of nice, because I could do Vim things for a while, until like my brain was hurting and I just couldn't handle doing things the weird way anymore. Then I would turn off Vim emulation, and I could just work normally for a while.

I got to the point where I started to see those speed benefits and those performances gains from using Vim. It's now to the point where, like I said, I don't ever want to turn off the Vim emulation. I always want to be working that way. Because it's must faster now.

Len: Thanks for that really great explanation. I'd learnt a little bit about it from researching for this interview, but now I understand a lot better what it is, and precisely what it's useful for.

I was wondering if you could also talk a little bit about what Tmux is?

Nate: So Tmux is - the name comes from a terminal multiplexer, which is not much easier to understand. The idea is that you've got the command line, or the terminal on your computer. Most programmers, they have to do some things here and there on the terminal. Which is just, you type in something and hit "Enter," and the computer does something.

What Tmux does, is it takes one terminal window, and splits it up into multiple windows. So you can have Vim running on the main part of your screen, and over on the side you can have a process running that is just watching your files. Then every time you hit "Save," or Vim autosaves, it checks all the files and tells you, "Hey, you've got an error on line X of this file." Or, "Hey, this is not good CSS." In a third window, you can have a real easy way to get into say, Git, and check your files in - or make sure that you're up to date.

It basically takes the command line, and turns it into a full IDE. But there's a little more to it. It's kind of cooler than that.

Let's say you're working on a server. So, your server is often in a data center somewhere. It's nowhere close to you. Well, if you have Tmux running on that server, you can connect to it and split up your windows remotely. So you've got a command line that you're working directly on that server, because all you're sending back and forth is just text - it's really, really responsive.

If you were trying to use a full GUI on a distant computer, you get some lag and you get some tearing, it just is kind of unpleasant. But if you're doing it via the terminal, it stays really snappy and really responsive.

The other cool thing is - lets say I'm working on my server, I'm updating the files on production or whatever - and then I'm done for the day. I can turn off my connection to the server, but my Tmux session on the server stays active. So the next time I connect to that server, everything's where I left it. Everything's ready to go. I don't have to go and find my files again. They're all already open, and ready for me to start work immediately.

Len: Your latest book that you've just started is called Painless Git. For those who are unaware of what it is, or maybe unaware of its history - I was wondering if you could talk a little bit about Git?

Nate: Yes. Git is a version control system, which means it's a way to make sure that every time you make an edit to your code, you can save that and keep those. So that if you're, say, writing code at three o'clock in the morning, and you save it and commit, and then you go to bed, the next morning you get up, and you're like "Wow, this is terrible," you haven't lost the good version that came before the three o'clock in the morning code. You can just go back to that.

It also means that you can't lose your code as easily. One of the benefits of version control is that you can push it to a server somewhere offsite, and have everything saved and ready to go. So that if your computer goes down, once you get your computer set back up - that code is still out there, and you haven't lost any work.

The nice thing about Git is that it works very well for teams. I haven't quite gotten into that in my book yet. That's one of the chapters I'm working on. But Git - instead of having like one central server that is the source of all truth for the entire team, it treats every machine that has a copy of that code as the source of truth. So if there was a catastrophe - if Bitbucket or GitHub went down, you could rebuild everything from any individual developer's machine. Nothing would be lost, you would be back up and running as soon as everybody connected to that one person's machine.

There's a lot of advantages to using Git. I think it's fairly straightforward, most people get it. But what I've seen is that a lot of people - and some of the 80/20 rule, where there's like 20% of the functionality is what you'll use 80% of the time - it almost feels like it's a 10/90 rule, where people use about 10% of what Git can do 90% of the time. When they get to a certain point, they kind of get stuck. Then they're like, "Well, I don't know what to do here, so I'm just going to delete everything and start over." So I'm like, "Well, we could probably do better than that."

Len: I was going to ask you. I know that you've done quite a bit of work training teams to use Git. It reminded me of an interview I did a while ago with a Computer Science professor, who was saying that now that more and more people are getting into programming, because it's just becoming more and more a part of our lives - teaching people version control, and the importance of version control, was kind of the modern day equivalent of teaching doctors to wash their hands. Because for a long time, we just didn't know about germs.

I wanted to ask you, what are the biggest problems that you've encountered transitioning teams over to Git?

Nate: There's a couple of different ones. One comes from the people who are used to Subversion. Subversion is an older version control system, where instead of having every machine be like a full repository, like Git - you have one central repository. Everybody's machine just saves changes to that.

One of the problems that Subversion had, and this part of why the Linux Foundation started developing Git - is that, it's real easy to get to a place where two people have committed code that's in the same file. Now it's a mess, and you've got to try and figure that out. It's really painful to fix that conflict. Git has a much easier version, a much easier conflict resolution system.

It's newer, it's a little smarter. It can figure out most conflicts on its own. But when it can't, it makes it fairly easy for the developers to fix those conflicts. The upshot of all this is that people who are really used to Subversion, they tend to never branch. They tend to do all of their development just in the main trunk branch. In Git,that's an anti-pattern. That's the equivalent of coming from the morgue to the maternity ward without washing your hands first. Which - that's how they learned that they should wash their hands. It's that sort of thing. It's just the opposite of what you should be doing.

That was the first problem you usually have to overcome when you're teaching a new team, is you have to take all the old seasoned hands and say, "You know what? We're doing things different now. I promise you - as you get into this, it's actually going to be easier." You have to trust me a little bit first before, before we start getting those benefits.

The other problem is the completely inexperienced people, who - they've kind of learned like, "Okay, so what I do is I stage all these files, I commit, and then I push." Then if it goes wrong, they start to freak out and just start pushing all the buttons.

I had a couple of developers like this on one of the first teams I was training on. I would come over, and I would see the lists of commits, like, "Okay, everything's fine, everything's fine."

And then they get to the point where they freaked out. Suddenly you've got like 10 commits in the space of about 10 minutes. It's like, "What were you doing?" So a big part of what I've been trying to train, especially for new developers, is to calm down and take a breath and step back. Because Git will definitely give you enough rope to hang yourself. The good thing is, it's very rare that you will ever get things into a state that's so bad that you can't recover from it.

But you can get yourself into a state where recovery is going to take a while. If you calm down and think through what you're doing before you do it, you'll save yourself a lot of headache as you fix things.

Len: Thanks for that great explanation. It's useful for me, partly because I don't do a lot of programming. But when I started learning programming, it was all Git. I didn't know anything else.

One of the things that took me a while to wrap my head around, and then I finally really liked about it, was the idea of branching. When I can just create a branch and go off on my own, then I feel like kind of safe. Like I don't have to be afraid of screwing up the master code. That was one of the things that I found - it took me a while to work my head around it, but I eventually found that was one of the best parts of it.

Nate: Yeah, it's something I tell people a lot, is that branches are cheap. They don't take up much space, they don't cause any real problems. You can create as many branches as you want, and branch from a branch - and then delete them whenever you want. The more you branch, the safer you are, and the easier things are going to work down the road.

Len: Moving on from the subject of your books to maybe the process by which you wrote them. Your current book is 5% done. So I know that you do write books in progress. I know that you directly solicit feedback from readers, and I wanted to ask you a little bit about that. What's that experience been like?

Nate: It has been absolutely incredible. I have amazing readers.

When I first put Painless Git up, I sent out a coupon to all of my readers of Painless Vim and Painless Tmux and said, "I'd really love to have your feedback on this one." Almost immediately, someone who'd read Painless Vim wrote to me and said, "Hey, the stuff you did in Painless Vim is the reason I'm still using Vim. Do you want feedback?" I said, "Yes, yes, yes. Very much yes please, yes."

And an hour later, I had an email from him. He was like, "I've read what you've written so far, and I was following through, and it's mostly good - but here's the thing that happened that you might not have noticed." He sent me like a screenshot of what had happened on his system. He's like, "You might want to talk about that." It's like, "You're absolutely right, I should talk about that." So I worked that in.

That's been the case with all of my books. I've always had readers say, "Hey, I like what you're doing, but I noticed this happened." Or, "Hey, sometimes you can't do it the way you said, but here's a way that works better." Or, even, "Hey, there's a typo on this line. You should probably fix that." "Yes, please tell me all of this, all the time. Because it just makes it - it makes my job easier, it makes the book that you're getting from me better. So please, all the feedback you have."

Len: Thanks for that, we really love hearing those kinds of stories at Leanpub.

One thing I noticed about your books is that they have great covers. That's something that I think all self-published authors aspire to. I just wanted to ask you if you have any advice about how to go about making great covers for your books?

Nate: Thank you for saying that, that feels so good.

My philosophy behind my covers - I've kind of just been copying myself since the first one. What I wanted was that feeling of painlessness that I was trying to get across. So to me, that meant the cover should be open and uncluttered and fairly simple. The images I choose - I'm not an artist, like I said, so all of the images I choose, I buy the rights to off of stock image sites. I make sure that I've got the EPUB rights.

For me, I really wanted that theme of, "This isn't going to cause you stress. I'm not going to call you, I'm not going to talk down to you. It's just going to be easy." Part of what I liked about doing the cover design was doing the font design. Again, I bought fonts. I'm not a font designer either, but I like good typography and I like good layout. This is not my main area of expertise, but it's something that I enjoy tinkering with.

There's three fonts on the cover of all of my books, so I could have the byline look different from the subject line, and have that different from the title, but still have them feel unified. Like I said, most of the design work went into Painless Vim. I mentioned when I sent out my, "Hey, I'm doing, Painless Git email - that all kind of came together on a Saturday morning in my pyjamas. Because I was like, "I really think I can do this."

So I spent four or five hours just looking at fonts, and just looking at - what would go well together? Grabbing samples, and screenshotting samples before I bought any fonts, and throwing them into a Photoshop document to see what they looked like together. I think there's a lot of very good cover designs in the world. Mine is one specific style that works for what I'm doing.

But it feels like we're in a time and a place where minimalism goes a long way. Staying fairly simple and fairly clean, I think, is very appealing to people in a world that's often very saturated, and often very busy.

Len: My last question that I always ask in these podcasts is a self-interested one. That question is - if there was any one thing about Leanpub that we could build for you, or one thing we could improve, can you think of anything you would ask us to do?

Nate: One thing that would be good, and, again, this is a very selfish answer - one of my most recent posts on my blog was about how I'm handling the transition - taking my text out of Scrivener, and preparing it for Leanpub. One of the things I did is I had Scrivener number all of the files and folders so that it has an intrinsic order to how that should be put in there. So I wrote a little Python script that creates the Book.txt file out of that directory structure. Now I no longer have to hand-maintain Book.txt.

It'd be great for me if there is a way to just take a list of numbered files and folders and say, "Okay, read the numbers, and that's the order I want the book in." I can see both sides of the argument here.

When I was writing Painless Vim, I would often write most of a chapter before I wanted to include it in the book. But what I've kind of learned is that - I don't need that pride. It's okay for me to put half-finished chapters in the book, because that's how I get a lot of feedback from my readers. They tell me, "You're working on this, here's something you can do that'll make it work better."

So if I could just take that one Book.txt creation step out of the process, it would speed me up a little bit, and it would mean I don't have to write weird hooks into my Git commit workflow to make things work, without me having to do it by hand.

Len: Thanks for that really great and specific feedback. I saw that article, and really, really liked it. Actually, we link to it in our Help Center now. So, "Can I use Shrivener with Leanpub?"- now, every Leanpub author in the future will get a link to your post and learn from it.

Nate: That's awesome.

Len: Thanks very much for taking the time to do this interview, and for being game to answer questions from everything from religion to video games, and for your great explanations of these tools that programmers use in their day-to-day lives. Thanks also for being a Leanpub author.

Nate: Oh thank you. I love Leanpub and I'm glad to talk, and this has been a great experience.

Len: Thanks.

Podcast info & credits
  • Published on August 15th, 2018
  • Interview by Len Epp on August 3rd, 2018
  • Transcribed by Alys McDonough