A Leanpub Podcast Interview with Noel Rappin, Author of Trust-Driven Development

Noel Rappin is the author of the Leanpub book Trust-Driven Development. In this interview, Leanpub co-founder Len Epp talks with Noel about his first encounters with computers, his career, the challenges that come with software consulting and client management (and in particular, the importance of trust), his book, and at the end they talk a little bit about his experience as a conventionally published and as a self-published writer.

This interview was recorded on March 7, 2017.

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 Noel Rappin. Noel is Director of Development at Table XI, a custom software development company in Chicago that does a variety of work on enterprise software, mobile applications, and custom websites.

Noel has written a number of technical books — including, Take My Money: Accepting Payments on the Web, Rails 4 Test Prescriptions, and a four-book series called, Master Space and Time With JavaScript.

Noel is also the author of a book in progress, published on Leanpub, called Trust-Driven Development. His book is about the importance of trust in the profession of building successful software, and we’ll be talking about that a little bit later.

You can follow Noel on Twitter @noelrap and find out more about him and his writing online at noelrappin.com.

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

So, thank you Noel for being on the Leanpub Podcast.

Noel: Glad to be here.

Len: I always like to start these interviews by asking people for their origin story. I was wondering if you could tell me how you first got interested in software development, and what your career path has been?

Noel: Well, software development — I have, in many ways, what used to be the standard path. I was a young nerd, who started programming Applesoft BASIC on an Apple IIe. Actually probably a little bit before that, there was a place near my house that gave after school lessons on like TRS-80s and stuff like that. This is the early 80s.

I didn’t do a whole lot with it for a while, but I kept going and learned Turbo Pascal and things like that, and eventually decided that that was the kind of thing that I wanted to keep doing. I really enjoyed it. I also have a regular CS Degree, and a graduate degree, which I don’t really use very much.

Then I came out of school. I was living in Boston for a while, and worked for a very, very small consulting company in what would become the dotcom boom. And since then, I have largely worked as web developer and consultant — although not exclusively, but for most of the intervening time.

Len: Do you remember your first experience with a computer?

Noel: The first thing I ever coded — this is very early 80’s — one of the competitors to the Atari 2600, was made by a company called Bally. They were mostly a pinball machine company, but they made a really early game console, and they had a programming cartridge that you could program in the programming language BASIC.

I have a very clear memory of — so I was probably about 10 or 11, and I was trying to copy a program from their manual. And what I didn’t realize was that there was no way to tell visually, but all the keywords in the program had special — it wasn’t a keyboard, it was like a 1 to 9, almost like a text message, like an old T9 text entry thing. So, this is very, very slow. They had shortcuts for all the different keywords in the language.

And you had to actually use the shortcut. If you typed the keyword, the interpreter, whatever, didn’t recognize it. And you couldn’t tell from the screen that was what was going on. And I didn’t know that I’d done it wrong. And it was very, very frustrating — and probably great preparation for my eventual career.

Len: So you must’ve had to just bang away at it, until you figured it out.

Noel: Yeah, I don’t even remember how I figured it out. But at some point, I think it dawned on me, what was going on. But it took a very, very long time.

Len: For some reason, that reminds me of the infamous Rumplestiltskin clue in King’s Quest. Do you remember that game?

Noel: That, I’m not familiar with.

Len: There was a game called King’s Quest, where the solution to a riddle was to type in Rumpelstiltskin backwards. In the code they’d misspelled Rumpelstiltskin.

Noel: Oh God.

Len: So even if you got the answer, you still couldn’t solve the problem. And this became a notorious -

Noel: This is total digression, but there’s a legendary story about the early days of Second City when it was the early days of the Second City improv troupe. When it was Alan Arkin and people like that. For some reason, they were doing, for some reason, Rumpelstiltskin as a theatrical piece, improv. And they get to the point where Rumpelstiltskin’s saying, “All you have to do is guess my name.” And then somebody just ran on stage, said, “Hey Rumpelstiltskin, old pal. Great to see you. How’s it going Rumpelstiltskin?” And then left. Leaving the other two actors to just sort of pick up the scene after the guy just completely destroyed it.

