Aaron Sumner, Author of Everyday Rails Testing with RSpec

Hi, I'm Len Epp from Leanpub, and in this Frontmatter podcast, I'll be interviewing Aaron Sumner.

Based in Astoria, Oregon, Aaron has over two decades of experience as a software developer and is currently a senior software engineer at O'Reilly Media.

You can follow him on Twitter @ruralocity and check out his website at aaronsumner.com, and you can read his blog and sign up for his newsletter at everydayrails.com, as well as follow the Twitter account for the blog @everydayrails.

Aaron is the author of the Leanpub book Everyday Rails Testing with RSpec: A practical approach to test-driven development.

In this interview we're going to talk about Aaron's background and career, professional interests, his book, and at the end we'll talk a little bit about his experience as a self-published author.

So, thank you Aaron for being on the Frontmatter Podcast.

Aaron: Thanks for having me.

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

Aaron: Sure. I grew up in a rural area outside of St. Louis, Missouri, on the Illinois side of the Mississippi River. We got our first computer in the classroom when I was in fourth grade, so that maybe puts a date on me a little bit?

It was one of those Radio Shack computers that you hook up to a TV, and you're off to the races. I started to learn to program on that, and never really - it was just kind of something that I did on the side, for fun to make graphics, or make really terrible games, or something like that.

And then when I was at the University of Kansas for my undergraduate, it was right when the web was taking off as a thing. I remember the main computer center, where the upstairs was - where there were computer labs with Macs and PCs, and people could type up their papers or whatever, because most people didn't have a computer at home yet.

But then downstairs were where all the mainframes were, and the servers and things like that. And all of a sudden, everybody had to have an email account. There was a line outside the door of this building of people, just waiting to get their first university email account.

And so, I was there finishing up school as this was all just taking off, and I wound up going in that direction, instead of - my undergraduate degree is in journalism, and I never really formally did anything with it.

I wound up hooking up with some people who were doing some interesting things in research in education - they had a lot of stuff they wanted to do on the web. So I went to work with them, and just learned on the job - I learned some Perl, and then that led to Java and PHP - and eventually to Ruby. I worked with that group off and on for probably close to 15 years. I left a couple times for short stints elsewhere, but always wound up back with them.

And then in 2013, I was at RailsConf in Portland, and saw a flyer on the job board that O'Reilly Media was looking for a Rails developer. I've always - that was one of those publishers that I always admired. I had the big thick Perl book, that I spent money on instead of beer in college, and so I always held them in high regard, and knew one of the editors there, and asked him, "You think I should apply?" And he said, "Yeah." So I did. The plan was to move out to California for that. For personal reasons at the time, I couldn't do that, so they made a remote position.

I started my first five years there working from Kansas, and then last year I moved out to Oregon. It was seamless from a from a work standpoint.

I work on the back end for O'Reilly's conferences. So like, if you've ever attended a OSCON or the software architecture conference, some of the older conferences like Velocity and Fluent - which was the web conference - if you ever spoke there, or registered to attend or sponsored, you used our software for that.

Len: Thank you for sharing that great story, there's a couple of things in there I'd like to talk about. One of which is something you said pretty quickly about - in the olden days when you got into programming, one of the things you might do is do graphics. I think for a lot of people who aren't dated the way you and I are, that sounds funny.

Just to spell out an example. It reminded me of a very clear image I have of a friend's older brother, who spent hours and hours and hours typing in each - basically each pixel to make a Detroit Red Wings logo appear on the screen. And there was something at the time, very magical about being able to type a command and see something happen right before your eyes. People really would spend hours and hours and hours just like defining the color for like each pixel on a screen, individually.

Aaron: Yeah, I remember that. I designed my own baseball cards for players that I liked as a kid. And they were terrible, super low-res. You had to have a really good imagination to say, "Oh yeah, that's who that is." But I had fun doing it, and it led to bigger and better things.

Len: What led you to study journalism at university?

Aaron: It was just a little bit of happenstance. The journalism program where I attended at the University of Kansas was, and is, highly regarded. My focus was in advertising. The reason I went that route was, it's a good mix of a lot of different things, like writing and design and psychology - and the sales part, I wasn't always great at. But there was some sales aspect to it, so some person-to-person interaction type stuff.

liked that it was combined all these things in a practical way, where I could graduate and go get a job, and not think, "Okay, I've got a liberal arts degree, what now?" This is before you could dovetail that into a software career, or things like that. My friends who had overlap because they were maybe English majors, or literature - wound up going into call centers right out of school, and that didn't sound appealing to me. They've gone on to great things since then, but at the time I was like, "I want to get done with school and get out and start doing something."

