A Leanpub Frontmatter Podcast Interview with Chris Hartjes, Author of Building Test Driven Developers

Chris Hartjes is the author of the Leanpub book Building Test-Driven Developers. In this interview, Leanpub co-founder Len Epp talks with Chris about his current work at Mozilla, the importance of design and getting out of your socioeconomic and other bubbles, the Magic: The Gathering meta game as a metaphor for great software testing, his book, and at the end, they talk a little bit about his marketing experience as a self-published author.

This interview was recorded on May 30, 2017.

The full audio for the interview is here. You can subscribe to the Frontmatter podcast in iTunes or add the podcast URL directly.

This interview has been edited for conciseness and clarity.

A Note About the Leanpub Frontmatter Podcast

This summer we split the old Leanpub podcast into two distinct podcasts:

Frontmatter, which is a general interest podcast where you can listen to Leanpub authors talk with Leanpub co-founder Len Epp about their books and their areas of expertise, from data science to molecular biology, to the history of labor and management. And for those interested in the nitty-gritty of what it takes to be a successful self-published author, at the end of each episode Len asks the author about how they made their book and how they are spreading the word, and other publishing shop talk.

Backmatter, a new podcast focused specifically on the publishing industry and its latest trends. In each episode Len interviews a professional from the publishing world about their background and their insider’s perspective on what’s happening in the huge and evolving world of book publishing.

Len: Hi, I’m Len Epp from Leanpub, and in this podcast I’ll be interviewing Chris Hartjes.

Based in Milton, in the Canadian province of Ontario, Chris is a Senior Quality Engineer from Mozilla, and he tweets and writes under the identity of “The Grumpy Programmer.” You can check out his website at grumpy-learning.com, read his blog at littleheart.net, listen to his podcast at devhell.info, and you can follow Chris on Twitter @grmpyprogrammer, just remember to not include the “u.”

Chris is the author of a number of Leanpub books, the latest two of which are *Minimum Viable Tests and Building Test-Driven Developers.

In this interview, we’re going to talk about Chris’ professional interests, his books, and at the end, we’ll talk a little bit about Leanpub shop, if there’s anything left to talk about after all this time.

I should mention that this is actually the first time I’ve interviewed someone for the second time for the Leanpub Podcast. Chris has been around for years writing great books, and making great content, and we really appreciate him being a Leanpub author.

So, thank you Chris for being on the Leanpub podcast.

Chris: Thanks for having me, Len. I know we were talking about this in email before, but yeah, four years ago we first talked. And boy, has it been a very strange journey that entire time.

Len: I’d like to talk to you a little bit about that. Normally l start these interviews by asking people for their origin story, but we’ve already gone through that probably 4 years ago, so maybe we could talk a little bit about what’s happened since then? I know you’ve moved on to Mozilla.

Chris: Maybe a year and a half ago, the opportunity came up to take a job at Mozilla. The title of the team keeps changing, but these days Firefox Test Engineering is the group that I’m with. We’re the group responsible for testing just about everything to do with Firefox, the browser itself, any properties that maintains, and the services that the browser talks to. That’s my focus at Mozilla.

I work with pretty small [team] and all I do all day long is fool around with fun — creating specialised testing tools, mainly with PI test, just to make sure that the services that your browser talks to are working correctly. It’s a very different environment, where the stuff that you’re working on — literally millions of people are going to be relying on the thing to work correctly. It’s a very, very different feeling from previous places I’ve worked.

Len: I wanted to ask you a little bit about that. I was speaking to someone not all that long ago who works for a very big and famous software company, and he talked about how they had recently merged the development and testing teams. It was a big decision. I was wondering if you could talk a little bit about what the environment is like at Mozilla, where — as you say — millions of people are going to be touched by everything that you do. Are testing and development separate? Are they combined in some way?

Chris: I would say probably the best way to describe it is that the QA people are embedded with the developers. I work very, very closely with the developers for all the projects that I’m doing QA work for. As a long-time developer myself, I mean, it’s — I couldn’t believe this when I started sitting down and thinking about this. This is my 20th year of doing software development. I’ve been doing this for a really super long time. And the first 18 were just as a developer, doing mostly PHP stuff.

And I have found that that experience as a developer has really, really helped when it came time to talk to the developers for the various services, and say, “Hey, I want to know what you guys are working on.” Most of the time I’m testing API, and I can talk to them about stuff like, “We need some hooks in there, so I can automate things a lot easier. What features are you working on? Are there new things I should be adding to the test plan?”

So yes, I work very, very closely with the developers. I would like to think I have a really good relationship with the developers. Very few of them I’ve come into conflict with. And most of them are just happy that the QA people even seem to care about what they’re doing, because there’s always been that perception that it’s always QA versus development. QA’s job only ever seems to be finding the mistakes of the development team. I can certainly sympathise with the developers who feel that way. At the same time, the QA people are thinking that the developers don’t care, and are expecting the QA people to find all the bugs in a product.

That hasn’t been my experience with the people in Mozilla. It’s been quite refreshing — an interesting shift. I was looking at my GitHub contributions the other day, because I was just wondering what’s going on with that. And I found that even though I’m doing QA work, the pace of my contributions on GitHub — because everything I do in Mozilla is open source and available for anyone to see, which, again, is a very, very different way of working — in the past year I’ve done like 470 contributions, comments and stuff on GitHub. Which is crazy, more than one per calendar day. So I still will get to keep those development skills going. Because I do lizard, I do a lot of Python stuff, and so I am constantly writing scripts and creating tools and doing stuff like that.

