An Interview with Corey Haines, Author of Understanding the Four Rules of Simple Design

Published Apr 12, 2017 by Len Epp

Corey Haines is the author of Understanding the Four Rules of Simple Design and other lessons from watching thousands of pairs work on Conway’s Game of Life. In this interview, Leanpub co-founder Len Epp talks with Corey about his career, his book, and his experience self-publishing on Leanpub.

This interview was recorded on November 18, 2016.

The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly: http://leanpub.com/podcast.xml.

This interview has been edited for conciseness and clarity.

Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub podcast, I’ll be interviewing Corey Haines. Corey’s based in Chicago, and is the co-founder and CTO at Hearken, where he works to enhance audience engagement in journalism, specifically by helping journalists interact with audiences earlier in the editorial process than they would normally.

Hearken is a powerful tool for journalists and news rooms, that engages with readers to help news providers write the stories that meet the actual interests and explicit needs of their audience — and fill the information gaps that people really want filled.

Corey is the author of a Leanpub book, *Understanding the Four Rules of Simple Design, and other lessons from watching thousands of pairs work on Conway’s Game of Life. Based on his five years of extensive interaction with developers through the Coderetreat training format, the book is focused on exploring ways to, and I’m quoting here, “build flexible, adaptable software systems by better understanding Kent Beck’s four rules of simple design.”

In this interview, we’re going to talk about Corey’s professional interests, his book, and at the very end, his experience using Leanpub, and any ways we can maybe improve it for him and other authors. So thank you Corey for being on the Leanpub podcast.

Corey: Hello, thank you, it’s great to be here.

Len: I usually like to start interviews by asking people if they could tell us their origin story. I can see from your profiles online that you’ve had a really varied career. You started out studying mathematics, and ended up in software development in various CTO roles. I was wondering if you could tell us how you got into software development from mathematics, and how you got to where you are today?

Corey: Sure. I was one of the really lucky people in the late 70’s, early 80’s. My father had gotten into programming, and so he made sure we always had a computer around. So I grew up with computers, and actually started programming when I was about 12. Mostly cheating at games, because back then we had- the source came with it, and so if you couldn’t get past a point, you could hit break, look at the source code around there. And then over time, I figured out that you could change the code, and rather than figuring out what you needed to do, you could just change the code to put a jump or a GOTO past that point. And sort of “resume line 200” or something.

And then over time I got into BBSs and found a mentor on there that helped me learn C. And then I moved into C++. Then, I had never really thought about being a programmer. And I have always wanted to be a theoretical cosmologist. So I wanted to study physics and the Big Bang and all that. And then I got into college, and found out that physics actually requires experiments.

It wasn’t really that fond of that. But I loved the math part of it. My math professor had taken me under his wing, and I switched over. Actually I took trigonometry, and found the beauty of the unit circle, which is probably a pretty nerdy thing to say. But I remember it being like, “Oh, this is something that I find beauty in.” The purity and the abstractness of it. And that shifted me over to mathematics.

I had planned on continuing on to get my PhD in math, and be a professor. But I ended up spending my last year of university in Hungary, on a program studying mathematics called the Budapest Semesters in Mathematics, and fell in love with the country, so I decided to stay. I needed to find a job and started teaching English.

And along the way, I started programming again. I mean, I had always programmed here and there in C and done this and that, and was programming, and got tired of teaching English, because I was a very bad English teacher. I went and looked for a job, and found a job in Hungary at a web studio. And I ended up — I actually started as a salesperson, trying to sell — this was in ’96, and so I was trying to sell website development to companies in a country where I think less than 1% of the populus had internet access.

So this was ’96, and the web was just at the beginning. Nobody knew what it was. I remember talking to one company, and they were like, “Yeah, we’ll take a half-page ad.” And I was like, “Well, you don’t really take a half page ad on the web.” This was pre being able to take a half-page ad on the web.

And so, I went through that, and ended up getting fired — unsurprisingly. But along the way, I had done a lot of Excel programming for our sales team. Half the company was leaving to start a web studio, and the person who was going to be running it, who was the lead of the sales team, he asked me if I wanted to come as their programmer. This must have been the beginning of ’96, the end of ’95, or so. Somewhere around there.

And so then I learned HTML, learned CSS, learned a little bit of — we were on the Microsoft stack, so this was pre-ASP, and I learned how to do that, then ASP came out. And I just kind of built up this web studio in Hungary. We ended up being the largest web studio there.

I got into like every day, writing code, and building for customers and all of that, and just sort of never looked back. It was like, “Well, this is something I love doing.” So when I came back to the States in ’97, I found a job, and started programming. I went up through the Microsoft stack, ’til about 2008, then switched over to Ruby for — well, still. I know a bunch of languages, but I have been doing Ruby for a long time.

Len: And that was 2008, was a year before you started the Coderetreat? Is that right? I was wondering if you could talk a little bit about how that got started, and what that experience was like?

Corey: Yeah, so Coderetreat came about because — there were four of us, me and this guy Gary Bernhardt, and Patrick [Welsh], and a guy called Nayan Hajratwala — we were at a conference I go to every year called CodeMash. And I would say we were doing what programmers do, which is complain about other people’s code. And had this idea — why don’t people practice?

I was at the very beginning of what would end up being called the Pair Programming Tour, where I spent a year travelling around, programming with people in exchange for room and board. I took a year off of work, and just did that. And so, I was thinking a lot about practice — the software craftsmanship movement was just at the beginnings of people talking about it, and practice was a big part of it, and that was my focus.

The four of us decided just to put on a workshop, and see what happened, that was focused very much on practicing software development, rather than sort of learning a new technology. And since I was travelling around, I had the opportunity to take the ideas that we had, and some of the learning we did on the first two of these Coderetreats, and really help define them and take them around, do them in different places.

I went to Romania, did one in Romania, where a guy named Alex, and his wife Maria, they took over, and started running them in Romania. And so the two of us — or the three of us — got back together in the next year, and started really fine tuning the format. And then by 2010, we had a format for the workshop that was really solid. And then I just started travelling around doing them. And kind of seeing what they were.

They were very much focused on practicing software development, and very much focused on the sort of minute-by-minute decisions that you make while you’re writing software, during the refactoring process. So not at that high level of design patterns and some of the SOLID principles and things like that, but, how do you make your decisions when you’re refactoring?

