Special Guest: Jeff Nickoloff, Author of Docker in Action, Second Edition

[Note: There are discount codes for Manning books at the bottom of this transcription. Please note some of them have limited uses and are temporary! - eds.]

Len: Hi I’m Len Epp from Leanpub, and in this Leanpub Frontmatter podcast I'll be interviewing Jeff Nickoloff.

Based in Phoenix, Jeff is a software engineer and an author who has extensive experience building and writing about large-scale technology services. He's also the co-founder of Topple, a team-focused consulting, training, and mentorship company.

You can follow him on Twitter @allingeek and check out his website at allingeek.com, and you can find Topple at gotopple.com.

Along with co-author Stephen Kuenzli, Jeff is the author of the Manning Publications book Docker in Action, Second Edition. In this bestselling book, you'll learn everything you need to know about creating, deploying, and managing Docker containers, and techniques applicable all the way from smaller environments up to full-scale cloud deployments.

In this interview, we’re going to talk about Jeff's background and career, professional interests, and his book.

So, thank you Jeff for being on the Frontmatter Podcast.

Jeff: Thanks for having me.

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

Jeff: I grew up in Portland, Oregon, in the 90s. We got our first computer - we were very lucky - we got our first computer from my father's work. It was a business machine. It was this old - IBM Business Partner was the brand, some 286 or something like that. No hard drive, just dual big-old floppy discs. And it was pretty magic, very early.

I like to talk about inspiration all the time. For me, one of my favourite movies as a kid was Explorers. It had River Phoenix in it. Computers were tangentially in it - but I was kind of always into science and geeky stuff like that, which was really awesome.

In middle school we got the Pentium 90 machine, the first big classic killer. It was just this raw machine. It was just Windows 3.1 with - AST was the manufacturer, it had put that on it, and whatever software was available on the big table at Costco.

It was just so much mystery. I really didn't have a whole lot of mentorship. There weren't a whole lot of resources around. Which was kind of weird, considering I was in the Silicon Forest and all that. But I took inspiration where I could, and like a whole bunch of other people, I got into, like modding Doom II - I would just go to like the book store.

Back in the day, the book store actually had a nice variety of books on computers. So I cut my teeth that way. I think I bought a Java Swing book, randomly. I did a little bit of C++. A lot of scripting. Just a ton of scripting. And then I got way into building HTML, CSS - really, really early.

Then, it was just hacking more in high school. I did a self-directed study on C++. And then went to Arizona State University, got into a Computer Science program, and went through that whole thing.

But I was always a tinkerer. I had a really hard time focusing on one subject and just crushing it. Usually, because courses just always take so long. Schools and our semesters are like 16 weeks long. And so it never moves fast enough to keep me interested.

And so, I took a job. I got a job in IT at ASU. That wasn't my first IT job, but it was probably my most significant early employment. It was really great, because I got this crazy, deep exposure to a wide range of technologies. And really for the first time, it was where I had this group of young adults who were really - they were much more experienced, and they gave mentorship.

And so, with a little bit of that positive example and a little bit of like, "Well, have you tried X, Y, Z?" Even if I had never heard of X, Y, Z before, it was enough to get me into it. That's when I hit my really crazy growth spike, when it came to my professional skill set.

Len: I've got a question - you moved from Oregon to Arizona. And I gather you've stayed there ever since?

Jeff: Yeah, pretty much.

Len: And you studied Computer Science. The question I always to ask people who studied Computer Science, who I interview on this podcast, is - if you were starting out again now, would you do a formal university Computer Science degree?

Jeff: Yes. I would, absolutely. In fact, towards the end of my college education, I actually discovered how to study for the first time. And so there was a lot of kicking myself in the butt. I was like, "Well, if I had studied this hard since middle school, things would have probably been very different."

It really depends on what you want. For me, what I want is - I'm just really into knowing as much as I can. For me, employment, compensation is second to learning, when it comes to where I get my fulfilment from. And so for me, I don't think I would've ever been satisfied without it. But it certainly is not something you absolutely need these days.

Len: And you worked for ASU, as you were just explaining. And then you moved on. And you ended up working for a company that many people are familiar with, called Amazon. I wanted to ask you about that. What was that like?

Jeff: I loved it.

Len: What did you do for them?

Jeff: I was a software engineer. I came in as a - their levels don't really translate. I came in as a software engineer. It was great, because I was in Phoenix. They opened a little dev shop in Phoenix. I think I was the fifth person in the office.

But for the first time - I was saying at ASU, I got this handful of people who were technically significantly more mature than I was. And it was enough to really throw gas on the fire.

But when I went to Amazon, the people that I was working with were-- they just raised the bar for me in so many different ways, and it was really - the first six months of working there was getting another four year degree worth of learning. It was just kind of crazy. So I just ate it up. I loved it.

Len: It's really interesting, you mention on your website, allingeek.com, that you lived the leadership principles at Amazon. I'd heard about them before, and I checked them out. I think most people are sort of skeptical of corporate speak and -

Jeff: Yeah.

Len: "These are our five points and stuff." But with the exception of "Leaders are right a lot", personally, I - when I read them, they're extremely reasonable.

Jeff: Yeah, yeah.

Len: And you get an impression of one of the reasons it's such a successful company at doing what it does.

Jeff: Well I think the - really, for me the secret of Amazon is that they're probably the best-managed company in the world. The corporate speak-is one thing that's really easy to pick out. You see a document like this for a lot of companies, and you're just like, "Sure, sounds great," right? But I mean in Amazon, this is - that document is your review criteria. This is, "Are you doing your job?" Like, "Are you being an Amazonian? Should I be promoted?" "I don't know, are you a leader? what's the scope and impact of your leadership?"

They do a really good job at Amazon, more so than any company I've worked with, or really taken a look at, in the past - of aligning everybody's interests very carefully. As an engineer, your interests are aligned with your customers’ interests. As a manager, your interests are aligned with your engineers interest, are aligned with your customers interest. All the way down, all the way up through management.

And that manifests in a lot of ways, some of which are very positive, and some of which are particularly uncomfortable for people who are not used to feeling customer pain directly. So, everybody's on call. I mean, your director is on call for the software that you write.

And so if the software you write is of poor quality and it's creating poor customer experiences, then you're going to feel that pain. And unfortunately, at Amazon-scale - if there's a little bit of customer pain for each individual customer, you are experiencing that times a million. They put these systems in place, and they really do seem to use that as their north star. And I think it works pretty well.

Len: And do you have a fair amount of autonomy, or empowerment, compared to other companies? Because of one of their statements on these leadership principles is ownership. And it says, "Leaders are owners." And I think, from a kind of old time-y perspective, you might read that and go, "Oh shit, that means shit flows downhill, right?"

Jeff: Right.

Len: But actually, I - of course read that to mean, you've got authority.

Jeff: Yeah - and I can't speak for every org, right? Everybody's experience there is different. They're a major, major employer. So, this is all anecdotal. But in my experience and from what I've seen, especially - ownership helps things actually flow up, rather than down. It isn't about, something is flowing down, "Deal with it." I don't know if it's still on the website, but they had a leadership principle that was, "Disagree and commit." Where you're empowered to disagree. But ultimately, you're willing to commit to the group consensus direction.

