Josh Justice, Author of Outside-In React Development: A TDD Primer

Len: Hi I’m Len Epp from Leanpub, and in this episode of the Frontmatter podcast I’ll be interviewing Josh Justice.

Based in Conyers, Georgia, Josh a professional software developer with nearly twenty years of experience in the field. He’s currently Principal Architect and Web Platform Lead for Big Nerd Ranch, a web and mobile consultancy based in Atlanta.

You can’t follow him on Twitter @CodingItWrong, for reasons we’ll go into later, and you can check out his website at codingitwrong.com.

You can also subscibe to his YouTube channel CodingItWrong and you can find him on Twitch under the same handle.

Josh is the author of the Leanpub book Outside-In React Development: A TDD Primer.

In the book, Josh takes the reader through the concept of outside-in test-driven development and how this approach can help you do software testing that actually helps you go faster in your application development, rather than slowing you down. Along the way, using the principles of outside-in test-driven development, you’ll build a front-end React application from scratch, inan extended exercise across multiple chapters.

In this interview, we’re going to talk about Josh’s background and career, professional interests, his book, and at the end we’ll talk about his experience as a content creator and a self-published author.

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

Josh: Glad to be here, Len, thanks for having me.

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

Josh: I’ve lived in the Atlanta, Georgia, area for pretty much my whole life. My dad worked in IT, and so, he would bring computers home from the office from time to time.

We were just talking about the Macintosh SE up on my wall, I’ve been able to get one in the last couple of months. If folks haven’t heard of them, it’s one of the earliest Macs. When you think about that form factor of the monitor built into the little rectangular machine, that’s the one. So, he would bring home different computers. We would try them out.

The other thing that played a role, was - Nickelodeon, the kids’ TV channel - had a TV show called, “Clarissa Explains It All.” On this show, she would make computer games about her annoying little brother, she’s a middle school student. And I was like, “Kids can make computer games? That’s amazing. I want to do it.”

A lot of folks from traditional programming backgrounds came up wanting to make video games and things like that. What I found was that making video games is really hard, and not fun, even though playing them is fun.

But I really have fun building utility apps and CRUD apps, and business apps. And so I decided, “Well, I’ll play video games, and I’ll make utility apps, and that’s the way that’ll go.”

But I came up, in my high school years, when the web was starting to become a thing. I did web programming, a Computer Science major, and from there, I worked at a whole variety of places doing software development, mostly focused on web development, with some forays into native mobile development as well.

Len: And so, when you were doing this early kind of web development, early for you, and early for the web, what kind of resources did you have to draw on? For example, were there magazines that you would buy, where you would learn how to program from that? Or were there, at the time, websites you could go to?

Josh: In the real early days, books, paper books were a few of the resources. I remember an online resource called Webmonkey. I think Wired magazine might’ve been the ones that supported that? That was one of the first web development resources to learn about HTML, and then later CSS. Because CSS didn’t come until later. Anyone who knows the web will maybe have their mind blown by that. So, yeah, there’s some early online resources there, taking advantage of the medium.

But paper books played a big role for me as well. I remember, I think it was, Teach Yourself Perl In 28 Days. Perl being a programming language. It was about two inches thick, and I remember going through that one. So yeah, books, paper books have played a big role in my learning and growth as a person, in a lot of different ways of my life.

Len: It’s really interesting. No one can see it, but I’m looking at the Mac behind you on the shelf there, and it reminds me, it’s very, very similar to the first Mac that we had in our household, the first computer we had in our household. People who maybe aren’t as old as we are, might still be aware of the very famous 1984 ad that Apple came out with, where there’s - I think the Olympics were on in Los Angeles or something like that. And there’s an athlete running down the aisle in a cinema, and throws a big hammer at this Big Brother figure on the screen, with all these zombie-like people watching it. The screen shatters, and it’s supposed to be some message about freedom or something.

But the Mac ad that most struck me at the time, I think it was around that time, was, I think, someone just like picks up the Mac out of a box, and plugs it in. There’s this shot of them just plugging it in. And it’s like, “Away you go.” And of course you plugged in - all personal computers were plugged in when you took them out of a box, you know what I mean? But there was something about it, the message it sent was, “I don’t have to learn anything to set it up. I can just plug it in and click a button, and my computer’s going.” There was no command line prompt, “Run,” “Go computer.” There was nothing like that that you needed to do, and that was just an amazing marketing tactic.

Josh: Yeah. And you know, there’s a focus there on usability and removing unnecessary detail, that has actually been a big theme for me as well. I’m drawn to programming languages that have the same sense of, “Let me focus on the key thing that I want to do.” Apple was about, just, as a user, I didn’t even know that I could use a computer. “Oh, I can do something with it.” Or as a programmer, “Let me program in a way that helps me focus on solving the problem.” The only software I have running on that Mac is HyperCard, which is this old, really revolutionary programming environment, that allowed average users to create interactive software. It was miles above the low-level compile code that was the other alternative at the time.

Really even in my focus on testing, and content creation, it’s all about like, “How can I get people the most useful thing, so they can be productive and build reliable, helpful, useful software?” Not everybody needs to be a nerd that thinks about every single detail of all the esoteric programming approaches, testing approaches. Someone who wants to go deep.

But I want to equip people who don’t want to go so deep. Or maybe even start an interest. As a kid, I was interested in making video games. I found that, for me, I was interested in going deep, becoming a professional software developer, and really digging in to expertise. But if other people can benefit from computers or creating software as well, it’s a win/win.

Len: That leads me to ask a selfish question, which I do from time to time on the podcast. But it’s something - I don’t know why I’ve been thinking about more lately than usual - but this concept of being a nerd, and the idea that there’s something special about programming computers, that distinguishes it from building other kinds of things.

Just looking at your Mac, that’s nearly a 40 year old computer. Personal computers are older than that by some distance as well. Yet, to this day, there’s this psychological constituency of people, that views the computer as not real.

We talk about virtual things, as though somehow you’re in a ghostly realm when you start using this particular machine. It’s not about building, and it’s not about logical chains, right? Because the same person who might be like, “Oh no, I could never program a computer,” might be happy opening the hood of an old car, and looking at how everything fits together, and figuring out how to fix it.

Do you have any general thoughts about that? Why is it that there’s something about computer programming that’s seen as nerdy, or only accessible or enjoyable to a specific mindset?

Josh: That question really hits on some thing that I care deeply about. Because I see trends in programming, or in software and computers - or two philosophies.

Actually, one of the books that’s been most impactful to me, talked about two views of software, in terms of literal, actual philosophy. The historical philosophers.

There is a view - actually, where I’m going with this is a bit different than that author. It’s object-oriented - shoot, what is the name? Object Thinking, by David West, is the book. But actually, I realize that where I’m going with this is a bit different than where he was.

Because, within the realm of the logic that computers can do, it’s so infinitely malleable. There’s always more that you could do, and more ways you could’ve rearranged those bits, and get those functionalities, and get those user interfaces, and get that data flow to work. So, I think because in a sense, it’s easy to move those things around, there’s always the temptation to go deeper and deeper into optimization, and lower and lower a level, to really make things more complicated for yourself.

Sometimes, for some organizations, and for some people’s personal wirings, that’s helpful. Google has certain very intense needs. Microsoft has certain very intense needs. I mean, Netflix. Yet, for smaller businesses, for individuals, for personal projects, you can get a sense of like, “Oh, unless I’m using all of those technologies, I’m not a real developer.”

I think a low-level thing it relates to is, being willing to hold things in tension. Where it’s like, “Oh, it’s really cool that those technologies exist, and I really respect the folks that can understand those hard problems in a deep way, but that doesn’t make me less.”

Because, as I said earlier, I like making simple utility apps. We do professional stuff that has some complexity, but a lot of the user interfaces I create are just different ways to show on the screen, different kinds of relational data. To make, create, read, update and delete. All those data changes, you could summarize with that. The term that I think is used is, “beyond software.”

But certainly in a software world, there’s imposter syndrome. The idea that like, “Oh, I don’t really know what I need to know. If people knew how little I do know, they’d realize that I’m an impostor, I’m a fake.”