Len: You have a couple of lines in your book, where you talk about part of the Coderetreat where you’re working on, I think, the source code for Conway’s Game of Life, and you talk about the impact of repeatedly deleting the code you’ve written, and the subsequent separation of identity from code. I found that really interesting and fascinating. I mean, it’s tied in with the idea of practicing, right? And the idea that you situate yourself psychologically in front of the code, not as something that is ever going to be used. Not as something that is ever going to be “owned” by you, or that you will ever be held seriously accountable for. And then with all that baggage out of the way, you can focus on your technique, and how you’re thinking and how you’re feeling when you’re coding. Is that right?

Corey: Yeah, absolutely. It’s funny, because first-time participants, often after the first session, have trouble with that deleting. But it’s part of the workshop… You just spend 45 minutes writing this code, because the format is you spend 45 minutes working on the problems. Then you delete all your code, and then we start again.

And we’re always working on the same problem, and we work in 45-minute increments. And then you always delete it at the end. And so it does free you up to try new things. Write really bad code, see what happens. This idea of just freeing yourself, and realizing that you can work for 45 minutes, and just get rid of it. You don’t have to live with that baggage.

And since, I’ve really pushed and moved even larger and do a lot of — I’m sort of an advocate of this thing called short-lived branches, where basically you have a day to finish tasks — and if you don’t finish it, then you have to delete what you did. And then you start anew the next day.

Because realistically, it’s not the typing that takes a lot of time in coding. It’s the thought of what you need to type. And so usually if you spend a day working on something, and you’re not done — it’s not the code that is the big lesson and the big takeaway and the artifact from that day. It’s all of the experimentation that you’ve done. You can generally re-type it in fairly quickly, and you’re not left with the artifacts from learning. There’s code, just bad code in there that you put in there, because you were learning, figuring it out. And if you keep it around, you have to work around it.

Len: I really found that idea to be very powerful, when I read about it in your book. And it reminded me of — there’s a practice for writing essays that some people adopt. There’s writing code, and there’s writing other types of texts, and I think a lot of your ideas would apply very well to sort of practicing and things like that. One technique for writing essays, is to write the introduction, write the rest of the essay, and then go back and rewrite the introduction. Just delete whatever you did.

Because as you’re writing — I mean, no matter how well planned your structure is, things will change, and you will learn things along the way, and actually then just clobbering what you did at the beginning isn’t a waste of time. What would be a waste of time would be to try to accommodate everything that came after your initial decision, to your initial decision — even though you’ve come up with a better solution since you started.

Corey: Yeah, and trying to shoehorn that in. It’s the same with talks. When you have to submit an abstract, and when you start building your talk — you realize that there’s other things you want to say that might not be directly related to the abstract, but they’re important. And so the thoughts can change. I think it’s [like that] with a lot of creative acts, acts of creating something. The initial idea that you start with is rarely what you truly end up with.

Len: Yeah, and the courage it might take to actually start over, to realize that completely starting over might actually result in a quicker result than trying to accommodate what you did originally, to what you’ve later realized you should do.

You write in your book also about the ping-pong pair programming style. There are two types of it, and I was wondering if you could talk a little bit about how that came about?

Corey: Traditionally, and historically, pair programming was done with two roles. There’s a driver and a navigator, where the navigator’s role was to type in the code, as well as pay attention to the sort of minute-by-minute, very small decisions that are made. Whereas now the driver was doing that. The navigator was really intended to look at the large structure of the system, where are we going. And the driver is really about making the small changes to get there.

And the problem with that is, I’ve found that you need people who are experienced pair programmers to do that. Because it can be dull to watch somebody code, if there’s not a great communication going on. And so over the years, I started really pair programming as a part of my technique, part of my process, back in 2004, which was when I was introduced to a lot of the concepts in extreme programming.

And I found, over the years, I would pair with a lot of different people, and find that when you really got into the flow and you were pairing well, then it didn’t really matter who was typing. There was a constant verbal communication going on. There was non-verbal communication going on. And you ended up just writing the code together, and both people were paying attention to things at all levels.

I don’t know exactly who introduced me to the idea of ping pong pairing. It must’ve been early on and probably when I was teaching people. I remember a couple of people that I taught, and as we were building systems, it was easiest to say, like, “I’m teaching you TDD,” test-driven development. And the easiest way I found to teach somebody, is for one of the pair to write the tests, and the other person writes the code.

And so over time, the person who is learning test-driven development has concrete examples of what tests look like. What do TDD tests look like? What form do they take? What are they focused on? But they don’t have to think about that at the beginning. They can just focus on writing the code to satisfy them. And then over time, the person learning can start writing tests.

This technique for teaching — it turns out that it’s really a great way to just pair. It keeps people active, it keeps people involved and focused on the problem at hand. And so one person writes the test, the other person writes the code, then goes back to the original person writing the next test — next code, and you bounce back and forth.

I think ping pong came up a little bit, because, well, it has that feel of back and forth. But you also were sort of passing the keyboard back and forth to each other. And that really is my preferred way, because that’s the way I found — especially for people who are new to pair programming, it’s a great way to keep everyone engaged in the process the whole way through, because the cycle should be on the order of minutes, if not even a more frequent cycle of 30 seconds or something. So it’s hard to drift off and start tweeting or something like that, if you are expected to pay attention to what they’re writing right then.

And then there’s also another form of it where what is sort of ping-ponged back and forth is the role of test writer. So you write a test, your pair writes the code to pass the test, and then your pair writes the next test, and then you write the code. So the role passes back and forth rather than the keyboard.

It also leads to things like, why do we only have one keyboard on the computer? Why not have both people have live input devices? That it becomes even less of a delineation between roles, and more into just — together, we’re using both of our minds to write the code. And over time, for the people whom I’ve paired with regularly, I have a few people that are just — we pair so well. We’ve just done it for a long time, we’re on the same page and on the same wavelength.

You bounce between these different styles. When you’re really engaged, you might be ping-ponging. And then someone has an idea, so they take over, and just start writing both the test and the code. And then you’re watching, because you’re interested in like — oh, what is their idea that they’re doing? And then it bounces back and forth and you can just sort of -there’s several different styles of pairing, but I like ping-pong sort of for the best for intro pairs.

Len: Yeah, it’s really interesting. Your particular way of focusing on, and clearly articulating the form of experience that one has when one is programming, is quite, is quite unique in my experience.

When I was researching for this interview, I saw there was a talk online where you talked about the Chicago School of Software Craftsmanship. I don’t know if you remember that, that was from some time ago, but I was wondering — you’re based in Chicago — if there is something about software engineering or programming culture there that is different from other places?