With regard to autonomy, autonomy's a really, really difficult - or a really interesting thing to talk about. I think it really does come down to the team that you find yourself on, or the org that you're in. A lot of times you're given very specific missions. And one thing that they do probably better at Amazon than any other place on the planet is, they're really, really skilled at leveraging group critical thought. So everybody really does - if you have insight into a problem and potential solutions - you're not only welcome to share it, you're compelled to share it.

Because at the end of the day, everyone involved is as culpable for the success or failure for that project, as anybody else on the team. And so there isn't a - I never really experienced any degree of, "Because I said so" type-stuff. In fact, they have a really strong culture of constructive feedback, and genuine constructive feedback. You don't get any benefit out of tearing anybody around you down, or sabotaging their work, because at the end of the day, your interests are pretty well-aligned with the interests of the people around you.

Len: Thank you for sharing that. It's really interesting. I've not myself worked for one of these giant companies. But people often, I think - we talk about tech, in the tech sector, and people think of Amazon as a tech company. Or they think of Tesla, for example, or SpaceX, as tech companies. What's often lost in the discourse is the fact that, what, the leadership from people like Bezos and Musk - and not to lionize anybody, but what they and their organizations have managed to do, is innovate on the way people work together, and that's one of the reasons they're so successful. A great example that is, Tesla managed to build a big power station in Australia.

Jeff: Yeah that was really cool.

Len: Yeah, in three months. And it's - yes, a lot of technology went into that, but the system in place to get that initiated and completed with all the - and just the regulation side alone, the way everything has to be in alignment, the way there has to be no bullshit, or at least as little bullshit as possible. As you say, with the "Because I said so," or "Don't tell your boss they're wrong" stuff- you just can't-- You can't get things done at that scale and that efficiently, if there's human bullshit.

Len: I mean, you're hitting kind of the thing that I've been focusing on for the last year. Which is really - the thing that they do, is they have leveraged scalable communication. Better than - well not better than everybody. There's actually quite a few companies that are doing it very well.

But there's just not a lot of "butts in seats" mentality. There isn't a whole lot of, "We have to face-to-face talk about everything." If you have to have conversations about everything that you do, and the only way that you communicate is by via conversation or some other short form writing - it's going to be miserable. you'll never scale. You'll never be able to do anything repeatedly.

All that communication is incredibly low fidelity, and you end up - you'll go six-month periods, and half your team will be building one thing, and the other half will be building something totally different. And then sales will be selling something that was completely not what you were doing. And marketing won't have been able to actually message what's going on. Because, well - they're out of the loop. And those are the kinds of delays that end up really hurting most projects.

The biggest difference I see between the - pardon the characterization, but the lumbering enterprise, the slow-moving, low-self-confidence enterprises out there - is almost purely in their communication mechanisms. They've got the people, that's not a problem. It really comes down to how do you communicate and do so in confidence, and do so in a way that you can leverage group critical thinking.

Len: I've got a few questions to ask you about that \a little bit later. And so thank you for sort of foreshadowing.

Jeff: Sure.

Len: But before we do that - so you were at Amazon, you really enjoyed it. You learnt a lot there, and then you decided to leave. Why was that?

Jeff: Well, 2013 was this little miniature tech renaissance of the decade. Pretty much everything that happened in this decade, happened in 2013, from a technology perspective. It was really an incredible year. Between Oculus Rift happening - incredible 3D experiences was happening at the same time. We were seeing this boom of 3D printers, which was happening the same time we saw autonomous drone technology, which happened the same time we saw Linux and Linux containers, and that turned into orchestration, and microservices was booming. I mean, I could go on and on and on. Pretty much everything interesting that happened really, was seeded in that year, and probably a little bit in 2012.

So I'm sitting in Amazon, right? And I'm working in an incredibly fast-paced environment, where we're talking about problems at an incredible scale. And that was all great. But at the same time, I'm looking at this whirlpool of crazy bleeding-edge innovation that's happening. Hacker News was really exciting that year.

In my spare time, I got to touch and get a little bit of experience with some of that stuff, especially around Docker. That, for me, was this really interesting project. Because I could go home, and in my free time - in under a couple of minutes, I could download and install this project that was - it helped me do something that we were doing at Amazon.

It was actually a little bit easier than working with packaging in Amazon, and it was free - whereas Amazon's funding an entire team to build and maintain and develop those tools internally. And for the first time, I was able to stick together three or four technologies at home, that allowed me to build and iterate really, really rapidly, and that was really exciting.

So I just got way into it, and started doing a little bit of public speaking about it, talked around the office about it. I did some public talks about Docker. I don't think I had started blogging about it yet, at that point.

And then in 2014, an acquisitions editor at Manning called me up and just, "So you want to talk about Docker?" Because I had been one of the handful of people that had come up when searching around for people who know anything about it. We had probably a good hour and a half long conversation. He asked me if I wanted to write a book, and I said, "Yes."

And then I ended up - my plan was just to do it in my spare time. I did the whole external work authorization request that they were having people do at the time. I was like, "Well, if I'm going to do this, I want to do it right. I don't want to be sneaky or anything that. Because it's going to be a major work, and my name's going to be out there, and you're going to be able to buy it on Amazon."

So I went through the proper channels, and they're like, "Oh". The whole conversation got really muddy. My entire line of management were incredibly supportive about it. But it's a huge company, as you know. And so ultimately they were like, "Well, we're not really sure, can you show us like - ?" And then, Amazon lawyers started talking. And - for me personally, when lawyers start talking - they're probably some of the best paid lawyers in the world. Like, I'm just going to go, "I'm cool."

So at that point I had been there quite a while. I had felt that I had learned - not everything that I could, but at the very least on that team, in that space - in that set of technical challenges and in management, I had validated a lot, and I had learned quite a bit. And so it was a natural time to make a move. Anyway, so I said, "Well, I've got an opportunity to do something that is fairly rare, so I'm just going to go do it." And so I bailed, and it was great.

Len: And it must have been really exciting to have that challenge of being - or adventure, of being on your own.

Jeff: Yeah. I think people in tech, especially software engineers are so fortunate these days. A lot of my friends are kind of like, "Whoa, what are you going to do for money?" And all this kind of stuff. I'm like, "What are you talking about? I'm coming from one of the most well-known companies in the world, with one of the most desirable and highly-paid skill sets around. I could just walk into the street and hold my hand up for five minutes and say, 'I'm looking for a job,' and have one by the next week. This is not a high-risk activity. There is no specific bravery here, right? it's a very safe thing."

And so, it was exciting and it was interesting - and it was great to hold myself to this high bar for self-motivation and discipline. But at the end of the day, that was kind of straightforward.

Len: My next question is a bit of a digression - was that when you started working in coffee shops?