Len: Speaking of Second City, I should mention that Noel is coming to us from Chicago, and Second City is a very famous -

Noel: Improv troupe. That had nothing to do with anything, I just love that story.

Len: That’s fine. Actually on the subject of digressions — one thing, I know that you like to write about on your blog, is tech. And I saw you had a post about the new MacBook Pro.

A lot of people who listen to this podcast are developers, and people who probably work on MacBooks, and I think they might like to hear your feedback on what your experience has been like with the new MacBook Pro.

Noel: I am apparently the only person in the known universe that likes the new MacBook Pro. But I do, and the person who sits next to me, who actually has the 15 inch, likes it.

I am coming to this from what was a four year old 15 inch MacBook Pro that overheated all the time, and had a battery life that we were starting to measure in minutes. And so this one seems great to me. I actually use the touch bar. Again, I seem to be unusual, from developers that I’ve talked to, in finding this to be like helpful and kind of cool. But I do.

I do find that my normal developer practice tends to be a little bit closer to consumer practice than a lot of other developers. I don’t use Vim, I don’t use Emacs. I use Atom, which obviously is a programmer text editor which uses normal Mac key bindings. And I do a lot of non-code writing, using consumer or power user writing apps. I find that my usage tends to diverge a little bit from hardcore developers, who are mostly using Vim and like iTerm. So my experience is sometimes a little bit different than -

Len: And when you’re coding, are you using an external monitor?

Noel: I usually do use both a laptop monitor, and an external monitor.

Len: So you type type on the laptop in front of you?

Noel: Yes, that’s my normal practice, I normally type on the laptop, and usually use a secondary monitor for the browser or whatever else that I’m looking at.

Len: For those listening, these are the tools of the trade, everybody’s got their own setup.

Noel: If you look down the halls here, you’ll see people using their laptops in all different ways. Some people just use a laptop, some people close the laptop and just use the external screen.

Len: And have you customized the touch bar that Apple added?

Noel: A little bit. I added a button — I added the lock command to the default thing, because I lock my screen a lot, whenever I get up. And now it’s easier to do that. I’ve customized it in a couple of apps. There’s an application called, BetterTouchTool, which is normally a keyboard shortcut and trackpad shortcut tool. But it also now allows you to customize the touch bar for apps that don’t have touch bar support. You can add buttons to it that trigger keyboard shortcuts or whatever on the app. And so that’s really helpful for a couple of things that I use that don’t support it yet.

Len: You had another great blog post that struck me about your mobile writing setup. It’s not just programmers who sit in front of keyboards and screens typing, it’s writers too. And programmers and writers can be the same people sometimes, like in your case. And what struck me about it — as soon as I saw the image of an iPad on a stand, some distance from an external keyboard, it seemed so much superior in some ways to the very distraction-heavy experience of having your mouse there, and the internet there to be easily interacted with.

Noel: Yes, I really like this setup. I haven’t used it as much since I got the new laptop, because the new laptop is smaller and pretty portable. But basically, I have these six dollar little plastic iPad stands, and a really inexpensive Logitech $40 keyboard, which, again, some people don’t like the feel of.

But I actually think it feels pretty good, for something that’s about the width of a binder cover. It’s tiny, and really light. And yes, that’s a very portable setup. In some ways, it’s a little bit more ergonomic than the laptop setup, because you can mess with the distance between the monitor and the keyboard in ways that are hard to do when you’re on a laptop, and the two of them are connected to each other.

Len: I really like the ideas of potentially putting the iPad more than arm’s reach distance away. So that you can’t poke at it, and interact with anything. Then you just have to write.

Noel: Yes, and then you can also put the iPad in portrait rather than landscape, so it looks a little bit more like a sheet of paper, if you’re into that kind of thing.

First of all, it’s a very lightweight, very portable setup. You can almost do it if you have some sort of goofy — I was in a SCOTTeVEST jacket, and the whole thing will fit in the pocket of the jacket.