Corey: I do remember talking about those sorts of things, because there was a couple of different places, London as well, that had really active software craftsmanship communities in the early days, before it spread everywhere. A lot of it came from who were the prime people that were — honestly, who were the loudest people. Not really that they were the most — they had the best ideas. But they were the loudest in the different communities, and had maybe the most network or connections with people in other communities.

I was one of the louder people at the beginning, and got my name associated with it. But Chicago is definitely, I feel, a hub of, I guess, innovation in software development. Over time, different techniques, different ideas come out. There are people here who have strong opinions. There are people here who are experienced. They’ve got a lot of experience writing software. And not just writing software, but thinking about the act of writing software.

London is another one of those places that has this mass of people. And while we all talk to each other, there’s styles that get brought out from that. There’s a few of us here in Chicago who talk a lot about extreme programming, or work on Rails. Things like that. And so there are small differences. There’s a lot of differences in sort of the test driven development styles. There’s sort of this — partially tongue in cheek, partially not — there’s sort of the London style, and some people say the Detroit style, the Chicago style of test driven development.

They’re not in conflict with each other as much as they augment each other. So, knowing the difference — London style tends to be a lot more use of these test doubles, when you’re doing test driven development, whereas the other styles don’t necessarily. It’s funny, because I associate more with this so-called London style of software for test driven development.

I think in the beginning, the people around [in the Chicago area] and in our net of influence focused a lot on professionalism, on some of the techniques around software. And some of the other places focused a little bit more on the technical aspects of it. But it was never to the exclusion of the other aspects of software development. I was just — who were the loud people, and what were they interested in at the time?

Len: And what’s the startup culture like generally in Chicago right now?

Corey: It’s really thriving. It’s — we’ve got a lot of great companies starting up here. The difference that I’ve found is that Chicago tends to have more roots in industry and manufacturing and, I guess, making money. As revenue. So whereas a lot of the coasts, say the west coast — Silicon Valley, which is sort of the big one people talk about — there tends to be less of an emphasis on building say a revenue-based, sustainable company.

This is not to say that there aren’t some of those out there. But there’s much more of a glorification of the VC-style run from round to round to round, trying to get to the point where someone will buy you. Whereas, in Chicago — while we do have some of that, and we do have venture capitalists here — we have a very strong investment culture. A lot of the companies tend to be focused on revenue.

Len: That’s really interesting. I didn’t know about that. That’s a really interesting distinction between a Chicago style of start-up culture, and Silicon Valley.

On that note, I was wondering if you could talk a little bit about Hearken — what it’s mission is, and how the engagement management system works for newsrooms?

Corey: Sure. Hearken came out of our local public radio station, our local NPR station, WBEZ, from my co-founder, Jennifer Brandel, a handful of years ago.

[They] started a series there called “Curious City,” which had the goal of, what happens if you ask your audience for story ideas? That’s been tried before, but just asking people “What should we cover?”… Some people don’t have ideas, some people have just vague ideas.

You also get people who are very biased. Like, “You should do a story on my company.”, that type of thing. So the innovative idea that she had was, what if you tapped into your audience’s curiosity about the place? Or about a specific topic? In hindsight, it feels fairly obvious. But that’s the way it is with all innovations.

And so Jen started this series “Curious City.” It was very popular — still is very popular. It got to the point where a lot of other newsrooms were asking her for help in starting up this style of series, or this style of audience engagement. And she was spending her lunch time and after hours working on it.

So she decided to quit WBEZ and start a company to help spread these ideas, which is really fundamentally what Hearken believes: that every individual deserves to be heard. What can we do to make it so that if you want to be heard, you have an opportunity to reach out and ask your question — or make a statement? It’s different than the idea of everybody deserves to be listened to — which I kind of say half tongue-in-cheek. But everybody does deserve an opportunity to voice their curiosity, or to ask a question. And have a place where somebody is listening, or is hearing what you’re saying.

And so, I joined with Jen. I was introduced to her in December of 2014. I was on a sabbatical learning to paint. I had quit my job, and was taking a little bit of time off. And then I met her, and she’s a very dynamic, thoughtful person that you meet and you just — you want to help her do what she does. She’s just an incredible visionary. She has wonderful ideas, and I like to think of myself not as much as a visionary, as much as a supporter. I like to find people that have these creative ideas, and help — do what I can to help those ideas come into fruition.

And so, I joined with her. We co-founded Hearken. And went through an accelerator in San Francisco called Matter that is focused on media startups. Their partners are places like KQED and Knight Foundation, some of these big media places. The Associated Press is also one of their partners. The companies that go through it all have a media bent.

So we went through that in San Francisco, then came back to Chicago. We raised some cash last fall, the fall of 2015. We have a buffer to hire some people, and really spread this out. We have nine people now, and I think somewhere around 60 paying newsrooms around the world.

The Australian Broadcasting Company is a customer. There’s a media conglomerate that has a bunch of newspapers in Hungary — newspapers and websites, and so they use us as well all across Hungary. Which was wonderful, because I have a soft spot in my heart for Hungary, having lived there.

We think of ourselves more as a technology-enabled company, rather than a technology company. The thing that we are selling is a lot of the ideas, the consulting. We have what we call “engagement coaches” for newsrooms to help them figure out, how is it that we can talk to our audience, and hear our audience, prior to putting the story out, and getting just a comments section.

Because traditionally what happens is, you do a bunch a work, you have a few people sitting around a table figuring out, what story should we do? Then you do the story, you put it out online hoping that it’s a story that people want to see. And the only feedback that you get is via the comments section. And different people have different opinions of comment sections. I don’t have a great one of them.

But as an example — NPR, National Public Radio — they took the comment sections off their entire website, and they’re trying some other, and we are working with them as well, to really engage with the audience in better ways. More one-on-one, with less [of the] conflict that comment sections often can bring about.

Not to make a long story longer, but there are generally three phases to a reporting process. There’s the pitch phase, the assignment phase, and the actual reporting — when the reporter goes out and does stuff. We have small widgets and things that you can put on your website, to elicit story ideas.

Usually the prompt is in the form of a question. “What are you curious about Chicago?” Or NPR, one of their series put out a question about, “What are you interested, or what are you curious about with regards to global disease epidemics?” And so people are asked questions around that specific topic. The assignment phase — figuring out what the stories are that you want to do — we have a module that can be embedded on a website that allows voting rounds to be done.