Len: I wanted to talk to you a little bit about your experience with changes in software development practices in the last few years. Four years is a long time in the tech world. On this podcast, I’ve had the pleasure of interviewing people who engage in software development in lots of different ways. Twice the metaphor of software testing, security testing and QA being like a martial art has come up.

There’s something interesting to me about the adversarial nature that people can fall into, that you were just invoking. Is that something that you think that has evolved in a positive way in the last few years? Are managers less likely to just sort of stick two teams on each other, or things like that?

Chris: I think it’s definitely changed for the positive. If we go back even more than four years, when I first discovered unit testing and all the skills and tools that I was going to have to figure out how to learn in order to just make that stuff work, I’ve gone from — at conferences — where I would ask people, “How many of you are writing tests from your code?” At the beginning, 10 years ago it used to be just a few people raising their hands. And now most places upwards of 50% of the developers I talk to have written at least one test. I think it’s almost like there’s been a tipping point.

There comes a point where the tools are widely available, the skills and practices at a base level are widely known. So it literally comes down to now where people are choosing not to use these tools. Instead of whereas, they used to be difficult to use. There was very few people who were going around telling people about them, and showing them how to use them. And so as more and more people have adopted these tools, that adversarial thing I talked about — it’s started to shift and go away. Just because the nature of software development now is that, for a person like me who was a server-side developer for so many years, the toolkit that you need to master — just to build a web app these days, is just ridiculous. It’s not only a server side scripting language, but you have to worry about JavaScript code and CSS and well, from HTML. And then all the tools that go along with using those — asset compression tools like Gulp and webpack and all sorts of stuff that just keeps popping up to try to solve a problem that people are having. So at the same time, people’s responsibilities are going up as well. It’s very rare that you get a developer that works on something, and they have no responsibility to test what they’re doing at all.

I think as people started using these testing tools, and writing their own tests and getting out of the habit of save and refresh the browser being their main way to test, they’ve got an appreciation of everything that goes into it. I think that’s made dealing with QA people a lot less adversarial, because people finally understand, “Okay, I can write code that has fewer bugs. There are tools that support me.” But at the same time, the QA people — we’re actually here to help. I mean, it doesn’t do me any good to be difficult with the developers that I’m working with.

To create that adversarial relationship, that benefits nobody. Maybe at some organisations, they have a long history of that, where the developers are literally throwing stuff over the wall to be tested. But that seems to be happening less and less frequently. And it’s definitely for the better.

These days, the tools are so easy to install, and to learn the basics is very easy. So there’s more reason that a developer — a halfway competent developer can’t learn those testing skills and get a better appreciation for how much work can actually go into making sure that application is meeting all the business needs, and the user’s needs.

And we can just kinda get away from sloppiness and laziness, understanding the goal is to deliver value. This extra time we’re spending fixing bugs that we could’ve caught, is actually having real costs. It costs companies money in terms of overtime and burnt out developers, and all sorts of other kind of personal things that people — I find anyway — never really think about.

Len: I was going to ask you about that. In your latest book, Building Test-Driven Developers, you talk about the two major forces that work against developing a test-driven culture. I think you talked about how the first one is being, simply, learning — has been mitigated or improved by the development of tools an better knowledge. But the second one, which you just touched on is: “The work culture pressure that says you don’t have time to write tests.”

Where say, a manager might be driven to hit a deadline. And so in their world, testing is a waste of time. Or they want to do as little testing as they can. Not speaking about necessarily your personal experience, where you work — but in general, do you see that when you talk to people? Do you see that work culture changing?

Chris: Yes. But it’s ironic. As the tools become more generally available, in many ways software development has become more of a like a start-up driven thing than support for the business idea. There are lots and lots of people under serious time pressures. And that’s the one big discovery I had, even before I did the latest book. Because I had been wanting to find ways to talk about that. I’ve spent more than enough time talking about, “Here’s how you use this testing framework, and here’s how you create test doubles,” and teaching people the common pattern of — arrange, act, assert. All that technical side of testing.

But where people need the most help now, is the personal guide. Because you’re right, we talked about this — the pressure. A lot of managers, they look at this and go, “This testing is extra time, and it’s taken up time from things I want the team to be doing instead.” But at the same time, you have to understand that every bug that somehow makes it out of your development environment — and for your users to see — there’s real costs to getting that bug fixed.

And sometimesthere are really quick things. It’s a syntax error, or the data wasn’t what you expected. But sometimes they can be catastrophic. They can be things like — you accidentally deleted the database that contains all your users’ information. Or you leave a big, huge, gaping security hole in your application. That’s the part I think most people are still having a really hard time wrapping their brain around.

And it’s even worse for managers. Especially for people that — maybe they’ve never done development work. Or when they used to do development work, these tools didn’t exist. Or if they did exist, they were really difficult to use. So you discounted them. And there is always this pressure — go faster, get more done. But I’ve seen time and time again where this constant drive, “Keep moving forward, new features. We don’t have time to test, let’s just get this done. Everybody’s got to stay late.” I’ve been through all those, and I’ve seen how it just demoralises teams and costs companies way more money and time than they realise.

Len: That’s really interesting to me, because one would expect that the interests of, say, not just the managers, but also the executives above them — their interests would all be aligned towards producing the best product that causes the fewest problems once it’s deployed — is as effective as it can be at generating profit. And yet, somehow there’s this strange disconnect that one sees, time and time again.