The battery lasts a lot longer than a laptop battery would. So it’s a very good portable setup. And it is kind of distraction-free. You generally have the one window. I use a very minimalist — I tend to use either an application called Ulysses or an application called iWriter, both of which present pretty minimal interfaces when you write.

It doesn’t work as well when I’m writing stuff that interacts with code a lot. So if I’m writing a very technical section, where I’m going back and forth between code snippets and writing, it’s not as effective. But for a blog post, or for something where — or something like the Trust book, which doesn’t have any code in it, this kind of thing works really, really well. I really enjoy that set up.

Len: My last tech question is actually about the SCOTTeVEST. I hadn’t heard about it until I saw your post, and I was wondering if you could talk a little bit about that company. It’s really interesting.

Noel: SCOTTeVEST makes clothes with a lot of pockets.

Len: Including underwear.

Noel: I don’t have the underwear. I have a jacket. I have a couple of things of theirs. I have a jacket that has an internal pocket large enough to slide an iPad into. You don’t really feel the weight of it, but it does make bending kind of a challenge. It just has a lot of pockets. It has a pocket that you can fit a water bottle in. It’s really good for travelling actually.

Len: They looked really interesting, all the products on that site. There’s a really interesting graphic they have, where you sort of look at the surface of the jacket, and then you can slide across and see where all the hidden pockets are, and with images of the things that you can keep in there. Really cool.

On the subject of maybe something not quite so cool, but also interesting, you’ve written something about what you call The Boring Software Manifesto, which I found really interesting. I was wondering if you could talk a little bit about that?

Noel: This is something I actually came up with several years ago, when writing manifestos was all the rage. I actually re-upped it on my blog relatively recently, because I saw a reference to it. And I’m probably going to get the detail a bit wrong actually, because it’s not in front of me as I look at this.

The idea is that there’s a certain kind of software team and software developer and project manager that really starts to think of churn and activity as a good in and of itself. And in fact, a lot of times, with really functional teams, things get stopped before they become emergencies. This is working against the hero march, software death marches — people saving the day by heroically working 50, 60, 70, 80 hours a week. This is boring software. We test our things beforehand, so that we get requirements beforehand. We test our tools, we commit to a sustainable pace. We don’t over-commit. So I wrote it up as, “The Boring Software Manifesto”, structurally in the style of the far superior and more useful, Agile software manifesto.

Len: It’s a really interesting topic to me. I mean, software is eating the world. And so how software is built is actually a really important issue for humanity.

After things like — a famous example in the United States, that I’ve brought up on this podcast a couple of times, is the Obamacare website fiasco from some time ago, and up in Canada, we’ve had a number of scandals around this kind of thing — where hundreds of millions or even more are spent on software development for something that just fails. And boring would be a much preferable reality to catastrophe.

Noel: At my own podcast, which is called, Tech Done Right, I’m actually going to be interviewing somebody who was involved with the healthcare.gov, Obamacare tech roll out — at a very high level, the rescue effort. Because it’s still a very interesting story — not just how the original roll out happened, but how they actually managed to more or less right it relatively quickly, given how bad it seemed to be in the initial roll out. So that’s going to be interesting. It’ll be up in a couple of weeks. I haven’t actually had that conversation yet.

With healthcare.gov, you’re dealing with scale and integration issues that go way beyond what most software projects have to deal with. But I think that software is challenging. And it is often challenging in surprising ways, even when you’ve been doing it for a while. It’s important to have a team that has enough of a process, and can build up enough trust, that when things go wrong — because things will always go wrong — that you can all work together to try and fix it.

And I think that when you start getting into these super large projects — healthcare.gov was the coordination of multiple different consulting shops, each of which was working on one part of it, under one kind of specification — when you start getting to scale, once it’s impossible to fit all the team in the same room at the same time — that sort of process gets very, very challenging to scale up. Just the number of communication paths. The amount of state that has to get communicated.

I talk about process being like the thing that you need to do to communicate state, so that everybody has a common idea of what’s going on. There’s all kinds of things on a small project. You might have a short 15 minute meeting every day for the six people on the project, and that’s enough to coordinate state. But if you have like 20 people, it’s not going to be enough. You need more effort placed, not even moving things forward, just making sure everybody knows what’s going on. This becomes increasingly complicated the larger the project gets. And then it becomes exponentially complicated.