We’re currently working on a tool called “The Reporter’s Notebook,” which is for engaging with your superfans during the actual reporting process, so you can very quickly, on a frequent basis, send out small little dispatches to your subscribers and say, “Today I got to interview so and so.” Or, “Tomorrow I’m interviewing so and so. Do you have any questions?” And so the person can reply to it, and send in a question. Or, “I’m looking for pictures about something, about this area. Does anybody have any interesting pictures?” They can send them back in.

[We call the] question prompt a “Curiosity Module.” And the voting display — that in itself is sort of commodity technology. You can use Google forms. Or you can use poll data. You can use these things.

When Jen started “Curious City” she used these tools. But what she found very rapidly was, like almost immediately, the spreadsheets that you’ve set up to manage the engagement, manage the questions that come in, manage the votes — all of this stuff — they become completely untenable. Imagine having even 100 questions that you’re sharing with the rest of the newsroom, and you’re color coding them — who’s assigned, who’s doing this and that? It just becomes — Jen’s term is, “Spreadsheet hell.”

With — some of the presentations we’ve done, she’ll put up little pictures of it — and everyone in the room starts laughing, because everyone has experienced that, trying to manage it with spreadsheets. And so we built what we like to think is a very fit-for-purpose system, called an “Engagement Management System.”

As votes come in, as new questions come in — you’re alerted. We post them into Slack for you. You can go to this back end and categorize them. You can put them into lists. You can put other people’s names on them. You can download email addresses, things like that. And that’s really the bread and butter of the technology part of it. It’s the only system out there that is exactly focused on making it easy to manage this style of audience engagement.

Len: It’s really interesting. As soon as I started reading about Hearken, it was totally intuitive to me, it totally made sense. I think that probably comes from our experience at Leanpub, which is all about publishing early and publishing often, and getting that engagement earlier in the process than you would have otherwise.

So in book publishing, I call it the “doorstopper” model, where, on your own in your cabin in Norway, you spend years writing your book. And then you just drop it, finished. Which is a great way of doing it, if you want to do it that way. But another way to do it, and what previously has been non-traditional way of doing it, is to put something out early on, and then start getting feedback from people, and seeing if that can help you make your book better. If it can help you pivot to dealing with the issues that your natural audience really needs addressed, as opposed to the ones that you maybe thought they would need to be addressed.

One thing I was looking forward to asking you about — if you’re up for it — is there’s a pretty big controversy around the news media in the States right now, that’s happening on a number of levels [Note: this interview took place on November, 18, 2016, just after the US presidential election — eds.]. One of them is the influence of fake news, and in particular, the influence of fake news on — and I should of course clarify, although I’m sure everyone knows I’m talking about the US election that just happened — but yeah, there’s a lot of talk amongst journalists and the public at large about the impact that fake news, and particularly fake news that was presented via Facebook, may have had on the outcome of the election. And as someone who works in the media, in the States — I was wondering if you wouldn’t mind talking a little bit about what you think about that?

Corey: Yeah. I like to use the term, “lies,” rather than fake news. It’s using a euphemism for something, but a lot of it is just — it’s just lies that people put up there in the form of an article or something. I mean it is a big, big problem and I think it is indicative of the ever growing distrust of journalism in the States. I don’t really know what all of the causes of it are, but it’s -

You can go back to talking about the extreme divisiveness of, or divided nature of America. Where we really do have — I know, the Washington Post put up that wonderful thing where you can put in a topic, and it will show you side by side — they call it the blue side and the red side. So what are people actually seeing because of the Facebook algorithm? And if you can get your thing into that algorithm, it doesn’t matter. Facebook doesn’t have curators that say, “This is fact checked.”

And so a lot of it too, I think, is because we’ve moved away from knowing who our reporters are, as things have aggregated into large national papers. And there’s much less local journalism happening. It’s harder and harder for people to feel loyal. It used to be that you were loyal to the New York Times, and that’s what you read every Sunday. But nowadays with the web, it’s so easy to find any story.

You go to Google, you type in a topic. You don’t oftentimes tend to look at where you’re going. You just look, first hit. I’m going to go do it. You trust Google, or you trust Facebook to show you them.

And one of our sort of foundational principles, is that if you — we’ve moved away from really the one-on-one interactions, of knowing who that reporter is, and being a fan of a reporter. I do know people who are like, “Oh, I love reading The New Yorker,” say. And there are certain writers in there that I like. Oftentimes they’re movie reviewers, because they like the movie reviews.

But we don’t have that as much. If you go ask, just somebody, the next person you see, who their favorite New York Times journalist is, you’re probably not going to get an answer. And, can you name someone from the New York Times, or somebody from The Post, or something like that? And so as we’ve lost touch… This is all, of course, personal conjecture. But as we’ve lost touch with that sense that the news is for us, instead it’s just repetitive.

They’re just trying to [see], who can get the clicks? If you get the story out first, then you’re going to get the clicks. Because we’ve lost that one-on-one feeling, it’s easier to just read whatever and go, “I don’t have a way of saying, I trust this one, versus this one.” And if you see something shared on Facebook, and it’s from Bipartisan Report, is that trustworthy? If you see something from Breitbart, is that trustworthy? Spoiler alert, no.

But there are sort of conservative publications, which are trustworthy, and then there are more liberal publications that are very trustworthy. They may have a bias about what it is that they report, but they tend to be fairly trustworthy. But we don’t have a sense anymore of who those people are. And I think that leads to being able to have our Facebook feeds showing us things — where we don’t even know — how do you check it?

It’s to the point now where like half the people don’t trust Snopes. So you can’t go to Snopes. And if you go to a place that has a differing opinion or a differing interpretation of it, then how do you know that that’s correct? And it really leads into this — just the sort of lack of knowledge in the US, that general knowledge that people lack. Then we can talk about how our education system is bad, and things like that….

Len: That’s a really good argument about the sort of lack of connection between the information that one is receiving, and a responsible person on the other side of it. One of my personal takes on it is that — and this is a higher-level thing, where this is totally banal, where news is turned into entertainment — but it reminds me of the discourse around drugs.

One of the things that’s very curious about drug prohibition specifically, one of the really curious things about the discourse around drugs, is that you’re not allowed to talk about it being pleasurable. For some reason, when it comes to that discourse, the fact that people partly do it because they’re enjoying themselves, is something we’re not allowed to say. What we have to invoke instead is social forces and historical forces and economic forces and material forces — to the exclusion of the immediate reality that people are kind of enjoying themselves when they’re on drugs.

And I think that one aspect of news — when people talk about how news has become entertainment, they often mean that it has been diminished in seriousness or something like that. But the other side of that, is that it’s become this source of pleasure. And what could be more fun than yet another conspiracy theory?