Something that I really resonate with in the software world, is a focus to work against that. A focus on inclusivity. A focus on people from different backgrounds. So that it’s not that everybody needs to code, or should code.

But if a mechanic finds something, that they’re trying software, and they’re using it, and they’re like, “I wish I could customize this,” and they find a way to do it. I hear so many people that I work with, even at the consultancy that I’m at, they talk about, “I was working in this other industry. I started using software. I started customizing the software, and I found that I was more interested in working on the software, than in the problem that we were solving, and I got into the industry.”

I think that mentality helps serve as a great check for people that are really theoretical, are really down in the technical details. To know, “Hey, software is useful for other people as well.” It’s very valuable to have people from all different backgrounds. The arts, literary world, cooks, cuisine, they have folks from those backgrounds. Sociology and psychology, for sure. To have those folks working in the software industry in various roles, it makes better software, and it makes better solutions. I think when we see that, that it’s not just, “Oh, I want these people to feel included. But I see that my software is better when they’re contributing. Then I can really say, ‘Wow, like this is an industry where there’s a place for everyone.’”

Len: It’s really interesting when you mentioned “seeing” there. Particularly people who might be, say, working with the software for a car, and they can actually change the way it works. This tangibility and visibility, I think - the closer I think that programming gets to something like that, that people of a certain mindset can relate to, the less ghostly and virtual it seems. It’s like, “No, I tinkered with it, and now I can turn off the alarm on my car whenever I click this button, or something like that, so it won’t accidentally go off when I park it at this loud place,” or something like that.

Over time, obviously, it has been like 50 years since the personal computer came out. Maybe it’ll be another 50, but eventually I think it’ll just be an ordinary technology to most people. Like a toaster, or anything like that, and lose this sense of exclusivity to a particular group, and I’m really glad you picked up on that. There’s more than one form of exclusivity that’s often associated with programming, for obvious reasons - getting beyond that, and making it more accessible to people. In a very literal sense, but in the more expansive sense, it’s really important for changing the way people view programming and technology generally.

You mentioned that you studied Computer Science. I think nowadays people would be like, “Oh well, that’s your ticket to a high-paying job.” It wasn’t necessarily at the time. Was that something that you studied because, Well, I mean, as we spoke about, you were already interested in computers and stuff. But was it something that you studied with a view to, “This is going to lead to a great-paying job?” Or was it something that you studied just because you were inherently interested in it?

Josh: It was definitely the inherent interest. I wasn’t specifically thinking about pay, or anything like that. I think my parents were very glad that what I happened to be interested in, was doing quite well most of the time, throughout the decades. They were very happy to encourage me towards that. Although there was a stint where I decided, I transferred, I was at Georgia Tech - which is a big, public, science-focused, southern, mostly male, at the time, hopefully that’s changed some, organization.

After one semester, I decided to transfer to a small, private, New England, Christian, mostly female school, and take up a Bible Study degree. They were like, “What is he doing? What?” But luckily it had a Computer Science program, and they were like, “Hey, how about a double major?” I was like, “Cool, I’ll do a double major.” I ended up just doing the Computer Science major, graduating from there.

In my view, I got a great education there. But yeah, that was my dalliance. It was great for life growth, and socially. Getting out of that, “I’ve always lived in Atlanta, I’m just an Atlanta person.” It was great to be stretched in that way.

Len: We’ll get to the combination of religion and programming shortly. But before we do that, I have to ask you, given the fact that it comes up so often on this podcast, and we’ve already talked a little bit about how learning on computers and how to program, has evolved, and things like that - if you were starting out now, let’s say in that double major, with the intention of becoming a programmer, and having a career in programming, would you actually study Computer Science formally at university, in the current environment? Or would you maybe just use all the resources that are available to be more self-directed?

Josh: The question comes up a lot when I’m in meetups, or meeting people wanting to get into the programming industry, and things like that. I feel like I’m not one of the most equipped to answer.

There are folks that have come up through those other paths more recently, and I really ask them for their advice. But I will give some thoughts right now.

Which is, I don’t feel like a Computer Science degree certainly is essential to get into software development, or to be an excellent software developer. It’s not the main or first thing that I would point people towards.

Now, if someone’s coming out of high school, and has a big interest in programming, and they’re wanting to go to college and do something, because they value that, for a variety of reasons - then Computer Science is what I would direct them towards. There’s a lot of folks that come through Computer Science, even back in the day before code schools and other learning approaches were more common, that said, “Why am I learning all of this theoretical stuff? This isn’t useful. I want to learn how to build this or that.”

Then, after time, a number of folks, ten years later, fifteen years later, realized, “Wow, my software is really fragile, I’m having challenges here. Software design, I’ll do oriented design.” Planning out architecture. That’s actually pretty helpful, whether they make the connection or not, I feel like they end up drawing on or coming back to some of those things that were taught there. Yet, there’s also a lot of practical things, that don’t come up in a Computer Science theoretical focus.

I guess maybe my ultimate answer would be, to really encourage folks to pick and choose the approach that works for them. What is your life circumstances, what is available? If you are a single parent or you’re working multiple jobs, or you have limited access in your environment to technology, just take advantage of the resources you have. Be encouraged that there are a lot of great things out there, and don’t fear that you can’t make it because you’re not getting a degree. But if some of those options - code school, a university course - if that’s appealing to you, and it’s available, I think there is a lot of benefit. That’s my both-and answer.

Len: That’s a really great answer. Of course, the one thing we would add to it, adjust it to what’s available to you, but also, money is the really important thing too, particularly in the United States. But that’s becoming a growing issue elsewhere, of course, as well.

I mentioned we’d connect religion and programming. So, you graduated and you started getting jobs, and you’ve done a couple of stints for North Point Ministries, I believe it’s called, yes?

Josh: That’s right.

Len: Which is a non-denominational, evangelical megachurch organization. I was just wondering - for people listening, we’ve had people who have actually worked for religious organizations on the podcast before. I think a lot of people might be just curious to know, what work is there for programmers to do at big megachurches?

Josh: We get the question a lot, even when I was working there. “You have a web team, more than one person? What?” What it comes down to - I was just talking to someone that I used to work with there, and she was mentioning the scale that happens once you get to a certain size. North Point Ministries, in particular, has, I think, about eight or nine campuses in the Atlanta area,with about 100,000 people between them, attending regularly. They are also working with a network of other churches.

There’s dozens of those around the country, and some around the world, that are separate legal and financial organizations, but share a lot of beliefs, and also strategy, for how to go about church. They partner up and share ideas back and forth, and everything. When you get to that scale, all of a sudden, something that would work as a paper sign up form for a church of 100 people, all of a sudden, it’s like, “Okay, we need this registration form to be online, and it needs to be reliable. We need to not have to manually process credits. That needs to just work.”

Just as the size and quantity of people coming through scale up, if you’re in an organization that is a chirch, a non-profit that is that size, and believes in being that size, and finds that that’s strategic, which there’s different views on - then, yeah, building software internally works.

Interestingly, in being there, we went back and forth over the years in the different times that I have been there, in the “build versus buy” concept, that comes up in a lot of organizations. In terms of, “Do we want to write custom software internally, or do we want to use things off the shelf, and is that a better value?”

Something that’s really unique, I think, even amongst megachurches and North Point, is, they have a high desire of - I’m not saying that others don’t do these - but I think they’re fairly unique - they want to have cohesive standards, as far as doing things with excellence. It’s a big, big focus. Whether it’s the Sunday morning productions, that’s good. But also being welcoming. That people get the information they need.

That’s one of the big things that struck me. It’s not all about the show, it’s about, if you show up as a stranger who doesn’t know anyone there, do you feel welcome? Do you feel informed, and that this was created for you? Or do you feel like you’re looking in on something strange and alien that you don’t know what it is, and you don’t know if you’re really actually allowed to be there? I’m getting distracted from the details, but, there’s a real focus on a very particular way of doing things.

That would lean towards, “Oh, let’s write it ourselves. We want to be able to have the software, the websites, the event registrations, the church database, to do things in a very particular way, that really fits with our model, and how we feel things are best done. But there’s also a very strong focus on stewardship. All this money, is something that people have donated, because they believe in what we’re doing, we don’t want to waste it. That leans towards, “Okay, do we really want to write this custom code? Do we really want to build something?”