Len: I believe the distinction that you make is between — I mean, you’ve got a number of distinctions, but one is between project and process. Project is the sort of tasks you do to accomplish your goal. And process is the communication that happens around it.

Noel: Yes. Process is one of those words that gets thrown around a ton without a hard definition. And that makes it challenging to really think about, how can I improve my process? What am I doing here that’s efficient and effective? One of the things I do in the the Trust-Driven Development book is to try to put enough of a definition around it, that we can start to think a little bit more critically about what kind of process is valuable.

I define process as the things you do in a project that aren’t helping you get towards the goal, but are instead helping everybody understand what the status of the project is. And that is a wide, wide range of activities. That could include commenting code. It can include a task tracker. It can include meetings. It can include a chat room. It’s a wide, wide range of things.

But then you can start thinking about — is this a good process? Is this time that’s actually being spent improving people’s understanding of what’s going on?

Actually, I once worked on a project where at the end of every cycle of the project, they expected one of our deliverables to be UML, which is a language for defining software structure. They expected us to have UML diagrams of the structure of the code, and all of the interaction paths.

In an ideal world, you’re supposed to develop those things first, but you never actually do, because you don’t know enough at the beginning. So our software development process would come to a complete halt as somebody would go off and build these diagrams, which nobody ever looked at. It’s like, is that really a process? That’s process, so we’re not building stuff. But nobody’s really using it. So it’s not really telling anybody anything that they don’t already know. And it’s probably not a really good use of our time.

Len: You’ve got a pretty interesting way of describing part of this issue, which is something along the lines of, you’ll never know less about a project than you will at the beginning of the project. And so as a moment for planning….

Noel: Right, but there’s a ton of pressure at the beginning of a project, to feel like you know where the end of the project’s going to be. And most of the time, you just don’t know enough. And unfortunately, that’s not a super satisfying answer.

We are a consulting company here. We start working with a new client, and they have a reasonable expectation that we’re going to be able to tell them how much their project’s going to cost upfront.

If you think about it in terms of a business transaction, that is a perfectly reasonable thing to want. It’s just a very, very hard thing to deliver. Because you don’t know. You don’t know the state of their existing data. Do they have the data in place to put in? Are we going to have some sort of weird translation? Are they going to decide that once they see the application, that it’s not actually what they need? Are they going to want a lot of changes?

Are there requirements that are hidden here — it just says, “allow the user to login.” But it doesn’t tell us that there’s an existing single sign-on system that they need to know about. Or that they need to have administrative users with special privileges. There’s all kinds of things at the beginning of a project that you don’t know.

One of the strengths of extreme programming and Agile is that they kind of roll with that. The expectation is that you don’t know. So they try to put lightweight processes in place, so that you can course-correct over the course of your project. The analogy is driving: when you’re driving, you don’t take your hands of the wheel and just try to steer once a block. Your hands are always on the wheel, and you try to make small motions all the time.

And that’s great — I think it works really, really well in a product company environment, where you have an ongoing project. And it works very well in a consulting environment too. It just has this extra challenge of, most of the time, customers want you to be able to say upfront how much you’re going to ask them to pay you. Whereas, the process is almost deliberately designed — it’s very, very hard to know that with certainty.

Len: And how do you guys do process? Do you use Slack? I can see behind you that you’ve got whiteboards with sticky notes on them. Timeless, I think.

Noel: Actually one of the sticky notes there is one of the things we do for career development, which is a separate issue entirely.

Len: I wanted to ask you about that in just a second. But I’m curious about what your tools are.

Noel: So we do a couple of different things. It depends a little bit on the project. We use Pivotal Tracker a lot for task tracking, which is a fairly opinionated piece of Agile software that integrates really well with the idea that you have broken up your task into small stories. And then you can give those stories estimates that are in a point system — one point, two point — rather than in time. And then you determine how many points you can get done in a given couple of weeks, based on how many points you’ve gotten done in the previous couple of weeks. And it all works — it can work very, very elegantly in an ideal project. Which, like a lot of ideal things, doesn’t always exist in practice.