Len: And so you're a self-taught programmer?

Aaron: Pretty much, yeah. I mean I won't pretend that I didn't have some great people along the way kind of guiding me along, but I've taken maybe two computer classes and one of them was super, super intro - I could have taught the class. I don't want to sound like I'm bragging about it. But it was like my last semester in school, where I had my capstone project. It's going to be taking all of my time, but I needed some hours to fill in. So I took "Intro to computing," which was like, "This is a mouse, and this is how you use it." And again - dating myself a little bit, where some of those things were new to people. But I did that just because I needed some hours that would not take too many brain cycles from my capstone work.

Len: It's really interesting how things have changed with regard to that, even in the last 10 years. But with things like Khan Academy and MOOCs, and being able to learn online - and things like Stack Overflow, and even Google itself - have changed the way people learn things. And back in those days when you were learning, it was, literally, go to the book store and get a book on something. And if there wasn't a book on that something there, then you maybe checked another bookstore or borrowed a copy from a friend, or something like that.

The resources that were available were incredibly diminished, compared to what we have nowadays.

Aaron: Right. It was books or you'd go into a university program and spend four years learning something, and then still have to buy the books to know how to do it on the web.

Len: That's actually the question I wanted to ask you next, related to that - this comes up pretty frequently on this podcast, but do you regret not having studied Computer Science in university? Do you wish you had done that?

Aaron: There are some things that I wish I had a little bit of a better grounding in at times. Like there are maybe some things around, say - really digging in deep into algorithms, or something like that. I am not one to just sit down and have a deep discussion with a fellow engineer about, "Which algorithm is best?" Or, "What do you think about -" I don't know? But there are things that if I need to learn it, I know enough to know how to find what I need to learn - and learn what I need, and then apply it.

But I've never had to understand things just for purely theoretical reasons, like you would maybe in a university program - and I don't regret that. There are times where knowing this algorithm instead of this one would make something a little bit faster, and that's where it's good to know. But that sort of thing is increasingly getting abstracted away from us, I think - where somebody much smarter than I am has figured that out, and made it so it's easy for me to apply to my problem.

Len: Speaking of your problems, before we move onto the next part of the interview and talk about your writing, I wanted to ask you about your work for O'Reilly. You said you work on the back end of the conference side of things. I think a lot of people listening to this podcast are more or less in the tech world, and they're familiar with O'Reilly - what kind of work do you do on a day-to-day basis? What are some of the problems or projects that you work on, on conference tech?

Aaron: Like I mentioned, the app that handles pretty much everything that you - at least, handles the back end of a lot of it, a lot of the parts of it are moving out to standalone front-end applications. But the back end that processes everything - let's kind of start from the top-ish, where the planners at O'Reilly decide, "Okay, there's going to be this event, OSCON 2020 in Portland," or whatever. "And the call for proposals opens on this date and runs through this date."

The system for that is on our back end, and so then you decide, "Okay, I've got a great idea. I want to talk about open source in self-publishing," or something like that. "And I want to submit that talk." So you go in and submit your proposal, that goes through our system.

Fast forward a little bit to where the proposals are up, and you decide, "I want to attend this event." So, going in and registering and saying, "Which package do I want?" Some of them might have extra tutorials or workshops that you have access to, versus just attending the regular 30, 40-minute sessions. So, going in and registering, it handles that. Lots of reporting on the back end for how many people need vegetarian meals, versus regular meals. Soup to nuts.

Len: You said, "Soup to nuts." And I saw on your profile on LinkedIn that you also work on security initiatives?

Aaron: I do. The engineering department is broken up into teams that work on their own parts of everything that the company does. We all have representatives that meet on a team regularly to discuss both high-level security initiatives, and what we're doing on a team-by-team basis. So, we do a lot in terms of education within the department about best practices. And then just making sure that the software that we ship is as secure as we know how to make it.

Len: Oh right, so this isn't like the security of the conference - like keeping bad guys out or something like that?

Aaron: Oh, no, no. We have professionals who - I think the venues provide that level of security. I fortunately don't have to show up and like look tough.

Len: Moving on to the next part of the interview - so you eventually started writing a blog. How did that come about?

Aaron: The blog predated the book, and was one of those things where I'd learned a lot from the Rails community in particular. I was pretty well ingrained in Ruby at this point, and started thinking about, "What are some ways that I can contribute back to this community?" And I was noticing - I was involved in a small local meetup where I was living at the time, in Kansas. And there were some of us who were doing Ruby development, some people were doing PHP - a lot of people doing Python. Django came out of Lawrence, Kansas, where I have lived a good while. So we would all get together and just kind of talk shop.