Jeff: Yeah, absolutely. I mean, I had off and on, on the weekends, or what not. I'd go out and hang out and do that whole thing. But one of the first things I did was - I mean even the month, I think the month prior, I'd just bought a brand new MacBook. I love that machine, I'm talking to you on it right now. And I just hit the coffee shop. I was like, "Look, I really don't need much. I'm a low-overhead kind of guy, it's why I studied CS instead of an electrical degree. I'm not into the high capital type stuff. So I figure - if I can get a chair, a cup of coffee and a laptop together, I'm good."

Len: I ask the question because, as I'm sure you guessed, you have a great post on Medium about coffee shops. It's lengthy and very, very good.

Jeff: Thank you.

Len: You are an expert on "coffee shop," and so I wanted to ask you a couple of questions. Because a lot of Leanpub authors and a lot of our listeners are software engineers, and a lot of them are quite independently-minded. A lot of them actually worked for big companies and became consultants. And writing a book is an important thing to do if you want to be a consultant, often.

Jeff: Yeah.

Len: And so, I wanted to ask the expert a couple of questions. What's the most important thing? What's the first thing you look for in a coffee shop?

Jeff: It kind of depends on what I'm looking for. Or I mean, it kind of depends on what I'm going there for. If I'm going because I desperately have to get some work done, all I really need is a clean place to sit. I will buy something, even if I know that the beverages aren't going to be that good. Because that's just part of this arrangement. I'm not paying for a $700 a month co-working space, I'm in a coffee shop. So I'm going to go there.

I'm going to buy - if I don't suspect that the coffee's very good, I'll get an iced tea. Because iced tea is always great. I don't even need it to be particularly quiet. That's not really that big of a deal. It is a little bit of a turn off if there's a ton of kids running around and bumping into stuff, or if it's particularly chaotic. But white noise, for me, actually helps me focus. Besides I've usually got huge headphones, on and it's not that big of a deal.

If I'm going there for coffee, there's one tell-tale that I think is almost 100% for us. Which is - if they sell more than one size of cappuccino, the espresso's probably not very good.

Len: Why is that?

Jeff: Pouring an espresso shot is easy to mess up. It's actually a small miracle when people can get it right consistently. And so if they have a very big menu, almost 100% of the time they're going to have multiple size of cappuccino. If it's -

Len: Oh, I see.

Jeff: Right? And so, if they have a very big menu, chances that they are constantly pouring espresso shots is very low, right? Or, if they have 40 different flavored drinks, people don't care what the espresso tastes like, right? Because it's going to get covered up with sugar. A cappuccino is espresso and a very specific amount of milk. There's really nothing in that to of get in the way.

But if you're looking for a good - a really good third wave coffee shop, you can usually tell just by walking in and looking at the menu. If they've got more than one size of cappuccino, then you're probably going to be a little bit disappointed. You should get a mocha or something that.

Len: That's a really great explanation that hits with something - I've got a friend who's a bit of a sushi snob - or, he would say "selective" probably or something that. But the big menu is immediately a way of setting your expectations. And that's one thing I really liked about your post, is like, "It doesn't mean you now are in a negative relationship with this place. It's just you do your triage, and now you understand the place you're in, and you adjust your expectations and your behavior".

Jeff: Right, right. It's 100% about levelling your expectations. If I go in and I look around and I see a drink that's big, frothy foam - I know, "Okay, this is a French style coffee place," right? And they'll have the giant mugs, and it'll be cozy and it'll be all sorts of lovely and pseudo-romantic. And so I'm not going to go in there and be like, "I'm really in the mood for a sharp third wave espresso shop." Because you're just never going to get it. It's going to be black. It's just not going to be right.

And so, I'm not going to go in and then be all upset, right? I'm going to go in and go, "Oh, okay. Well, I'm going to get a mocha." Or, "I am going to get a big floofy thing and know what that's about." It's a really interesting little microcosm, because it really is - managing expectations is really what companies are all about, right? Brand is established through consistency.

When you're going to a universe of little coffee shops that are all different owners, all different brands - you don't expect a whole lot of consistency. If you're ordering the same thing, there's a temptation to do so. But I think that's pretty worn down. If I go to the same coffee shop time after time after time and it's variable, the quality there - I'm not going to go to that coffee shop for very much longer, right? Because I don't know what I'm buying before I give you money. I'm certainly not going to tip before I get my coffee, right? Because that, which is another crazy pattern - not that you should not tip people, but it feels weird doing that when I have no idea what I'm even buying.

Len: It's really interesting you mentioned third wave. I'll ask you what that means in the coffee shop dimension in just a moment, but there's actually quite a funny coincidence here.

Just a couple of interviews ago, I interviewed someone named Alex Hillman, who was involved in sort of first wave coworking.

And he told me the origin story of first wave coworking, which was basically - there were a bunch of people in San Francisco in the mid-2000s who loved to work at a coffee shop. But they'd show up en masse, because they'd coordinate. And then it was like, people didn't really understand what was going on. All of a sudden a bunch of people showed up with laptops, they'd all be quietly sitting at different tables. And then they'd all laugh at the same time, because they were all in the same chatroom. It was just sort of surreal.

And then one day - maybe they didn't have their tipping etiquette down? Maybe they didn't drink as much coffee as they should have? Or they'd get one cup and sit there for eight hours or something that?

Len: And one day they all showed up, and the coffee shop manager had blocked all of the power outlets. It was very like, they knew, "That is directed at us, and that is a way of telling us to not come here anymore."

Some of them were opening up an office for a start-up anyway, and they said, "Well, why don't we just get a bigger space than we were going to do otherwise, and we'll have people come here?" So there's an interesting connection - that was first wave. Then there was second wave, which was basically WeWork and the commercialisation of it. And then there's third wave, which is sort of learning the lessons. So, third wave coffee shop - is that sort of similar, along a trajectory that?

Jeff: Yes. I mean - as soon as you say what something that is, you're just going to get shredded by a whole bunch of pedantic definitions. \I would just go out to say it's - it's really a return to - it's part of the food movement, right? So it's about finding really good beans and very purposeful roasting, and making very purposeful coffee. I wouldn't say it's one kind or another.

But it's like, there's a lot of intent put into it. And so that's where you'll see people say, "No, a cappuccino is this many ounces, right?" If you want something bigger than that, you want a latte. If you want something smaller than that, maybe you want a cordoba, or maybe you want a macchiato? You get into these things. But it's kind of, it's - well, I wouldn't say that it's a reaction to a Starbucks coffee. But the transitions from a Starbucks lifestyle into a third wave - having appreciation for third wave coffee, is actually a pretty easy transition. Because it's a very Italian tradition.

You're not going to find a lot of French style. It's tight-type microfoams when they're appropriate. It's really, really good espresso. It's espresso that you actually enjoy just drinking, as espresso. Instead of it being some very black, abrasive experience - unless that's specifically what you're going for. But you're not going to walk into a very French style, more of a hangout place that happens to serve coffee, and be able to talk to the barista about their single origin natural processed beans. That's just not going to happen. And that's fine. It's not for everybody, not everybody has to get into it. I, kind of accidentally - so the more you learn about something, the more you begin to appreciate it, and then the more you develop a taste for it.