An example that’s come up on this podcast quite a few times is HealthCare.gov in the States, where there was this huge effort — people’s bodies were affected by it, their lives, their pocketbooks, and it was of huge political significance and consequence — and yet somehow it was a total disaster. I think a lot of people wonder how it is that, say, an executive in charge of an effort like that, won’t just sit down and use it. How do they end up being in charge of something that?

What is it about that culture that means — well, for example, we still have people who think of programmers as 400 pound guys in their mum’s basement, as someone famously said recently in the United States. I know it’s the sort of view from 30,000 feet, but do you see that culture, that executive culture changing generally? Or is that staying the same? Do you think people are coming out of their MBA programs with more respect for the computer person now than they had in the past?

Chris: My honest opinion is no. I think it’s still pretty much the same.

There’s this tendency that I’ve seen in people — and this is not just computer people, but this is people in general — a lot of people have a very hard time with empathy and with looking at things from a different person’s point of view, or the ability to like adopt a different mindset and understanding that there is a difference between the person signing the cheques and the person that’s managing the developers, and the developers, and the people that have to use this thing that you’re asking people to build.

People forget that not everyone else is like them. So, the things that motivate them are not necessarily things that motivate other people, or even the user of this thing you’re trying to build. You talk about healthcare.gov. I mean luckily, it sure looks like, after the initial launch, somebody grabbed hold of the reins and said, “Look, we can fix this. There’s a better way. We need to get this fixed.” It sure sounds like they brought some people in, and saved what was clearly a disastrous launch.

But this is a problem too. There’s all this arrogance, combined with lack of domain knowledge that just causes weird things like this to happen. You mention the MBAas. Well, I don’t hate businesspeople. I understand the role of businesspeople. I don’t hate marketing people. I’ve become a marketer myself in the process of writing my books. But at the same time, there’s this ridiculous amount of arrogance of people that think, because they’ve studied a bunch of business stuff at university, they can go and solve any problem by applying what they learned at university.

If you don’t understand the problem you’re actually trying to solve, you’re in for a world of hurt when the software project goes on. If you look at healthcare.gov, the overarching goal of that should’ve been: we need to find a way to sign up the most number of people possible who are looking to get health insurance in the US. That should’ve been the overarching goal. Nothing else should’ve deviated from that goal. We need this thing to work and be rock solid, and accomplish the goal of allowing people to easily sign up to get health insurance. Anything else is not going to lead to success.

I still see, in my informal discussions with both my peers and people that ask me questions about stuff, it’s still there. Often the people who are in charge of the developers don’t understand the problem you’re actually trying to solve. They’re there for all sorts of reasons. They could be the founder of the company. They have the idea. They don’t understand why it’s so hard to implement it. It could be former developers who maybe weren’t so good at the development part, and so a better path for them was to manage people. So they bring all their own weird prejudices and misunderstandings about software development — like anybody has — into a management position.

It’s never one thing that causes these failures. It’s a combination of developers who resent the people giving them the orders, then the people who are giving the orders not understanding the problem they’re trying to solve. And then the people who are telling the managers what to do — looking at it and going, “I don’t understand, this seems so simple. Why can’t we make this work?”

Because as my latest book talks about, the biggest problem in software, it’s really not deciding what language to use, and what other technologies. It’s people, because it’s people who are building these things. And people are infallible, and people make mistakes. And people have all these weird, unconscious reactions to things. It causes such weirdness in software development in general. And why I think, [although] the tools are getting better and we can create more things faster, there’s still this problem of managing and understanding people. And that’s the part that, at this point, I’m trying to help people with.

Len: It’s really interesting you bring up empathy and the people side of things, and weirdness.

You reminded me — I was doing some research a while ago, and had to watch a — an annual conference by a big company. And the executives who were on stage, were very pleased with themselves, and trotted out with, I would say, contempt for the engineers. It was very clear it was staged st that the engineers weren’t allowed to wear suits like the executives were. They were sort of dressed up to look like an engineer — according to some stereotype.

It was just very odd to witness the theatre of contempt that was being played out. I mean, here you are running a tech company. Everything you do comes down to the things that the people build. And yet somehow, there was internally this very familiar, but nonetheless weird culture, where it needed to be really hammered home that there was a distinction between the people running the business side of things, and the people doing the — let’s call it, the labour.

Chris: This is just a weird people thing. Generally speaking, I’m not a big fan of the venture capitalism and the Silicon Valley mindset, and just throwing lots of money at problems. And we’re talking about things like — we want to create self-driving cars, when there’s ways we can make existing cars safer. And we’re talking about terraforming Mars — when we should be looking at how can we make Earth more liveable? It’s just this weird combination of opportunities for people to have their strengths greatly amplified, and their weaknesses totally ignored. In the pursuit of money.

I’ve told people — if you’re a severe introvert, but you’re good at computers — and so you think that a career in software development is going to be good, well you’re going to be really disappointed. Because to get anything of any significance done in your career, you’re going to have to deal with people and talk to people. There are very few places left, I would imagine in North America, where the autistic/Asperger computer genius who nobody can talk to, who sits in a cubicle somewhere with their headphones on, and cranks out all this beautiful code, and everything just works all the time — without interacting with anybody else. That’s the most ridiculous myth I could think of to tell people — stereotypes. No, you’re never going to get a chance to be that person. You’re writing code. You’re a person writing code for other people to solve problems, and you’re going to have to talk to people.