They really innovated and thought a lot about, something that is happening in the business world as well, which is, “How can we stitch together these various services? How can we outsource the things that don’t need to be our core business for?” Certainly for payment charging. For tracking members and having people’s information there for event registration, for social media, and things that.

How can we really let another company be the experts in that, and we can be customers of them, and use that to be most cost effective as we provide things? There’s a real tension there, over the years, build versus buy. They’re still learning, they’re still trying to figure out how to do that most effectively.

Len: That leads me onto the next question I wanted to ask you, about a blog post that you wrote, I think, not too long ago, about how to decide between different technologies and how to talk about it with people. Which can be controversial sometimes, and is related to what you were talking about with the imposter syndrome.

I can’t help but bring up, you were reminding me of, I hate to - my Mennonite background doesn’t really want to talk about religion and the military in the same breath. But when you were talking about working for North Point, it reminded me a little bit of a podcast I listened to, not too long ago, I think from the Centre For Strategic International Studies, which was with a very high ranking American general, military general.

He said, “One of the challenges we face is that when people show up, we might not be prepared to meet their expectations.” It’s funny, because you think that the new recruit has all these expectations that the military’s desperate to meet, shouldn’t it be the other way around? But when someone shows up, and they’re like, they need to get their payment set up, “How are you going to pay me?” They’re like, “What? Where’s the app?” The military guy goes, “Actually here’s a triplicate form with a carbon copy background and stuff.” That potential new recruit might just walk right out the door.

Nowadays, if you’re recruiting people, or if you’re trying to get people interested in joining your organization or doing things with you, you really do have to be prepared in one way or another. It is a choice. Your choice for a religious organization could be, “We don’t do any of that. Here you’re free of all that.” Or it might be, “Welcome, we’ve got multiple things you can sign up for, multiple groups you can join. We’ve got meetups,” things like that. It can be a really interesting challenge, for big organizations, in particular.

But anyway, the question I wanted to ask you about, was, your post was called “Disagreeing About Tech Respectfully.” I was wondering if you could talk a little bit about that post - I think you published it in February. What motivated you to write that? It’s a bunch of guidelines for getting through conversations yourself or with others, who might be combative, rather than productive.

Josh: I was really excited about that post, and so I’m happy to talk about it. Because it’s a distillation of things that are becoming more and more significant to me over the last four or six years. Working at Big Nerd Ranch, I think that, in many, many ways, they do this really, really well. But certainly not perfectly. I’ve seen circumstances where it hasn’t happened, that we’ve learned from, and been able to say to me or to someone else, like, “Hey, this is not really living up to our standard of the way we converse about these things.”

Just about the idea that - related to what you were saying before, about the exclusivity of the software world. I mean, it’s a fractal all the way down. “Oh, not just a programmer, but, you use one of those programming languages? That’s a bad language.” I saw a diagram years ago of programming languages, in terms of who looks down on the others. There’s a strict dependency order, maybe with some cycles in there. But I’ve seen something a lot better. Really, what I found, is that the people I respect the most are the people that are able to interact positively. There’s an aspect of it that’s just kindness, in terms of just not being a jerk to other humans.

Which - a lot of people get into software - I shouldn’t say “a lot,” because things are very diverse. But there’s a subset of traditional folks that get into software, because they really don’t want to interact with other people, and they really want to be in a closet and working on code. There’s personal wirings, that is totally fine. But, for a lot of software development, for a majority of places, you are interacting with other people. Certainly on social media. Just wanting to be kind to other people, is one aspect driving this, that I think makes that better.

But there’s a deeper thing that comes from that object thinking book that I mentioned before. I think this is where it really started resonating with me. An idea of uncertainty. That you don’t really know things for sure.

This actually ties to the Agile software development world that my TDD book comes out of, and I’m very influenced by. It’s something that I’ve really come to embrace in a large way.

Another thing that draws some folks to software, is the idea of certainty. It’s ones and zeros, it’s black and white. You tell the computer to do something, and it does it reliably. Unless there’s a network connectivity drop, or cosmic rays, or a user clicks something you don’t expect. The users of software bring uncertainty.

But also business uncertainty. “The requirement is we build the system this way.” But then a month later, “Actually, the business decided we want something else. Not just to be flippant, but maybe the market decided they want something else? Or we all thought about it, and we thought that this way of building something was going to work.” But no matter how much effort we put into it, when you actually get into the code, you find out, “There’s something we missed.” There’s a contradiction there, it’s not going to work out.

The Agile software development world really encourages folks to think in terms of uncertainty. You cannot know the future. You don’t know where your software is going to go, or where the world is going to go. I think in 2022, we can feel that very strongly. Making decisions about how you approach software, in light of that uncertainty.

Back to the blog post, I think that view of uncertainty affects how you see other things as well. The way I think about it now, is, I have certain programming languages that I think are really affective for me. I have certain practices, Agile development and test-driven development, that are really effective for me. But I don’t know another programmer’s circumstance.

Different people’s wiring is different. Test-driven development resonates with some people my wiring, much stronger than others. For me, I just inherently love it. For other people, it’s a chore, it’s a slog. You need to really be in a circumstance where you can get the benefit for it to be worthwhile.

I don’t know someone else’s organizational circumstances. I don’t know other industries, and what the real constraints are, and how things might go. I lean far away from saying, “This is a best practice.” Or, “This is the best way to go.” Or, “This technology’s better than others.” Really to speak for myself. “Here is a benefit that I get. Here’s a benefit that I see.”

Just remembering when I first got to Big Nerd Ranch, and I’d ask about the standards or the best practices, to a person, their response would be, “We stay away from the term ‘standards,’ but for me, here’s what I tend to do, and here’s a benefit that I see.” I think, that sense of really philosophical uncertainty there. Or you could say, “recognizing different contexts.” Even being willing to hold two things in tension that aren’t logically resolved.

You’re a different person, you have a different view on software than me. I can allow that to exist. Some folks struggle with that, with allowing that to exist. I think you really embrace that. You get to a point where you can learn from anyone, where it’s like, “You have an opposite view of me on something. I would love to learn from you, tell me about it.” Not feeling we have to win an argument coming out of it. Not even feeling like, “I might disagree with most of what you say, but I might get an insight on something.” “I’ve learned about something that leads her to choose a certain choice.” Or, “There’s a circumstance that would lead someone to that one, but I don’t have that circumstance. It’s not a problem that I have.”

You learn from those things. I think those are some of the themes behind these specific guidelines of recommendations in there, that me and some of my friends recommended. I just feel software is so much - just human interaction in general, is a lot less stressful, and a lot more productive, when you don’t have to be right, and not everything needs to be black and white.

Len: When you mentioned “in general” there - it’s one of the things that really struck me about your post, is that, I don’t know how deliberate this is, but it doesn’t necessarily need to be specific to discussions of technology, that these rules apply. It could very much be about politics, or it could be about philosophy.

But on another, on a even, I don’t know? Deeper, higher level of - it’s basically making explicit the unwritten rules of an intellection conversation. For example, describing the downsides of your preferred technology, along with the upsides, is one of them.

One thing I really liked here, “represent other viewpoints as fairly as you can.” Probably my favorite one was, “a disagreement with your idea isn’t an opposition to you as a person.” This, I think is something that - there’s a million ways you can divide people up into two kinds of people. There’s two kinds of people with this one. There’s some people for whom, that ability to understand and internalize that we’re talking about the idea, not about ourselves, comes very naturally.

I think there’s other people who don’t have that concept at all. They really think everything is about you and me, our status, and whether we respect each other, and stuff like that. For people with that mindset, a disagreement is an insult.

Do you have any thoughts on that? What to do when you encounter someone who, let’s just say, whatever mood they’re in, it’s not available to them emotionally, to abstract away. How do you deal with disagreements about, let’s say, because it can be in the technology space, right? When someone’s personhood is at stake in what they’re discussing.

Josh: A general thought came to mind. Let me say that, and then I’ll answer your question.

When you were listing out those specific guidelines in there, it struck me, it’s like, “I don’t know that I’m very good at those actually.” Not that I was ever saying that I was great at everything in that document. But those ones in particular, it’s like, “I think I struggle with that sometimes.” It’s not totally obvious to me, that at all times, I am totally separated from my ideas, and it’s totally neutral.