There were a couple people in particular who were a little newer to Rails than I was at that point, who would ask questions, and I would answer them. And I realized, "If this is helping one or two people here, maybe it would help a few more people if I put it online?" So that's how the blog came to be.

It was inspired a lot by what Ryan Bates did with RailsCast, which was a weekly video service with - he'd have five-ish to ten-ish minute long videos. He would talk about, "Here's how to use this library to do authentication with your Rails app," or whatever little piece of functionality. And he probably built up like four or five hundred episodes, and then called it quits after a while.

I wanted to do something like that, except more in traditional blog form, where I could write more than talk, and list out code - and just try to find ways to help people who maybe weren't as far along with it as I was at that point.

It started - I don't even know the date anymore. Certainly, maybe nine years ago or so at this point? I built a little following, and I don't write there as much as I used to, but every now and then if there's something that interests me that I think other people might be interested in, I'll write something up there.

Len: One thing that you've written about quite a bit is software testing. And you actually - one of your more recent posts was about how to do test-driven development when test-driven development is hard, and we might be talking a little bit about TDD in a bit. But for those who - imagine you're talking to someone, as I'm sure you sometimes do, who's totally unfamiliar with how the computer goes. What is software testing, how does that work?

Aaron: So the way I like to describe it is - imagine you're building up some software bit by bit. And for the first few features, you can open up what you're working on in your web browser or on a simulation phone, or wherever the end platform is, and you can click around a little bit and you can see, "Okay, I think this is working. What if I type something - a really long string in here? Oop,s that broke. Okay, I can fix that, and I can go back and reload it. And okay, now that works - on to the next a little bit of functionality for my software."

That works pretty well when you're starting out. But over time, that doesn't scale. As you add each thing, not only do you have to test that new thing, but you have to go back and manually test all those other things, to make sure that the new thing didn't break something that you wrote two weeks ago, or two years ago.

So the first win with software testing is, it helps you automate that sort of thing. So you can test all that in seconds, rather than minutes or hours or days.

Len: Maybe you have a concrete example here? The way I was introduced to software testing when I joined Leanpub, was - I'm the sort of resident non-technical person. And so it's like, "All the programmers have done something; Len, go break it." I was always working with things from the user's side. So it's like, if we created a new feature, that when you click a button, X thing is supposed to happen. So I would go click that button and see if X happened, and see if X happened properly. And I got pretty good at this. I've never formally trained or anything like that - but just like, I call it "cowboy testing." In a way, it's a fun challenge - especially if you didn't build the code yourself, so you're not embarrassed if something breaks. But I think what you're talking about is quite a bit different from that.

Aaron: Yeah. So what you're talking about is definitely an important part of it, where it's good to have that second set of eyes looking at everything, before something goes off into the wild and you have real customers paying you money for something - you don't want it to not work for them.

But what the automation starts to give you is more of a rapid feedback loop. So, instead of me writing a little bit of code, or writing a bunch of code and saying, "Okay, Len - here it is for you to test." And you find something that - had I known about it a week ago, would have been a quick fix. But I've piled up so much more stuff on top of that - "Oh, that fix is going to be another two weeks."

Versus automation, where I can really quickly iterate through finding those things that are wrong or that are going to - that look right, but as soon as I say, "Oh, but it also needs to validate that an email address is valid," or whatever. "Oh, I need to go in and fix that." So it really tightens up that loop and helps the person writing the code do a lot more, quickly.

And then as you can get comfortable with the tooling - you write it more efficiently in terms of from your head, to the keys, to the screen - on down to being designed, from an architectural standpoint.

Len: It's really interesting - the role that culture plays in things, and how software gets developed. One of the reasons I like to talk about this in depth in these interviews is that software has eaten the world. Everything you do has software behind it, and so the culture behind how that software was made matters - just as much as the culture behind the company that built the bridge that you drive over every day.

I was interviewing a Computer Science professor once, who talked about how we're sort of still in the - like, people been programming for decades and decades now, but imagine if you were only 70 years into the medical profession, or something like that?

One great image I like to bring up - he talked about how "We're only now at the point where we're learning you need to disinfect before you operate." The image I like to give of that is that - you know how on a normal man's suit there are still buttons on the sleeves, often even if you can't unbutton the sleeves? Those are from when surgeons wanted to be able to unbutton their coat to roll up their sleeve, so they could operate and not get blood on their sleeves. But of course, you shouldn't be operating in the coat that you just came from lunch with. And it took people a long time to learn that, for all kinds of really basic - well, complex reasons, actually.