But then again, you get thi corporate-driven culture. I don’t know if MBAs have something to do with this. But the idea of that the suits are in charge, to use a nice pejorative comment, and then that the engineers are just resources to get stuff done — you’re starting to dehumanise people. And believe me, people know when you’re doing it to them, and then they’re going to get resentful of the people who are in charge.

Then you end up with this weird thing where the developers are contemptuous of the people asking them to do stuff. And then, at the same time, they start hating the people that are using their products. If you don’t think that people at Google or Facebook like have developed this weird contempt for the people that use their tools — because maybe they’re not using them in the way that they think they should use them — I mean, you haven’t been paying attention to anything. Talk to your peers. I hear lots of stories about people who are resentful about the people who use this thing. And then I remind them — those people don’t use that thing, your paycheque doesn’t show up.

The focus on money and big moonshots, and we’re doing these weird things, because “I want to disrupt and save the world,” when there’s so many things that programmers could help to make just regular people’s lives a little bit better, by improving a lot of terrible systems for them. It just gets lost in this whole contempt culture, where the techies think they’re better than the executives, who think they’re better than the techies. It’s just this weird cyclone of despair, and people get sucked into it. And pretty soon you’re in this bubble, where everyone else is like you. And then the goal just becomes, “I want to make as much money as I quickly can, and I’m not worried about the consequences of the things that I’m doing.”

Len: There’s contempt coming from many sides in this type of activity. That’s a really interesting topic that I like to think about quite a bit, which is, user contempt. Especially if you are using, say, Gmail. For example, one thing that their designers have decided to do is to hide information from you. So if you type in the “to” email address, it then hides the email address, and shows you the person’s name. And then if you select your “from” email address, and then you go to write, it actually completely hides the email address that you’re sending from.

This kind of thing it might sound trivial. But if you’ve ever had a job where you could go to jail for disclosing information to people that you were’t supposed to disclose — hiding that stuff is just really punishing the user. And yet I’ve heard this from different designers, saying things like, “Well, but I don’t want to look at that. I don’t want to look at that email address. I know what email address I typed in. What kind of idiot wouldn’t know what they just typed in?”

I guess I wanted to ask you your opinion — is there an explanation for where that comes from? That, “I understand what you’re saying, but I wouldn’t want to look at that, and I wouldn’t want to use it that way. So I’m just going to design it and dump it on humanity based on my personal preference.”

Chris: If we’re going to be honest about it, it’s really about arrogance and thinking that — maybe that weird kind of paternalistic view, like, “I know better than you. And so because I am the domain expert, because I’m the designer and I’ve built bazillion interfaces — if you don’t like what I’m doing, well the problem’s not with me, the problem is with you.” So this is how we end up with poorly thought out interfaces.

And this idea — “Why is this information being hidden from me? If I’m typing an email address, maybe I want to make sure?” What if I know — I mean this is certain in this day and age — it is certainly not strange for one person to have multiple email addresses. Well, how am I going to make sure I’m sending this to the right person’s email?”

I have a work email, I have an email address for my side business for Grumpy Learning. I have that old, ancient email address for littlehaart.net, which is a domain that I’ve owned since 1998. If someone wants to send me one, okay sure — I eventually read them all. But what if I need to send an email to a person’s very specific address? Maybe they have a secret email address? They’re like, “Please only send responses here”

It’s this idea — it’s very easy when you work in this industry, and only interact with people who are doing the same jobs as you. You forget that everyone’s not like you. So you get these weird interface decisions. One of the more interesting and frustrating things is to watch non-technical people, like my wife, or my mother, or even my kids, who don’t share the same love of computer stuff as I do — watching them interact with the same systems that I use every day, and watching how different their experience is. The way that they’ve chosen to do things. Often it’s very, very different from how I’ve chosen to use it. A few times I’ve wanted to grab a device out of their hand, and go, “No, do this. You click here and press here and press here and press here.”

But my experiences are so different, and I’ve learned to not tolerate a lot of the nonsense that I see. Whereas so many people are just like, “I guess this is just the way it is.” I see people’s solutions to problems are these crazy workarounds. I’m like, “It would be way easier if you would just tell the person that this thing isn’t working. And they they will probably fix it for you.”

The bubbles are the biggest problem in the tech industry, when you work especially in a culture where you’re spending a lot of your hours at your job, and you’re only ever hanging out with people who [are] maybe same race as you, the same socio-economic status as you, they’re doing the same work, spending all these hours with them, not just during your work hours, but outside of work. It’s very easy to get caught in that little bubble that everyone around you is expecting the same things. I think that [?] has been really, really lost. As software is busy eating so many parts of our society, that people aren’t understanding that you shouldn’t be creating interfaces for yourself, you should be creating interfaces for people that know nothing. And they have to be able to instantly figure out what it is that you want.

Even me, seasoned tech guy, the first time I saw the kiosk at McDonald’s — because a lot of McDonald’s around where I am are getting rid of a lot of the cash registers, and you have kiosks that you can order from with touchscreens. Even those aren’t as clear as they could be. They’re getting better, because I do notice subtle changes when I go back. But it’s the same type of thing. You built a system that you like, but there’s no guarantee that the people who actually have to use it are going to like it.

Len: It’s really interesting that you brought up socioeconomic status, and all the other kinds of bubbles that one can be in, and the way that one can lose sensitivity.