Len: Just to give people a sense of the level of detail that you can go into for appreciation of coffee shops, you talk in your post about the importance of flat surfaces in bathrooms, so you can rest your laptop there. And when I was reading it, I was laughing out loud because I was reminded of how often nightclubs deliberately don't have flat surfaces because they don't want people doing cocaine in there.

Jeff: No, in a coffee shop, they sell the cocaine in the front, right?

Len: That's right. But that really resonated with me because I - in a former life, I was an academic, or in academia generally. And one of the things that I found really frustrating about working in libraries, was what to do with my laptop when I had to go to the bathroom. And of course coffee shops had the same - I mean, I guess in libraries, it's probably orders of magnitude safer generally to leave your laptop at a desk, or something that.

Jeff: Yeah. I mean, you really have to make a judgement call. Every shop is different, right? If you're sitting there and there's 30 people that you see there every single day, and it's otherwise a fairly low churn, then - but at the end of the day if you're working on something that's highly valuable on a machine that's highly valuable, then you should treat it with that appropriate level of respect. If you're working on your five year old, $2,000 machine at the time - and all of your work is backed up, and it's properly encrypted at rest - the worst thing that's going to happen is you're going to lose a laptop, then forget about it. Just flop it around. Take as much risk as you're willing to allow, or that you can tolerate.

Len: Thanks for talking about that. I was really looking forward to--

Jeff: No, I'm glad you brought that up. That was a really fun article to write, and boiled from a lot of opinions that had been formed over the last half decade.

Len: And it's also, I think, really important to think deeply about how the way we work and the way our spaces are designed affects the way we can work. And that's particularly true if you're independent. If you're independent, you can choose where to work, and you can probably make more choices about what your working space is like, and what your working life is like.

Jeff: You can certainly make a lot of poor choices. It's a lot easier to make poor choices, right? If you're going to the - but even like - it doesn't take much to inspire discipline. if you're getting up and going to the office at roughly the same time every day, you've already got that fundamental cadence built in.

One of the first things that I see people struggle with is failing to maintain even something that looks a rough regular schedule, right? Sometimes, people who - and this is, again, not universal - but I see a lot of people like, "Man, I'm having a hard time getting started." And I'm like, well - and I come to find out, yeah - they were working four hours in the middle of the night the other day, and then two days later they were trying to work for six hours during the day, in these large blocks - and they're not stretching, or they're not doing basic self-care stuff. I'm like, well, why? You just have to walk them through it with questions, try to - let's see if we can solve the problem. But yeah, it's good to have the control, but it's not necessarily for everybody yet. So I think we've got a little ways to go.

Len: Getting back to your career and to working independently. So you wrote the first version of Docker in Action, and then you started a consultancy, I gather.

Jeff: I did. I needed to make some money. The book took a little bit longer than I anticipated it taking, for a myriad of reasons. We had these chunks of high productivity, with some travel interspersed in there, or long periods of editing that really weren't planned. And so it just took longer than we wanted it to. But six months in, I was basically like, "I need to do something to start earning some money. I don't really want to get a full time job yet, so let's see what's out there."

It was a particularly fortuitous time for this whole thing, because I was very, very early. I'm an OG Docker Captain, as they used to call it. I was creating all sorts of content. I was doing a lot of blogging, still doing a lot of public speaking, and of course writing the book, doing a lot of stuff throughout the book, running a meetup for Docker - or about Docker, not for Docker. And doing a lot of travel, and just kind of generally spreading the word.

And so starting the consultancy - starting it was kind of hard, honestly. I met a couple people through public speaking. It was usually through the meetup, or public speaking, or things where I would meet a person and just kind of push it a little bit more. And it turns out I was talking to a decision-maker who actually needed help or something like that. And so that was okay.

What I found, interestingly enough - maybe this is interesting? It was interesting to me, that 95% of the time they found me because of Docker, but almost never did they actually need help with Docker. They would say, "Oh yeah, we need - oh this containers thing." But then they'd they were just never ready for it. So it turned into a lot of application design consulting. It turned into a lot of general automation and devops consulting.

Quite often, we would end up talking about disposable infrastructure, or getting to the cloud, or cloud management practices. It's a broad range of stuff, that of course I had a lot of opinion about, and had a lot of experience with. All that stuff is so tightly coupled anyway. But yeah - so it was a good conversation starter, I would say.

Len: You mentioned communication earlier - and so you consulted for a few years, your book came out, and then you started Topple.

Jeff: Yeah.

Len: I was wondering if you could talk a little bit about the company, and its mission?

Jeff: So we started Topple, initially - well it was - it's a different entity. But really, what we were coming around to, was that the consulting that we were doing, we just kept - it was not particularly fulfilling, if I can be totally blunt. The problems that our clients had were almost never technical. I mean, certainly there were technical issues that we helped them work through, and all that good stuff. But at the end of the day, when our clients would fail, or when they would encounter major setbacks - it was never because of technology. It was almost exclusively because of the communication patterns, or their lack thereof.

We took a good six months to kind of really roll around what's going on, like, "Okay, we want to do something else. We don't want to necessarily chase the consulting anymore. So what do we want to do?" We rolled around a couple of big ideas in open source, or other things in the DevOps and infrastructure space - projects that we could kick off and really launch.

But ultimately, that whole industry - by then, had kind of - I mean in my opinion, really eaten itself. There was so much consolidation, and there was almost no innovation. With the exception of maybe two companies, there's really - it was all business model tweaking. And we had fallen into a very deep sale cycle, and I don't mean that in a negative way - it was just, we were really trying to convert a lot of these adopters at the time. And so that was just really not a good place to be - a good kind of company to start.

And so we circled back around to this communication thing. And, based on my time at Amazon, I said, “I think I've got an idea." And so we started Topple, really as this second vessel, and to try to figure out what the business around communication looked like. Would it be training? Would it be consulting again? Would it be product? And really, by the beginning of 2018, we saw a path forward for a product.

So we said, "Okay, Amazon doesn't have these problems. Why doesn't Amazon have these problems?" Or at least, nowhere near to the degree that everybody else does.

It really came back around to long-form writing. If there is something that they need to communicate, they do it using long-form writing. And it's very - you don't just say, "long-form writing." They wouldn't say that, they'd talk about their "one pagers" or their "six pagers" or "Jeff Bezos' memos to shareholders."

It really comes down to memos. Long-form writing to me is something that had, or like - a single document that has enough content that allows the reader to think critically about that content, right? It doesn't have to be long. You can have long-form writing that's a page, if you can think critically about that subject matter in that page. And so this is something that they do for everything. There's a whole lot of other opinions, not just about the writing, but also on how they consume that content.

And so what we did was we ended up writing some docs. We wrote a couple of six page documents that say, "This is how to write, to communicate at work. This is how to read to communicate at work, and this is how to manage using long-form writing as your medium." It's really that, that I believe helps them scale. Because they're able to communicate en masse with high fidelity and asynchronously. Which is really remarkable.

