An Interview with Tonya Mork, Author of Refactoring Tweaks: 7+ Easy Wins to Make Your Code Better & Increase Your Profits

Published Jan 10, 2017 by Len Epp

Tonya Mork is the author of Refactoring Tweaks: 7+ Easy Wins to Make Your Code Better & Increase Your Profits. In this interview, Leanpub co-founder Len Epp talks with Tonya about her career, her book, and her experience self-publishing on Leanpub.

This interview was recorded on September 8, 2016.

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

This interview has been edited for conciseness and clarity.

Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub Podcast, I’ll be interviewing Tonya Mork. Tonya’s a tech leader, software and electrical engineer and educator who has been involved in high-tech engineering since the mid 1980’s. She’s worked on multi-million dollar systems for the world’s big manufacturers — and started her own engineering company in 2002. Through, Tonya focuses currently on helping WordPress developers become awesomer, by writing and teaching about code construction, programming, and how to think about code.

Tonya is the author of the Leanpub book, Refactoring Tweaks: 7+ Easy Wins to Make Your Code Better & Increase Your Profits. It is being sold as part of a bundle on Leanpub, along with the Refactoring Tweaks Workbook.

In this interview, we’re going to talk about Tonya’s career and professional interests, her book, and her experience self-publishing on Leanpub at the very end. Please note, you can follow Tonya at @hellofromTonya on Twitter. and she’s got a great blog at

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

Tonya: Well thank you Len, I appreciate being here.

Len: As you know, I usually like to start these interviews by asking people for their origin story. You’ve got a particularly interesting story, with the history of work in lots of different areas and a lot of personal adventure, and I think people would really like to hear you tell your story in your own words.

Tonya: Sure. I do have an interesting story. I think those who tell stories need to also have an interesting story. Mine’s unique.

I’ve been in engineering since the mid 1980’s. I used to work — and I’m going to say used to, and we’ll talk about why here in a moment — I used to work in the high-tech manufacturing sector. If you think about anything that you use — your computer, your car, your refrigerator — all those things that you purchase and use, those are manufactured, they’re mass-manufactured. They’re put together with very sophisticated, high-tech automation equipment, such as robotics, instrumentation, quality control, those types of things. That’s the world I used to belong to.

So in that, I was a tech, and then I worked my way up into project management, engineering. I became a manager, and then an executive, and had my own engineering company. Those are things that I used to do. And then something happened.

I got sick. I had an engineering company, we were doing very well — very profitable. And this illness that I had was so rare, that basically the doctors told me, “There’s nothing we can do for you.” You’re just going to have to protect yourself.” Because when I would get ill, it was life-threatening. And the environment around me affected me. Imagine being in a car, watching a bird fly — being with family, too many people talking at once. The noise, the chaos. Those types of things would send me into a seizure, and make me so ill that it was life-threatening.

And so, what we had to do is lock myself away and be able to protect myself — control the environment. That went on for quite a few years. Quite a few years. I was in a dark, deep hole of depression, obviously. My whole company was ripped away from me. You’d watch people come and take away all the stuff that you built — your whole career, all of it. Your home, your savings — everything. My company — the families that were counting on me lost their jobs and had to start over again. My clients. So it was very devastating.

Somewhere along the way though, I said, “That’s enough. I’ve got to get back to me.” And I’m a happy person. So I found a way to be able to say, “Okay, I can’t go out into a manufacturing space and help people to be more profitable, and do better with your automation. I can do something virtually to contribute in this world.” And I started teaching and helping. “I have all this experience in engineering — how can I help people?”

And I ended up — first I started a non-profit, to help people like me. And then I ended up in this space. This WordPress space, this large community of people that stepped into the world of programming, without a programming background. And they are asking very elementary questions. Things that I could help them with, and they accepted me into their community.

What I do now is — I’m in the third chapter, and I focus on teaching programmatic thought, troubleshooting — all of those things that developers and seasoned software professionals take for granted. Those are the things that I’m teaching, and helping people in the WordPress space become, as I say, be more awesome.

Len: And you’ve got a particularly interesting moment of recovery as well in your story.