I think an observation I had as I was thinking about that, is, it depends on the relationship. When I have a relationship with someone that is built on trust and positive interactions, and that I know, it gives me a way to interpret what they’re saying as, “They’re discussing an idea. I know they respect me. I know they are kind towards me.” Versus someone that has a track record of being abrasive or curt towards me. Or has even demonstrated that they conflate ideas and people. It’s hard, I tend to get riled up. I think it relates to combining myself with the ideas, and theirs.

The relationships help. I think that does lead into an answer to your question. I guess maybe, now that I think about it, I recognize where the relationship is. I recognize, like, “Okay, this is a person,” You really emphasized their wiring, which is a key part of it. And/or the relationship I have with them at this point, is one where that separation of ideas and people is not clear.

I think in a social environment, or a social media environment, I might - the principle I came to on social media, and I wish I knew, I’m sure someone tweeted it, and so I wish I knew who, so I could credit them, was basically, “If I reply, how likely am I to feel better, versus feel worse?” I’ve had enough bad Twitter experiences, that I just have a feel now for like, “I will feel worse,” in a certain case. Maybe 80% of the time, I’m now able to say, like, “Okay, not going to reply, and that’s okay.”

Now in a work environment, it’s different. You’re working with this person. I find I really need to gather my thoughts. Talking about writing as the topic, journaling, writing out notes, is what I do. “Okay, what’s going on in this circumstance?” That is a way to sense outside of the person and my personal feelings from it. “Okay, they have this thought and they’re approaching the team in this way.”

I make a plan. Not to take them through a script, but to have ideas for what to bring up in a conversation with them, that might be productive, to get us to an understanding.

I find myself more able now than earlier in life, to affirm things from people. “Hey, I see that you really care about this, and I think that’s really great, I do too.” Or, “Thank you for advocating for that on our team.” Really meaning it, being genuine, that’s a big part of that communication as well.

Then taking it down to, like, “When you just talk in this way, when you interact in this way, it’s causing our team challenges. Or, it makes me have trouble knowing how to respond to you. Let’s talk about it.”

A lot of times, people say, “Wow, that’s not what I meant. That’s not how I meant to come across.” Wow, now we have a connection on that. In a work environment, that can be helpful. Or a family environment, an environment you’re going to be with folks a lot. That can be a helpful way. Just to get real in a sense there. I don’t reach for it as quickly as I should, but when I do get a time to do that, it is often beneficial.

Len: Thank you very much for sharing that really thoughtful answer, and also for making the connection to social media, which is the next thing I wanted to talk to you about.

Just to manage that segue a little bit. One of the things I also really liked about your post, is that, it also can serve as a guide to evaluating, not only yourself, but other people, and their trustworthiness, and whether they’re acting in good faith.

It teminds me of the problem of choosing a martial arts teacher, when you’ve never done any martial arts before. How do you know the person’s not a complete sham? You can’t really know until you’ve had some experience, but you’ve still got to dive in and decide.

Choosing who to follow, who to look up to as a thinker, and things that, can often pose the same challenge for people who are trying to get into the world of ideas, for example. Having some guidelines along the way, that are just generically applied, can be good. Not only to apply to yourself, but to see, “Is this person presenting the people they oppose in a charitable or fair light? Are they just giving me the dumbest version of what their opponent might be? Are they trying to activate in me emotions about myself, rather than the idea being discussed? Are they trying to make me feel looked down upon by someone else?” For example.

Well now, all of a sudden, we’re not talking about an idea. Now what’s happening is I’m being pushed around emotionally, to feel looked down upon, maybe to get that reaction elicited from me.

But on that note, you decided, as I mentioned, in the introduction, to leave Twitter. You mentioned just now some bad experiences about replying, and replies, and replies to replies, and stuff like that. Tou’ve got a post about it, which I’ll link to in the transcription. But if you could talk a little bit about that decision? Because I think it’s something all of us who are on Twitter think about from time to time, “Should I do this? How much should I do this? How should I do this? Should I just leave? Would my life be better if I just didn’t do it?” If you could just share your thoughts on Twitter, and specifically your decision to get off of it?

Josh: I have so many. I’m going to try to give one sentence per thought, and keep things moving.

I was an extremely heavy Twitter user, to the point that the last time I left a job at North Point Ministries, one of the feedback I got was, “Maybe don’t be on Twitter so much in the middle of meetings and conversations, Josh?” But I really enjoyed it. I have made so many great connections, and folks that I still stay in touch with over email.

There’s other authors of books that I’ve met, and they’re kind enough to give me thoughts over email now, and everything. That was really great. At the time of using Twitter, I really enjoyed it, over years and years and years. The idea of just having a place to throw thoughts out there, and to assemble like, who has thoughts that are useful and helpful to me, and links and references? That was really, really great and I enjoyed it.

My wife and I have been married for thirteen years now. As we started having children and raising kids - we have three small children - whe was researching the negative effects that screens can have on kids development. It’s like, okay, I always envisioned oh my kids are going to have all the technology, all the video games. She was like, “Well, actually, there’s a lot of downsides. A lot of the Silicon Valley folks severely limit the iPads and phones that their kids have.” “Wow, interesting.” That planted a seed for thinking differently about technology.

Then a few years ago, I watched a documentary called The Social Dilemma that was talking a lot about the downsides of social media, in particular, corporate social media with algorithms. The fact that the business is advertising. They’re using all the data they can for advertising. I would go so strong as to agree with them to say, surveillance, in terms of extracting information that you as a person don’t really want to be providing, and you aren’t being informed that information is being provided and used, and the negative psychological effects that that can have.

That really impacted me. I was like, “Wow.” It got me thinking, like, “What do I think about social media and Twitter and Facebook and things that, and using them?”

Then, January 6th happened in the US. The invasion of the US Capitol, by folks trying to prevent the legitimate results of an election. I’m sure there were some people more devasted by it than me, but I was pretty devasted by it, pretty affected. Some ideals I had about, “Things go smoothly in the United States,” were really disavowed and set aside for me then.

As I thought about what had already been said about the impact of Twitter and other social media, on extremism, not just specific views, but just causing views to become extreme by being in echo chambers - how the incentives, even if all the leaders of those companies wanted and did their hardest to work against that, that the incentives of advertising-based social media drive towards those things, maybe inexorably? I was just like, “You know what? This is not helping.” I decided to get off Twitter. I was privileged enough not to be in a place where I had to be on there for my work.

I would say, back to the point of disagreeing, I don’t judge individuals or companies that are on Twitter. Everybody needs to make the choice for themselves. I would rather for folks to be informed by watching documentaries like The Social Dilemma, and books that they recommend. Be informed about these things, and make your own decision. Because there’s a way to be on there and limit your negative impact on others. But if you feel strongly about it, and you’re able to get off it, it’s something to consider.

I’ve actually found, there is a platform called Mastodon, which is an open source social network, very closely modeled after Twitter. It’s based on something called “activitypub,” which is a protocol that a number of different tools interoperate on.

I’ve actually found that it really scratches my social itch. Because it’s open source, and it’s not monetized by advertising, there’s no advertising. There’s no algorithm affecting the feed. You just follow people, and you just see their posts in order. What I was saying about the appeal of - putting my thoughts out there, finding people and getting their thoughts, I get that as well.

The last thing I’ll say about this, is, now when I look back on Twitter, or when I look over on Twitter and people share things, or they cross post on both, I find there’s just a different feel, that even subconsciously I can just get a gut feel for. “It seems that person’s posting that just to get likes and engagement.” Even just a random, funny, specific interest there, it’s like, it just feels they’re trying to get engagement.

Whereas on Mastodon, it’s super small. You’re not going to get a big business by posting things on Mastodon. When somebody posts something weird, I just have a much stronger confidence, that they’re just into that weird thing, and that gets me excited.

When I post things, I know that it’s just a weird thing, and it gets me excited as well. I’ve found that I really enjoy the dynamics of Mastodon a lot more. But I’m still on LinkedIn and some other big social sites, YouYube, certainly. That’s some of my thought process on making those decisions.