When I see the things that slow people down, or - at other large companies, it's - when they communicate using PowerPoint slides, they don't actually say anything. It's basically a cave painting, right? It's incredibly low fidelity, a raw construct. They get a little bit from the orator. But ultimately the author, the presenter is really hoping that the people consuming this content share enough background context that they can actually understand what's even going on. And the dirty little secret is that the audience talk so infrequently that you really, that the percentage of time where they actually have any idea of what's going on is very, very, very low.

And so, it's almost a completely useless medium. I say, like, "Presentations are for sales." And I don't mean that in a bad way either, because the way people make purchasing decisions is very well-studied, and it has absolutely nothing to do with evaluating things on merit. It's all about emotional appeal. If I can think of one thing that you should not do internally for a company, it's make decisions based on the emotional appeal of a given solution.

Len: This is a really interesting topic. It's very deep in the nature of what it means to manage a successful company, in an age when every company is a software company. It's come up a few times on this podcast before.

One observation I like to make, and it might be me who came up with it, or a colleague of mine I worked with a few years ago, when we were working on a collaboration software product - but one of the reasons that it took so long for the personal computer to be adopted into businesses, into companies - was that typing was seen as an underling's activity. And it was gendered, right?

Jeff: Right.

Len: So, typing was women's work. To this day, and I'm going to just go ahead with the full on stereotype and generalization here, an east coast executive is someone who never touches a keyboard. That's one of the reasons that Blackberries took off so well, and one reason that tabloids and mobile phones became so popular.

An executive is sort of conceived of as a - and I'm going to gender it, because it's gendered - as a man of action who is playing golf and getting on an airplane and having dinner and having a big-time meeting, and then banging the table and making decisions. But the idea that sitting down and thinking about something at length, and then writing about it - and at length, as you point out - I think's very well - doesn't necessarily mean a long document, right?

Jeff: Right.

Len: What was the Mark Twain joke? "I'm sorry I wrote you such a long letter, I didn't have time to write a short one."

Jeff: Right.

Len: And this idea, that if you're managing complex technology, which is what all companies have to do, if they're going to succeed nowadays. The way you communicate - communicating intelligently, and as you say, "asynchronously," which is a way of saying "through documents" - unless you can master that, you're not going to be - the paradox, I think in a lot of people's thinking is - if you want to get that power station built in three months, you need to have a really robust -

Jeff: They make micro optimizations for things that are fast. And in doing so, they sacrifice fidelity. And they lean on - I mean, really what it comes down to is they think, "Oh this has to be fast. I just want to get it out," these minimization statements about communication. "Can't I just see it via chat? Can't we just have a quick conversation?" Right?

And it's incredibly harmful. You've talked about the east coast executives, but I actually think that we're facing this really interesting challenge. Because I mean, even you called out tech and software. And this is not different. This is - we're actually in this really weird age where communication over distance and at scale has become so cheap that it's useless. It's completely and utterly useless.

Internet comments. The value of any given tweet. You just - the Slack conversations are absolute garbage. You can have a creative conversation in the world, and 70% of that conversation took place in your head. It never even got out of your mouth, right? And there's no way to actually analyze complex ideas or actually have thick, rich discourse - because we're always chasing the bleeding edge of the conversation. If it follows more - if some point follows more than two sentences back, it's gone, right? You'll never get back to it. It's incredibly linear.

And so we're very much these slaves to this short-form addiction, and it has really killed everybody. And I would say people in software are probably the worst of them all. Because we're born of the internet today, right? But look at - I mean, if you look back to a time when communication was not so cheap - it was all long-form, and it was done really well.

George Washington's one of my favorite examples. This is a man who managed exclusively through documents. He would ask his generals each to draw up proposals, and they would write it in a letter, they'd send it to him. And he'd sit down and he'd read them both. And he would think critically about the subject matter, and he'd render a decision, or he'd ask for additional information. This is just the way that you work, that you manage at scale, right? And we've had the gift of writing since forever ago, and it was born out of the necessity to be accurate.

I've got this really great post that I've used in some of my trainings. It's the communication maturity timeline. It's one of the first records that we have - like, the line between prehistory and history comes back around to people who had flocks of sheep. And, when - before they would send the sheep out with the shepherd, they would want a record of how many sheep they gave to the shepherd to roam the fields and graze.

Because when they came back - if they didn't have the same number of sheep, they wanted to have something to point to, right? And so the first thing that they did was they - it was really interesting. They had these beads that they would press into clay. And they'd say, "This is how many we had." And they'd both agree to it, and then they'd count them up and do that whole thing.

If you want to be accurate about something, you want to be able to communicate with other people, or even yourself, across time - you have to write it down and you have to write it down with a high fidelity. I can't just blurt out three random words at someone and expect them to have five pages worth of material. And it really -

Len: It's really interesting how fundamental this kind of thing is. I interviewed someone on this podcast a while ago named Ian Miell, who eventually became Chief Software Architect for a giant multi-national investment bank. I hope I'm getting it right, that it was him. But he had at one point earlier in his career, been working for a gambling site. And there's millions and millions of dollars at stake every second. You have to get everything right, you have to be up all the time - because there's a game on, right - that people are betting on real time.

And I think he at one point convinced his boss or colleague, "I'm going to take a few months just to write documentation." And that was sort of his ticket to a rocket ship career - was really understanding everything, but taking this gamble, that like, "I'm not going to be writing code or anything that. I'm just going to be understanding everything and writing it down well. So that, if something goes wrong - somebody not only has a place to go, but I have to structure it in such a way that they know where to go."

And it's that structure that's so important as well. It's not just having the documents. There needs to be a structure to it, and there needs to be an understanding of how that structure works.

Jeff: Yeah. And especially in software. there's - I think it's really important to realize that they're - we have this tendency to say "documents", to mean "documentation." And there's certainly - that is a real use for long-form writing, and it's incredibly important - especially in operational scenarios or, basically, if you want to do anything with a high degree of consistency, it has to be documented. You can't just sit down at an espresso machine and be like, "I'm going to make espresso," and just figure it out on the fly and then figure it out every time.

You say, "No, what we're going to do is - the water is going to be this temperature, there's going to be exactly this weight of espresso in this. I'm going to tamp it a very specific way. And when I make it, the machine is going to bring that water to a specific pressure for a certain amount of time, and I might back it off to a certain amount of pressure for a certain amount of time. And after a certain amount of time, it's over," right?

And when you can do that, when you can actually say, "This is our process," you can execute consistently. That's what documentation and modelling the systems are for. But what's really missing, what we're not doing, is using documents to communicate, right? These don't necessarily even need to be these maintained machines over time.

This is ephemeral, this is point in time. It looks like journaling. And this is a particularly bad word among modern forward-thinking companies, but it looks writing reports. Which felt like this really gross, gross thing that was a fallout from high-bureaucracy environments.

But, I think there was misattribution there. They weren't bad because you were writing something. Reports are bad if they're not used. If you're doing work that doesn't make any sense - it really is the bureaucracy that's the problem, not that you're writing to communicate.