What’s even more fun is indulging in not doing all that vigorous self-policing that one does when one is thinking, “Well, is this trustworthy? Let me apply some analysis to this. Does this correspond to other things that I’ve heard from other sources?” Instead it’s just this like riot of the passions, internally.

And I mean — to invoke one side of the election, Trump himself said on numerous occasions, “We’re having fun here, we’re having a great time here.” And if you saw videos of those rallies, and heard descriptions of them — the people, they’d have tailgate parties beforehand. It was fun for those people.

Anyway, I think that that’s also a really interesting thing about the media — the news media and what’s happened in the States. It’s become this source of enjoyment and pleasure, for people in a way that it was maybe more a source of information in the past.

Corey: And especially since, even though there’s a historically low trust in the media, and trust in journalism now, they’ve still built into us that they are supposed to be experts. And it’s a wonderful feeling when I think something, I have an idea that something’s wrong, and then I go to a news site. It says it’s a news site. And they’re saying, “You’re right. You’re right Corey, that is bad.” And you’re like, “Yeah, it’s true.” Like confirmation bias and things like that. I’m going to go to the sites. I forget which comic it was, but they said, “The way you do research — is you go to Google, type in the thing. And then sure enough, that first link — it tells you you’re right.” And it’s like, “Oh yeah, that’s true.” One of my favorite pastimes is like on Friday night, drinking scotch and going on YouTube and looking at conspiracy videos.

I love the idea that the moon is actually a hologram, and is a projection. And there’s videos out there that show scan lines going across the moon. And that’s wonderful, as are these conspiracy theories. Now imagine if I then went to Google and typed it in, and I saw a news site that said, “Yes, this is true. And here’s the things that we found. Because of course we did our research.” Instead of just going to YouTube, and seeing a video that has ominous music — it’s actually a news site that does it.

I think this goes back to why people were so easily accepting of these fake news sites putting out lies — just stories, made up things. Because we want to have news sites tell us that we’re right. I wish I, I should have names of people, but somebody had said that nowadays, the US is so divided — it used to be that we had facts, and then the different politically-leaning news sites and journalists, would interpret those facts in different ways. But we’ve gotten to the point now where the base facts that are used to build up the stories are different. They’re just wrong.

So is our unemployment rate 5%, or is it 40%? These are two facts that are put forward, and the reporting is based on that. So when you go talk to somebody who has differing opinions about our employment economy and say, “Wow, we’re doing really well. Obama has really kicked ass in our economy. Unemployment’s down to 5%.” The other person can come back and say, “Well no — the real unemployment rate must be around 40 or 45%. That’s what I’m hearing, is that there’s this real shadow unemployment rate.”

And how do you argue about that? There’s no common ground where you can get together and say, “Okay well let’s, as a pair — even though we have different sources, or different interpretations of it — let’s look at the facts together, and then come to a common interpretation of it. Trying to shed off the bias.” But when you start with different sides, just totally different facts, you can’t do that at all. And that’s why I think the division is so pronounced, and there’s no communication between us.

Len: In invoking what you were saying before about how gratifying it is to have, say, a conspiracy theory that you’ve had, or a suspicion that you have — to see it on a news site, and see it reinforced….

Really looking, and this is kind of a cliché, but looking into the facts, rigorously, is really boring.

Corey: Yes.

Len: For most people, it’s no fun. It’s not exciting, it takes time. And it’s like, “Well really, I’m going to have to go read a paper written by a bunch of economists? I’d rather have someone I follow on Twitter say, ‘It’s 40%.’” Or, “There’s actually like 80 million undocumented migrants in the US, or something like that, right?”

I think that that disconnect is also really important — that one side of the activity is fun, and another side of the activity, the one that people don’t do naturally enough, is the one where you personally have to be like a journalist yourself, and go investigate and look at sources. And maybe learn a little bit of statistics. And, I mean, I don’t want to do that.

Corey: Yeah. I went and read the Republican Party Platform. After a big meeting, they establish what is the plank. And I went out and read it, and it’s dull. It’s really boring. But when you read it, you say, “Oh look, it’s important enough to them to put it in the party platform, that they want to fight marriage equality.” Or that they want to spread the so-called bathroom bills around the country.

And so you actually go read it, and you find these gems in there. And then you go read the Democratic platform, and you have to interpret certain things, and find out what it is that they value. But nobody’s going to do that, instead you’re going to find — like you said — find somebody on Twitter who says, “The GOP hates the LGBTQ community. And puts this here. And this is in their platform.”

I could’ve made it up. I could’ve just said that. Because nowadays, well — a perfect example over the last couple of days is — Trump tweeted out that, “I talked to Tom Ford, and I’ve convinced him now to not move the factory to Mexico.” [Note: This may have been intended to be a reference to claims Trump made about discussions with Ford’s CEO. This article is a good example of the way this issue was represented. The title of the piece talks about a Trump win, while the caption under the video with Ford CEO says “Ford CEO: We’d Make Same Mexico Decision Without Trump” — eds.] Well he’s been making this statement that they’re going to be doing that throughout the campaign. And the Ford Company has always said, “No we’re not. We’ve never said we’re going to do that. We’re not moving jobs to Mex– What? That doesn’t — we’ve never said that.” But yet he continues to say it.

And it’s easier to just look at the people you respect on Twitter on Facebook or wherever, and not go do the research. And if your bubble that you’ve cultivated does not include people who would be tweeting that, or even your bubble may be like that, but the Facebook algorithm has added its cultivation to your feed — you’re not ever going to see that. And so the only thing you see is people retweeting that. You look at Donald Trump’s Twitter thing, and it’s got 500,000 retweets. And you’re like, “What? 500,000 people agreed with this. So am I going to go actually look it up?” But it happens on other sides as well. Not quite as much, but it does.

Len: Do you think there’s a connection between the era of financial uncertainty in the news media industry, and the emergence of this fragmented multi-sourced news fire hose that we’re all exposed to now?

Corey: I don’t know. If anything, I would say that they’re symptoms of the same thing. Or they stem from very similar places. But I don’t — I’ve never really thought about that. So I don’t think I would have a great opinion.

Len: Do you have any thoughts about how — I mean, the media as an industry doesn’t move as one. But is there anything people can do to help change the culture away from where it’s moved towards? Which is as you say, this sort of — what The Economist called this fact-free environment.