Len: Thanks very much for sharing that very fairly put argument for why it might make sense in some circumstances to get off Twitter, and why some people can’t, and things that. It is, as you say, you used the word, a “dilemma.” It is a genuine dilemma, right? In all kinds of ways.

For example, maybe because a platform is used for all kinds of disinformation, and maybe the fact that the structure and nature of it has disinformation, perpetuation, or propagation built into it? But it might be all the more reason to stay on it.

I’m thinking for example of, there’s the old joke, I forget who came up with it, that Facebook is who you went to high school with, and Twitter is who you wish you went to high school with. I’ve had the experience over the years of seeing some old, literally old high school friends and acquaintances, obviously going down a path towards conspiracy or extremism, and things like that. On occasion, the gentlest nudge from someone they haven’t spoken to for literally thirty years, can actually stop the inertia, and push them back in the other direction.

Because it’s just a voice from the past reminding you, holding up to you a mirror of what you used to be like, and what you are now. It can sometimes really help.

But at the same time, for all those one or two good stories that you see, there’s years and thousands of posts being directed at the person, and coming from them, that can be very damaging in lots of different ways. It is a real dilemma to decide what to do.

In the interests of moving on in the interview, to move onto the next part, where we talk about your book, Outside-In React Development: A TDD Primer.

We’ll talk a little bit later about the importance that books have generally in your life. I know it’s something that you want to talk about - that you took the writing of this book very seriously.

I was wondering if you could talk a little bit about the book’s origin story. At what point did you decide that you wanted to write a book, and that this was the book you wanted to write?

Josh: Big Nerd Ranch, where I’ve been for six years, is really very much tied up in all this. I came to Big Nerd Ranch because I was learning about automated testing for software and test-driven development. I was like, “Wow, this is really helping, and I think it could help even more if I understood it better. This is helping me get from the point of, my software is getting worse and buggier over time, and I’m risking working nights and weekends to keep things running.” To a point where it’s like, “Wow, I can be confident in what I’m delivering, and I can go home and hang out with my family and my friends.”

Automated testing was providing real life change there. But I realize I like working in an organization, and in a program ecosystem, where it was new paths through the jungle to figure out testing. I wanted to work somewhere where the testing paths were well-trod.

Ruby On Rails is definitely one of those. Folks sometimes say about Ruby, “Rubyists write a lot of tests because they have to. Because that’s how flexible the language is. You need tests to give you safety.”

But I joined the Ruby On Rails team at Big Nerd Ranch wanting to learn more about TDD, and I totally did. All the pairing with folks and learning from them, working on projects together with them. Getting references to books that I could learn from from them, and digging into those. It was really, really helpful, where I grew a lot.

A couple of years into that, the industry was shifting, the amount of work that we had to build when Ruby On Rails was decreasing, and there was a real increase in frontend JavaScript frameworks. Vue.js, but especially React.js.

As a business, we needed to shift towards the frontend, and I was up for that. I was interested in that. I did some Vue.js, did some React, learned about it. But even as I was testing the waters before I did the project work in those, I was like, “Cool, I’m interested in learning these rich, frontend JavaScript frameworks, to make these rich user interactions and interfaces in the browser. But if I’m going to be there, I want to do test-driven development, because it’s essential for me.” For me, personally, “If I’m going to be there, I want to be able to do that.” So I was learning from folks, “Who’s writing about test-driven development in React, in Vue, in Ember.js?” or another framework. Learning from them. Trying things out.

Early on, I ended up creating a website called, learntdd.in. This was a place where I was just putting up very simple tutorials on doing test-driven development in a variety of these frameworks, as I was learning different ones, and trying out different ones. Because I wanted that to be available for me. I wanted to learn it. Once I learned it, I wanted to make it available to others, so they could easily get access to it. There was a good encouragement at Big Nerd towards creating content, personal blogging, blogging for the company.

After that I did a few more standalone online sites in different topics, even beyond individual blog posts, but a whole site on a given topic. React native testing. Or JSON:API as a certain data format.

Actually, I was using tools that I find a lot of analogies with Leanpub. VuePress is a name for a documentation tool in the Vue world. Docusaurus is one in the React world.

The level of abstraction that they operate at is really, “Hey, you can customize the themes and the sidebars and navigation and everything. But really, out of the box, they create a good, clean, useful documentation website.” I was like, “Great, that’s what I want to do. I don’t want to theme the website.” There’s a lot of people that are great visual designers, great CCS stylist/developers. I’m like, “This is just information to me. I just want something simple out there to get this information out there to people.” VuePress and Docusaurus have worked great for me in that regard.

Next, what came up was, I found that, in the React world, there were a lot of principles about testing in TDD, that I was having trouble articulating, having trouble getting across to people. There were ways that these principles worked together and built on one another. Or even things, approaches to testing that only made sense within a tester and development context. The way I say it is - don’t take this the wrong way. Others, I don’t want to create imposter syndrome for everyone. But I wrote an online book first, before Leanpub. I wrote an online book about React test-driven development.

Because I had trouble having conversations about it. I really do mean that as a limitation thing. It’s hard for me to talk about these things off the cuff. But it’s easier for me to go put my thoughts together in a blog post. Or in this case, in an online book. That was the most helpful way for me to be able to articulate a strong point that would be useful to other people. That’s what I mean when I say I wrote a book, because I couldn’t have conversations about it. It was an online book at first. It’s just freely available.

Test-driven development is not the most in-demand topic in the world right now. It’s not the biggest thing on Hacker News, at the top of those discussions. But I just wanted to get that information out there. Because I wanted it, and I wanted another thing, and it’s common about the way I think about these things. I wanted to put it out there to be available as an option to people. I didn’t expect that I would become the authority on testing in React or JavaScript for the frontend. But I didn’t see options. Unless people were reading twenty-year-old books about test-driven development, there wasn’t really a good way for them to learn it.

I wanted to take principles I learned in Ruby, that had even come from Java and from Smalltalk, and contextualize them to React, so that people had an easy option to read, and then consider. They could say, “No, that’s not useful to me.” Or, “I’ll keep that as a tool in my tool belt. Every once in a while I’ll reach for it when something’s really hard.” Or maybe they would say, “This is the way I want to approach my React development.” All of those are a win for me. If they’ve gotten to consider the viewpoint, and make their own decision about it. I’ll get briefer in my response here now.

After a few years of this online book being available there, I started to drift towards the idea of self-publishing, or publishing in some form. One reason is, I’d gotten the advice years ago that there’s something about perceived value. If you give something away for free, it’s like, “Cool, okay, I guess I might check it out.” But if you say, “Hey, this is worth $10, $20, $30,” people will say, “Well, okay, let me think about that. You know, I think it is. I’m going to pay that, and I’m going to take it seriously.”

I found myself reading thoroughly through the books that I bought. Things that I got for free, I was having trouble prioritizing, getting back to. I felt it was useful. I felt it was valuable. I actually have ideas for a few other books that I might write in the future.

I decided, as a lean approach, “There’s an easier process. Let me take this content that’s already available online in Markdown, and let me try it out on Leanpub. See what the tooling is like, see what the process is like. See if I enjoy it. See if anyone’s interested.” I had a friend who had also self-published, but he had come through the Big Nerd Ranch books, because Big Nerd Ranch publishes guides on iOS and Android, and various things. He wanted to work on building a book publishing tool chain. For me, I did not want to do that. With VuePress and Docusaurus, I wanted tools where I could bring my content, and I could get a book out the other side. I was so pumped to learn about Leanpub in that regard. That was the right level abstraction for me, at least for right now. That was the draw to the Leanpub tool chain.

Then when it came to the Leanpub storefront and selling on here, I realized that, what I wanted was market, visibility. I wanted people to see this information. That was what was most important to me. Even more than royalties, it was getting it out there. Having Leanpub be a bookstore that people come to on different topics. Having the newsletters that go out to share. I wanted more people to hear about it. That was a great, great value to me.

Now I’m at the stage where I’m working with a friend who’s designing. He’s a professional designer, designing a book cover. There’s a cooler book cover coming soon.