For interpersonal communication, we use Slack a lot. We have regular team meetings. Most of our projects have weekly or bi-weekly iteration planning. Meetings where we talk about what was done in the last week or so, and what we’re going to do in the next week or so. One thing we do that’s really important, is we have retrospective meetings every week or two.

And in that case, that’s everybody on the team just making a list of things that are going well, and things that aren’t going well. And then you talk about some of the things that aren’t going well, and try to come up with something actionable that will make them a little bit better over the next couple of weeks. That’s really, really effective. If there’s just one thing that your software team could adopt tomorrow that will improve the way your software team works over time, it’s that.

Every couple of weeks, just get in a room, figure out something that’s not working very well, and try and figure out one thing that you could do to make it work a little bit better. And over time, that gives you a lot of growth.

Len: Speaking of career development, I have kind of a meta career development question. You have a talk on YouTube, that you gave at a conference a little while ago, where you talk about your own transition to an HR style role.

Noel: Yes, and then out of an HR style role. To be clear, the point of the talk is the transition into, and the somewhat more interesting transition out of.

Len: Right. That’s an experience that quite a few of our listeners sort of face as either something they are going through, or might go through some day. Is the transition from being a developer — and maybe perhaps not permanently, but for some period of time into another type of role. I was wondering if you could talk a little bit about what that experience was like?

Noel: Sure. For about a year, I transitioned to being a — I never stopped being a developer, so I was a part-time developer for a while, and wound up being, part time, the title here is, Director of Talent, which put me in charge of most of pretty much everything HR-related, except for benefits. We had somebody handling benefits, and that’s a very specialized field.

In practice, [my position] involved our interview process. Spearheading diversity and inclusion efforts within the company. Trying to create an issue resolution process. Talking about issues involving hiring, company policy in the sense of, what’s the vacation policy going to be like? Should we change the maternity policy? And that kind of stuff. I certainly have like a lot of opinions on how companies should hire, and how interviews should go.

Len: I wanted to ask you that specifically — your opinion about interviews. How do you think they should be conducted?

Noel: Technical interviews — so interviewing is inherently impossible, right? That’s the problem. You have a very small amount of time, during which you’re trying to figure out whether somebody’s going to fit into your company over an extended period of time. And you have a bunch of constraints on it, like you can’t ask for too much of the person’s time.

It’s not respectful of them. It limits your applicant pool. Because if you’re limiting it to people who can come in for a week, or even come in for two or three days, you’re excluding people whom you might otherwise be interested in. So it becomes a real challenge.

There are a couple of things that we have tried to do to mitigate that a little bit. One is to be really transparent about what we are bringing somebody in to do. When we ask you to do a coding exercise — we have a relatively short take-home exercise — which has it’s own problems, but we haven’t thought of anything that we like better yet — we try to be really transparent. “This is how much time we expect this to take. If this is a problem, let us know. We’ll work something out. This is what we’re looking for. This is what you’re going to be evaluated on. If it goes well, we’e going to ask you to do this.”

And when people come in for our interview day, we try to be very upfront about, who you’re going to meet with, what they’re going to be talking to you about. What kinds of things we’re trying to get out of it. And we look for feedback too. We ask people, “How was the day for you?” even before we make a decision on them.

Len: And you will actually give feedback afterwards as well, right?

Noel: It’s true, yeah. It depends on the exact situation. I really like to do this for people who are in their first job hunt, and might not have a really good sense of — because it’s very hard to get your first junior developer job. Especially if you’re trying to figure out how interviews go on your own.

So we say, “You came in, we saw this, this and this in your pairing session, and that is something that indicated, that you’re not the right fit for us at this point. Your skills aren’t what we expected.” Or, “We had this concern.” Obviously you don’t want to be obnoxious to the person, but we do try to give people something constructive, if we can. To say, “This is how you were presenting yourself. This is something we saw that you might want to work on.” Or, “This is something we were looking for that other companies might not be. Here’s a place that might be more interested in this particular set of skills that you have.”