Tonya: Yeah, I do. So towards the end of this saga, my body failed. The doctors were throwing different medicines at me, trying different techniques to help control me — and my body just gave up, and I passed away. I got a miracle. And when that miracle came, I decided, “I need to change the trajectory of my life, and move into helping people and being in a service mode.” And that’s what I do. I’m on this mission, and it’s a real mission. It’s a mission that was given to me, because I got another chance in life. And I’m here to help other people, and that’s what I’m going to dedicate this part of my life to.

Len: In your wonderful essay, “Finding your purpose in life”, where you talk about your journey, you write about the way that, in the engineering world, in your first career, everything was proprietary and closed off, but you found something very different when you joined the developer community that has grown around WordPress. I was wondering if you could talk a little bit about that experience?

Tonya: Sure. So the world that I came from previously — when you’re going to go into things like robotics, and you’re going to build machine learning systems and those types of systems — that information is going to be proprietary. It’s going to have to be owned, so that companies can protect their interest, their knowledge, their profitability. Well, when you’re doing those things, that means people are protecting their little silos of information. You can’t just go out into a community and say, “Hey, I’m building this cool little reasoning engine, I need x, y and z. And it’s got to be able to work, and do these types of things.” Well, that just doesn’t exist. That doesn’t happen.

Then I found this community. This community is completely different. Everybody will give of themselves to help each other. It’s open source. And you’ll find that when you get into open source communities that the communities themselves will reach out and help lift up somebody else. If you’re having an issue, it’s not, “Well that was a stupid question.” Yeah, you can get that, but for the most part, it’s, “Let me see what I can do to help you, and give of my knowledge to make you better and help solve your problem.”

Len: Yeah, that’s really great. I really enjoyed reading how you described that experience. I mean, it’s such a contrast. It reminded me of Elon Musk releasing all kinds of information about the stuff that he’d done recently [Well, in 2014 — eds.]. Which was for all kinds of crazy — well not crazy, but like all kinds of complex reasons. And I was wondering, do you think that world — the world of patents and protection — has changed? Or is there just one or two well-known outlier situations, but really it’s all the same as it used to be?

Tonya: From my experience — now obviously I was out of the market for a while, being ill — but from my experience, from what I see right now, I don’t see that much of a change. I still see companies — and with good reason — being able to say, “I need to protect this knowledge. My team developed it. It gives me a competitive advantage. I need to protect that.” So there are times when you can say, “I can give away this knowledge for free. It’s for the betterment of the community.” I can see that, [but] I can also see instances where [you] can’t give that away. You’ve got to give away your trade secret. So yeah, I can see the differences from a leadership point of view, and a business point of view, where you need to have those two separate approaches and strategies.

Len: I recently interviewed another person who started out in the very high stakes world of programming and engineering around manufacturing. And I really enjoyed reading your recent blog post, in which you talk about firefighting and being reactive, and how much you dislike those approaches.

Tonya: I do.

Len: I was wondering if you wouldn’t mind talking a little bit about that experience that you had, and what firefighting is, and why it’s so bad.

Tonya: Right at the very beginning of that particular article, I tell you I despise of reactive strategy. I do, it’s too costly. And then I go through, and I tell you a story of one of my favorite projects that I did. That was to transform a company from this reactive strategy of firefighting to a proactive approach, and how they went from nearly having chains on their door, and everyone losing their jobs, to flourishing.

Okay, so how do we do that? Well first of all, what is reactive? Reactive is something’s already happened, and now everybody drops everything, and comes running to fix the problem. That’s what firefighting is. “Oh my gosh, we’re in crisis mode, something has happened,” some event. A site’s gone down, a line’s gone down, a customer’s complaining. And people can relate to this, right? Because that’s how we do a lot of our customer service. We think about, “Oh okay, I have a help desk, and I have clients call in. Well they’re calling in now, because they have a problem,” right? That’s reactive. It’s already happened.

The proactive approach then, is to change that strategy. It’s to think about how to ask the question, to prevent that from occurring — putting systems in place to prevent it from occurring, changing the dynamics of your team, to be able to say, “Okay, yeah stuff’s going to happen. And yes, there’s going to be a reactive model to certain things. But our business structure and our strategy should be, we need to anticipate what those things are, and put systems in place, and have leadership from the top down be able to drive that. Hey, we’re proactive. We solve problems before they happen.”