I’m looking forward to taking advantage of the Leanpub features to export to Kindle, KDP, I forget what it stands for, I know you know [It’s Kindle Direct Published - Eds.]. To get print-on-demand books, that was the other helpful thing. Having a friend who’d gone ahead of me. He was like, “Print-on-demand is a thing. There’s no overhead. It’s like, it’s just a couple of bucks out of each copy is billed.” Leanpub equips me with the tools to be able to generate the files in the format they need, which is so great.

I think once the content has settled down a bit more, I’m hoping to put the book out in Apple Books, and on Kindle as an ebook as well. If people are just looking on there, they’re not searching the web in general. But Leanpub will still be my preferred place to send folks. Because I love DRM-free. I love people knowing that they own that ebook. Regardless of if Leanpub goes away - I hope that doesn’t happen -or decides, “Nope, nobody can have Josh’s TDD book anymore,” yoink. Say, “Well, I’ve still got the copy of the book.”

That’s what’s led me here. Given how impactful books have been to me, it really is a huge personal milestone to be a published author. I do say to folks, I feel my parents and my young kids aren’t totally sure I published a book, until that Kindle physical copy shows up. That’ll be a nice milestone as well. But being able to contribute to something permanent. If React is around 10 years from now, people can pull off that book, and they can learn from it. Or maybe some of my future books that I hope to do, that are more on theory. Theories that will still be applicable decades from now in software development. The permanence of that, of sharing something that way, is really motivating to me.

Len: Thanks very much for sharing that great story. There’s so many moving parts there. I’m really looking forward to talking to you about the importance of books in your life, and a specific example of that. Also, the nature of books themselves. What makes an ebook different from a long online document, or something that. Those are really interesting topics.

But before doing that, given that the title of this episode is going to be the title of your book basically, and your name, I didn’t want to move onto all that, without spending a little bit of time talking about what outside-in test-driven development is, for those listening.

I think one thing I wanted to pull out of the great story you told there, was that, I think a lot of people who are listening, who might not be programmers themselves, might be a little bit pleased to hear that programmers sometimes have a hard time explaining themselves to other programmers. Because often people who aren’t programmers have a hard time understanding programmers.

To talk about things at the level of principles, I find it’s often really a fun exercise, as long as it doesn’t come across as patronizing. To try to think of things from the perspective of someone who doesn’t do it or know anything about it.

For example, one thing I think people might know about programming, is that it’s writing. You write, you’re writing things down. But if there’s a typo, for example, imagine a physical paper book that you just couldn’t open if there was one period out of place, that’s the image I to come up with. A program that doesn’t run. It’s instructions to a computer, as you mentioned earlier. You’re writing instructions to that computer. If your instructions are bad, the typical computer will just stop there and your program won’t run. It won’t work.

When I try to explain that to people, with that cartoonish level of explanation, the next thing they often think is, “Well, why would anyone ever run anything that was broken? Why wouldn’t they know that it wasn’t going to run, by having something a test in there, to make sure that it wasn’t going to go?”

Then you have to explain to them, that actually there’s a lot of people who look down on testing. When, from a layperson’s perspective, it might be like, “That’s the most important thing ever. I don’t want my plane falling out of the sky. Definitely if I tap on the app, I want it to open.”

I was wondering, given that perspective, if you could talk a little bit about what an actual test is, why it’s something that a lot of programmers and people who maybe are in management, who are sitting on top of programmers who are trying to produce products and services, sometimes resist introducing testing systematically into the development of their products?

Josh: I’m glad you’re asking me this now, instead of a year ago. Because my views on this have definitely been maturing, reflecting the blog posts of a fair view of others, and things that.

There are real tradeoffs. Testing is something where there’s not black and white. It’s an area where there’s diminishing returns. You could write more and more tests to get more and more confidence. Yet, it would be exponentially slower, and exponentially more expensive to do it. This is something that programs especially struggle with - the fact that there’s tradeoffs. The fact that “it depends.” That the level of testing that you want and require for a pacemaker and for an airplane computer system, is very different from a blog that’s just showing information.

In between, there’s things taking payments online. Okay, well, that needs a certain level of security. Confidentially of personally identifying information and medical records, I guess, maybe even a bigger thing? Tools that protect activists and people that are sharing information that maybe those in various kinds of power do not want them to be doing. Another security that’s needed there.

Really you have to make judgement calls all along there, of like, “What level of confidence do I need, and what level of tests?” Or other ways of assuring correct functioning. There’s other ways, in addition to these automated tests, that developers can write. There’s different ways. You can pull from them in different ways.

To go to what I should’ve said before, of like, what is an automated test? It’s really code that tests your code. Whether it’s at a very low level in code, or whether it’s something that’s simulating what a user does, you’re really writing code that’s - well, think about it this way. You can manually go through, even as a non-technical user, you can test that a website works, test an app works by tapping through it, and seeing if it blows up, or not and if it gives you the right results or not. Or even if it is intuitive or not. That’s another test. Does it look good visually, or not? It’s all ways that you can manually test some software.

Automated tests are ways, of, instead of doing that by hand, or maybe after you’ve done that once by hand? You write software that does it automatically. There’s some things that that’s more amenable to than others. When you have little bits of code that just takes some data in, and sends some data out, it’s pretty easy to write a test to automate that. When you have something that’s testing that the screen stays the same, and you haven’t introduced a visual bug, by making something disappear or be underneath something else, it’s a harder problem. There’s people that are making companies, to make money to do that, by investing the effort to do that better.

Something even harder, is like, “Is the animation smooth?” Is it 60 frames per second? Well, just as a user, you feel it. An especially experienced mobile app developer will say, “Feels like it’s clunky.” But it’s hard for software to detect that.

Then even beyond that, the idea of like, “Does this make sense? Are these words in the software intuitive? Does it make sense to the user that I do this and that I do that?”

Or even things checking if, a credit card was charged, does a paper receipt get spit out there, and does the system,?

I did a contract for a food service place. The ultimate test is, does someone at the drive-through window get the bag with the food? The correct food that they ordered? A full end-to-end test, is testing that the food shows up in the bag. That’s hard to automate. Maybe with Elon Musk’s robots, or something like that, we’ll be able to automate that eventually?

All along there, you’re making judgement calls at each of those levels of testing. Outside-In really talks about those levels, actually. Low-level code and high-level user interface things, which is really only mid-level, compared to, “Does the food show up in the bag?”

But that’s exactly what the book gets at, and that’s what the new book cover’s going to show, is these multiple loops of high-level tests and low, that are stimulating what a user does. Low-level test-checking code inside, and how tests for those can work together in a productive way, in a way that minimizes cost, and maximizes the assurances you get from that.

Len: Speaking of those loops, actually, that’s a great opportunity for me to ask, what is “outside-in test-driven development,” as opposed to “middle-out,” or something like that?

Josh: When test-driven development was first originated, it started as “middle-out,” or sometimes “inside-out,” it’s sometimes called. Talking about building little bits of code. Little small pieces of code, or “modules,” or “classes,” are two technical terms for those. You would write tests to build out those individual pieces. Then you’d assemble them together to build something up. The Lego metaphor works really well there, in terms of like, “I’m building these reusable pieces,” and tests can help you think about, “What is the way to make this reusable, in a way that plugs well with other things?”

One downside to that approach to testing, though, is you can build something that doesn’t end up being used. You can be theorizing, like, “If I just build this Lego piece that’s so cool and looks so great and works just right,” but then it turns out that the project you have doesn’t need that Lego piece. That’s effort that is not necessarily needed.

I keep referencing The Lean Startup, and things like that, which I know you all are knowledgeable about. I actually haven’t read any of the books, I just absorbed it from Twitter and osmosis. But the idea of, you can correct me if this has nothing to do with lean, the idea of like, “What is needed?” then, “Let’s just build the things that are needed to make that happen.” That’s related to outside-in test-driven development.

Where you’re starting with a user feature, you’re starting with a test that says, “As a user, I want to go onto this screen, click this, input that, and then I want to see this as a result.” You write that test first. Then you say, “Cool, okay, what Lego pieces do I need to make that happen? Is that piece already there? Great. Do I need to adjust that Lego piece? Great. Do I need to build a whole new Lego piece? Great.”

So the outside-in is the - the outside test, that’s walking you through just the pieces you need for that feature. What it avoids you doing is spending months and years building out things that aren’t actually what’s needed.