This is I guess a bit in the weeds of design, but one thing I’ve noticed with a certain payment processor is that it began serving up circle faces and names automatically to me when I was making payments. Of course, a circle face and a name are not the same thing as an email address to which something is being sent. And information was starting to be hidden, like actually how much you were sending. Actually where it was going. When you completed the transaction, you just saw a check mark or something — rather than the transaction details.

It struck me when I encountered this that everybody working on this who has any authority about what gets deployed in the end — none of them has ever been in a situation where if they made a mistake sending that 50 bucks, grandma wasn’t going to be able to get her bus ticket to come visit for Christmas. There was no sensitivity to how catastrophic it can be for someone to make what might — to someone who’s say sailed through computer science and got a job — no sensitivity to those little… it seems like little things. But as you were saying about — when you’re working for certain types of products, it can be millions and millions and millions of people that can be affected by these things. Especially where money and communications are concerned. People can often not have that kind of sensitivity, because it just doesn’t correspond to their personal experience.

Chris: Len I’m sure you’ve heard that thing where people have talked about so many of these start-ups and other things are solving the problems of our rich, white twenty-somethings who are living away from home for the first time. So they’rereinventing [?] all these services that were doing things that their parents might have done for them.

This is why you have all the food delivery places and laundry services and Uber. So someone can drive you around. And all these other things, this whole eco-system that gets created where people like creating services for themselves. I always feel there’s friction between the idea of — create something to solve a problem for yourself, or something to scratch an itch. But at the same time, it’s like people have this fantasy idea that, “Oh I’m solving this problem.” And then millions of other people are going to want this solution in the same way.

I think so much of this is because I missed out on one of the first tech bubbles when I got out of college, and I’ve never really worked for one of the big Silicon Valley types. Mozilla’s a very, very weird place, in that it’s a non-profit. So our motivations are much, much different than somebody like Google or somebody like Facebook. I never worked in that culture. I never got opportunity to do it.

Because early on, the thing that mattered to me was work/life balance, and working from home, because I felt it was better for my family to be home. So I missed out on getting immersed into that whole thing that we’ve been talking about. The bubble, the long hours, you’re constantly surrounded by people just like yourself, and pretty soon you’re all thinking the same. And then you end up just solving problems for your small group of friends, instead of big-time problems that benefit people outside of your little immediate circle.

This is the thing I wish developers — somehow we can make this easy for people. It’s like, “How about we solve like real problems for people? Like problems that people who aren’t lucky enough to have a $3,500 laptop, and a nice six-figure-paying job, where we’re solving, in some cases, very trivial problems for very little gain. Whereas, there’s so many ways that we could be helping people out there.

Even things like — to ramble a little bit — let’s take a look at something like, for example the tragedy that happened in Flint, Michigan, with their water system getting compromised, because somebody made a monetary decision, “Let’s temporarily switch over, flowing the water through this different set of pipes.” And then the pipes turned out to be contaminated with high levels of lead. And for like almost three years, there have been lots of people who don’t have safe drinking water. They’ve been drinking bottled water and bathing with bottled water, and doing all these things.

There’s so many things that people could’ve done to help these people get organised, once there was a way to help them. People could’ve been helping to create tools to track which houses are experiencing problems with the water. Who needs their plumbing fixed? Who’s behind on their water bills, and now nobody’s offering to fix anything for them until their water bills get paid?

People want to joke about social justice warriors, and people wanting to turn around and give stuff back. That’s the thing that’s still really, really missing in my opinion. An unwillingness of people in the tech industry with money and resources to help somebody other than a really narrow group of people. And that creates resentment. You have all these people that look — probably look at people like me, and think that I have a useless job and I’m not doing anything important.

And that’s opinion, and we’ve got to be careful to not substitute opinion for fact. But at the end of the day, the thing I work on is used by millions and millions of people. And the stuff that I do is used by people who are not like me, and I’m helping provide them value by making sure the things that they need to work on, that they work and they work correctly, and things aren’t behaving unexpectedly.

I don’t think you can discount the feeling that you can get when you’re actually solving problems for people other than people who look just like you. This bubble and lack of empathy is really starting to grind the tech industry down. And I think most people in the tech industry aren’t even aware that it’s a problem.

Len: As you mentioned earlier with Marc Andreessen’s phrase “software is eating the world” — ne thing I think that people might be coming to understand more and more is just how much the way software is made, and the decisions that are made when it’s made, affect so much of life. The way things are shipped from one place to another. The way things are designed, including physical things, are designed in the first place. The decisions about how software are built go all the way down, and people who might not use computers, might not know how much the culture around software development actually makes a big difference.

Chris: I think the average person may have a vague understanding of how much the world around them and all the things they interact with — how much of it is software? Most people, in North America anyway — the penetration of smartphones is ridiculously high. So people are walking around with computers in their pockets all the time. Cars these days are essentially computers on wheels. All these automated systems — phone systems, the banking system — I mean I can go on and on and talk for hours about this. But people don’t understand.

You’re right. There’s all this software, and most of the people interacting with it had no say in how any of these things got built, and how it was decided who was going to do what. You’re at the mercy of a system that you have no ability to impact or change. If then some automated system glitches, and decides that you owe the bank 20 grand for something, when you don’t owe them anything — digging yourself out of that, unless you’re in a really good socio-economic position, it could wreck you. It could wreck you permanently. Wreck you — affect your life in a way that you never thought was possible.