And one of the things that I talked about was, in this particular company, they had the engineering department set up, where the systems were so complex that the engineers had to drop everything and run out to get the lines back up and running again. That’s wrong. Engineers are too expensive and too valuable. They have a role. Their role is creating new products, and coming up with more efficient ways of being able to do things, right?

So we need to have them not be our firefighters, and enable our maintenance department — our technicians, those folks that handle service and support — enable them to do their jobs better. So that was some of the things that I talked about in that article. All the way to the point of, just the culture, how can we shift the culture to think more in a proactive mode, versus a reactive?

Len: I was very interested in your description of the culture. There were two twin aspects of it. One of which was, as I gathered, the managers around the facility thought that their presence during moments of crisis would kind of increase responsiveness.

Tonya: Yes.

Len: Just their personal being around would would increase the pressure on people to perform. And you also mentioned that you had a really funny moment, where you talk about how like, if you show up to a boardroom, and tell the board they’re making mistakes, that won’t work.

Tonya: Yeah, you’ll get kicked right out of there.

Len: And so you need to show up with proof. And that latter point is really good. I just wanted to ask you, was that true generally in your experience? That personality was so important that on the one hand, even if you were right and you went in with true statements, the interpersonal nature of a board meeting makes it impossible to just be direct? And at the same time, you have managers in an expensive, valuable facility, who have an ego problem. I mean, is that just part of the industry?

Tonya: Absolutely. It’s not just the industry, I think that’s just human nature, the higher up the echelon that we go, even in engineering — engineers have egos, right? People have egos. Now when I step into a board room, there are some big personalities in there. I’m a big personality. There’s a lot of big personalities sitting in that room. They got to that level, because they’re visionary. They have some sort of path behind them, that says, “Hey, I have the experience, the ability, the vision, the leadership to be able to sit in this room.” So you’ve got to then walk in and say, “Alright, there’s a problem. You’ve hired me to come in and solve a problem. There’s a problem. You know there is,” okay?

I can’t just walk in here and say, “You guys are part of the problem.” Because if I do that, those big egos are going to march me right out the door. And it’s true, if it’s a boardroom, if it’s an engineering room, if it’s a meeting — any meeting whatsoever. I find it’s much more productive if we walk in and say, “Okay, here’s the truth. There’s a problem. Here’s a solution. And here’s the proof to back it up, here’s the data.” Now there are things that we can’t just yet prove in our plan, but we can put metrics in place, to be able to say, “Alright, you can put a short leash on me now, and measure me — and say, “Okay, this plan is going to reach this pinnacle, here’s some sort of metric to be able to measure that.”

So what I talk about in the article too is, one of the problems was leadership did feel — and this is true in a lot of companies that I’ve been in it doesn’t just have to be the top leaders themselves, it can be a manager, who feels like, “Okay, I put more pressure on people if I stand there over your shoulder. My presence being here lets you know this is important.” That’s wrong. To me, you’re either a spectator, or you’re part of the solution. And part of the solution is not putting more pressure on people. People don’t perform well under pressure, right? It’s sending the wrong message.

So the message that the leadership was sending was, “This is a crisis, everybody drop everything and come running.” And literally, I would see the IT manager out there on the floor. Sometimes there were secretaries out on the floor. Because it came from the top echelon, to say, “Everybody drop everything, there’s a crisis.” It was so reactive, that everything stopped, okay? Well there’s lots of tasks in a company that need to get done at the same time asynchronously. And if everything’s going to come to a grinding halt, well that’s a problem.

Len: And the solution that you came up with, the long term solution that brought this facility into a much better position within its company, was to refocus the engineers away from that firefighting and reactive role, and onto proactive situations. Where a) they were doing the innovating that engineers should be doing, and b) they were doing the kind of predictive kind of work that they should be doing to prevent problems from happening again, rather than fighting them.

Tonya: Right. It was a culture shift. What we said was, “What’s everybody’s role in a company? Alright, go do that role.” So then the question had to be asked, “Why do the engineers need to be on the floor?” So part of the total transformation was, management get off the floor, stop coming out. Let’s enable our people, and trust our people to get their jobs done. And if they’re not getting it done, then ask the question, “Why aren’t they capable? What systems aren’t in place to make them capable of doing that?”