In fact, building out the minimum-sliced, so you can very quickly get to, “Hey, that’s a screen that I can use,” and that’s helpful. I’ve totally applied that on my side projects. The latest project I’ve worked on is building a bookmarking app, to save links for myself, because I love doing that. I got to the point where I was like, “Okay, the minimum is, I need a field where I can paste in the link and it saves it, and then it shows the links in a list.” Cool, it’s actually already useful to me. I’ve got a bunch of other things, as far as marking red and tagging links and viewing them later, and editing the metadata on them. But if I can save links to a list, and I can view them there, that’s enough to be useful for me to get started.

With outside-in, whether your company’s app would actually ship to end users like that - but you’re at least shipping to internal users, and the business internally, you can see, “Hey, I see the links. I see them being added.” That allows me to give feedback on like, “Now that I see that, I think the most important thing to do next is actually not the tagging, let’s do marking the link as red next.”

That’s something that I don’t even get into too much in the book. But by focusing on the user and user visible features, that allows the business and the project managers to steer things, to always be building, “What’s the most useful, most important next small thing to build?” We build that before we go onto anything else.

Len: It’s really interesting the way you bring up the concept of “lean” there. You’re sending my mind off in all sorts of different directions, about how like, basically the same principles can apply in very different dimensions. For example, you know the concept of lean, to keep this very high level, hand-wavy explanation, starts in manufacturing. But then Eric Ries comes out with The Lean Startup, which comes out of, rather than product development concerns, it comes out of customer development concerns.

There, the idea of like, “Don’t build what you don’t need,” operates on the level of like, “What do customers actually want?” Customers, in this case, might be people who you want to sell an app to, for example. They might then have users for it, or something that. But basically, unless you start from the perspective of, “What actually needs to be done here?,” you can end up building things that you don’t need.

From the perspective of programming an app to work, you might actually build little bits of code that have all this functionality, that actually aren’t required to achieve the goal that you need to achieve. But on another level, you might build a whole service that customers don’t want. In that case, you’ve also built something that you don’t need. Just not in the engineering sense, but in the business sense. But the principle applies in the same way, and it can actually be expressed in the same terms, about not building what you need, and getting out of the building, right? Getting outside, seeing things from the outside perspective.

One thing I really like, that you explained very well in the book, is, when you talk about these loops and things that, is the way that, if you start - there’s technical reasons why what - one of the words, one of the terms we’ve used is “frontend.” Why testing on the frontend, with the design, the thing that the customer might interact with in the web browser, or something that - why testing there was much less robust, until recently, at least, than it was for the backend.

Because in the past, this backend, which we might think of like, the program’s sitting on server somewhere running. Then it’s displaying stuff to you in your web browser, but the work is actually being done somewhere else. More and more, that work is being done, as it were, on the frontend, so you can do more robust testing there.

But the idea partly of - you’ll have to read the book to really understand this better than I could ever explain it - but the idea of starting from the outside in, means like, I’m actually using the website, and I click a button, “Does it do what it needs to do,” right? If it doesn’t, then your test has failed. Now what you do, is you make a unit test inside the program, and then you try it from the outside again, and see, “Does that work?” then, instead of just doing it internally, you do it from the outside. The interesting thing about that, is that, the inside can change a lot, but your diagram for the test can say the same.

Josh: Totally, that’s a great explanation. I want to track back to something you were saying about a lean process, as it relates to Leanpub’s whole approach. I love the book that you all put out about the lean process, to educate people on how they can use the platform. It was really helpful to me to learn about the idea of putting out books early, when they’re partially done, to gauge interest, and to direct and steer you to pivot into what your readers want, or what there’s a market for, or an interest for.

Now for my first book, here, the content was done in the online form, before I went to Leanpub. That content, that part of pivoting, didn’t really come into my approach. When I thought about these other books that I’m considering for the future, I was like, “I have a really clear idea of what I want to do. I have the message I want to put out there.” So I wasn’t sure I’d be able to take advantage of that lean approach.

But as I talked to someone at Big Nerd Ranch, and getting input on ideas of, “Well, is your book going to have extended examples or short examples, or none? Is it going to be programming-language specific, or generic?”

Because there’s tradeoffs. If it’s general, a lot more people can read it. But if you don’t have examples, it’s like, “I don’t really follow what’s going on, and how does this work out in the real world?” There’s a lot of questions there. I realized, “If I do write that book, that’s the thing I’ll be pivoting on.” Is putting it out there in a partial form on Leanpub, and seeing if there are any readers, and getting readers input to say, “Is this helpful to have these short examples? Do you want a longer example? Do you want exercises, where I actually ask you to do something and try it, to put this into practice? Am I going into too much detail about a certain topic here?”

You’re like, “No, I understand that. I’ve gotten that from other books. What I’m really curious about is this part you mentioned just in passing, Josh, can you go into more detail on that?” That’s when I realized that even though I have a strong overall message that I’m excited about getting out there for this future book, the details of what it might look could vary a lot. That lean publishing process of getting reader input, is something that I really hope that I do get to write that book soon. Because I love to engage with that part of Leanpub, and with an audience, and to collaborate together on writing something cool.

Len: Normally for the last part of the interview, we go into the weeds and talk about how someone maybe has used Leanpub to publish their book, their writing process, and things that. But you’ve actually already naturally covered all that, by talking about the story of your book and why you wrote it. Which was, how you did it, was connected to “why.” So you’ve actually covered all that naturally enough.

The one thing I’ll add on that, with respect to the weeds, is “KDP” is “Kindle Direct Publishing.” This is Amazon’s self-publishing service that you can use to actually make print books from Leanpub books. Or from anywhere really. But if you write a book using one of our book writing processes, you can just click a button and get the print-ready PDF export that you need, that you can upload to Amazon or any other print on demand service.

But since that’s all been covered then, I wanted to take the opportunity, if you’ve got the energy left, to talk about another version of “in the weeds” about books - why books are so important to you, and what, what makes them distinct from other formats? If you could talk, for example, about a specific book or book you’ve read recently that’s really impacted your thinking. It’s a bit of a funny way to talk about it, but if you could talk specifically about a book on a topic, and how it’s affected your thinking, that might be the most hands-on way in to answering that question about why books are important.

Josh: Totally. That is interesting way to approach the topic, so let me do that. I am very excited about software, and about this Agile world, and so, my example’s going to fall within that. But outside of it, on the fringes of it. That book, Object Thinking by David West, talked about philosophers and philosophies that impact two ways that people think about software. In the Agile world, the Agile side of things, he pointed to an author named Christopher Alexander. Christopher Alexander was an architect. Not a software architect. I don’t remember if he’s still alive or not, I hope he is.

He’s not a software architect, but an architect of buildings. He also published books about architecture. He had a pretty unconventional approach to thinking about architecture, to the point that, a lot of architects, apparently, would say, like, “This guy’s very mystical.” Like, “This is not professional.” They were building buildings, it’s very concrete, I was about to say, it’s literally concrete a lot of the times. “What’s with this spiritualism, this mysticism in here?” Yet, so many of the people that influenced me the most in the Agile world pointed back to Christopher Alexander, that I was like, “I want to read one of his books, I want to check it out.”

The one that I picked up, there’s a few, but in the one that I picked up is called, The Timeless Way Of Building, he’s talking about building buildings, dwellings, “I’m building buildings.” I’m not going to be able to do justice to his approach here. But to get to the spirit of it, and talk about why it’s impactful, and then talk about the medium of it, and how that impacts things. He’s really getting at, instead of a very mechanistic worldview of like, “Hey, we think top down. We’re going to have a village.” Or, “We’re going to have one building.” Or, “We’re going to have a home. We just, well, they all have front entrances, and they go here. Then behind that, usually there’s kitchen, and if not, there’s that, this other room instead.”

Very geometric, very set in stone, I get all these building metaphors, unintentional. But very dry and unfeeling environments. He talks about the idea of these places, especially traditional places, traditional villages, cultures all over the world. It just feels more welcoming. You feel more alive there. He talks about why, and he talks about an approach to, I guess the way I’d summarize it in one sentence is, fitting the, what you were designing and then building in architecture to the use, to the people who actually live there and how they interact, and it be a feedback loop, just we’ve been discussing, where you let the way people actually interact influence what you build.