And really - there's another big leap. When people are talking about it these days, they talk about writing culture a lot. The word becomes "writing culture," the catch phrase. And it's really - the writing has almost nothing to do with it. Which is something that I discovered over the last year, year and a half. The word you need to be looking for, if you're going to make a change in your organization, the change that you need to make is, you need to be able to expect to read the things that you need to know to do your job. Because if you need to read it, someone will write it. But if you don't know what you need to read, you'll never get what you need written. That make sense?

Len: Yeah it does, it totally does.

Jeff: So if I can say, "Hey, I'm thinking about -" Or like, we're reviewing our business strategy. We are considering getting into the open source infrastructure software market. I need to know like, what's the total market opportunity? What are some of the pillars that our would-be competitors are marketing to? what are the values that they're trying to sell?" Yada yada yada. #What are the costs of their solutions?" That kind of stuff.

If I say, "I need to know these things," then a lot of people - maybe people don't even know things about those things - can actually answer those questions. You’ve scaled out the number of authors, because you've been able to say, "This is who I am. I am your audience." Because you've been able to say, "I'm your audience. This is exactly what I need to know. This is when I need to know. This is why I need to know it." If you can answer these five questions that we preach, then you can actually get the information you need quickly and way more effectively. So -

Len: Speaking of knowing what to read, we've been talking for almost an hour now and I think it might be time to move onto the subject of your book -

Jeff: Sure.

Len: Docker in Action, and specifically the second edition.

So, without going sort of too deep into the weeds, I wanted to ask you if you could explain just - imagine you're talking - and I'm sure actually this happens to you all the time. But if you're talking to someone who doesn't know how the computers go, what's Docker?

Jeff: Oh man - if I'm talking to somebody who doesn't know how the computers go, it's incredibly difficult to talk about. I would probably hit on - I don't know man. Honestly, this is something, that was specifically the question that held up chapter one for so long. Chapter one was a nightmare to write, because there are so many ways to talk about the benefits of this technology, that only someone who is experienced with software would really get. I could give -

And what everybody at the time, even back in the - even now, was falling back on - these metaphors. It's a virtual machine, but it's not really. It's an efficient virtual machine. But all that messaging actually gave rise to an entire world of people with a fundamental misunderstanding, who were technical, of what the thing was. And it led to a whole universe of pedantic security arguments. And it was just, it did the whole thing - a really big - it was really rough. I think it had a lot of negative impact, that whole marketing challenge.

Len: I don't want to interrupt you, but I just want to say what a - that's such a great answer on a number of levels. One of which is, actually when I was reading it - when I was reading the chapter, I was - the first chapter of your book. I was like, "That's an interesting way to open." You kind of open in medias res.

Jeff: Yeah, yeah.

Len: And I was like, "Huh, I wonder what was behind that decision?" Because obviously it's a very carefully written book. And it was obviously -

Jeff: Thank you.

Len: There was a decision behind that, and I can see it. Another reason I like that answer so much is that oftentimes - and I'm sure someone listening who doesn't know how the computers go, felt I was being condescending when I put it that way, but -

Jeff: No.

Len: In contemporary, well in - I mean, generally speaking we have this common sense idea - it's not explicit, that we believe this in our minds - but that anything can be more or less communicated pretty quickly.

And that's just not true. And so often - because we have this non-explicit belief, people are often immediately on the back foot if they can't understand something quickly. And to say straight up, like, "In order to understand this concept, what Docker is - there's a lot of stuff you have to know first, before we can talk about that."

It's just a great answer. If we approached many things in life that way, with that kind of understanding, a lot of us would be a lot less anxious and feel a lot less insulted all the time.

Jeff: Yeah. It's hard, I mean it's so hard, right? Because - I mean, I was learning about writing a book as I was doing it. The conversations that I was having with my publisher, and with the development editor and the feedback, were just across the board about chapter one. Everybody wanted to put the entire chapter into the first paragraph. Really, the first paragraph of the first chapter of the book, was by far and away the hardest thing to write.

Not because it was bad writing or because I was learning to write. I went through probably 1,000 completely viable first paragraphs. But -the problem was that every person you bring it to and ask for feedback, brings their own context, right? And if they want to have all their questions answered in the first paragraph, no one will be happy. This is a "please everyone" type scenario.

So for the executives, the CTOs out there, or the analysts that just want to read the first chapter of a book - if I really am writing a first chapter to talk to those individuals, then everyone else should just skip the first chapter, right?

Or bring something into the front matter that says, "Executive Summary." An actual executive summary, something that -

But it was so frustrating. Everybody wanted something different from it. And no two metaphors worked for anybody. So it was really super challenging. That was absolute misery.

But lessons learned, right? And the more I've learned about marketing and messaging and even sales since then, has been completely eye opening. I'm like, "Okay, well this is what they were going for." And I really wish they would've just come out and said certain things much earlier, because it would've taught me, and I probably would've been able to come to what they were looking for much more quickly, so -

Len: Thank you very much for sharing that. A large part of our audience is authors, or would-be authors, and hearing about how difficult these things can be sometimes, and the discussions that can happen around things, I think helps people feel a little bit less alone when they come to face them themselves.

And so, one of the interesting things about Docker, I think, is that, in order to understand it, it's important to have an understanding of the history of computing. And this is probably, you could probably - anyone who's interested in something could probably say the same thing about it. But, so - let's try and talk about it to someone who is - sort of knows enough, has concepts to understand what it is.

So for example, sorry, just to give a little bit of context, I'm sort of - I know a little bit of programming and stuff that and I used to build financial models in my investment banking days, and stuff that. But I'm Leanpub's resident non-technical person.

So let's put it this way. Let's say you're actually talking to me, and you're trying to explain to me what Docker is, what would you -?

Jeff: If I'm talking to you, and you have a little bit of programming experience, there's a term that almost all programmers become familiar with early in their career, called "dependency hell." Where you're trying to write something, or you're trying to install something, and it depends on a whole world of different things. And when you try to install them, you find out, "Well, I need this version. I need, - if I've got my library A and the software I'm trying to install needs version two of that, well then - some other program that I also need to use explicitly, requires version one of it."

And so you have to figure out ways to carefully untangle this very difficult to discover web of dependencies, when all those projects are sitting next to each other. Because they're pulling from the same locations. Which means you can't have two versions of the same thing in the same location, it just doesn't work.

And so, one of the biggest benefits that Docker provides, is it allows software authors to package up their software, and almost all of its dependencies, into a single abstract blob, right? And as a consumer, you can install these packaged blobs of software, and they can all co-exist, and they can all run at the same time. This was, for me - this was the first, this was my eureka moment with Docker. I'll give you the brief story.

So, six months prior to learning about Docker in May 2013, I was trying to install - I wanted to use a time series database for one of my personal projects. Because Amazon had a few, they were really, really good. I loved them. I became just absolutely enamored with doing that. So I was like, "I'm going to do this at home." And I found, what - probably the most popular open source project at the time was called "Graphite."

I went home one day after work and I was way into it. I'm like, "I'm going to get this thing set up and installed, and I'm going to have a nice setup, and I'm going to be able to do my stuff." I spent the next eight hours going through probably ten different installation guides, poring through config files to find commented out comments saying like, "Oh, if you actually want to install this thing to this thing," and then fighting with the dependency hell of the whole thing. And even at the end of eight hours, I couldn't get it done. I was just like, "Look, this is garbage. I never want to touch this again. I'm over it."