And what we saw was, things were too complex. The equipment was too complex. So we started simplifying things. Okay, we needed more training. Well let’s put some more training in place. We needed a system that would help people that, when something goes wrong, how can we have the system tell us, “Hello, I might be going out of my threshold, something might be coming?”

And so part of the transformation was to build a system. It was a machine learning system, that then did predictive modeling, to be able to say, “Alright, this area is starting to go outside of its parameters that you’ve defined. I’m going to alert you that something might happen.” And then we put a system in place that walked you through the steps of how to resolve those issues.

Maintenance departments have those anyway. They’re usually some sort of document that says, “Okay, do this, then do that, then do this.” Well we just automated it. We put it into a software package, developed that. We even looked and said, “Okay, do we have the parts and system?” “No? Well then send a message off to purchasing. We need to order this. This is where the parts are at. Here’s how the shop order is to build things.” So it was a total transformation, of shifting the culture, the equipment and the processes to be proactive.

Len: It’s interesting, I think I might have noticed a bit of a thread in your work about getting to the fundamentals of what’s going on and understanding them. And you talk in a video at, your website, about teaching people the building blocks of computation, and knowing the essence of code.

I was wondering if you could talk a little bit about what those important building blocks are, when people are doing their own development, and maybe in particular, what people should learn when they get into WordPress development, which is part of the subject of your book?

Tonya: Sure. I’m working in the WordPress world. But here’s what I try to tell people — and I’m actually putting together a presentation for a WordCamp that I’m going to be going to, on this subject, which is that programming is not hard. It’s not, if you understand programmatic thought and troubleshooting, problem solving.

If you understand those things, here’s what people don’t understand is — I don’t care if I’m building a robotic system, a machine learning system, or a simple website. They’re built with the same building blocks. We just put them together in different ways. And we incrementally put these little building blocks together, that come together to form incredible different systems that we can do — from banking systems to security systems, to sending something up to the moon.

An if is an if is an if. A while is a while is a while. All of these different types of instructions and code are the same. I can go from Python, I can go from C++, I can go from C, I can go to PHP. All of these things have the same different, small building blocks. And once you understand those, all of a sudden you’ll be able to build anything in code. Because now it’s just, “Okay, I understand all the different little building blocks of code. I can read it in different syntax, because it makes sense. I understand that there are looping instructions. I understand that there’s decision-type instructions. I understand that I need to break up my code into subroutines.”

And now we start to learn about different design patterns, and quality coding. How do you make things to be more reusable, or more modular, more configurable, more readable? I try to focus folks on readability, if I can read the code, because code should be human readable. Without inline comments, I should just be able to read it, and it tells me a story. If I can do that, right there, I’ve made code more maintainable. I’ve reduced the cost over its life cycle, and those are the types of things that I talk about when we get down to the basic building blocks.

That’s the bigger picture. But it all starts if I’m a new person coming into programming. It all starts with the fundamentals. First of all, what is programmatic thought? What is problem solving? What are some of the big blocks that you’ll see in every single language? What are those? How does data move around? What does it mean to be able to move by reference or by value? What do those things mean? Those are the things that I teach — I break it all the way down, so it’s very tiny and small. And then we start to put together more complex things.

Len: And do you think things are easier nowadays to get started, than say 10 years ago? If one wants to get started, as a self-taught programmer?

Tonya: Yes.

Len: Okay. I guess it was a loaded question, but -

Tonya: How is that for a big question. When I started back in the mid-1980’s, there wasn’t the internet. We didn’t have email, we didn’t have cell phones, we didn’t have the internet. So it basically was — you put yourself with a person who is better than you, and you scarf all the information you can get off them, and they help teach you about this profession. You can go to college, you can go and get your computer science degree. But now step out into the real world, and add value on day one in programming. There’s a gap there, right? That doesn’t happen, okay?

So what we have now though, is the ability to go to all these tremendous sites. To be able to share information about how you put systems together. Not only that, but we can share different frameworks, we can share different starting blocks — and we can take all this great code, and we can pull that in to save ourselves time. So we’ve got resources for training, we’ve got resources for building blocks to start with projects, to reduce our time. And then we’ve got different experts around the way, that are sharing their knowledge — either through books or blogs or presentations — or all of it.