Corey: Subscribe to your local newspaper. The media industry is struggling financially… There’s a handful of companies, Hearken is one of them, who are trying to sort of rise from those ashes to help the media industry move into what it’s like in this really super-fast digital age. But so much of it is: subscribe. Go subscribe to the New York Times. One of the encouraging things is that over the last week, The New York Times has seen a substantial rise in subscriptions. And I think a lot of the newspapers are as well.

But not even just the national ones — go to your local newspaper, and just subscribe. It’s not that expensive. And it helps them, and it says that there’s people out there who are interested in what they’re talking about. If you go to inn.com, maybe .org?

Len: Yeah, inn.org, Institute for Non-Profit News.

Corey: So what they do, is they build and host websites for a ton of non-profit news organisations — the small, focused [ones]. And they have a wonderful list of members that are doing great journalistic work, and they’re all non-profit. And so go to some of these and contributing to them, and finding ones that you enjoy reading, and just send a little bit of money to them. It’s a couple of bucks here and there every month. If enough people do it, then the news organisations that are doing good work will survive and be able to do better work, with a little bit of contributions to them. Mother Jones is one of the very large ones. There’s a lot of people who agree with them. They have a ton of great organisations. And INN is a non-profit as well, that can benefit from the support of sharing it around. They’re one of my favorites that I think is doing a great service to journalism as a whole.

Len: Thanks a lot for pointing them out, and for that suggestion for what people can do if they’re concerned about the future of media, by donations. I actually donate to organisations like the INN, and also get out subscriptions. Actually, one of the publications you mentioned I bought a subscription for, inspired by that same motivation, just recently.

Corey: Excellent. Thank you.

Len: Switching to the subject of your book, Understanding the Four Rules of Simple Design. You talk in there about the distinction between thinking about good design, and better design. I found the distinction compelling, and I was wondering if you could talk a little bit about what that distinction is, and why better design is such an important idea?

Corey: It comes about from the idea that every software design is intimately connected to the context that it’s for — and the context that it was built in. Context being — is it the first year of your company? Is it a multi-year project? Are the developers very inexperienced? Are the developers very experienced? Do you have a big mix of them?

And so all of these contexts, these outside forces influence the design choices that you make. Do you need to have everything in your code base super clean, and super beautiful? Well, if you have very experienced developers, you might be able to skimp a little bit, because they can work a little more efficiently in slightly messier code bases.

If you have a lot of beginners, then it behooves you to spend the time to keep your code clean. If you are in the first year of your company, and you don’t even know if you can sell this product — you might need to take cut a few corners. I prefer to cut features than corners in the code base. But there’s trade-offs everywhere.

And so, the idea of good design, to me, implies that there is sort of this Aristotelian concept of — in every context, this is good. Like a dodecahedron is a dodecahedron regardless of whether or not it’s red, or whether or not you’re trying to bounce it or something. So saying good design also implies that yours is the best.

Like I wrote it, I built a good design, and it may be completely bad in another context. And so, what I prefer is this idea of — if you have two designs to choose from, look at the one that best suits your context. Almost always, the context is going to make you want to be able to change your software faster. Especially when it’s early in the project, or early in the company.

And so, in general — better designs are more flexible. As you’re making your design choice, you can say, “This one is going to be a little bit easier to change in the future. It’s not necessarily the most extensible, or it’s the one that you’ve made decisions about what people are going to want to change. But I don’t want my design to calcify into this big mass, that when a new feature comes in, I can’t change it.” And so pick the design decision that will allow you the most flexibility to change it in the future. And that’s what I think is better.

Len: You draw an interesting distinction between designing code to anticipate change, and, as it were, designing code to anticipate a specific change.

Corey: Yes.

Len: So often people think that preparing for the future means thinking — okay, let’s imagine what might happen under various different scenarios, and then build in advance, something that makes it easy to implement that idea, that change that you think might happen. And that’s very different from what you were just describing, right? Because instead of coding for specific things that you think might happen in the future, you code for being able to change what you’ve done now easily. It’s sort of a subtle distinction, but it’s a really important distinction, I think.

Corey: Yeah it is. Because all developers have gotten themselves into that problem where you build a really extensible system, and then somebody comes around and it turns out that they wanted to extend it in a way you didn’t foresee. That always happens. And your decisions to extend in certain ways, sort of make it so that you can’t extend it in other ways. Every design decision you make is implicitly throwing out all of the other design decisions you could’ve made.

And that always leads to trouble. But making your system where you can quickly go in, find the place that needs to be changed and make the change — that’s the goal of everything. And that’s where the four rules come in. Because the two major ones that are sort of the refactoring rules, or…. On a simplistic level, you can say “no duplication” and “good names.”

The “no duplication” says that every piece of knowledge in your system should have one, and only one, representation. So if a piece of knowledge in your system changes, you can go change it there. And it ripples throughout your system. Good names make it so that you can find where things are happening. If you look at a method, and it’s named something, you can be fairly certain that it does what it says it does. And so spending time on these two concepts makes it so that when you come back in six months, you can very rapidly find the place where you have to insert the changes.

Len: You invoked the four rules there, Kent Beck’s four rules, I think?

Corey: Yeah.

Len: And just sort of literally taking a page out of your book, I was wondering if you could point people to the further reading they might want to go to, if they’re not familiar with what those four rules are?

Corey: There’s a couple of places. I mean, go to Google. Type in either “the four rules of simple design,” or, “XP simplicity rules.” There is a wonderful website, where everything is sort of encoded, which is the C2 Wiki. It’s currently under the — I think maybe he finished it? He was upgrading it, Ward Cunningham, the inventor of the wiki, which is really neat. He actually is the one who created wiki. The whole idea of wiki, and C2 is one of the original ones.

It was the place where a lot of the software thought and innovation in ideas were discussed back in the day. If you go there, it ends up being this time sink. It’s almost like every idea in software is there. Not really, but it feels like it. And it was set up for the Portland Pattern Repository’s wiki, it was called, and it just has all of these wonderful discussions around this, and the four rules of simple design are there. There’s discussion around them, about what duplication means.

Another person is Joe Rainsberger. He’s written a lot about it, and he’s just really thoughtful about how he writes, how he thinks about these sorts of things. The C2 Wiki, it’s just c2.com. If you go to wiki.c2.com, that should take you to the beginning of the Patterns repository. And you can also find a lot of great discussions around software, or around design patterns. And just lots of interesting conversations that happened back in the late 90’s around these things.

Len: Thanks for that guide, that’s really interesting. I’m sure a lot of our listeners will find it really helpful to have that nice summary.