But, so, test-driven development is the idea that you should be testing as you go and it can actually be really hard to convince someone to do that, like let's say a superior, because it slows down the development, at least in the local sense.

Aaron: It can, especially up front. There's a quote that I like, I think it's from Kent Beck, but I'm not certain now - about the notion of slowing down to go fast. I think it's just like anything - I remember when I was learning how to drive a car, and I was out on a country road, and I was maybe braking seven miles an hour? And I just thought I was zipping down at a million miles an hour, I just felt like everything was going by so fast. And I'm sure the instructor was just rolling his eyes as I was creeping along there, and super timid.

But as you get comfortable with how the wheel feels in your hand, and how much you have to turn it to go this far left, or how hard you have to hit the gas for, to brake or whatever - you get more efficient with it. And it eventually gets to something where you don't even think about it a whole lot.

You're just, "Okay - I need to go to the grocery store, get in my car - and then five minutes later, I'm there." And for better or worse - you may not even remember how you got there.

I think that testing is similar. Where, when you're newer to it - there are two ways you can go about it. One, you can sit there with a blank screen and say, "Okay, I know I need to write a test first, but I don't know what I'm supposed to write." But the same could be said for, "I've got a blank screen with software that's supposed to do something, and I know it's supposed to add up to 45, but I don't know how to write the code to make it add up to 45, or to make this cool animation on a web browser," or whatever.

With testing, over time, as you get to know the tools, you can say, "Okay, I know that it's supposed to be 45. Now let's back up and think about, 'Okay what are my inputs that I'm going to bring in?'" So, whether they're nine times five, or whatever.

And then, how do I say, "Okay - bring this in, make this happen. And then the result of that should be 45" - the order is complete, or the markdown has been rendered into a PDF, or whatever it might be.

The testing and the coding just start to interweave with each other, where you're writing a little bit of test, and a little bit of code, and a little bit of test, a little bit of code, and that's where you're talking about those feedback loops. That gets a lot more rapid, so I can see, "Yes, I'm on the right track. Because the test tells me I'm on the right track." Rather than, "Okay, I wrote a bunch of code." And say, "Okay Len, could you test this for me?" And have to wait hours for you to get back to me, because you’re busy and -

Len: It's interesting you mentioned the feedback loop, because I think - at least one way of developing software that was, in the past, conventional, and probably is now - you would have maybe a non-technical executive sitting on top of a bunch of managers that report to him or her. And those managers might not be technical, but then they've got like buckets of activity that they have categorized. So for example, there's the person who writes the code. And then conventionally, there's actually - it's a separate group of people that test the code. And so a bunch of people might write some code, give that code to the manager - who then goes and gives it to the - I mean, I'm just putting this in a cartoonish way, but like, they gave to go and then give it to a bunch of people, whose only job is to test that code.

This can create an adversarial relationship between the coders and the testers. And it can also create a sense of hierarchy in the organization, where the person who's doing the testing is lower down than the person who's doing the actual coding.

And so in order to combine these processes, you often have to overcome a lot of institutional practices that are baked into the organizational structure itself.

Aaron: Yeah, I think you're right, I've been lucky to work with some really great QA-type testers like that. Where the work that we do upfront as developers, to check our own work as we go - to make sure that their time is going to be better spent. They're not going to be finding silly errors - if they find something, it's because, "Oh wow, we didn't even think about that. It's a weird case, but it's legitimate enough that we need to address that before we take this live." We're not just saying, "Okay, here's some code and oh you've spelled the company's name wrong here."

But yeah, I think it makes every step of the process more efficient over time - and makes sure that the people doing that traditional testing like you described, are really testing things that matter, and not just testing to make sure that we spell their names right.

Len: Speaking of testing - you had a line that I really enjoyed from a blog post, that I think you published in June. The line goes, "Who here remembers when we had to make sure everything still worked with some shitty old version of Internet Explorer?"

I was wondering if you could talk a little bit a little bit about that? What has changed such that you no longer need to test to make sure everything works with some shitty old version of Internet Explorer?

Aaron: Unfortunately, I think we're getting back to that stage, where there's those browser differences. I don't do as much front-end development as I used to. But for a long stretch, libraries like jQuery - which is a JavaScript library that was and really is still very popular across the web to - I write my interactivity with jQuery, and then jQuery does the work to make sure that it compiles down in such a way that Internet Explorer can work with it properly, and Google Chrome and Firefox and - not just the current Firefox, but maybe a Firefox a few years old.