So there’s lots of information. There’s also a lot of bad information out there. And learning how to disseminate what’s good and bad — well, that’s a different skill set, of being able to learn the basics from someone who really knows their stuff, and knows how to transfer that knowledge out of their brain to yours. It becomes adaptable for you.

I talk about adaptability a lot. I can teach you how to build one website, well yeah, whoopee. I know how to build this one thing, but I want you to make it your own, so you can go build something else.

Len: That’s a really interesting issue. It’s one I encountered indirectly in an interview a couple of months ago, with a couple of network engineers. But they were talking about how — what you really need to do, if you want to succeed in this world is to first think and learn, and truly understand what you’re doing — rather than fall for the very seductive trap of just Googling for little solutions every time you run into a problem.

Tonya: Absolutely.

Len: Because one of the consequences of having such powerful, and so much information available for programmers nowadays is that, every time you hit a road block, you can just kind of Google and then copy/paste a solution. I mean that’s putting it sort of crudely, but -

Tonya: It’s very true though.

Len: And is that something, when you’re teaching people that you — is that another thing that you have to teach them?

Tonya: Absolutely. Part of what I teach too is, to think about the cost of what you’re doing. So every single hour you put into a project, is impacting the cost of that. Code has a life cycle to it. It has a cost to it. So I try to come up with ways to teach people to think, not only about the profession of building, the actual building of code, but how can you build it more efficiently, more effectively? There’s a cost to that. Now if I was spending my time out searching for snippets of code, how productive am I being? I’m looking and I’m trying to ascertain — does this work for me, does that work for me? And then you go and you pull it in your code, and it has a side effect. It wasn’t built for your solution, your use case.

So you put it in, and if you don’t understand the why of it — all of a sudden, you may get this side effect that pops up. And maybe it’s popping up somewhere else, and you’re not understanding why. So then we end up with little band-aids all over the place. “Okay, I squashed this bug, and oop, it’s going to pop up it’s ugly head over here.” So I’m a big proponent of not spending your day out there Googling for solutions. I’m more into — understand the why of it, understand the intent of it, understand the fundamentals of it — and then get down, put your head together, find a team, work within a team. You have ideas to be able to share with other people, and bounce ideas off — and start writing that code.

Len: Moving on to the subject of your book, which I think is related to what we’ve been talking about, it’s called, Refactoring Tweaks, and I was wondering if you wouldn’t mind talking a little bit about who that book is for, and what it is that you go about explaining in there?

Tonya: Sure.

Len: I really like the in-depth argument about refactoring.

Tonya: Refactoring is the process of taking code that’s working, and making it better. You’re improving it, you’re cleaning it up, right? You’re going to put in the steps that do this. Make it more readable. It makes it more reusable, and it makes it more maintainable. Those are the key factors of what you’re trying to do when you refactor something. You’re just improving your code. Improving code is going to lower the cost of that code over its life cycle, wo that we can then turn around and reuse it again.

If you can picture that — okay, if I’ve got this code, and let’s say I have a function that’s 200 lines long. Well, first of all I’m going to tell you, it’s probably doing too many things. But if I’m looking at that, and a bug happens — I wrote it, but I’m typically not going to be the person that maintains it. So it gets passed a long way, a bug pops up — and it’s taking too long for people to be able to go in and fix these problems. And maybe it’s impacting something else. We all know these horrors if we’ve been in software long enough.

What the book is about is this: you can go and read a technical book, and I’ve got some great ones right here in my library — on refactoring. They’re very, very technical. They go into big words, and big descriptions. And code that maybe you’ll use, and maybe you won’t. Well what I did instead was, I tried to make things more relatable. I start where you’re at. And I say, “I don’t care about big words. I want to get down to the nuts and bolts. Here’s a problem. Why is it a problem? Let’s talk about why. Why is this the way it is? What’s the intent of it?”, and walk through a thought process. And what Refactoring Tweaks does, is it gives the simple solutions that you can say, “Okay, here’s some clues that tell you, you might have a problem. And now here are seven different — and I actually threw a couple of extras in there — seven different things that you can go do right now, in your code. These are simple, easy, they’re going to make it better.” And then the workbook then takes that, and I say, “Okay, here’s a code challenge.” There’s going to be seven of them.