It’s a hard problem, because it’s inherently very fraught on both sides, and there’s no way to know in advance what the right way to respond to somebody is. But we try.

Len: It’s a really interesting issue. I wanted to ask you your opinion about nervousness in interviews. Because an interview is a very artificial situation. And one that they — if you hire them, they might not encounter again at your company.

I remember once interviewing someone for a job in finance, who had recently completed a graduate degree in maths from Cambridge. And they just completely flubbed basic arithmetic. It was interviewing for a high-pressure job, so the nervousness kind of mattered to some extent in that area. But at the same time, it was like — well this person will never be in an interview again if we hire them. Or not like this.

Noel: That’s very challenging. Because it’s hard sometimes to even tell what’s nervousness and what’s not. We try not to put somebody in too artificial a situation, so we don’t make people code on whiteboards, which is a common interviewing technique, where you make them solve a small programming problem by writing their code out longhand on a whiteboard. Which is something that you never actually do, and is ridiculously artificial. I probably couldn’t pass it, and I’ve been doing this for 25 years.

Also, it’s just the tone. We try to be super welcoming. We try to make it feel like the person being interviewed is the most important person in the office when they come in. And eventually, we hopefully break through the nervousness. We try to take that into account in our decision process too. Like, this person seemed kind of nervous, and we try not to hold that against people.

Len: Moving onto your book, which is about trust, you have this line where you say, “We are continually telling people that they need to give us money to solve complicated problems that they cannot fully see.”

I was wondering if you could talk a little bit about that problem, which I think is — it’s not entirely unique to software development, but the idea that you’re doing work that people can’t see, is just fascinating to me.

Noel: It’s actually not unique to software development at all. I think that’s an important insight if you’re a software developer, and you’re dealing with non-software developers. Because almost all of us have been in that situation on the other side. We go to auto mechanics, or we go to doctors, or we go to lawyers or accountants. In all of that case, we’re going to somebody who has expertise in a problem.

I specifically analogize an auto mechanic at the beginning of the book. The auto mechanic comes out and says, “Yeah, the problem’s with your brake lining. Here, look at this. Doesn’t that look bad? That’s going to be $5,000.” And I don’t know, maybe, it might not even be my brake lining. I don’t know enough to be able to tell. And I have to trust this person.

Or the doctor says, “I think you should take this medicine.” Or a lawyer says, “Your will needs to be filled out this way.” And this, this, and this. I don’t have that expertise. I can’t have all this expertise. I’m going to somebody because they’re offering me expertise. Of necessity, I need to trust them. I think that having empathy for being on the receiving end of that experience, if you’re a software developer, can really help you when you are on the delivering end of that.

We talk a little bit about the kinds of things in that situation that can build trust. One of them is making sure you have an incentive structure in place, that incentivizes long term relationships. The easiest way to build trust, is to say that you’re going to do something and then do it. So setting up a structure where you have that ability to do that helps a lot. Having satisfied customers that you can say, “We trusted them, and it worked for us.” That’s a great thing too.

There are things that you can do in that situation to make that interaction more friendly. Friendly may not be the right word, but, to try to increase the level of trust that you’re going to need. Because at some point in any software project, you’re going to have to say, “I know we said this was only going to take a couple of days, but it’s just not.” Or, “There’s a bug here, and we’re sorry. That’s just part of the process. Sometimes this just happens.” The time to say “Bugs are part of the process” is not when you’ve delivered your first major bug.

Len: I was going to ask, when is the right time to say that?

Noel: It’s the second or third thing you say. It’s really helpful to sit down at the beginning of a project and say, “This is what’s going to happen. You’re going to present us with some requirements. We’re going to try to turn them into something that we can operationalize, that we can turn into software. So we’re going to ask you a lot of questions. And we’re going to make a best faith estimate about how long it’s going to take. But we don’t know yet, because we haven’t built it. And sometimes we’re going to make mistakes. And sometimes that mistake is going to be because you have a requirement that we didn’t know about. And so it’s going to go wrong. And sometimes that mistake is just going to be a mistake. Things are going to happen, and hopefully we will catch them. And the more that we work together, the sooner we can catch them. But inherently we are flawed people. We’re very good at what we do, but we’re not perfect, and things are going to happen.”