The good news is some of those really, really old versions of Internet Explorer - they are so far in the minority now, that you probably don't have to worry about them, but there was a time where they were just a thing. So I know that a lot of people who really focus on front-end work and libraries like jQuery, and now React and Vue.js - and there's a new JavaScript library every week. When you use them correctly, you have to worry about that less, that it's going to work differently in this browser, than this browser.

The nice thing with testing - to bring it back to the automated testing - though, is - a lot of that is automatable now. So I can say, "Okay, run through this scenario through Firefox. Okay, now this time run it through IE 11 or Safari," or whatever - and find those issues a lot quicker than you would if you had to have 12 browsers on your computer, and go through each one of those one at a time.

Len: To date ourselves once again - in the olden days, when you got an internet browser, you bought it. And it might have come on a disk, and then you would put that disk into your machine, and then you would install the program - and that was the program you had. They didn't update.

If you wanted an update - you had to go buy a new disk, and come back and put it into your computer, and put that on there. And so what would happen in the - not even just the early days, but when the internet started, when the World Wide Web started becoming very popular and things like commerce started to happen on it, people would be like, "Hey, I tried to make a purchase on your website and it didn't work." And then you'd have to ask them - well we still do this, people who run e-commerce sites - but if someone had an old version of an internet browser, then either they couldn't use your site, or you had to do something to make it so that it was compatible with that browser. But nowadays, when I - I use Chrome mostly, and I see a little arrow when I need to update Chrome. Or when I have the opportunity to update Chrome, and I can just click that and do it. I mean - I'm not a web developer, but I've often - when I read your line about the shitty old version of Internet Explorer, that's what I thought about. And so one of the answers to someone saying, "Something on your site isn't working" - nowadays, we can say, "Well, click the update button and you'll be fine."

It's something that you couldn't do before. So it's like the solution is on the other end now.

Aaron: Yeah, it is definitely a lot easier. It does - now we're kind of, instead of the shitty old version, now it's the shiny new version. Like, "Oh, there's this new feature in Chrome that breaks this one weird thing that we were doing." But ideally the tooling is in place to make that fixable.

Len: I mean, updates bring their own hell with them too, right? For example, it's like, "Oh, I click the update button." Because I associate the word "update" with improvement, and now half my apps don't work.

Aaron: Right.

Len: And this is the sort of like sweaty finger of death, when you go to click the button to update your operating system.

Aaron: Yeah.

Len: "What is going to happen?" Because I know a bunch of settings are going to change on me. I know there are going to be things that won't work. I work on a Mac, and I get these periodic warnings like, "Yeah, your operating system doesn't work with this app anymore." Or, "Won't work optimally." What does that mean? "Click here to learn more," and it's like, "What am I going to learn?" Aaron: "Sorry," yeah, oops.

Len: Moving on to talk about your book. So there you were - you started writing this blog, and it was doing well, and then you decided to make a book out of it. I should say, I think you published the first version on Leanpub in 2012, and this has been one of our more successful books over time. So, it's been a long time that we've been looking forward to talking to you.

I guess the first question I should ask is, why did you decide to publish the book in progress?

Aaron: So, I had started this series on test-driven development, and it was really - it was specifically on how I learned to do it. As we've talked about, I don't have a formal background in a lot of this, and I was learning it as I went. I knew that TDD was seen as valuable within the Rails community in particular, maybe more than it was in other software communities at the time. So I knew, "I need to figure this out." I'd read a lot of books and there wasn't one book, "Right, okay - I've got it now." I just kept reading and building on it, reading and building on it.

And so what I did was, I just made the decision to start simple. So, I'm going to start my testing at the smallest little atoms of code that I can - really test things that are super obvious - that I really probably don't need to test. But just to get familiar with the flow, I'm going to write tests for that, and I'm going to do it against code that I'm pretty sure already works. Because it's been through the slow click, click, click browser testing. It's been in production for a while, so real users are using it. So if this were a bug, I would know it. So then that way, if I'm writing a test and it doesn't work - I can probably blame the test and not say, "Well, there's something wrong with the code."

So I started there, and then as I got comfortable with that one little piece, I would build out to more and more complex chunks of code. Different scenarios, on up to - rather than just saying, "Okay, just test this one little five-line bit of code that's around order processing," or whatever. "I want to test the entire order process.

So, going to the site, selecting the book, adding it to my cart, and saying, 'I want to pay.' Enter my credit card, click the button. Make sure I get the email, make sure that email has a link to download the book." Just as an example there.