And then there’s a total solution, where I walk you through the thought process. I want you to hear from the way I think about code, to be able to say, “Okay, step one: Do you see this? Well why? Why is it like that? What can we do to make this better? And then we step, by step, by step, we walk through the process of the why, the how, the when and the what.

Len: With respect to process, I’m really interested in asking you about the process of making the book itself. It’s a beautifully formatted book. You used our “Bring Your Own Book” feature to upload it to Leanpub’s bookstore. I saw in your book that you mention you had five collaborators on it, including a cover designer, editors and proofreaders. I was wondering if you wouldn’t mind talking a little bit about that process of making the book with a team of people, and, how did you assemble your crew?

Tonya: Well my crew has been with me since I started really out there teaching in the WordPress space. These are volunteers. If you can believe it, WordPress people give of their time to help other people. These people have been here with me. They give of their time. And then I give back to them. I help them with their projects, I teach them, I help them to be able to be better. So it’s a give and take.

I came to Leanpub, because I buy books from Leanpub. I like the idea of ship early, ship often. It fits within that. But there’s also — with Leanpub, you can use the tools that are built in, to then do a minimum type of publishing. It’s a very lean process. Well, I shifted that model for myself. And I said, “Okay, how can I use the platform then for me? For my purposes?” I like things to be visually pretty. Something that you want to pick up and read. It’s not just a white page of words. Instead it has color. I can then callout sections, and be able to emphasize those to say, “Hey, here’s a master tip. Here’s a what if.” And I can pull those out, and add some color to them, to make them pop as a sidebar. So that visual sense in my mind, that user experience.

The total platform’s not going to work for me. But you guys built it in a way that I can still ship early, ship often — get the content out as I write it, get feedback. But then I can produce it the way I want to produce it — which is well-edited, beautifully-designed, and bring my own book to the platform. I’m still within what the intent of the platform is. I can get the information and the ideas out. I just twisted it to fit my needs and the way I like to work.

Len: As I said, it’s a really beautiful book. There’s one page in particular that I really love. On the top half, it has an image of a kind of really dilapidated and risky-looking suspension type bridge, like an Indiana Jones-style bridge across a chasm, or a river I guess in this case. And you say something along the lines of, “It looks like it works, but do you trust it?”

Tonya: Right.

Len: And I thought that was a great metaphor for looking at code. I imagine — I mean, I’m not a developer myself, but I can imagine you look at some code, and you’re like, “Okay, I know this product works, but my God — venturing out onto this thing is going to be much more challenging than another one.” You can just look at it and see the difference.

Tonya: Yeah, and that was the whole point behind that page. I use that in talks that I do too. There’s code that just works. That doesn’t mean it’s quality code. And that picture right there brings that point to mind. It’s a bridge. There are boards. “What do you — when a problem happens, do you want to be the one to step out in the middle of it, and fix that board?” Well I know I wouldn’t want to. And then it shows you a picture of a beautifully engineered bridge that’s safe, secure, and does the same thing. They both do the exact same thing. They’re both working bridges. And that’s the point of refactoring.

Len: The workbook that you’ve published, along with Refactoring Tweaks, I believe is about 70% finished?

Tonya: Yes.

Len: I’m sorry I don’t know the answer to this, but did you publish, Refactoring Tweaks before it was finished also?

Tonya: Yes. I actually went through the process of, I think at first was maybe 20% that I put out there. And then as I went along, I think there were maybe four different releases to that one — if I remember right. And then the workbook itself will have a couple of different releases to it. It’s actually — the biggest chunk of it’s off in editing right now, and then we’ll be releasing that later this week.

Len: And have you been incorporating feedback from people? Are you inviting feedback from readers?

Tonya: Absolutely. Each person that has signed up for it, they’ve been very kind with their time, to come back and tell me what they think. I always tell people that, “You don’t need to blow wind up my skirt, just tell me like it is. If there’s something you like, great. But I’m more interested in those concepts that didn’t quite resonate with you. Maybe you didn’t quite understand it, because that means I need to go back into that and do something a little bit different — to make sure that it resonates with everybody. That it’s explained well.”