And then six months later, I come around to Docker and I'm like, "Alright, cool - let's kick the tires on this." I didn't really understand what it was all about yet, but I knew that I can sell software. And this was really early. They didn't have Docker Hub yet, but they had some kind of index for pulling software. And I said, "Let's try this out." And sure enough, I found an image that had Graphite in it. And including the time it took for me to install Docker, I had Graphite up and running within two and a half minutes. And I was just like, "Oh my God. this absolutely changes everything," right? Because suddenly I didn't have to pore through all that wasted effort. They're letting the software author or the publisher, package their software in a way that makes it consumable at scale. I no longer had to have an incredibly deep understanding of the software I want to consume, in order to do so. And for me, that was the real lights-on moment. This was the value that it was contributing at scale.

There's a whole universe of other benefits associated with using containers, Docker or otherwise, today. But I think that was probably the biggest, and continues to be the biggest benefit of using that software.

Len: Thank you very much for that. That got across to me some things that I hadn't quite internalized yet. For example, I remember one time, I was sort of managing some programmers developing an app. And this app was on the App Store and it was dependent on things external to itself. So it would sometimes break.

And so the idea behind Docker - or, well I mean, containers or containerization, had existed as a concept for a long time. Docker was one of the things that made it useable, as it were - to just really shortcut the explanation. But what happens is - instead of having this library that an app is dependent on being external to the app and changeable, so that then the way the app looks at it breaks, you actually put an instance of that library into a box with that app, and then that is all working on its own.

Jeff: Yeah. It had its own little copy of the whole world, right? It had everything it needed right there, and everywhere you go to pick up and drop this app, it carries it along with it. It doesn't have to worry - it still does have to worry about the way it interacts with the system, in an app, or whether it's a browser or an app or Linux itself, there is a little bit there. But it dramatically reduced that surface.

Len: And as I understand it as well, and I'm probably going to get this wrong - but these containers are immutable, is that correct? And so is that generally -? I mean, so okay - here's my cartoon -

Jeff: No, no, yeah.

Len: Here's my cartoon understanding of this. It used to be that you had your code out there somewhere running, right? And if you wanted to change it, you would go into it and change part of it. And that's something that's mutable. And something that's immutable means, "No - I'm not going to go into something that's out there and change it, I'm going to destroy it and replace it with something else."

Jeff: So, yes and no.

Len: Okay.

Jeff: The intent is to be immutable. They do not have to be immutable. They have - Docker and containers provide a lot of really interesting ways to provide reuse, in ways that promote not changing things. Because the hardest thing about making real immutable systems, is the fact that everything is designed to be changed, right? This is the root of modern computer architecture.

And so people - "immutable." What they really mean is disposable, okay? I don't know who it was that wrote the book somewhere that proliferated the term "immutable infrastructure" or "immutable computing." It is absolutely the completely incorrect term. When people are talking about pets versus cattle or they're getting rid of things when they're the old configuration, what they're really talking about is disposability.

And yeah, because containers are so, it's so easy to be consistent with creating them, because it's formulaic = I mean it's - we have this high-level attraction that literally does the exact same thing every single time, given the exact same inputs. It way reduced the bar to installing things. It gave us a language for talking about running software, and moving around software and running software that was a little bit more platform agnostic than it had been in the past. And that was really, really powerful.

But yeah, so this is a whole suite of tools, and really that whole - the whole eco system that grew around it - whether we're talking about Terraform from HashiCorp or other devops tool suites, it was really about seeking the best practice of changing things as little as possible. Like, instead just disposing of a prior generation and being able to bring the system up in any state along a timeline - a roll back does not necessarily mean change, mutating something back in time. It means literally blowing away the new thing and creating new from previous versions of the input. And so it is a roll forward. I could geek out on that all day if you let me keep talking.

Len: No, no that's a great explanation. But just on the subject of change - so Docker itself has changed. And you're writing a second edition of your book, along with your co-author.

Jeff: Yeah, no it's out.

Len: Oh it's complete?

Jeff: Yes it is. We finished it - let me remember, late summer.

Len: Sorry about that. I live so much in the world of in-progress publishing. The uncompleted. So that's fantastic.

Jeff: Yeah. Believe me, I can relate to that.

Len: And what were some of the things that are new to the second edition of Docker in Action

Jeff: So, the first edition was published on the precipice of what became known as orchestration and clustered platforms for running containerized software. And at the time that I published that book, Kubernetes was still very, very, very young, and very volatile. Amazon had the Elastic compute service out, and that was the default way to run containers in the cloud.

And Docker had - I think for the six months prior to writing the last chapter, had released something called Swarm, which was just a very little proof-of-concept-grade cluster control suite. And so the last chapter of the book, I think I even prefaced it with like, "Hey, heads up - all of this material is volatile, we're at the beginning of something crazy and new. But if you want to touch it and get interested in what's going on, here's chapter - I think 12 or 13".

But between then and the time that we published this book, the whole world had shifted and it became way - the whole - for whatever reason, the entire - it seems that the entire world became focused on high-scale service software. Because all of those companies ultimately were interested, really, in selling to enterprise. And all of those enterprises wanted to run service software, and they were all obsessed with high scale - whether or not they need it. And so that was really where it came back around to.

So we got a new version of - well, Swarm matured into something that was actually baked into Docker. Kubernetes matured and had really taken off. And we had got some cloud, some actual cloud-specific tools - and a whole bunch of stuff.

But that was the biggest change. For the most part, the material in the first edition held up really well. There was a few things that needed to be cleaned up. A few minor things that needed to be added, definitely some errata to take care of. But for the most part, it worked out really well.

I think we only ended up rewriting one or two chapters that ended up - it was just hard for people to read. And so we tried to clean up that material as best we can, and maybe pivot it on the way that we were explaining some of the concepts.

And then the last third of the book, we just ripped out and replaced with something that was new. Chapter 11 is all about service software. We removed the chapter about running Docker registries. And I think we added a chapter on - actually publishing pipelines and integrating that stuff with your CI/CD.

And we focused on Docker Swarm. Partially because it was built in. Anybody that is using Docker has it. But also because it was a very - compared to Kubernetes, it's a very straightforward platform to understand. And besides, most of the concept - really we're using Docker and Docker in Action to teach concepts, right? Because if you understand roughly what it's doing, you learn a lot about the system, plus you get to be much more productive in what you're doing.

Docker Swarm is a completely appropriate tool suite for teaching those things. And it's running everywhere where Docker is anyway. So we didn't have to worry about any kind of crazy - we were very picky in our picking third-party dependency. So I can't imagine having written a book about Kubernetes. I mean every edition would be a complete rewrite, with the amount of change that's happened to that ecosystem. So I'm very, very pleased with our decision not to include that.

Len: Actually on the subject of Kubernetes, is the fact that it changes so much a drawback in your opinion?