And then the deal is, when things happen, you deal with it, again, to engender trust. You can build a lot of trust when things go wrong. If you were willing to come out there and go, “Yep, we screwed up. And here’s what we’re going to do to fix it.”

If you try to hide — if you learn nothing from sitcoms, it’s that the initial problem doesn’t get you in trouble. It’s the repeated attempts to go over the top, to try to cover up the initial problem, that gets you in trouble.

Len: You make an interesting observation related to this, that the broken windows theory applies to software projects.

Noel: Yes. So one thing that is true about doing software for people who are not software developers, is that, if you’re not a software developer, you have a much different sense of what software is. And you tend to think that software is the interface. So you tend to think of things that are just like, “This is red instead of blue.” Or, “This is over here, instead of over here,” as being sometimes more complicated than they are, and the underlying logic that drives that as being less complicated than it is.

In kind of a related way, one of the things that you can do to really quickly build trust, is like fix problems right away. Especially early in a project. The customer’s going to come up. The first time they test stuff, the first time they look at it, they’re going to have a list of things. “I wanted this over there.” Or, “When I click here, it doesn’t do what I expect.”

And if you can get a lot of that stuff done really fast — and often you can, because a lot of those things are small, a lot of the time, but they’re the kind of small things that are really interfering with the client’s ability to see the application for what it is. Their view of it is literally just what we present, and if it’s hard for somebody to see like the underlying logic, if they are caught up in the surface not being correct -

It’s not a value judgement here, it’s not that the software developers have a grand insight in general. It’s just that the software needs to be built for the customer. And what the customer sees is an important part of their experience. And if you can make that keep working for them — especially for a non-technical customer.

There’s nothing more satisfying if you’re like a customer in this case, that you say, “This thing isn’t quite working,” and then the next time you go to test it, it’s fixed. That is a very strong step towards building like a little bit of trust.

Len: I imagine the beginning of the relationship is probably the most crucial time for building trust. I’ve got an old observation that — if you get a new job, show up half an hour early for the first six months, and you’ll be “early guy” the whole time, even if you stop doing it. And if you can fix a client’s problems right away at the beginning of a project, then they will trust you further on; if something is still broken, it’s not because you’re negligent, it’s just because something happened.

Noel: Right. Eventually when you say, “This is harder than I thought it was going to be,” if you have prefaced that with — again, the time to say that for the first time is not when something’s already late, the time to say that is before.

Len: That’s a really good piece of advice. I’ve run into issues related to that in the past.

Another thing you talk about in your book is dealing with hostile environments. I was wondering if you could talk a little bit about that? This could be an environment where you have lost trust with the client, or maybe they’re under a deadline. They’ve suddenly dropped a deadline on you that you can’t meet, and they didn’t know in advance that it couldn’t be met. Things like that.

Noel: A client environment or a programming environment can be challenging in a number of different ways. Like you said, it can be a situation where you have either lost trust with the client, or the client — for whatever reason — is reluctant to give you trust. Or the client has impossible demands placed on them, and they’re passing them along to you. Which is also a thing that happens. Or the client wants to do something that you frankly think is a bad idea, or is potentially a user hostile idea — or in some cases potentially illegal. If you’re dealing with software and money, it’s not that hard to wander into stuff that is actually illegal without even kind of realizing it.

Len: Or personal data.

Noel: Yes, or personal data. There are all kinds of things that you can do that are either actually illegal, or are violations of — PCI compliance is not the law, but it’s a standard. Or you have unreasonable expectations for deadlines or things like that. And it is very, very hard in that situation.

Every challenging environment like that is challenging in it’s own way, and it’s hard to come up with a one-size-fits-all [solution]. But I do believe that you can make some progress if you need to, if you’re willing to make slow and steady progress that like — being the change that you want to see, it’s sort of a cliched kind of concept, but that can be powerful.