So building up that way, rather than just feeling like I have to know everything at once. It really worked for me, and so I started writing about that, and I was - at the time, I thought, "This would be maybe a four, five part blog series, and I'll call it good." But about three posts in, I was getting really good traction - not just the regulars that I knew were coming to check out my site whenever I had new stuff, but it was getting picked up elsewhere, and I was getting a lot of new people.

I had recently heard about Leanpub at that point. Just as a little side conversation - and, "I'm going to try it, and strike while the iron's hot. It's got really good traction right now, and I'm just going to see how hard would be to take these four blog posts I've got right now and turn it into a book."

From a technical standpoint, it turns out Leanpub makes that very easy. And because I was already in Markdown, I just copied the files over, had to tweak a few things, and like a few hours later, I had something there and just said, "Okay it's not done - but if you want to buy it, support the work, I don't know what to charge, so $9." I figured maybe I'd sell a few copies, maybe a hundred? I hate say it, I don't even know how many copies - I think maybe around 6,500 at this point. But it really took off quickly.

There were a few people who were like, "Oh, this isn't done, I want my money back." But by and large, people were like, "Oh, this is great, keep it up. Have you thought about including this?" And sometimes it'd be like, "Yeah, that's a great idea, I'll add that." Because now it was beyond those four blog posts. It was, "How can I make this into something that is worth the money that people are buying?" And so that's how that came to be.

Len: Thanks for sharing that. It's actually really interesting. We're getting into the weeds a little bit, and this typically happens when we're nearing the last part of the interview, where we talk about the practical experience of being a writer, and particularly a self-published author.

You mentioned that you didn't get too many people saying, "Oh, I bought this book and it's unfinished." I just wanted to remark on that, it's really interesting, because you've been around on Leanpub since the early days.

When Leanpub started, the idea of in-progress publishing a non-fiction book was very unfamiliar to people. People were familiar with serial publishing of novels from the 19th century, although that had actually sort of fallen out of public awareness. So I guess even in fiction, at the time it might have been, "What, this book is only three chapters in?"

But we basically don't get anybody saying that anymore. People are familiar with the idea. And of course, we've also learned better how to communicate and things like that - put a progress bar under the book, things that seem obvious. But it's actually very rare that we get someone who doesn't notice that the book is unfinished and is surprised. And then it's even more rare for someone to not notice that it's unfinished - to be surprised, and then be unhappy about it. The idea has just caught on and people get it.

Aaron: Yeah, I totally agree. And what I've found is - as people have kind gotten used to the idea, not only are they just used to the idea of something being 50% done or whatever, but they're more open to saying, "Oh, I found this issue." Whether it's a simple typo or, "I typed in this code and it didn't work." Sometimes it's, "Well, I didn't explain that very well. So if I re-frame it like this, that helps explain it better." Or other times it's like, "Oh yeah, I screwed that up. Let me fix that. And, "Thank you very much, and the next version has that corrected."

Len: It's been really interesting to watch. Not only for us, but for our authors as well, to see the change over time. In our early days, the idea of an author interacting with a reader, terrified a lot of authors, and intimidated readers. But over time, it's become - we've got an "email the author" link on the landing page for the book, and people just click it with abandon, and people have learned how to be polite about it, on both sides.

Once a reader realizes that they can actually help improve a book, like there's a typo on page 92 - it's very exciting when they communicate that to an author, get a response, and then see the change in the next version of the book.

We never actually really heard this speculation all that much, probably because so many Leanpub books are programming books and programmers collaborate all the time and like to help each other out all the time.

But there's never been a jealousy like, "Why would I just go and help someone else with their book?" We basically never encountered any of that. Once people realized we were facilitating this interaction, the idea clicked - and then when you sort of dip your toe in the water - when you start, as a reader, communicating with authors and vice-versa, it can become this really rewarding experience, that makes everybody happy.

One thing I wanted to ask you about was - you set up a GitHub repo for your sample code, and you invited people to give feedback there. So have you had experience with getting pull requests from people that help you improve things?

Aaron: So, it's a little bit weird in that it's not pull-request driven. I do use the issue tracker - the sample code is in the repo, but not the book's contents. The book's contents I keep separate, I keep that private, - my writing process can be a little messy sometimes, and there's only so much of that I need to share with the world, I think. But the translators I've worked with have access to it. And that's what eventually feeds to Leanpub for new books, once it's polished up a little bit.

But the public repo is the sample code, and it's structured so that you can check out a branch at a time to go through each chapter. So, check out the previous chapter if you're starting at the beginning of chapter two, or check out chapter two if you want to see how things looked for me once I got everything together.

