A Leanpub Frontmatter Podcast Interview with Katrina Clokie, Author of A Practical Guide to Testing…

A Leanpub Frontmatter Podcast Interview with Katrina Clokie, Author of A Practical Guide to Testing in DevOps

Katrina Clokie is the author of the Leanpub book A Practical Guide to Testing in DevOps. In this interview, Leanpub co-founder Len Epp talks with Katrina about her background, the importance and nature of software testing, some interesting tools of the trade, her book, and at the end, they talk a little bit about her experience as a self-published author.

This interview was recorded on September 8, 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 Leanpub Frontmatter Podcast, I’ll be interviewing Katrina Clokie.

Katrina’s a test practice manager based in Wellington, New Zealand. As well as being a popular blogger and international conference speaker, she is also the editor of Testing Trapeze magazine, which you can find at testingtrapezemagazine.com. You can follow her on Twitter @katrina_tester, and read her blog at katrinatester.blogspot.ca.

Katrina’s the author of the Leanpub book, -A Practical Guide to Testing in DevOps](https://leanpub.com/testingindevops). Her book addresses the evolving challenges for software testers within organisations, including how risk tolerance can change when products can be tested in production, and how testing should look in an environment with automated build and deployment pipelines.

In this interview, we’re going to talk about Katrina’s professional interests, her book,and at the end, we’ll talk about her experiences as a self-published author. So, thank you Katrina for being on the podcast.

Katrina: Thank you for inviting me.

Len: I’m here on Friday afternoon, but Katrina’s doing this on Saturday morning, so I wanted to say an extra special thanks for you taking some time on your weekend to do this.

Katrina: It’s no problem.

Len: As I think you know, I like to start these interviews by asking people for their origin story. I was wondering if you could talk a little bit how you first became interested in software, and how you ended up in the testing world?

Katrina: I came into software at university. I hadn’t had a lot of exposure to computer-related things before that, and I decided to enroll in an ecommerce degree, right at the time when the dot com boom was happening. My local university was offering a course which was a mixture of management and finance papers, with a little bit of computing, with the idea that the degree that you got out of it would be suited to this ecommerce environment.

In my first semester, I was taking I think three management papers, and an intro to Computer Science. I really loved the intro to Computer Science paper, and I decide to switch degrees in my first few weeks at university. I went into a Computing and Mathematical Science degree, and majored in software engineering, and started a career as a developer. I worked as a developer for a little while, and I found it to be not that fun.

When I was at university, coding was a very collaborative activity. There were a lot of team-based projects, and I found the lab environment at university really interesting. When I went into the workforce, the organisation where I was working had quite a waterfall approach to their development, and so it felt like someone gave me requirements — and I sat in isolation and typed up some stuff, and made something work. And then I handed it over to someone else and then got the next thing.

I took a role as a solution delivery engineer, primarily because I got to do a lot of travel doing that. That role was installing and testing mobile phone networks for Central and Latin America and Asia Pacific, and from an office that was based in New Zealand, when I wasn’t travelling. That was really fun, I did that for a few years, and then I wanted to stay home, and I needed to change jobs. I was trying to think about what I wanted to do, because I’d tried development, and it didn’t really appeal, and the role I was in only really existed because of the geographic region that we were trying to cover.

I thought about what I liked, and what I didn’t like in my brief, professional experience to that point, and decided that I’d go for a testing role. That was about eight years ago now.

Testing, for me, was a conscious choice. I think a lot of people say they fell into software testing. For me, I chose to go into testing, and it’s an area I really enjoy. I like testers as connectors in an organisation. There’s lots of communication with other people.

I like the investigative nature. When I was a developer, you just had to find one way to get it to work, and once you’d found that way, you were done. Whereas in testing, you get to continue to pick apart — what about this? What about this? I really like that kind of mode of exploring things.

Len: You said you started university around the time of the dot com boom. Would you study Computer Science again, or do you think you would just dive straight in and do training on your own?

Katrina: I would definitely study again. I really enjoyed my degree. While I was at university, I got the opportunity to do some summer internships in the research labs, and that led to me going to a conference while I was still an undergraduate, getting to connect with a lot of people and learn a bit about the broader industry.

After I left university, a friend of mine and I met up with some of our old professors, and it was really good to reflect on university not just being about what you are taught, but it being about teaching you how to learn. In computing and IT, things are changing so fast, that getting skills that teach you how to learn something is really important. You need to be able to research new ideas and understand how they might apply to what you’re doing, and then take those ideas and alter them for your context. And all of that, I think I got from my study.

Len: I believe you work for the Bank of New Zealand, that’s your current employer.

Katrina: I do.

Len: The reason I bring it up is that I like to ask people the question I just asked you, because I find about half of the people that I ask say, “I would do it again,” and half say, “I wouldn’t.” But one consistent answer across both groups is. if you’re going to work for a certain type of big organisation — or if you plan to work for a certain type of big organisation, having a computer science degree is a requirement. Is that true for your employer?

Katrina: It isn’t. We hire testers from a lot of different backgrounds. We get a lot of people applying from within the bank who have very strong domain knowledge and banking expertise. We get, for want of a better word, manual testers, who are looking to switch into automation. They have a very rich testing experience in a lot of different domains, but they don’t know how to code. We also get people with a computer science background who, in some cases, have never been in testing. And so we try and balance out within our teams, the experiences of different people, so the team has a rounded skill set. But the individuals bring their own strengths to that.

Len: That’s really interesting actually. It reminds me of a post that you wrote relatively recently, that I found when I researching for this interview, about a recruitment effort that you were involved in. I really enjoyed it, because often people who are starting out their careers — and some of the people who are listening to this podcast I think are in that stage of life — for them, recruitment seems like this very mysterious and opaque process. And scary, when you’re on the being recruited end of things.

I was wondering if you could just talk a little bit about what you wrote about in that post, and what that recruitment effort was like? I remember part of the challenge was how many people you needed to recruit, and how many applicants you had?

Katrina: For that particular round of recruitment, we had two advertisements running. One was for an infrastructure tester, and one was for an automation tester. Hehind those advertisements, we had nine vacancies, and we ended up with 150 applicants, which was quite a lot — it’s a little unusual in our market to get that big of a response. We had people apply from a graduate level, to changing careers, to swapping disciplines within IT, to experienced people, who could do the roles straightaway.

For that round of recruitment, we decided to trial a bulk approach to interviewing, which was a new thing for us. The candidate experience would change a little bit. Our normal process would be, we sent out some screening questions, because often it’s really hard to tell personality and communication from a CV. And if you’re screening 150 CV’s, they start to feel like the same CV over and over again.

So once we’d done the screening questions, normally the candidate would come in for a one-hour behavioural interview with a manager and a coach. Then, if they were successful from that interview, they would come back to do a one-hour practical interview with two of our testers.

Len: And what’s a behavioural interview?

Katrina: It would be a set of questions around your background and history — how you like working in a team, maybe how you problem solve and challenges you’ve faced, how you like to learn — trying to find out about you and your style, for want of a better word. Whereas with the practical we’d be looking more at your skills, and your ability to demonstrate those skills. That’s the distinction.

Len: That reminds me of some experiences I’ve had in the past. I wasn’t given the name of what type of interview I was being subjected to. I do remember taking certain sort of personality tests, which were easy to game. It sounds like your process didn’t involve that kind of exercise.

Katrina: No, we don’t generally do the test approach in that way. We did it once only, where we had two people, and we only had one role. We ran the tests, and they were useless actually. We ended up hiring both of the people anyway.

Len: That leads me to ask, is there a specific type of personality that one looks for in a successful tester? Or someone who might be a successful tester?

Katrina: Yes and no. In our organisation, the particular area where I’m most involved in recruitment, we have quite mature Agile teams. I live in Wellington in New Zealand, which is the home of our government, and so there are a lot of large government departments in Wellington who work in quite a traditional way. What we’re looking for in those behavioural interviews, is people who we feel show an understanding of what the environment might be like. But also, to a degree, a kind of natural appetite for working in a collaborative and flexible and slightly uncertain environment. When you talk to people, it’s interesting how quickly there are little red flags around people who enjoy a structured work day, and having their tasks given to them in well-defined -

Len: I’ve always wondered — I’ve interviewed a few people who are testers for this podcast. As a person working for a start-up, I do some ad hoc kind of testing myself. But is there something particularly curious and independent that might make a person a good tester? Because as I understand it, partly it is not very structured, or it isn’t necessarily very structured, and does involve a lot of imagination.

Katrina: Yes. That is what we look for in our practical interview. It can be quite hard to tell in the behavioural whether someone truly is curious and will go looking for things. If you’re interviewing a tester, they’ll always say that they are curious. But when you put them in a practical…

We have an exercise where there’s a small, really awful web application — which I feel comfortable saying, because I wrote it. And we have a fake story with some acceptance criteria. We ask the person to test that application, and the two testers who are with that person, one of them acts as the business analyst, and one of them acts as the developer. They role play through what it would be like for that person to be testing a story.

It’s really interesting how for many people, this particular application can work, and it can work by the acceptance criteria, but there are a lot of problems with it. It’s a good way of weeding out the people who will test that the acceptance criteria are met, and then feel happy, and the people who will go beyond that and look for the ways that the application is faulty and broken.

Len: It sort of seems fitting that if you’re looking for mistakes, if you expect to be given concrete instructions — you kind of don’t understand what you’re up to. If people knew in advance where the mistakes were, they wouldn’t need need to be doing what you’re -

Katrina: Exactly.

Len: Speaking of creativity, you do a bunch of things outside your regular work. One of those is that you created and you edit the Testing Trapeze magazine. I was wondering if you could talk a little bit about how you got started doing that?

Katrina: I used to work for a consultancy. We were employed as full time employees, and the consultancy would then put us out onto client sites or short term engagements. One summer, maybe four years ago now, myself and two of my colleagues all happened to be in our home base of the office at the same time. January/February is the New Zealand summer, and if you finish a contracting engagement just before Christmas, the likelihood of you picking something up before early February is relatively low, because everyone is on summer vacation.

The three of us were sitting together in the office and talking through what could we do to keep ourselves busy, essentially, to address our frustration with the wider testing industry. For us at that time, there wasn’t a testing magazine for our part of the world that we felt was really reflecting the calibre of people we had working in our industry. So we decided to create one, because we thought, “How hard could that be?”

It was quite a naive start. But in fairness, once we’d done one, we have actually settled into a little bit of a pattern. It’s not too hard. The hardest thing now after four years is continuing to find people through the networks that we have. We run the magazine with two New Zealand contributors, two Australian contributors, and one international in each edition. I’m in New Zealand, so finding people from my own country is relatively easy. But finding people from Australia can be a little bit of a challenge, as my networks over there aren’t as strong.

It started basically because, serendipitously, three of us did not have a client engagement one summer.

Len: Speaking of networking, you also have the WeTest conference. Can you talk a little bit about that, and how that got started?

Katrina: How did this get started? I went to something called a “Kiwi Workshop” on software testing in maybe 2011 or 2012 — it was a wee while ago. It was a two day peer conference where we had about 20 testers on a Friday and a Saturday having discussion-based conversations about different testing topics. I had never experienced something like that before, and I wondered why it was only open to 20 people by invitation only.

I messaged a colleague of mine who was at the event and said, “Surely this is something we could run more regularly, in a more open way, so that other people got to experience this?” And that’s how WeTest started. We just made a meet up, picked a topic, shared an invite and said, “We’d really like to discuss this. If you’re keen to discuss it too, come along.”

So our first event, we had maybe 16 people, and that was really exciting. Now I think we have 900 people in the group. In a week and a bit, we’re running a conference, which has just over 200 attendees in Wellington. Then we’re also running the same program in Auckland, where we have another 250 people coming. So really, over the past four or five years it has grown a lot. It’s now in a couple of cities in New Zealand, and is one of the bigger communities for testers here to discuss and learn and get excited about being part of this industry.

Len: It sounds like a big success. There’s a lot of demand obviously for people to get together and talk. Is that perhaps partly because — I mean, I know you’ve got something in Auckland as well, but is it partly because Wellington is a government town, and you’ve got a lot of people working in departments where they have formal testing rules?

Katrina: I do think there are a lot of testers. I feel like, when I look at the meet up groups and communities in American and European cities, that they’re not as big as I would’ve expected. I do wonder if we have a disproportionately high number of testers in New Zealand. Maybe we’re slightly more risk averse? I’m not sure. Part of it could be that there’s more of us; I think potentially the geography here helps as well.

I have heard of the Atlanta group moving towards virtual sessions, because apparently commuting around Atlanta can take hours. That’s not really something that applies so much in New Zealand. To go to something in the middle of the city, you might have up to a half an hour commute. But it would never be prohibitive to you participating in something. So potentially the close geography of our cities is helpful.

Len: That reminds me, I think there was an article in the New York Times about driving in Atlanta and the advent of self-driving cars, and how it can actually improve society a great deal. [Note: The article does not mention self-driving cars but that is a good point — eds.] That’s a topic for another discussion, I think.

Before I start asking you about your book, A Practical Guide to Testing in DevOps, I just wanted to make a statement or explanation to people listening about how the testing of software can often seem like a rather arcane subject.

Software is eating the world, and it drives not only the sort of apps we use in our day-to-day lives, but also a lot of the decisions that are made about how our lives are structured, and how our communities are structured. So testing is a really important activity, and how software is tested has a really big impact on our lives.

Just yesterday the news broke of a software breach, a security breach for this company called Equifax — something like 143 million Americans had their social security numbers and other information about them released. So it’s actually a very serious topic — not that I need to say that to Katrina or to anyone that she works with, especially working for a bank.

I wanted to ask you first if you could perhaps define what DevOps is? I know you have a section devoted to that in your book. If you could just maybe explain to people for the purposes of your discussion in your book, what you mean by DevOps?

Katrina: Yeah. I find it a little hard to describe without being able to draw the picture. So basically, DevOps is the intersection of development and operations. That manifests in an organisation where developers are sharing their practices and knowledge towards operations. So, potentially coding skills, source control skills that are used in infrastructure as code, and operations are sharing their knowledge and practices back towards development, in building dashboards or on-demand environments — there’s that exchange and flow of information. It’s a culture shift, and it’s a change in the tools that we use to develop software quickly and try to reduce some of the risk in releasing.

Len: Conventionally there are people who write the software, and there are people who deploy and manage the deployed software, and this is these two groups working in concert.

Katrina: Correct.

Len: One thing you write about in your book is a test strategy retrospective. I wanted to ask you what you have to say about the concept of a test strategy? What is a test strategy?

Katrina: These are hard questions now.

Len: Sorry, it’s because I come from a naive position.

Katrina: No, no. Okay — what is a test strategy? Usually it’s not enough for the tester to say, “Ooh, I’m really curious about this thing you’ve given me.” People want a little bit more information about how you’re going to spend your time, what you’re going to look for, what types of activity, and what types of investigation you might be undertaking against the application; what the person might get back from you at the end of your work. And so a test strategy is to capture that, to be able to communicate to someone in a little bit more detail whereabouts you plan to go and investigate, and what they might expect back from you at the end of it. Really broadly speaking, that’s what a test strategy is.

Len: There are so many different groups that are involved, and I know from the images in your book that you often have the tester at the center of all of these different groups. Do testers often have a lot of say in what requirements they need to meet? Or are they often on the receiving end of a bunch of different groups’ interests and messaging?

Katrina: I think a good tester is both. They are often on the receiving end, but also they have the ability to influence what they’re getting. Generally it will feel like people are giving you a lot of stuff and asking you to do a lot of different things. But if you can promote the types of things that you want to do, or that you want other people to have done so that your workload shifts a little bit — generally, you can do that too. That’s one of the facets of testing I really like, is that the social game of it, almost — how you can change what your role is by essentially building individual relationships around you, and changing the way that those people interact with you and the information they give you and what they might expect back from you as well. I don’t know if that was really an answer, but -

Len: I think there’s actually a lot behind that. Do you think that within, say, a conventional, large organisation, have attitudes towards testing changed in say the last 10 years?

Katrina: It varies by organisation. I think there are some traditional organisations who aren’t particularly aware of anything that’s happening in the wider software industry. Just yesterday I visited a government department, and I was astonished. I asked who had heard of the testing pyramid, and two people in a room of 40 raised their hand. That’s something that’s been around for a long time, and there’s just no awareness of it. I was truly a little bit baffled by that.

I think it depends on the amount of engagement an organisation has with the wider industry, as to their perception of a role, and what that person should be doing. How much that changes is going to be based on what they see happening elsewhere, and if they are not seeing anything, then I don’t think they do change what they are expecting.

Len: One really interesting thing I came across in your book was — again, coming from a position of naivety; I confess, I would have been one of those people who didn’t raise their hands about the testing pyramid.

Katrina: I should clarify. I was in a room of testers. It was a testing meeting. There were 40 testers in the room, and only two of them knew what that was.

Len: The really interesting thing I came across was, you talk about machine learning, and I was wondering if you could talk a little bit about that, and automation, and how that’s affecting the testing of software and testing of software quality now and going forward?

Katrina: Machine learning is something I find really interesting, and only know a tiny amount about. There’s two ways that it’s changing testing. One is, we, as humans need to test a piece of software that uses machine learning algorithms to determine what it’s going to do. And the other way is that machine learning becomes how we test an application.

So I think the example in the book — King, who write the Candy Crush games, have created this machine learning-based testing. That it determines all the different routes of winning the game, and can quickly test that a particular level of Candy Crush is still functioning properly using these machine learning algorithms. Which is really interesting — both ways that it could impact on the work that we’re doing brings a different set of challenges.

At the CAST Conference last year, they had Nicholas Carr come and speak. He spoke a little bit about the effects of automation and machine learning on humans, and how it changes the way that we learn, and the skills we have. That was a really interesting talk, which I am I not going to even attempt to summarize. But you could go and look that up. I see lots of interesting things happening. I haven’t yet had any direct experience with these things, but it’s definitely something I’m reading about, and looking out for, and trying to learn from what other people are doing.

Len: One of the things I really enjoyed about your book was the very clear definitions and descriptions you gave for certain terms of art. One of the things I find so interesting about this, about the testing space, is that there’s all this work going on in the background for the things that make our lives go properly, that the rest of us are not necessarily aware of. One of the concepts that you describe is that of a “canary release.” I was wondering if you wouldn’t mind talking a little bit about that idea?

Katrina: A canary release was named because of the way that miners used to determine whether there were any noxious gases in their coal mine. or whatever type of mine. They would take a canary down with them underground, and if the canary stopped singing, they knew that they needed to get out. So a canary release in software is, releasing the software to a small set of the users.

If the canary dies — as in, if the users experience a lot of issues, or have a very negative reaction to the change — then they can get out of that release, they can roll back that change from that group, and iterate and try and find something that will work better. Try another canary — and when the canary keeps singing, roll it out to kind of the wider group of people who might be using the application.

Len: There’s also the concept of “dark launching,” which is maybe a little bit more complicated than the canary release concept. I was wondering if you could talk a little bit about that. What is a dark launch?

Katrina: So dark launching, as I understand it, is putting all the code out, but in a way that it’s not visible to the user. So, if you were creating a new workflow in your application, and maybe the entry point to that workflow was that the user was clicking on a button to go into this flow, you would not release the button, but you would release everything else, so that code would be in production. If you knew how to get to it, you could go and have a look at it and make sure that it was functioning. But people wouldn’t be using it.

So you could tell maybe if that code was going to have any negative impact. Maybe you were worried about releasing it or configuring it, or whatever. Then, when you’re happy that it’s stable in there, you can kind of turn the light on, put the button there, so that people can find that new thing that’s been there all along. So yes, a dark launch is putting the stuff there, but not turning the light on so people can see it.

Len: And the idea, I gather, is that you can launch code that, even if it’s not being used by users, can potentially break other parts of your app or whatever it is you’re up to.

Katrina: Yes.

Len: I had the concept in my mind, but I hadn’t heard the term before, and just found it fascinating.

Moving onto the specifics of writing and publishing a book — I noted that you wrote your book using our in-browser editor, with Leanpub-Flavoured Markdown for the formatting. For those listening, over the years we’ve built a number of different ways of writing books using Leanpub. That’s been in response to us watching authors and talking to authors, just like this. And I was wondering, Katrina, if you wouldn’t mind explaining a little bit about why you chose that mode of writing, rather than say Dropbox or GitHub or something like that?

Katrina: To be honest, I didn’t know that I could do it any other way. I decided to write a book as a New Year’s resolution, and I signed up to Leanpub. On your very front page, it says, “Start writing now,” and I was like, “Okay.” I clicked that button, and it took me to the in-browser editor. So I assumed that was how I started to write now, and so I did. It was only when I had published the book, and I wanted to create a sample chapter, and I spoke to someone from Leanpub, and I said, “How do I do this?” and they said, “Oh, if you have written the book using GitHub or Dropbox, here’s how you do it.” And I said, “I didn’t even know I could do that. Like I used this thing.” And they said, “Oh sorry, you can’t make a sample chapter that way.” And I was like, “Oh.” So I chose that way, purely because it was effectively marketed through your website, and it seemed like the easiest way to go.

Len: Thanks for that feedback, I haven’t heard that before. Sorry for the very detailed question, but it is helpful to people who are thinking about starting out to write themselves — were you familiar with Markdown when you got started?

Katrina: Yes, the Wiki that we used to use at one of my old jobs was using Markdown. So that was okay. But I also had to reference the manual quite a few times when I wanted to do quirky things that I didn’t know how to do. But the manual was awesome actually, kudos for your manual. I could always find what I wanted in there.

Len: Thanks for the compliment. We can’t take all the credit. One of the great things about working with authors, is that they pay attention to words. So over the course of years, we’ve had people like say, “There’s a typo in paragraph 86.” So that’s been hammered at by a lot of very smart and meticulous people. But thank you.

I wanted to ask you a higher-level question. You have a blog post where you talk at length about the pricing model that you chose for your book. I was wondering if you could talk a little bit about that, and about the interactions you’ve had with other people, about the choices that you’ve made?

Katrina: I wrote the book primarily because I wanted the people in my own organisation to have it. And when I started to write it, it quickly became apparent through Twitter, especially, that a bunch of other people wanted to read it, and I thought, “Okay.” But I still wanted the people in my own organisation to read it, and I was pretty sure that they weren’t going to pay for it. I wanted them to have no excuse about why they couldn’t download it and engage in the material.

Then I started thinking, “Okay, initially at least, free has to be an option.” And then I started thinking about, in the broader testing community, how many people I knew who would look at a book, and especially an ebook with a price on it, and rationaliae in their head that that was why they weren’t going to download and read what was in there. I guess I felt that it was more important to me that people would read it, and learn a little bit about how the industry is changing around us, than to opt out, because they felt that they couldn’t afford it.

I decided to set what I think is a fair price of $14.99 US, but to leave free as the minimum. When I wrote the blog post, which was a couple of weeks ago now, it was roughly at one in five who were choosing to pay something. Some people paid the recommended, and some paid more, and some paid less. But then four out of five were taking it for free. I know some of them were definitely in my organiaation.

The other thing I’m observing is that a lot of people outside of the main areas that you might think about software being developed, are engaged in the book and reading the book. I’ve had people in South America and Africa, Pakistan, those type of countries where I think, potentially, even if you work in IT, maybe you don’t have the level of disposable income to invest in things like this? And then I started to think, “That’s quite a cool side effect as well.”

I have had some feedback from people in the community saying that it shouldn’t be free, and that it undervalues the work that I’ve done. I’ve had women saying that they particularly think, as a woman, I shouldn’t undervalue what I’m doing. But for me, the flip side is that, if it was pay only, a proportion of people who might otherwise want to learn about this, wouldn’t have the option to. And so I’ve left it how it is. We’ll see how it goes. The other thing for me probably is that the money is kind of a nice bonus. I wasn’t even relying on this as a source of income.

Len: One thing I really appreciated about your post and about your answer just now is — speaking to the complexities around pricing, and in particular, the complexities around trying to speak to a global audience — we’ve had authors, for example, who do set the minimum price to a higher value than free, but who specifically note in their “About the Book” section, “Hey, if you’re from a part of the world where this — or, just you personally are in a situation where even the minimum price is too high for you, get in touch and I can give you a coupon,” or something like that. It’s very interesting to see the ways people relate to prices that are set.

I’m sure you’ve encountered this, where there are people who say, if you don’t make the minimum price free, “What are you trying to do to me?” And there are other people who say, if you’ve set the minimum price to free, “You’re sending the wrong message,” or something like that. Part of the challenge of putting yourself out there and creating something, is engaging with these “You can’t please all the people at any particular time” realities.

Katrina: For sure.

Len: The last question I always like to ask in these interviews is, if there’s anything on Leanpub that we could build for you that we haven’t built, or if there’s anything that’s broken that we could fix, what would that be?

Katrina: Ooh. I would’ve liked to be able to make a sample chapter from the in-browser editor, which I hadn’t thought about at all. Only when people started asking me for it, I realized that I had no idea how to do that. Generally, everything worked really well. I think the only other thing I encountered with the in-browser editor, was when I was switching between machines, I quite frequently saw the error where it says, “Your local version and the remote version are out of sync.”

I at times got a little bit nervous about which one of those I was keeping, because when you get quite a long chapter, it can be difficult to see — I would have to remember which machine I was on last, and whether this was the right version or the other one was the right version. But in the end, I actually just decided I was just going to write my book on my one laptop, to try and remove that noise, because it got a bit too hard to track. I think it’s because the webpage must save? I don’t know why that comes up, but that was something I chose to work around. For people who are trying to write from different locations, that could be something to look at potentially.

Len: Thanks very much for that feedback. Testing myself, I’ve encountered that error in the in-browser editor before. For those listening, what happens is, sometimes there might be a potential difference between the local version and the version that we’ve got of a text that’s been written in our in-browser editor, and we offer you, “Which version do you want to keep?”

For any sort of potentially nervous authors listening, we do have a “Versions” feature, so that every time you create a preview of a Leanpub book, we actually save the text, so you don’t need to be all that nervous about losing text. But as a nervous-about-losing-text person myself, I understand the position you’re in when that error gets thrown up.

before we go, I wanted to say, thanks very much for taking the time on your Saturday morning to be on a Leanpub podcast, Katrina, and thanks very much for being a Leanpub author.

Katrina: Thanks again for inviting me to talk to you.

Len: Thank you.

Originally published at https://leanpub.com/podcasts/frontmatter/katrina-clokie-28-11-17.