It’s slow, and it doesn’t work everywhere, because some places will just smash that. But it’s worth trying. To try to model for other people, the behavior — a culture is made up of the people in it. And if you come into a culture that expects things, certain ways, especially if there aren’t that many people in it, if you try to do something a different way, suddenly you’re like — you’re a six person team, you’re 18% of the culture trying do something new. Trying to do pair programming or trying to do testing. You convince somebody else, and suddenly it’s a third of the team. And so you have this gradual process. Which is not like necessarily fun, but you can make it better. Every environment in that respect is a little bit different.

Len: Speaking of changing environments, you write a lot, and you’ve published quite a bit online, and in books as well. And you’ve had a couple of books published by a conventional publisher, The Pragmatic Programmers. And you’ve now decided to do a project on Leanpub. I was wondering why you decided to try do this book on Leanpub?

Noel: So, I’ve done self-publishing before, and I’ve actually self-published this book in other ways before, a little bit. I started self-publishing several years ago, Rails Test Prescriptions actually was originally self-published, before it went to Pragmatic.

And I had had some experiences with conventional publishers. I had worked with a couple of other conventional publishers. And one of those experiences was not great. I decided that I was done with that. And I had some reasons to believe that the Rails Test Prescriptions was a little bit too niche, even for technical publishers. I turned out to be wrong in that case, but I believed it at the time.

So this was like 2009. And I started self-publishing it as a PDF. This is pre-tablet. So I was shipping it as a PDF, and I was actually designing it as a landscape PDF, so that you could read it better on a laptop. And eventually someone talked me into submitting it to Pragmatic, when it was about half done. And Pragmatic decided that they were willing to buy it. So I stopped self-publishing it, and we transitioned to a somewhat longer version of the same book, that Pragmatic published.

A little bit after that, I wound up in a situation where I had, for other reasons, a partially finished JavaScript manuscript that didn’t have a publisher. I self-published that myself for a while, using my own toolchain and using a third party shopping cart. And that worked pretty well. But this time around, I decided to redo this, to re-issue this book in Leanpub.

I had had my own process for generating all the ebook stuff a few years ago. But I hadn’t really looked at it in a while, and was not really looking forward to updating it. And looking at Leanpub’s tool chain, it occurred to me that Leanpub had spent the intervening time putting a lot of effort into improving their toolchain. It was a lot further along than the last time I had evaluated it, in terms of like what the end products looked like, and what kind of options you had.

There was some option that I wanted that wasn’t available the last time I had tried to self-publish, and it was now. And it occurred to me — a lot of people have worked on this tool chain, worked with this tool chain, and I bet it’s probably a little bit further along than the one I had that nobody’s touched for four years. And it turned out to actually be true. So it led me to really quickly be able to transition what I had to Leanpub and put it out there.

Len: One of the ways we’ve developed Leanpub over time is through interviews with authors, and asking them about their issues. And I was wondering if there was one magical feature we could build for you? Something missing perhaps, in your experience that we don’t have that you’d like?

Noel: I suspect that if I start to do something on Leanpub that has a lot more code in it, then I’m probably going to have — one of my toolchains has a pre-processor that drops code from my source code in. I don’t actually expect Leanpub to have that feature. But I suspect that that kind of thing is where I would start to bang up against the corners of what Leanpub winds up doing.

Len: One thing you do in your books, is you include an email address, asking for feedback and comments about eratta. In fact, you even have eratta at noelrappin.com.

Noel: Yes.

Len: I was wondering, is that something that you’ve had success with, with readers? Do they email you with comments?

Noel: Sometimes. I think that probably the way that I am presenting it in the book right now, is not really getting very much. It seems to be kind of sensitive to when you hit people up for comments. You need to hit them up when they’re in a mood to respond. And possibly when they’re reading something on a tablet, is not necessarily the time. It seems like that is something that you might have more success with in a follow up email. Like, “Hey, you bought this a week ago. Do you have any comments about it?”

Len: That’s really interesting.

I’m afraid our time is just about up. But I wanted to thank you very much for being on the Leanpub Podcast, and for taking the time to talk to all of us about this. It was really interesting.

Noel: I appreciate it. Thank you for having me on.

Len: Thanks.