But then GitHub also has issue tracking, and so that's where I send people to go and say, "I found a typo." Even if it's not in the sample code, but it's somewhere in the book. That's a good way for me to have a central place to keep track of those - and then as I've fixed them in the next iteration, just go off and say, "Okay, thanks this is fixed in the September 2018 edition," or whatever, and mark those off as I go.

I think part of it, being a programming book - a lot of people are familiar with GitHub anyway. So they know how to file issues on an open source project and have that dialogue about, "Well, can you tell me more about your setup? I can't get this to fail the way you did." And, "Oh, it's because I'm using this operating system or this database," or whatever. And it's, "Oh, okay that helps me out," and I can go from there.

Every now and then I have somebody who, for whatever reason, either can't access GitHub - I don't know if there's maybe some limitations in some countries, I'm not sure? Or maybe they're just a little shy, and they'll email me.

A lot of times, what I'll do then is, I'll just post a few myself on GitHub, so other people can see it. So then if you came along and found that same typo - you could go and say, "Oh, that's already being worked on, so I'm not going to worry about it." Or, "I'm going to +1 it," or whatever.

Len: Thanks for explaining that process. That's really helpful to people who are planning their own projects, to hear about the experiences other people have had, and the ways they've used the tools that are available to them, and the conventions that are available to them out there.

So, the cover for your book is a cool old red farm truck. It's a really good cover. I was wondering if you could talk a little bit about why you chose that particular photo?

Aaron: I sometimes think I way overthought the cover. At one point I visualized - when I was at a previous job and was just in a different frame of mind, so much was new, and it was all like so exciting and, "Okay, I'm going to write 50 books." I was trying to think around a theme, like O'Reilly has the animal covers, and Manning has their own style. And all the mainstream publishers have their - you can see that cover and say, "Oh that's who published that book."

I wanted to have something similar for a series of books around software. Probably primarily Ruby, which is where the red came in.

I was searching around on a stock photography site, and came up with maybe six different cover ideas. I have a friend who's a graphic designer by trade, and worked through the ideas with him, and explained what I was thinking of at the time, in terms of this being a series at some point.

And so, that's where we headed with the truck. I have an old truck, it's not that old - and I don't leave it parked in a field like that. But that resonated with me as well. So yeah, the series of books with other - I don't know if they would have been vehicles or what? It hasn't come to pass yet. But that was the origin behind the book cover.

Len: Thanks for sharing that, it is a really great cover. And people sometimes joke about book covers, but it actually is really important to try and find a good one. And just as importantly, one that you're happy with.

And so, we've talked about your English-language book, but you have a translation into Japanese of the same book - and that's something I wanted to talk to you about. Because for a lot of people, if you've written a whole book - there are a lot of other languages in the world, and whole audiences you can reach in those different languages. But actually getting a translation done, can be a tricky thing. Can you tell us the story about how your translation came about, and how the process worked for you?

Aaron: There was a Chinese translation before the Japanese one, which was just - somebody approached me and asked if they could do it. They had some credentials in that they had done translation work for Michael Hartl, who wrote the Ruby on Rails tutorial. That is like the gospel of Ruby on Rails tutorials. And so with that, I said, "Yeah, let's do it." And so that translation happened, and I didn't hear a whole lot more after that. It is what it is.

But not too long after that, a small team of people from Japan said, "We'd like to do the same thing." Japan is the birthplace of Ruby, and it would be really neat to have that. And so just like you said, it's - there are people in Japan or many countries who either speak English fluently or speak enough to be able to piece together, "Okay, this is what this piece of code means." But to have it in the native language, alongside the code, can do a lot more to help people understand it. And I don't know Japanese or Chinese or - I know English okay. And so I said, "Yeah, let's do it."

With that team in particular, it's been such an amazing experience. We've talked about people submitting issues on GitHub when they find typos or something in the book doesn't make sense. I think there's a - there's an extra level of thinking through that, when you're having to not just make sense of something, but take something that makes sense in English and make it make sense in a totally different language.

And so they found so many things that - in some cases it was a bug in the code, or a simple typo. But a lot of times it was, "This does not make sense to me, this paragraph. What did you mean?" I'll go back and read it a few months later, and I don't know what I meant. So I used that opportunity to continually improve the product, the book. And that team in particular has been really great to work with - continuing on with the iterations of the book as they've continued over the years. They're right there to apply the changes to the Japanese version, and they always find new things with each iteration. And we fix them, and everybody's content, and -

Len: And did they sign a contract with you, the team?

Aaron: No. We did it really informally. With the translations I've done so far, the people doing the translators keep the royalties on the translated version. I maintain rights, for whatever that's worth. I mean, if somebody said, "Well, I'm just going to keep on doing it," I don't have a team of attorneys in Japan to make them stop. But I feel like it's better to get that thing out there than really worry about that too much.