You’ve got an unpublished book on Leanpub called Fun with Lambdas: Explorations through the lambda calculus. I know you gave a talk about this, that people can find online. I imagine that your maths background probably helps you a lot in understanding the topic, and I was wondering if you could explain a little bit, for people who might not have a maths background, about lambdas and what the connection is to computation?

Corey: This book came about — I mean, I’ve been working on it for two years, I think, and I keep going in and out of working on it — so what a lambda is, at the core, is a function that takes one parameter and returns a value. And the lambda calculus came about when Alan Turing was building up the ideas of the Turing Machine, and a lot of these concepts around computability. What are the limits of computability?

Alonzo Church came up with this idea of — it ended up being equivalent — can you build up computation using this idea of these functions, that take a parameter and return another parameter, or return a value? And the lambda calculus became a lot of the foundations of a good number of our programming languages. So all the ML languages — things like that, that deal very heavily with this idea.

But if you drop back to just that core thing of, the only thing I have is a function that takes a parameter and returns a value. Where do you go from there? Ostensibly you should be able to build up all of computing. You should be able to build stuff that allows you to do everything that any other general purpose programming language can do.

And so the book is really — a lot of the books around lambda calculus are very academic. They talk about the identity function, and they talk about K combinators and B combinators and Y combinators. And they start putting them together.

My idea for the book was that whenever I talked to people about it, they either were very academic and very high level, and it was this mathematical thing. Or they were people who had told me “I’ve looked at them, but who cares? Like it doesn’t make any sense, I don’t get [what comes] out of it.”

\And so, I started talking and a friend of mine — Josh Cheek and I started playing with it. Like just in Ruby, what happens if I just start with a lambda, can I do different interesting things? And then I ended up, some time later, starting a book, where the goal is to not really talk about the academic parts. It’s to not go in. Not even go into lambda calculus, but to go in and start with a function, start with this identity function, and slowly build up programming.

One of the first things you need to do, is you have to be able to build — say you want to build numbers. You want to build a concept of numbers, but you don’t have them. All you have is this function. How can you build up a numbering system? And so we go through — well, since I do test driven development, the beginning of the book is building up a testing system. I want to be able to build tests, to test that my numbers work as I expect them to.

Well to build tests, you need to have a way of saying “true” or “false.” Well to have something that says true or false, you need to have a thing called “If.” And so we back all the way up, and then build the concept of true and false and decision. And then we come back to this tests, and we come into numbers, and we start building tests based on what are called the Peano axioms, which are a set of axioms around the natural numbers. And so we write tests that satisfy the axioms, and build code to satisfy those tests.

And so it’s really intended to be just fun, like if we were just hanging out with a computer. And I’m like, “Oh hey, let’s look at this.” And just start writing along. [There is a] lot of prose around it, but very little saying, “This is the K combinator.” So you can compose the K combinator with the identity, and that gets you the equivalent of false, whereas the K combinator is the equivalent of true.

And so, then it starts to get confusing for people. There are a couple of really great books. Another Leanpub author, Reg Braithwaite, he has a wonderful book on combinators. And it’s a joy to read. All of his stuff is a joy to read, but…

Len: Yeah, Reg is really fantastic.

Thanks for that. Actually, switching gears to Leanpub and to self-publishing, you had a lot of success with Understanding the Four Rules of Simple Design. I was wondering if there was anything special you did for marketing the book? How did you get the word out about it?

Corey: Coupons helped a lot, like setting up a coupon for — since it’s a technical book — conference season. Making the coupon, and then making it specifically to that conference, and then either asking the conference organizers — using it as some form of, almost sponsorship, if it’s a very small conference, that they can give into their bag, or just tweeting about it with their hashtag. Not being obnoxious about it, although some people probably say that I might be at times. But really aligning with that, I think, has been a huge thing.

And going on podcasts, talking — all of the sort of standard marketing things. But I think coupons have been a lot of the way that I’ve kept — I think it’s like two and a half years since I wrote it I think, 2013, maybe is when I wrote that book? So it’s been maybe three and a half years?

It goes through waves. I’ll have a burst where I sell a couple of hundred copies, and it’s generally because I keep on it. So when conference season comes around, or when something interesting happens, I’ll tweet it out, and tweet out a coupon for it. I think that’s the biggest.

Len: That’s really, really good advice. It reminds me of something. I interviewed another Leanpub author, named Phil Sturgeon, a while ago. And he talked about how one of his tactics was to use coupons to get his book into to be sort of “above the fold” on the Leanpub bookstore, like this week’s bestseller, to be in the first two rows — which is another way that coupons can help. It sort of gets you that burst. And then you’re there in a more prominent position on the bookstore.

I was wondering why you chose to self-publish, and specifically why Leanpub?

Corey: there’s a couple of reasons around the self-publishing. One is, I actually wasn’t sure if I wanted to write a book. I started writing it because I was invited to speak at the Agile India Conference in, I guess, 2013. And on the way there, on the plane — I have a 22-hour trip or something — I started writing out the talk. I was explicitly going to be talking about the four rules of simple design. And I started writing out the talk, gave the talk, and then on the flight back, kept writing it.

And I had spent five years, however many years, four or five years, talking about the four rules during Coderetreats. And so it was all in there. And I came back, and I told my girlfriend, I said, “I think I’m writing a book.” But I didn’t want to get into the situation where there was an expectation, or a stress around it, because I have lots of friends who’ve written books. And it’s always so stressful. I’ve looked at them, and I’m like, “I don’t ever want to do that.”

And so as I was working on it, I decided that I didn’t actually want to tell anybody I was writing a book, until I was sure that it was going to be done. But it didn’t makes sense to write it, and just have it in random files. I looked around and I talked to some of my friends, who are publishers, and I didn’t want to write a long book as well.

The book itself I think is 85 pages. It’s a short, very concise thing. I wanted it to be an electronic publication, because I wanted to be able to put links out to other things. And any publishers that I had talked to, there’s expectations, there’s minimums, there’s deadlines and all of that.

And so, I looked around at some of the self-publishing platforms, because that was about when I started noticing, about 2012, it felt like there was a surge of self-publishing platforms coming out. And it may have just been that I noticed them. So that makes a surge in the universe.

It might actually be Reg that was the reason I went Leanpub initially, because I had no idea, I didn’t know anything about it. And all of them look the same. But then when I looked at some of the toolsets, I loved that Leanpub was connected to GitHub, which I use. At the time it was only the Dropbox distribution. So when you did a preview, it would come into Dropbox. And I think, at the time I had to actually explicitly say, “Make me a new copy.” And I think now you can trigger it with a push or something.