As more and more things shift over from people being behind them, to some faceless algorithm that somebody wrote — a lot of developers are wiping their hands of it saying, “Oh no, that’s the system that decided you were to be randomly screened for something.” Or, “It was the system that spit out something saying that you owe us money, or you were late on your taxes.” Or, “It cost our company $10 to send you a bill that says you owe us a penny.” I mean these decisions, they all keep piling up. And we end up with these systems where -

I tell people, “What’s it going to be like when you go to a restaurant, and there’s not actually a person there?” You’re trying to order food, or if you’re trying to do something, when these automated systems that we are going to be rushing headlong towards building — what happens when they go wrong, and there’s no person there that can help you, can say, “Oh, this is the system’s fault, and we’re going to get it fixed.” When there’s nobody around to help you, this is going to be even worse.

There’s the idea of the customer service person, the surly person behind the counter, who doesn’t really care about your problem, and is just there because they’re working a job. That’s even going to be worse when there’s actually nobody with any emotion who’s responsible for what’s happened to you — pay cheques being held when they’re not supposed to be. Identity theft. I mean, there’s all these things that automated systems — the pain of them are amplified by systems where there’s no people involved, and the people can’t stop them from doing the wrong thing.

Len: It’s really interesting when you talk about the consequences. I’m going to go onto the subject of your books, and your particular subject of testing.

Just recently, I think all British Airways flights at Heathrow were cancelled for a day or longer. When you think about the incredible amount of personal and economic disruption that can cause, it really brings home the importance of something that otherwise might sound boring, like testing. But actually it’s crucial. It’s as crucial as the doctor or the surgeon washing their hands properly before going in there.

I wanted to ask you — as you would of course say, testing can actually be really interesting, and I wanted to ask you, in Minimum Viable Tests, you talk about how much you enjoy, Magic: The Gathering, and you talk about the meta game that the true pros can use to help win tournaments. And then you use that as a metaphor for an approach that one can take to testing. I was wondering if you could talk a little bit to people about the Magic meta game, and how it can apply to quality assurance, and things like that?

Chris: The idea o meta testing, being this idea — so a quick refresher, and hopefully people don’t fall asleep while I talk about the most infuriating hobby possible. So we look at Magic: The Gathering, which on the surface is a children’s card game, where some of the cards can cost thousands of dollars to buy on the secondary market.

This game has a set of rules about how you play the game, right? So the game itself, which consists of, usually people playing each other one-on-one, and there’s a bunch of rules that govern all the interactions that you get to do — what cards you can use in the game, and how they all interact with each other in the rules. And you can create your own. You can create your own decks, depending on the rules of the game.

And so I always tell people, Magic in many ways is, imagine chess, if they kept making new chess pieces. I think that’s kind of the best analogy I can give people about magic. So at the same time we have the game itself. But then on top of it we have what people refer to as the “meta game.”

Magic is divided into different formats, where different cards from different eras are allowed to be played. For a specific format, there’s even rules about what types of decks can be built, and what decks are successful and what aren’t. So if you want to be a very competitive player of the game, you have to understand the meta game. You have to understand what tactics people are likely to use? What cards are they likely to use? What decks perform well against other decks? And what are some tricks that I can use to give myself an edge in a match up where things aren’t mentally going to go my way?

So it struck me that, if we can look at software testing in a a similar vein, there’s the testing tools themselves, and kind of the rules about how you test. And in this case, I’m talking about mostly the kind of end unit style test that came back, and the Extreme Programming folks came up with in the 1980s — the assertion, “We’re doing a bunch of work, and we know ahead of time what the answer’s supposed to be, and then we run our code and get it to do a bunch of stuff. And at the end we’re doing an assertion that says, ‘Yes, I’m getting back a response that I’m expecting.’” That’s like the game of testing.

But if you look at the meta game of testing, or meta testing as I labelled it in that one book, there’s all these things you need to know, just to be proficient. It’s not enough to understand the game of, “Here’s how I write a test.” You need to understand the tools. How do I use these tools? You need to understand for a particular programming language what features of the language are easily incorporated into testing, and what aren’t? And at the same time, if I have multiple tools available — which tools are better suited for what I’m trying to do? What techniques are better suited for what I’m trying to do?

So when I wrote Minimum Viable Tests, I had sat down one time, because I was going to do a conference talk. I wanted to talk about all the stuff I thought you needed to know, just to get started. I was just astounded at how much stuff one person would have to learn, and how difficult that would be to learn on your own. So I wanted to kind of highlight in that book — here’s the basics, the bare minimum that me, a person who’s very experienced at doing this stuff, thinks that you need to learn just to get started. That was the idea of the meta testing. It’s not enough just to know how to write a test, you have to understand how all these tools and how all these moving pieces fit together.

Len: And they can coalesce in different strategies or styles. And in your book you talk about the London School and the Chicago School.

Chris: So of course, programmers love their tribalism, and they love to express themselves through the tools that they use. So what you mentioned is that there’s this idea that there’s two “schools” of testing theory, as part of the meta testing part, that revolve around the use of test doubles.

As a quick kind of explanation: when you’re writing a test, there’s usually a bunch of things that the code that you’re testing depends upon. And so the London School and the Chicago School take two different approaches to what we do with the dependencies. The one school says, “We want to use tools that allow us to create pretend versions of these dependencies.” The correct term’s “test double.” But people usually lump them all together and call them “mocks.” So when you hear a tester talking about, “Oh, I have to mock this,” or there’s a mocking tool — it’s generally what they’re talking about.