They've been cool about - there's been a few times where like, "Oh, just want to thank you for all the work you did, here as an Amazon gift certificate," or something like that. Which, it's not something asked for, so it was a nice little surprise. But yeah - for the most part, I've never hired an editor to help me out with this. So the the things that they found, and have helped me improve, I think more than paid for what but they're keeping in royalties - rather than me taking a cut of that. I think everybody probably has a different way they want to go about something like that, but it's worked well for me.

Len: Thanks for sharing that, it's such a great story. Just one thing I wanted to remark on is that - in the publishing world, translation is a fraught thing, when you're talking about the world of traditional publishing, where like there's a company that's the publisher, that will do all kinds of negotiating for like language rights to a book. And I really believe that one of the reasons you often hear about authors having a hard time making money from their writing, is all these incredibly complex conventions that exist around - that people think have to exist around doing certain things.

A lot of those things don't have to exist. Your translators have made a great book, and they've made a fair amount of money - and they've made that book available to an audience that wouldn't have been able to improve their professional careers if it weren't for that translation. And it was all done without needing to license regional rights or anything like thatt.

And it's often - a sort of classic example for me, is people who spend a lot - I just wrote about this recently in a post about DRM - but there are authors who will sit there worried about piracy and thinking about, "How can we resolve this? Well, let's get the EU to change all their laws and then apply them globally so that my book doesn't get copied." And it's like, "Wow, do you ever have things backwards with respect to what you're presumably really trying to achieve - which is to write, not to police the internet - and to publish, and hopefully reach an audience."

And, in most cases, people are also interested in making some money. And just not stepping into all these traps you don't need to step into in the first place, carries some risks with it, but it also actually brings with it a lot of very practical benefits. And it's important, if you're thinking of being a self-published author, to really think through what your attitude is going to be towards these kinds of things in advance, or learned along the way, too.

But I would just say that - well, we had one story, I can't point to the specific book - where someone saw that their book had been translated into Russian by someone who was not communicating with them about it, they'd just gone and done this. And instead of getting mad, and instead of hiring a team of lawyers, the author of the book contacted the translator, who'd essentially pirated the book into another language, and said, "Hey, I'm writing another book - do you want to translate that one? Why don't we work together this time?" And it worked out to great success for both of them. So the informality, and then accepting a bit of messiness, can actually make things a lot a lot cleaner in the end.

The last question I always like to ask of Leanpub authors on this podcast, is - if there was one magical feature we could build for you, or one thing that really bugs you about Leanpub that we could fix for you, what would you ask us to do?

Aaron: For almost my entire, my whole workflow - I think Leanpub has been great. I imagine one thing that you've gotten before, and I know is like not a trivial thing to implement - would be indexing.

Len: Yeah, that's planned in the Markua spec. For anyone listening - you write a Leanpub book in a flavor of Markdown called Markua. Now well, no - that's not exactly right. We have an old thing called Leanpub-Flavored Markdown, but we've replaced that with a whole new - Markdown for books, basically - called "Markua." And it is fully specified - so we've specified how we're going to let you create indexes in books, writing in this syntax - but it's not implemented yet. The plan is there, it's just the execution. But eventually we will have very robust support for book indexes.

Aaron: I feel like that's also not - with my books in particular - I've resisted print with them, just because they change so often. You can keyword search an electronic book, so it makes indexes a little less important than they were with print only. But I do have people ask about it every now and then. It's cool to know people are thinking about it.

Len: Indexes can be very, very important. I mean - I shouldn't say, I don't know if I've ever seen an index in a fiction book - but in a non-fiction book, actually an index can be a whole - the writing of good index is a whole art unto itself. Someone wants to look up - you can keyword search for Abraham Lincoln in an ebook, but if you can actually go to an index and look up "Lincoln, Abraham," and then just see a structured set of pages with little descriptors of, "Early life, pages 10 to 15." That can actually really enhance the experience of reading a book, and getting what you need from it - especially if you're not going to read the whole thing, and you're only there for a specific purpose.

So it's something - we understand the importance of it, and we know authors do ask for it, and they have been asking for it for years - and it is something that we plan to ultimately deliver.

Well, thank you Aaron - very much, for taking the time to do this interview. I really appreciate it.

Aaron: Thank you.

Len: And thanks for using Leanpub for your books, and for being a Leanpub author.

Aaron: I'm excited - I've been very happy all these years, so thank you.

Len: Thanks.

And thanks as always to all of 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 yourself, please check out our website at leanpub.com. Thanks.