But the fact that I could write it in Markdown was important to me, because I feel comfortable writing in Markdown. The Leanpub manual was great. I read through that, and it was so clear how to do things.

Len: Well thank you very much.

Corey: Did you write that?

Len: I had a big hand in it. It’s pretty rare to get manual shout outs or compliments. So I really appreciate that.

Corey: I downloaded it and read it. And it was like, “I can write this.” I liked also at the time, the constraints of — it’s not like you could lay it out any way you want. Especially at the time, I think there’s more flexibility now than there was back then, but it was like, you write Markdown, and if you want the callout to look like this, you put this markup in there. And I wasn’t as interested in like pixel-perfect, “I need this to be here, and this,” all of that. I wanted to just get the content out. And have it come out in a way that looked good. So that was good.

Len: Thank you. That’s really interesting. Regular listeners to this podcast will know that core to Leanpub’s philosophy is the idea that, when you’re writing, except for a very small subset of projects, formatting is procrastination. When you’re done writing, if it’s very important to you, please use our InDesign export, get a book designer, do whatever you need to do.

But often — and having written some myself, you do find yourself, instead of writing, instead of thinking about what you’re supposed to be writing, you end up playing around with formatting.

I mean, people can do what they want. But one approach is to say — let’s actually try and get a lot of those ideas — just not even present them to people during the period when they’re writing. Give them what they need to quickly generate really good books, like really, really good looking books, but not, as you say pixel perfect. Don’t worry about that until the time comes.

Corey: Yeah, and being a technical book, I didn’t really need — I really was about just getting the content out there. And I would have messed around with the formatting, because writing is very — it’s a struggle for me. And so while that book actually flowed out, because I’d been saying the things for five years, or four years or whatever it was, it still is a struggle for me to write, because I just don’t have the practice around it. I’m more of a speaker than a writer. And so having those constraints where I could just… write in them. So it’s just pure text. Just [being] in there, writing — and not having to worry about all of that stuff.

Len: Did you publish it in progress, or did you publish it all in one chunk?

Corey: That book I published in — I didn’t put it out that it was even available, I don’t know what the exact term is, [you could] put your thoughts out on how much it should cost.

Len: We have a mode where you can have a landing page for your book, available to the public before you publish it. And then people can sign up and say, “Notify me when it’s published.” And they can say how much they’d be willing to pay for it, and share their email address with the author if they want to, and things like that.

Corey: Which was a great feature. I got a lot of people telling me how much they’d pay for it. Which helped me, because I had no idea. But I think I published it almost complete, if not totally complete. Because even leading up to, until it was done, I almost wasn’t sure it was going to be done. I wasn’t completely confident. And so when I was — whatever, 90% confident that I was going to complete it, that’s when I put that landing page up and started gathering that. And I think it was like two weeks after that that I published the book, and put the cost out.

And I liked how it told me all of the different statistics around the price. Of like, “If you want to make the most money, it’s this. If you want to have half the people buy it, then do this.” That was a very nice, geeky -

Len: Yeah, my co-founder Peter will be very pleased to hear that. He wrote that years ago. It’s a text you see on Leanpub, just for everyone listening, that explains at length how much you can make under different scenarios and things like that. And it’s really very nerdy and very fun, and serious at the same time.

The last question I have about your process is — you had an editor for your book, someone named James Rosen, and I was wondering, did you go into the writing process thinking — I mean, now that I know a little bit more about it’s genesis, I can see how it started out not necessarily with the intention of being a book — but did you hire, or did you get the editor at the end? Or did you have the editor helping you along the way? Was it something you expected to need?

Corey: I expected to need it. What I was very, very lucky with, with James, was when I was comfortable enough to mention to people that I was working on it, I put out on Twitter that I was looking for early reviewers. People to read it and give me feedback on it. And I got a bunch of responses, got a lot of really great feedback from people.

James stepped up and just edited the thing like crazy. It was amazing. He’s not an editor, not officially, he’s a software developer like I am. But he dove into it, and gave me such amazing feedback, and made it so much more readable, that I just kind of was just like, “Well you’re the editor, you get editor credits on this,” because he spent a lot of time and gave a lot of wonderful feedback.

I was so appreciative of him. But it was just incidental. He was somebody who I’ve met before, didn’t know him tremendously well, but he followed me on Twitter, and just kind of stepped up on it. I’ve since then bought him a couple of meals. I’ve told him that he shouldn’t ever pay for his dinner, if we have dinner.

Len: Well that’s great, generous on both sides I guess.

My last question is, if we could build a magic feature for you, what would that be on Leanpub? Is there anything that you can remember along the way that would’ve been nice to have, but you didn’t have?

Corey: I still struggle a bit with book organization, like file organization around the book. Especially around code snippets, especially with the lambdas book. I write the scripts. And then including them, keeping them up to date — I don’t know if I’m missing something, but it’s sort of a struggle to have them go along.

Because — for example — in the lambdas book, every code snippet builds on the previous code snippet. And so, it’s almost as though if you were able to say, “I want this set of code snippets to be based on this file, and go over the history of the commits on that file.” And give me a time-based, or commit-based code snippet.”

Not interactive, but just like, — snippet one is the first commit, snippet two is the second commit. And even if it took putting a SHA in there, in the little external resource thing. I think that would help me a lot. Because I struggle with that, keeping them up to date and up to sync, and making sure that they’re correct. Does that make sense?

Len: Mostly. I’ll pass it on to our team. I haven’t written a programming book myself, and I’m not a programmer. I do some programming, but I’ll definitely pass that on. That sounds like a really good idea. We do have, kind of in the hopper, designed a versioning kind of system that might have some of the features in it. And I’m not sure when we’re going to get around to building it. But it’s pretty well thought through. And it sounds like we could incorporate something like what you’re suggesting into that as well.

We do currently have a versions feature, but it’s very rudimentary, and you might not have even noticed it. You can’t name versions, you just know what date and time. But it is there, because obviously authors, their work is very important to them, and knowing there’s backups and things like that is really important.

Anyway, I wanted to thank you, Corey, for a really great discussion, I had a really good time. Thanks.

Corey: Thanks a lot.

Len: Thanks for your time, and thanks for being a Leanpub author. Good luck with Fun with Lambdas. I’m looking forward to the day when that’s published.

Corey: Yeah, me too. Thanks so much.

Len: Thank you very much.


Originally published at leanpub.com.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.