It’s the idea that you use these specialised tools to create replacements for the dependencies that you need for your test. And that you’re creating dependencies that are a specific state — you need them just for this test. It may be, I need to create a pretend object that handles database connections. So, rather than have it connect to a real database, I can use a tool to create a fake database object. And then my code knows how to use this thing, and it doesn’t need to know that they’re not talking to the real thing. That’s a strategy if you’re looking to have a test suite that runs really, really fast. You don’t have to rely on outside database systems and third party API calls on somebody else’s service.

And then there is the other side that says — whenever possible, you should use the real thing. Meaning that, you should not be using these test doubling tools. Every chance you get, use the real thing. And it doesn’t matter if you’re talking to a real database, or you’re making a third party API call to somebody’s service. So it’s the Chicago, London Schools. Even the testers have to be silly enough to try to put themselves into tribes.

I found that sort of argument — it’s interesting, because it’s almost like by declaring that there’s two schools, people want you to declare where your allegiances lie. When the truth is, you don’t really have to ever declare an allegiance. You can just do whatever fits the situation. I’ve written tests where I’ve used the doubling tool to create fakes of everything. And I’ve used tests where I’ve used the real thing. Sometimes you need to use the real thing, to make sure stuff is working correctly. And sometimes you want a nice, quick test. Because slow test suites are ones that nobody ever uses.

So sometimes the goal is, “I need to create as many tests as possible, and I need the developers to use them all the time. So we’re going to sacrifice using the real thing, we’re putting a bunch of work into creating fakes. But the whole thing will be really, really fast. And therefore, people will want to run it more often, and people won’t ignore the test.” So there you have it, Chicago versus London.

Len: As we were talking about before, the consequences of the choices that you make when you’re deciding how to test things are real. And I think you’re so well pointing out — one should not become ideological about it, as it were. Just remember that there are different approaches manifested and expressed in different ways. One should pick and choose what’s best for the situation one’s in.

Chris: The interesting thing about that is that, I really think it benefits people when they’re first learning a set of tools, or first learning some programming techniques, to pick one approach. And then once you’ve got that mastered, and you understand the trade-offs that you’re making — then it’s time to introduce the other thing. I tell people — yeah, I was always a big believer in using doubles, because I like my test suites to be fast. But yeah, there are times when I see the benefit.

The problem is, again, this is also a software development agreement, about people saying, “I don’t need training wheels, I don’t understand why you’re creating a framework or a set of tools that are intentionally limiting me. There’s all this overhead.” Sometimes you can see that now, because you have experience with it. But for a beginner — it’s like the idea of a kitchen with super sharp knives. When you’re teaching your kid to cook, I don’t think you want to give your kid the first time they’re doing stuff, the sharpest knife. Because they may accidentally slice their finger off. But an experienced chef shouldn’t be afraid of a sharp knife.

ou’ve got to learn the basics. And then once you’ve learned the basics and you understand the turn-offs, then you can start picking and choosing, “Well, of these five things associated with the Chicago School, I like three of them, and I’m willing to toss away the other two, because I understand the implications of tossing them.” But people, sometimes they think they understand, but they simply have lacked the experience to know that they don’t know what they’re tossing away.

And again, with software — because we have so much information available to us online, it’s very easy to find conflicting opinions about just about anything — any practice in software development. So I tell people, I’m sorry to tell them, but experience is the only teacher that is really worth a damn. Because you only learn by doing stuff, and you even learn more when you do stuff and you get it wrong.

Len: Speaking of meta games and experience, normally at the end of these interviews, I like to ask people about their experience using Leanpub. But we’ve already gone through that. So I wanted to actually ask you about the development of your online presence, which you’ve been very successful at, and your use of Twitter, which is something that anybody who’s listening, who’s thinking about writing a book — I mean there’s the writing part, which is very important, but there’s also the getting the word out and selling the book part, that really matters.

I was wondering if you could talk about how perhaps your approach to say using Twitter or otherwise managing your identity has maybe changed in the last four years?

Chris: It actually is kind of interesting. To be completely honest, this kind of branding as the Grumpy Programmer has worked way beyond what I ever thought it would. It’s been far more successful than I ever thought it would be. I think a couple of things that have really helped in that regard is, I first treated the Grumpy Programmer stuff as a persona. And so on Twitter, I acted very, very differently from how I was in real life. I was way more over the top, and way more aggressive.

My friends labelled me a Twitter performance artist, where I use Twitter as a medium to market my stuff, and pretend to be something — there was a core of me in there, so much of it was exaggeration. It got to a point where I had to finally — people would meet me in person, they’re like, “Wow, you’re nothing like your Twitter feed.” I’m like, “That’s because I’m a real person. A lot of that stuff is marketing and attempts to be funny and all part of like building a brand.” And so that worked really well.

I’ve toned it back in the last couple of years where I think what I’m doing on Twitter is a lot more representative of who I actually am as a person. But the consistency and the messaging is probably the thing that I would recommend to authors.

Four years ago, I didn’t have quite the Twitter presence and following that I have now. And so it was the combination of the books and the willingness to talk about it on Twitter — because it was mostly Twitter, my main outlet, it still is my main outlet for marketing. Engaging with people — in my industry, there’s lots of opportunities to speak at conferences. So go and speak at conferences and do stuff.