Jeff: No. I have a really interesting relationship with Kubernetes, in that I think - fundamentally, it's fine for what it is. I think from a software architecture perspective, it made some very interesting choices early on, that were honestly really awesome. It looks just like any other piece of service software when you actually look at it.

But the problem that I have with Kubernetes isn't so much from a user's perspective. I think from a developer’s perspective, it's fine. It might be a little bit verbose in places, but that's because it can do a lot. And I think that's really good. It's a very good general platform.

From a systems operator perspective, I would never take that job in a million years. The number of failure modes - the number of ways that that system can fail, is really amazing. It's just a lot of work, and not something that I think 90% of people who could do it, would actually want to.

So, yeah - it's fine, it does a good job. I don't - I mean, I just use - I have Kubernetes running locally, but only because Docker ships with it now, so -

Len: Thanks very much for sharing that opinion.

Moving on just to the last part of the interview, I wanted to ask you a couple of questions about your experience as an author of books.

Len: And so, you wrote your first book - I mean, you had a development editor and a team, because you were working with Manning. But then for the second edition, you worked with a co-author. How did you guys manage that?

Jeff: Well, it was interesting, because we were coming from two very different levels of experience at that point. Stephen's a great author, he'd never written a book before, right? And I had written a book and learned a lot about writing books in that time.

And so the deal I cut was like, "Look, I don't really actually have time to do this. So why don't you champion the new content, or most of the new content? And I'll work on, clean up stuff." I did write one or two new chapters, or one replacement chapter. And then I rewrote - I think, two chapters?

And so, there was a nice, clear delineation of who was responsible for what. But we - I mean, we bounced ideas off each other frequently. We had regular conversations, and we handed each other iterations for feedback. And so I read what he wrote and gave him feedback. And he read what I wrote and gave me feedback. Just we would working with a development editor, or a copy editor. I worked really hard to try to manage his expectations better than mine were.

I can be a bit of a perfectionist. There was a lot of parts of working with copy editors, or working with technical editors - they're like, especially early when I was doing my first edition - they just really rubbed me the wrong way. I went into it with an open mind, but chapter one - where I'm getting very strongly opinionated and conflicting feedback from every person I'm getting about the first paragraph, right? At a certain point, I'm just going to go, "Okay, well this is the paragraph. I'm not interested in your feedback anymore."

But I had to learn that, right? I had to learn that not all feedback you get from a technical editor is particularly useful. A lot of times, they just kind of want to share their experience. And they will give feedback that's like, "This isn't the way we do it where I work." I'm like, "Well, I'm really not particularly interested in that." And so like, it's really - it's a big exercise in managing your own expectations for what kind of feedback you'll receive, and really a good exercise in learning how to ask for feedback and constrain the feedback.

If you say, "What do you think?" Someone's going to say, "I like it." Which is just garbage feedback, right? I get nothing from that. But if I say, "I need to understand how many times did you have to re-read these three paragraphs before you could understand the thing?" Or maybe ask them like, "What did you take away from this paragraph?" Or, "Can you explain something that happened in this section?" And be specific.

The other thing that I tried to manage these expectations were around were, the whole process overall. And what level of - what to expect during the copy editing. What to expect during typesetting and all of that kind of stuff. And it was really fun. I mean, he experienced a lot of the same frustrations that I did, even though he had forewarning. But it was a lot of fun.

Len: I think that's an excellent story for people to hear, especially if you're going to be working with other people and particularly have - if you're working with a publishing company and they're going to assign editors to you, how you interact with them is - can be very challenging in a number of different ways.

Jeff: Yeah, it was good to - I'm glad that I did it. I think it really informed a lot about the process of building and marketing a book. I'm pretty confident that I understand it well enough that I could assemble the team and establish the cadence and communication touch points in order to do it myself. I could probably self-publish now and be very comfortable with it. I know a lot of copywriters, copy editors and people in that space - who, I'm sure that I could pull in to get feedback when I needed it. But I'm glad that we did it, so -

Len: There's a version of this question that I ask to Leanpub authors, if I'm interviewing them for this podcast, which is - if there's one thing we could fix for you or one thing we could build for you, what would you ask us to do? And so with respect to the publishing process generally, and your experience of it - if there was one thing that you could fix or one kind of "world peace button" you could click -?

Jeff: I'm just - if I find myself imagining the responses that you get - I think - I never care about tooling. I think that's probably some nice low-hanging fruit for people to talk about. People might be like, "Oh, I wish we could - wrote our book in Markdown and put it in GitHub," or something that. Or, "I wish we were just - can't I just use Google Docs for everything, or -?" But there's so many opinions in that world on what the right development tooling looks like, that I really don't care. I'm pretty flexible in that regard.

And so I think when we were doing it, they were just working on some of their more forward-leaning tech at Manning. But I mean, I wrote it in Word using their Word templates, which were very rough. And I was working on Word in a Mac. So half the things in the template were portable and there was version conflicts - everything Microsoft. And so it was just all sorts of weird stuff.

And rather than investing in fixing it, because this is not something that I need to do at scale - "I need to write one book. Can't I just learn how to work these garbage templates, these buggy templates - long enough to get through this book?" And I did, and it was great. I didn't worry about solving the deeper problem or anything that. So I'm pretty tolerant of that.

I think that there's one thing that I would fix or invest in. It's - I don't know that it's a good idea, just really helping people understand and level their expectations for what they're doing - what to expect out of it. And really help them understand for themselves why they're doing it. I was doing it because I knew it was going to be hard. And it was a rare opportunity, and I knew that I would learn a lot. And I did all of those things. I would not have done it -

I was pretty realistic with myself about what monetary compensation to expect. Or, I was realistic with myself in what I knew about publishing and writing a book beforehand - which was almost nothing. But I can imagine a lot of people maybe not going into it with the same kind of mental readiness. The onboarding experience I think is probably pretty good. If there's publishers out there who are having a hard time with authors not finishing their work, then that's probably your problem. They're probably in it for the wrong reasons, getting frustrated and bailing. So that'd be it.

Len: Thanks very much for sharing that. That's very insightful, I think. And it is something that anyone who - in any long term project - but a book is a particular kind of long term project and really, one ought to think hard about what one's in it for, before getting going.

Jeff: Yeah.

Len: And it's not just because you don't want to sort of - have a concept of wasting your time, it's just that like - if you have an idea of what you're going in it for, when you encounter setbacks and stuff that, you have a context to put them in - and that can be really helpful for getting to completion.

Well Jeff, thank you very much for doing this interview, and taking this time and for being willing to gamely cover so much ground. We talked about Amazon and coffee shops and things high and low. And thanks for your insights about writing and publishing as well, I really appreciated that.

Jeff: Thanks for having me, it was a joy - and let me know if you want to talk again.

Len: Okay, thanks very much.

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

---

Below are five free purchase codes for Docker in Action, Second Edition. These are good for one use each, so each one is first-come, first-serve:

dcktwr-B716
dcktwr-34F7
dcktwr-23E4
dcktwr-933C
dcktwr-8CB8

If you're too late, you can use this code:

podmatter19

...for a 40% discount on all purchases at Manning.