Len: And how do people communicate with you?

Tonya: There’s multiple different ways that people can reach me. I have a Slack group that people talk to me on. They can get me there. They can get me on email. They can get me from the different contact forms. I make myself very, very accessible to people.

Len: I’ve heard this from two or three people now, with Slack channels that they have set up around book development. Which is just such an interesting shift from the old “write in stealth mode, and then release the finished doorstopper” method, to having a live Slack channel, where you can interact with the author, and where they can see what people have to say about their books.

I guess the last question I have about your book is — I believe it’s the first in what you’re planning to call, “The Little Green Book Series..” I was wondering if you could talk a little bit about that? We’re really interested in promoting series of books on Leanpub.

Tonya: Oh sure. Green is my favorite color. But green also means money. And so what I do is, I try to help you to go out and be more profitable. Make more money. That’s the whole point of what “Know the Code,” is. It’s a profession. If you do it well, you’re going to make more money. So, “The Little Green Book” series is this. They’re very short books. They’re 100 pages or less. Somewhere around the 100 page mark. They talk about a specific topic, they’re easy to digest. They get rid of all the jargon and stuff that makes it less consumable. Beause then you have to go and explain — well what does the jargon mean? What’s this, what’s that?

Instead, it just gets down to the points. And the whole premise of these are this: We’re going to teach programming, and we’re going to teach business skills, to say — okay, I ran multi-million dollar companies. I’ve run big, huge projects of tens of millions of dollars of things. There’s a process there, so I can teach people in that space too, to be able to say, “Okay, this is how you market yourself. This is how you do this. This is how you do that.” And give them discernible skills that when you read the book. “Do this chapter, I read it — and now I have a skill set from that. I can go and apply it right now.”

That’s the whole point of “The Little Green Book Series.” Quick, easy, and something that you can pull into your workflow, your business, your work space — and be able to do it right now.

Len: That’s a really, really great idea. I’m looking forward to seeing all the forthcoming books in the series.

I was wondering — just very selfishly — the last question I ask in interviews is always — if there’s anything we could build for you, or fix in Leanpub, if there was any one thing you could pick, is there one thing you’d like us to do or like us to fix?

Tonya: Well I think that some folks would love to have more styling control over things. The ability to be able to add anything in. Even, like I said — just to have the callout. So there are sidebars that you put in, to be able to emphasize something that’s not within the direct workflow of what you’re talking about. It’s a sidebar, it’s more information. The ability to be able to have those sidebars in there, because you can do information, questions — those types of little blocks. But they don’t really pop off the screen as well as they could. If there’s a way to put some sort of styling around — a little background, a little border — some way to be able to differentiate that this is outside the flow of the content. I think that would help a lot of people.

Len: Thanks very much for that suggestion. I loved the callouts that you did in your book. You’ve got a lot of really fun icons, and they definitely pop. I think there’s one — a coffee mug, which I really liked. Thanks for that suggestion.

That’s something we always try to think about. One of our basic approaches to publishing — that’s why we’re called Leanpub partly — is formatting is procrastination while you’re writing. But it’s definitely not when you’re ready to finish your book. And it depends on everybody’s individual process as well. But your book is so nice, and I think we might take some inspiration from it.

Tonya: The callouts are something that even when you’re in the process of writing, you know that this is a callout, right? It’s a separate side bar of information. So something like that, in somebody’s eyes as they’re reading it too — it would be nice to just have a way to be able to discern that, “Oh, okay — this is extra information, and not in the content flow.” I can skip over it if I want to.

Len: And as I understand it, that’s a well-established convention in programming books, right?

Tonya: Yeah.

Len: Alright well — thanks very much for telling us your story and for telling us about your book, and your approach to teaching, Tonya. And thanks for being in the Leanpub Podcast, and for being a Leanpub author.

Tonya: Oh thank you. I really love Leanpub, guys. Get out there and buy more books.

Len: Thanks.

Tonya: Thank you.

Originally published at

Leanpub is the best way in the world to write, publish, and sell ebooks. Publish in-progress, serial and complete ebooks in PDF, EPUB and MOBI.