That, in his view, at a legitimately mystical level, but also a very practical level - he says, “It just leads to places where you feel more alive, and it feels it’s fit more to humans, and it’s for you, instead of being a large concrete thing that’s not for humans. That humans are only there incidentally.”

When I read about that - I’m not an architect, nor do I have any interest in building. We’re on this video call, where I’m almost effectively a closest right now. Spaces, it seems to me, don’t feel too important to me. But that resonated with so much of what I think about software.

Now, talking about the medium of it. This book was published in the 1970s. There’s no digital version of it that I can find anywhere. I’m sure somebody has scanned it, or something that. But it’s really cool to be able to go back to something from sixty years ago, and to be able to have access to it. Something that resonates with me. Something that I’ve seen has influenced that early programmer, that influenced this not so long ago programmer, that has influenced me today. To be able to go back through that history of books to get to something substantial.

Another thing about it, I find, is, something, book-length, it really is a helpful medium, and a helpful challenge. Like, okay, “Well, do I have something that really is a significant amount, takes a significant amount of explanation?” I’m glad to throw out a blog post, but that’s enough to make a point. I’m glad to make a social media post, and that’s enough to make a point, which it often isn’t. But when there’s something that takes some exploration, some illustrating, some explaining, some giving an example of, the length of a book, or the kinds of lengths that books, can be really helpful in that regard.

Now, how about the medium of software, and of the web, which is what I came up through? It’s ironic to me that I would end up writing a book, and even being excited about that print book. Because for a while, and I still am very excited about the web and the impact that it has for sharing information and getting it out there into the world, I was super, super excited about that at various times, in various ways. Why go from an online book, to a print book? Part of it is the perception of value, versus one part, like, “It’s a website, I can get it there.”

Part of it is permanence. I could put a paywall on my website, but then people, they’re paying for access to my website for right now. If it goes away, it goes away. They’re out that money. Whereas, with paper books and with DRM-free ebooks, Leanpub has, you have that permanently. You can get access to it in the future. Well, you can’t resell Leanpub ebooks, please don’t do that. But paper books, you can resell. You can pass them along. I can get Christopher Alexander’s book now, that’s a long time out of print.

The last thing I’ll say that I really like about book formats, and this is so funny, but I’m curious if you, Len, or others, resonate with this - I do not do continuous scrolling for anything long. I like turning pages. I can’t believe that ebook editors have continuous scrolling options. “No, why would I ever want that?” Because what I found from a usability standpoint, just being able to look at a page, “I’m on this page, cool, I’ve done this page.” Flip, I’m onto the next one. The interaction and the cognitive load of that is very low.

Whereas, for anything longer than a blog post, when I’m scrolling continually down the page, it is draining on me, to have to think about, “Have I scrolled far enough? Have I missed any sentences by scrolling too far?” If I’m on a computer that has a sidebar that I can just click once to scroll down a page, but like, “That sidebar is really small. Am I clicking on it, or am I clicking off of it?” So, the experience for me as a reader is just far worse with continuous scrolling. Even certain big tech book publishers that have continuous scrolling for their libraries they make available. It’s like, “I want pagination, I need pagination.” I respect people that are wired differently to me, going back to the blog post. But for me, I would be challenged reading my online book, because - bookmarking as well. Remembering, “How far did I get through the certain chapter?” I’ve got to go delete my bookmark for one chapter, and add a bookmark for another, for my browser bookmarks. Versus Kindle and Apple, and even other concepts to these things, they save your place. The experience of going through a book at length. And all those other things that I just said.

A book is still a thing. I read a lot of ebooks, and I read a lot of paper books. But that’s the thing about it, that I think there’s still a place for it. Alongside the web. I think it’s a “both-and,” and provides new options for folks, rather than an exclusive thing. I don’t think books or even ebooks are going away.

Len: It’s funny, it’s been so long since we’ve actually had a theoretical discussion of the medium on the podcast, that I feel a bit rusty. But thank you very much for talking about it so well.

The one thing I guess I’d add to that, is that my first experience reading long texts online, was Project Gutenberg, clicking on the HTML. Actually just scrolling through the entirety of Jane Austen novels and Dickens novels, and all kinds of other things - just in particular, when I first got into it, it was 19th-century English literature.

I had no problem at all with the scrolling, as opposed to turning pages. I think it was partly because it was just such a magical thing, to be able to not have to pay for it, and not have to go to the library to get it. To just have the text there with me. That was really, really a big deal. When you mentioned the “both-and,” I think that’s just a perfect way of putting it. It’s an irreconcilable, unresolvable thing. But there’s, “Which is better, print or paper?” Or print or ebook?, blah, blah, blah. It’s “both-and.”

Particularly, I’ve got a doctorate in English literature, so I spent a lot of time reading texts, with the intention of potentially quoting them. Having a searchable digital document, where you can copy and paste the quote is way - but if you just imagine the process of like - no one can see it, but imagine you’ve got a print book, and you’re holding it in your lap and you’re reading it. Then you’re like, “I need to quote that line.” What you need to do, you need to crack the spine so it’ll stay open. You need to maybe put weights on it, so you can put it down on your desk. Then you look at the book, and you type a few words. Then you look at your screen to make sure you got it right. Then you look back at the book, and you look at your screen.

Working with text for research purposes, as it were - a single page, searchable page, where you can copy and paste from it, is just an amazing improvement over paper and flipping and stuff that. Particularly, I’ve - my brother is 100% on your side, particularly with respect to - he’s an English professor. Particularly with respect to remembering where something was in a book. He’s like, “I know it was two thirds of the way in,” right? Or something that, right? I mean, you could do it with a scroll bar or something like that, but it’s just not the same.

But my counterpoint is, I could “command F,” that’s better for me for finding things, than remembering where it was in the book. That’s my perspective on it. I don’t feel any loss from not having the page thing. But I completely get why that actually is a very big difference between one experience of reading or another.

Josh: For me, it’s literally a “both-and,” in terms of books that I like. I have young kids, and so a lot of times, especially when they’re really little, walking them around, rocking them to get them to sleep, and I’m reading something on my phone - that’s when I leaned heavy towards ebooks, even for technical things. It’s like, “Okay, I can’t process this code sample now. I’ll do that later. But I’m at least getting the high-level principles in this ebook.”

But now I’m going back, and a lot of books most directly behind me on the shelf here, are ones that are so meaningful to me from reading, and ebooks, the ones that I reference all the time, I want a physical copy. I want it, a), so that I can reference it easily physically, and b), so when I’m on a Zoom call or on a live stream, I can show it and be like, “This is the book I’m recommending, check it out.” But also just to make sure that I have it.

Also, I don’t know if that money goes directly to the author. But just a show of support in some way. One of the most meaningful books to me, the ones I’m going to go back to every year multiple times a year, I’ll buy a physical copy of, in addition to the digital copy, so “both-and.”

Len: I always promise to end on the weeds, but to end on a very specific note, when it comes to having print copies of your book - if you’re a consultant or something that, or if you speak at conferences and stuff that, actually having a print copy there for people to buy, and to show support directly for you that way, to have proof, it really makes a big difference to people. That’s one of the reasons that we have our print-ready PDF output code. Because it is so - even though we don’t produce print books ourselves, it is so important.

Well, I think we’ve almost reached feature length in our interview here, Josh, but thank you for being so game to cover so much ground, and thank you very much for being on the podcast, and for being a Leanpub author.

Josh: I just enjoyed my experience working with Leanpub so much. Listeners, please check it out if you haven’t, if you have any inclinations of writing a book. There’s so many options. You don’t need to be a programmer, for sure, to write. I mean there’s multiple ways to publish and set up books and stuff like that, but I’ve just had so much fun. If you’ve every had the idea, “maybe I’d write a book,” the whole point of Leanpub is to make it easy to dip your toes in. Len didn’t pay me or force me to say this, it’s just how I feel. That’s why I’m so excited to be here, to be a part of the Leanpub author community. Len, to get to connect with you, and to meet you, and see some of our shared passions together today. Thanks so much for having me on. I hope we individually stay in touch from here.

Len: Thanks.

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