So, slowly building the brand up and staying on message and reminding people, “Hey are you struggling with this testing thing? I’ve got a couple of really small books. Think about it, if you’re charging 150 bucks an hour as a consultant, my book that cost you 30 bucks — you’ll make more than your $30 back the first time you go and do one of these things. Because I’ll help you take a whole bunch of shortcuts.”

You’re absolutely correct — the writing of the book is one thing, the marketing is a completely different thing. And it is a lot of effort. You can’t just write your book and put it out there and expect lots and lots of people to stumble across it and throw money at you. It requires effort. It requires messaging. It requires understanding that you decide where some people might think you actually know something, when you’ve sat down and committed a whole bunch of stuff out of your brain and into a book.

So, those messages. Stay focused. Stay consistent. Remind people. “Hey, you have this problem, I have this solution. Check out my books.” Be open to interacting with people. I gave lots of free copies of my books away to user groups and for my friend Ed, who was doing a fundraiser for his little non-profit that he runs. I gladly gave him a bunch of books to give away. So the marketing message really makes a big difference. I definitely see — I have a base level of sales that happen, but I can always see when I’ve been actively promoting and doing stuff, or when I’ve been literally mailing it in, doing nothing. I can always tell.

Len: And one of the things you do — I mean you do write pretty consistently, I think, on your blog. And one thing you do is share things about yourself as well. Which I think probably helps people establish a connection. This just reminded me — or maybe it was from a long time ago — but did you write a blog post about allowing yourself to buy a nice car? I was wondering if we could just close on that? Because I remember really enjoying that piece.

Chris: This is a very interesting story. I’ve worked from home for a variety of different companies for a super long time. So I never really needed a decent car. I always make sure that my wife and I — when it came time to lease a new car, get something else — I always made sure my wife had the nice car and the new one, because she needed a super-reliable car to get back and forth from work. So, I had an old beat up Ford Taurus that I brought from a car auction 10 or 11 years ago type of thing.

After a really long time, I was like, “Okay” — I’m pretty transparent about my personal life online, [although] there are clearly areas that I don’t talk about; I try to not talk about my wife and talk about my kids without asking them, because it’s not fair for me to blast all their details if they’re not cool. I’m a pretty open person about all things — book sales, money that I make in my job — all that stuff.

So I’m like, “Okay, I’m doing pretty good now, and I’m sick and tired of this car, and I want a nice car. I want to get the nice car for once. So this started a little dance with my wife, and pointing out to her, “Yeah, I got all this money over here from the book stuff. Look how crummy my car is. You always get the nice car. Isn’t it time that I actually got a nice reward for all these years of working and all the time? This crummy car.” And it broke down a whole bunch of times. And she’s like, “You work from home, what do you need a nice car for?”

And so eventually, we had to go on a long trip in my car. And my wife broke down and said, “Alright, that’s it — you can get rid of this thing and get yourself something nice.” So what I did do is — I had wanted a BMW for a while, but I couldn’t afford a brand new one. So I bought a previously enjoyed one. But to really reward myself, I got a custom plate for my car. So the custom plate on the car says, “Test more.” Which I thought — and I would just tell people, “Look, if you worked as hard as me and tweet 50,000 times and constantly evangelise about testing — you too can end up with a super sweet car and a custom licence plate.”

It’s a bit of a tongue in cheek thing, but also pointing out to people, you shouldn’t be afraid to reward yourself. Like I said, I’ve been doing this job for a super long time. And you should never feel bad about rewarding yourself. If you’ve done a bunch of work, and you want to do something nice for yourself — you shouldn’t feel bad about it. And so I didn’t feel bad at all about finally getting rid of my 2000 Ford Taurus and getting myself a 2006 BMW 325i that I’m very happy to drive, and I keep in really nice condition.

Again, it’s part of the [?] stuff. And people were like, “If you doubt my commitment” — it’s a nice joke, right? “If you doubt my commitment to testing, check out the license plate on my car.” That idea that, the persona is total, and at the same time I’m willing to poke fun at my self. But at the same time, I’m also well aware that I do need to reward myself. Because for me, there’s way more to life than just work. They don’t load up all the cash with you, when you go onto whatever happens after you pass away. [sounds] Hold on one second.

See, that’s a perfect example, Len. My daughter just came in. That’s a perfect example of there’s way more to life than just me. If I had a job working 60 hours a week — before we stop here, the main reason I started working from home, was so I could spend time with my kids, because I was never seeing them. So it’s just great. All these years later, I’m able to enjoy that decision I made 11 years ago — to say, “I’m never going to an office again.”

Len: Well I’m really glad to hear that. I mean that’s a great story, thanks for that. And I’m really glad to hear about how things have gone in the last few years. And that perhaps some of your Leanpub sales played a role in getting you that nice car eventually. And I wanted to say thanks for taking the time to talk, I really enjoyed it. I remember enjoying it last time. It was great fun this time too. And thanks for being a Leanpub author.

Chris: Oh thank you. Getting involved in Leanpub was probably one of the best things I did for my career, because it allowed me to get my views expanded to a larger audience. And in the end, I honestly believe all the book writing stuff has led to the career that I have now. If I hadn’t made that decision four or five years ago to write a book, I don’t think my story is anywhere near as interesting.

Len: Thanks for sharing that. I think that’ll be good inspiration to a lot of people listening. And thanks again for doing the interview.

Chris: Thanks Len.

Len: Thanks.