Andy Hunt was our special guest. Andy is a writer of books on software development, co-author of “The Pragmatic Programmer,” one of the 17 original authors of the Agile Manifesto, and a founder of “The Pragmatic Bookshelf” publishing agency.
Video is here.
Transcript
[00:00:00] Andy: Good. All right. Hi. How are you?
[00:00:02] Yegor: I have a lot of questions for you.
[00:00:04] Andy: Oh, good. I’ll have some answers and if I don’t know, I’ll make them up.
[00:00:07] Yegor: Hello everybody and welcome to the Shift-M podcast. Today, we have a very special guest, Andy Hunt, who we know for, first of all, of course, the famous book which is called The Pragmatic Programmer, the second one is the “Agile Manifesto’ who most of you know, and some of you love and some of you don’t. We’re gonna discuss that later. And of course the tons of books which were published by the agency, which was found by Andy called the Pragmatic Bookshelf. So a lot of respect to you, Andy. And welcome to the podcast.
[00:00:39] Andy: Thanks. Thanks for having me.
[00:00:41] Yegor: So my first question, the most interesting for me is, do you think we still, the young people who are now listening to us, they still need to think the way you were thinking 20 years ago when you were trying to, well, when you’re publishing your book 20 years ago? Your book made your career, I believe. And at that time, we didn’t have so many books written in the style you wrote your book. And the market was pretty, you know, more empty than now. Now we have tons of books. So is it still worse for a young programmer to actually think about developing the career that way by publishing a book? [00:01:17] Andy: Yes, I definitely think so. And I find it funny, it’s like, you know, is this valid for young people? It’s valid for old people too, you know. And there’s two angles to that. The stuff that we published in the “Pragmatic Programmer” back at the turn of the century, cough, cough, was, you know, we wanted to put, Dave Thomas and I, who wrote the book, we wanted to put that the learnings that we’d had from being consultants and working out in the field, you know, we kept seeing the same mistakes that teams and developers would make over and over again. And we thought, you know, our initial thought was, we’d just write a little white paper of, you know, tips, you know. Here’s the things we see people doing in current practice that’s not effective for them and here’s some suggestions for how to get around that. And that grew into the book.
And the funny thing is, here 20 years later, we just came out with the 20th anniversary edition of it last year, we had to change very little in the book 20 years on, you know. There was references back then to the build machine sitting in the corner, which now is a pipeline in the cloud. So, you know, tech marches on. And, you know, a lot of the languages weren’t useful. You know, a lot of experimental languages we had referred to and spoke of, no, one’s heard of now. They came and went. And new, interesting languages are out like Rust and Elixir and, you know, these sorts of things. So we had to make those sorts of changes.
But by and large, the advice all stayed the same because we’re all still the same. It’s the same people. People with the same, you know, default cognitive biases that we all share and, you know, all of our foibles as humans, that’s all the same. And that’s what keeps tripping us up and running into trouble. And yeah, as you mentioned, yeah, writing that book really launched mine and Dave’s career. And that was why we started the Pragmatic Bookshelf because, you know, really twofold. For on the one hand, we wanted to get good, valuable information out into the hands of everyday developers. And at the time, that was really rare. And now in a way, it’s almost even more rare because a lot of the stuff that’s out there is either someone trying to sell you something, you know, there’s some agenda behind it, sponsored by a big corporation or it’s, you know, it’s really interesting little open source project that has three committers and, you know, there’s not a lot to it.
There’s a lot of misinformation out there, you know. You can find a lot of YouTube videos saying here’s how you should do this and here’s how you should do that. And they’re just flat ass wrong. It’s not even a matter of being. They’re just wrong. So I think it’s, you know, as you mentioned, there’s a wealth of resources out there today, but sifting through them and finding the ones that are really valuable versus just the, you know, the faff, you know, it’s much harder to determine that. So we still, you know, a lot of people say, oh, the book is dead and, you know, everybody wants videos or this or that. No, that’s rubbish. People still want well curated books written by, you know, experts who’ve been there and who know how to get stuff done in whatever their environment of choice is. Whether it’s Rust or it’s Elixir, it’s Java, or it’s Python or what have you. And that is still, you know, getting that look inside the mind of an expert or even just someone who’s very proficient at the skill stack that you’re working on, that’s hugely valuable. And not even just to the reader, but if you wanna learn something, you know, really learn it solidly, the best thing you can do is give a talk on it, write a book on it, write an article on it. Because as soon as you start writing down what you think you know, you begin to realize, you know, the holes in your knowledge. Like well, how does the, you know, I’ve always done it this way. Why am I doing that? Does this really work? Is there a better way to do this? Is it, you know, so on and so on?
So, you know, those are kind of the main drivers, I think, as to why, you know, the Pragmatic Bookshelf is still, you know, a very successful tech publisher. It’s still independent. It’s not owned by, you know, any large corporation trying to force their product down your throat unlike some others that will remain nameless (laughing). But the, I mean, that kind of independence is rare these days, I think.
[00:05:59] Yegor: You know, in one of the videos you, I watched your interviews, you were saying that when you started this white paper, as you said, that was like, not a book but still a white paper, you just sent it to Addison-Wesley and then they said, okay, we’re gonna publish that. That sounds like a tremendous success. I don’t think that.
[00:06:15] *Andy**: That was remarkable. And I still don’t know whether to file it under success or blind luck or good timing or it was just the right thing at the right time. But yeah, we had no intent of really writing a book at first. You know, it was just this paper. But it started like every software project, right. It started growing and getting bigger. And someone said, well, you know, if you’re really serious about a book, you know, who’s your favorite publisher? I was like, “I have no idea.” And they gave us the very sage advice, said, we’ll go look on your book’s shelf, you know. Look at your bookcase and whose books do you have? And we looked.
Of course, at the time that was the Gang of Four book. And, you know, all the, you know, classic titles from Addison-Wesley at the time. And so, yeah, we literally blind emailed the editor for the computers and tech series or whatever they called it at the time, with our proposal and, you know, sample of the white paper. And we figured, when Dave and I sent that, we thought that, okay, of course, we’ve never written a book before. We know nothing about this. They’ll dismiss it out of hand. I mean, this is like going to random house and saying, well, I’ve got a book about this young wizard and, you know, will you publish this? And yeah, go away kid, right. Well, we figured we’d get some good constructive feedback from it and then we would know better what to do next time. And to our shock and maybe a little dismay, they were like, “No, we’ll take it. When can we have it?” It’s like, wow. Huh? (laughing).
[00:07:46] Yegor: How long you’ve worked now, with the Bookshelf, with the Pragmatic Bookshelf, can I do the same, you, me or somebody who is listening to us now, can we do the same with the Pragmatic Bookshelf? Just send an email.
[00:07:54] Andy: Absolutely. Just send an email. If you go to a pragprog.com, there’s a section in the menu bar, if you wanna be an author. And there’s a recommendations on what kind of format to send the stuff in and that kind of thing. But we get, up until very recently, we got, you know, the lion’s share of all of our submissions, exactly like that. Just from, you know, average developers who had something passionate they wanted to write about. Something they discovered. Something that they really enjoyed, you know. Well, I really like working in closure and I want to show people how to do a web, you know, thing in enclosure. I really love doing this in Rust or I really love this in whatever, NoSQL Databases, you know, whatever the topic might be. The key to that is, it’s something they’re passionate about. And that’s what really makes the difference. So, you don’t need to be a standard, you know, you don’t need to be a published author or anything.
[00:08:54] Yegor: How often do You reject these guys?
[00:08:56] Andy: A lot. both laughing Well, cause you know, it’s like any other kind of bell curve, I suppose. We’ll get submissions in any given week that range the gamut from, you know, really well thought out, well crafted, you know, this is clearly some of the top of their game versus, you know, somebody who maybe knows how to turn the computer on and says, Hey, I wanna write a book. And there’s no meat behind it, you know. But one we do tell people is, and it’s different about the Pragmatic Bookshelf, maybe from some other publishers, we have development editors that work with you to develop the text as you go. So if you’re not a professional teacher, professional writer, and I mean, most of us are developers, right, so these aren’t necessarily skills we have. That’s what our development editors help you with. They help get that information out of the subject matter experts had and onto the paper in our style, which has worked very well, lo these past several decades to help people, you know, get up to speed on pretty complex topics relatively quickly.
[00:10:06] Yegor: And if You compare my option of going to Amazon and doing self-publishing, which I do, I published five books over the last four years, and the option of going to a publisher like your agency, which one is better for me as an author.
[00:10:21] Andy: I’ll give the consult, excuse me, the consultant’s answer, it depends. For the most part, you’re better off going with an established publisher for one major reason and that’s audience reach because, you know, even as a well-known person, myself, the Bookshelf is maybe more well known and has a wider base. We have access to the development editor experts who have done tens, sometimes hundreds of these titles. They know how to do it. You know, we have our stable of all the sort of, support personnel, copy editing, proofreading, type setting, all these things. And, you know, it’s an interesting thing because I too have self-published books on Amazon. So, in addition to the tech books, which I go through a Pragmatic Bookshelf obviously, but I also write science fiction. And I just wrote a thriller, a psycho-supernatural, psychological thriller called “Weatherly Hall.”
[00:11:23] Yegor: That was my question. You published it not through Pragmatic Bookshelf. So you publish through other publisher.
[00:11:28] Andy: ’Cause it’s a fiction book. So I didn’t really wanna, you know, cross the stream. So I’ve done all the Sci-fi and stuff on my own. And you know, it’s harder because now, you have to do everything on your own. You have to line up the cover artist, the copy editor, the thing. You’ve got to do, all the scheduling, you’ve got to get someone to type set it or type set it yourself. You’ve gotta do all the marketing. You got to do, you know, everything that a company would do for you, you got to do yourself. I mean, you’ve done it. You know.
You’re, you know, chief cook and bottle washer. It all falls to you. And, you know, depending, you know, for the fiction books, I’m kind of comfortable doing that because there is just straight text, you know. There’s not a lot of formatting, a lot of code samples to keep up, you know, all the kinds of other stuff. But for a tech book, that starts to get a lot to have to manage, you know. Because now, not only are you writing and debugging the code that you’re writing and making sure that that code is right and it’s in the book and it’s type set correctly. And on top of the marketing and getting review copies and getting reviewers and having your mom say nice things about you on Amazon with a five-star review and you know, all of that. And I mean, you can do it, but you know, for time is the one thing we never have enough of.
And, you know, overall, and I think for my next book, I think I will, you know, find an agent and get my next fiction book published through a regular publisher because given X number of hours in the day, I’d rather spend that, learning and writing, not trying to figure out why that page breaker on page 27, doesn’t look right in this EPUB reader on Android, because someone complained about it, right. I mean, ‘cause this, if you’re doing it yourself, that’s the kind of morass you get sucked into amongst, you know, everything else. You know, Amazon’s now upping their prices on this and cutting your percent and they’re doing this and that and you know. And the other thing is, speaking of Amazon, any major publisher gets a much sweeter deal with Amazon than you as an individual will do. And not even just in terms of royalty, but in terms of sales support, you know, in terms of going after piracy violations, copyright violations, I mean the whole business aspect to it. A major publisher has deeper relations and access to more resources than any individual does. So, you know, yeah, you can do it yourself. I’ve done it myself. You’ve done it yourself. But you know, I think again, given the hours in the day, I’d rather have someone else do all that crap for me and I’d rather focus on the writing.
[00:14:09] Yegor: You know, as you mentioned Amazon, I can tell you a story and I would like your opinion about this. I have a friend who wrote a book, probably in the beginning of this year with another publisher, not Addison-Wesley, and not the Bookshelf. And he published that book. And that book became like in the top 10 on Amazon. And it stays in top 10. It stayed from top 10 for like, I think four months or five months. So there was a lot of, you know, a lot of copies were sold because of that. So I was telling to this guy that probably your book is on top because you went through a famous publisher. So probably there’s some kind of a deal between this publisher and Amazon. So they you know, my point is that, that book would not be in top 10, if you would just do it self publishing. So I might right?
[00:14:53] Andy: That’s correct. It’s correct, but it’s not as linear as that. So it’s not that any publisher has, you know, one secret recipe or one bit of secret sauce, it’s that they’ve got 37 little fingers into Amazon in different ways with different resources and you know. I mean, it’s their business, right. They know how to do this. They have professionals who do this all day long, you know. You know, I wanted write a press release for our new book. We’ve done that a few times, maybe a dozen times. Person at a major publisher, they’ve done this hundreds of times, thousands of times. They know what to do? Where to send it? How to get the reaction that you want? So, you know, it’s funny really. I mean, it comes, it’s the same kind of issue with software development teams, you know. It comes down to the fact that there’s really no shortcuts, you know. If you want something done well, or even world-class, you know, you can’t just buy that. That’s something you’ve got to cultivate and grow and build up. And if that’s your business and you’re doing that, that’s great, you know. And the rest of us, we’ll buy it from you as a service, you know. It doesn’t make sense for us to try to, you know, reinvent that wheel ourselves, necessarily.
[00:16:08] Yegor: So there is no like secret deal between Amazon and this publisher. When the publisher is…
[00:16:12] Andy: Oh, might be.
[00:16:13] Yegor: Might be?
[00:16:14] Andy: (laughing), could be. I mean, I have no evidence either way, you know. But that’s the thing. I mean, you know, any big company with their vendors and their suppliers, there is all kinds of stuff going on. But again, it’s probably not one thing. It’s probably a dozen different things that all contribute and add up and make it work.
[00:16:36] Yegor: Is it possible for again, consider a young, I mean, not the age wise, but you know, career wise, the young person who has not published anything before and now, this person is thinking about writing a book, is there a, some money down the road for this person or it’s pure altruism and pure publicity or something like that?
[00:16:57] Andy: It, again, it really depends on the subject matter and the timing. It can be very decent money. I mean, we’ve had authors who make six figures quite easily.
[00:17:09] Yegor: Like, can you give some examples, like six figures per year, per month.
[00:17:14] Andy: Over maybe a three-year, two year, two year, three year time span, you know. The kind of the, life of a tech book is often relatively short because versions change.
[00:17:23] Yegor: Or like, $10,000 a year, it’s possible?
[00:17:27] Andy: Oh, $100,000 dollars a year is possible.
[00:17:29] Yegor: $100,000? Wow.
[00:17:23] Andy: 250 a year is possible if, you know, if it’s a popular, hot tech topic that everyone’s into. But again, timing is everything. I remember one of the very early books that I wrote for the Bookshelf was on unit testing. And we put our version in Java, which was fine. But it was so close to C#. It’s like well, let’s make a C# version as well, and try and get, you know, the Microsoft crowd into it. And so we, you know, we put out the C# version of unit testing in Java and it stiffed, you know. It didn’t sell anything because that community wasn’t there yet, you know. It was one of those things where, you know, they’d heard about it and these other, you know, those Java folks over there were doing it. But it wasn’t really part of that culture yet. A couple of years later, maybe five years later, I’d have to look, but some number of years later, we got some more help on it. We came up with a second edition. And by then, the community was receptive to it. It’s like, oh, yes, yes. This is something we wanna do. And then it sold very well.
So you just never know. We’ve got some books, especially some of the more methodology oriented books that don’t sell a lot every year, but they sell consistently every single year. And over 15, 20 year time span that, you know, that adds up a lot. Because that kind of material doesn’t go out of date with a point release, like it might on some tech stack. So you have some kind of perennial books that just sit there and chug along quite happily, throwing off cash.
[00:19:16] Yegor: Well, that’s cool. These numbers are really gonna motivate people. You know, I’ve heard stories that if you go self-publishing like I did, then the doors are closed for me for all the publishing agencies. So nobody will accept me now because I made a mistake of going to the self publishing road. Is it true?
[00:19:36] Andy: I have heard that. And again, I think it depends. If so, if you have a title that you have self-published most often no other publisher will then take it, they won’t take an adopt it and do it, especially not in fiction. There’s a bit of an exception, you know. People will put stuff up on Leanpub, which isn’t really a publisher, but it’s, you know, a distributor, I suppose, might be a better phrase. And people will, you know, some publishers will go in and take that. The Bookshelf will go in and take what’s on Leanpub and consider it a draft. And then, you know, maybe work with the author and beef it up and come out with a better version. In a couple of cases, they’ve taken it as is if it was a really good effort. But yeah, for the most part, for a given title, if you decide to do it yourself, you’re gonna be doing it yourself. No one else is gonna touch it. But that doesn’t mean you can do, you can do something different with your next title. So it’s not like, you don’t get branded as an author that you’ve self published. You self published that title. Okay, well, we don’t want that. But if you wrote something similar, then you could go to a larger publisher with, you know, that or a completely different idea. And it’s, you know, that’s fine. That’s like a separate, it’s a totally separate entity.
[00:20:56] Yegor: I think their logic is that, for example, I come to you with my next book, and you take this book and you publish it. You start promoting this book and you automatically promote my other books because a lot of investments you make into marketing will automatically affect me as an author. And people will go to Amazon and see, okay, one book published by the Bookshelf and there are five books published by, but they don’t care who publish them. They just buy everything. And, you know, that’s kind of logic I think that the publishers.
[00:21:23] Andy: I think there’s a little bit of that. And some of it is just practicalities, especially with retail book publishing, where you’ve got a publisher, you’ve got a distributor, you’ve got bookstores like Barnes and Noble and Independence, you start getting into just practical limitations. Like, you know, you have to know that this book comes from this distributor, but you can’t have more than one distributor, whoever you are, if you’re Random House, if you’re Simon and Schuster, if you’re O’Riley, if you’re Addison-Wesley, if you’re us, every publisher has basically one distributor and you can’t change, you can change that over a course of months or years, but you can only have one at a time, ‘cause otherwise there’ll be chaos in the bookstores as they try to figure out where he get the book from.
So there’s some practical concerns just with the supply chain of this is how it works. And these things were set up in the, you know, maybe the 20s or the 30s and they’ve stayed that way, you know. So, you know, and its hard. You know, publishing is an industry that’s very reluctant to change. You know, a lot of publishers were very late to the e-book party, you know, kind of like, you know, Kodak was late to digital photography. They were like, oh, that’s fine. We’ll just make paper and film. Well, that didn’t work out so well for them and didn’t work well for publishers.
I distinctly remember, and I’ve told this story before, but Dave and I went to a publishing conference in the early days of the Bookshelf. And the publishers in general, were just trying to come to grips with how do we get our content out into EPUB and mobi formats and I think there were some others at the time. But you know, how do we get our content out in these formats? And there was a whole cottage industry doing file conversion. And it was a topic of all these talks at the conference and all these products. It was this whole big deal. And literally we’re sitting there in the audience and Dave on his laptop like, takes the text of one of our books, makes an EPUB, makes a mobi sitting there on the Wi-Fi in the conference hall. Because for us it was no big deal ‘cause we started off mostly knowing we wanted to do that. But even before that, we had a common format for all of our books. So it was easy for us to say, okay, well now we’d like to produce this and basically just add that as a back end. Whereas the other publishers had to contend with getting manuscripts in Word, in FrameMaker, in InDesign, in PoD with Pearl, in Markdown in, you know, Sanskrit written on a rock. I mean, you know, you name it.
[00:24:14] Yegor: Do You compete for authors? I mean, I know the answer will be yes. So let me rephrase. How do you compete for ulcers?
[00:24:22] Andy: So yes, the problem is, there’s a small number of really technically good people in the world. There’s a small number of people who can express their thoughts and write and teach very well. The Venn diagram intersection of those two is really small. Not a lot of us out there. And so yeah, every publisher is kind of clamoring for, you know, not even just the next author, but the next hit series. Something like a Heads First or, you know, R seven and seven or, you know, one of these, you know, like the XP series with Addison-Wesley back in the day. And yet, quite a few of our brethren publishers treat their authors, they treat them horribly. They spit them up, they chew them out, they screw them over on the contract. They do questionably legal things with the rights and the contracts. And we’d knew none of this until we’d started the business. And we’d have authors come to us from other publishers with these amazing tales. And honestly, the first, I don’t know, dozen or so were like, oh, well, they’re just being sour grapes. Surely, you know, such and such company can’t be that bad. And then you get, you know, the fourth or fifth person coming to you with the exact same story. And so like, wow, okay. And that’s always amazed me because, you know, we work in the knowledge business, right. As a publisher, even as a software developer too, but as a publisher, our raw material is authors. We’re small, We can’t afford to spit up and chew out, you know, good authors. So we treat our authors really well. I mean, to us, they’re really almost family. And so toward that end, we pay a 50%, half, five, zero, 50% royalty on our books. Most other major publishers pay 12, 15, something like that.
[00:26:25] Yegor: You’ll pay 50, really?
[00:26:27] Andy: 50%, really. Now there’s, I mean, that’s not really a catch. Some publishers will pay in advance. So you get a pile of cash. Maybe they’ll give you $5,000 up front. But the dirty secret is, 80 to 90% of their titles never earn that back. So they give you a pile of money up front and you never see another royalty from them. And I wasn’t really aware of this either when we started. That was something we sort of, learned as we went along. It’s like, wow, that doesn’t sound very cool. So we don’t pay any advance, but we just pay half of what we get. And whether that’s through retail channel, whether it’s direct off our website, whether it’s through a translation partner, you know, if you want your title, some foreign publisher wants your title published in, you know, Polish or Japanese or Australian or wherever it might be. Yeah, you know. And wherever it comes in, we split it with the authors. It’s that simple.
[00:27:25] Yegor: This is a surprise to me because I talked to another publisher before I decided to go to Amazon and do self-publishing, I had a contract, actually, a draft of a contract with a publisher and there was a 14%. So I compared 14 with the 55 on Amazon and of course, Amazon sound more, but if you offer 50, then there is no reason to do self-publishing because of this 5% would definitely offer a markup.
[00:27:48] Andy: And you get a development editor, you get all the support staff, the cover design, the type setting, you know, the whole package. And that’s why we’re still in business. you know, here at 20 years on. I mean, you’ve seen the statistics, most startups fail after, you know, two, three, four years at some small number. But we’ve been able to carry on through, you know, recessions, pandemics, whatever, because, you know, we treat our editors, we treat our authors, like friends and family. ‘Cause in often cases, they are, you know. We’ve known these people a long time. We’ve been through thick and thin together. We don’t treat them like, you know, some kind of fungible resource of just, you know, try to screw them out of every last little nickel. And there’s plenty of other folks who are very willing to do that and that is their business model. But, you know, we don’t.
[00:28:44] Yegor: Yeah. The numbers actually speak for themselves. So definitely 50%, that’s amazing. And do you influence the officers? You mentioned the situation, I write a book about Java and I come to you. And in my book, I say things which contradict, what other books say? For example, I say, don’t do this in Java because I believe this is a bad practice, but traditionally people think this is a good practice. For example, you take the look at the Gang of Four design patterns and they suggest to use this and that. But I write the book and say, this is wrong. Don’t do what they suggested many years ago. So my book is different. Will you reject that book even if it’s written on
[00:29:20] Andy: No. Actually that’d be good reason for us to want to publish it. We have a lot of advice that is maybe contrarian to the mainstream. But we don’t just take the author’s word for it. So, you know, for any title that goes through several stages of review and stages of technical review, so something like that would be passed by other figures in the community, who would say, yeah, yeah, we’re starting to see this. We think this is, you know, he’s onto something here or no, they’re completely paddling up the wrong thing. Have you asked them this, that and the other and give us points to discuss.
And in some fast moving technologies, especially like Elixir or Rails, we’ve had things like that at the last minute where it’s like, okay, well, the community had been saying do this sort of thing and now they’re changing at the last minute. Are they really? Is this really a change? Is this just another flash in the pan? And you know, we try to get as many opinions in as we can and try to get some sort of consensus to figure, okay, is the author just making this up or is this, you know, is this something real? And the other half of that is what keeps everybody honest. When your book is at some specific point done, and we’ve changed the number, but call it 70, 80%, something like that, when your book’s mostly done, we’ll go ahead and print the beta version of it. Just like beta software.
And, you know, we really, you know, ran with and kind of pioneered this concept and other folks have copied us off, you know. Other folks have rough cuts and you know, various other flavors of it. But the advantage is, once you start selling the beta version of the book, the author is still working on it, so if something like that goes out where it is, you know, a contrarian nature or something a little different from what common practice is, people who bought the book will tell us and say, oh, yo, this is great. Wow. I never thought of it that way. Or are you sure, you know?
Seems a little bit wackadoodle. But we’ll get feedback from it and then the author can change course as they see fit. And the other nice part about this is, when the book goes in beta, the author is getting royalties from it right away. You’re not waiting six months or a year. My wife wrote a textbook in nursing informatics, a classic textbook in that field as it turns out and watching her go through the process with an academic publisher was like trying to tow a glacier from Iceland by your teeth. I mean, it was unbelievable. And they went through all these hoops, as you’d expect with a large bureaucratic, you know, these folks were in business back in the time of Gutenberg and damn it, they’re not gonna change anything, you know, these days. But they had a, she and her coauthors, had submitted the final manuscript. And their editor’s like, thanks. That’s great, you know. We’ll have proof copies for you in about 12 to 14 months. And I’m, literally, right. My jaw’s on the floor. It’s like, what the hell are you gonna be doing for, y’all. Anyway, so yeah.
[00:32:40] Yegor: Did I understand it right, so you sell this beta copies to beta readers, right. Not to everybody. Not on the…
[00:32:44] Andy: To everybody, yep. They’re there for sale on the website. And the idea is you buy the beta copy and you get all the updates as the author makes them. And then, you get the final copy when the final copy is ready. You’re buying the book, you’re just buying in early.
[00:33:01] Yegor: So, there’ll be two books, basically. I buy the early version and then when the final version is out, I get this for free or how does it work?
[00:33:07] Andy: Yeah, it’s all the same book. So you get updates to it. So you might get the first, you know, say PDF or EPUB file that’s labeled beta zero. And then two, three weeks later, you get beta one and it’s got a new chapter in it. And then a couple of weeks later, you get beta two and beta three. And this chapter now has revisions. And they change this example ‘cause that code didn’t run on a Timex Sinclair 80, and you know, you put this thing. And there will like, close a new chapter at the end. And oh, now it’s got a table of contents. Now it’s got an index, whatever. You know, it goes through the bits and then you get, one day you get a file and it says, this is P one or P zero. I think we’ll probably start at P zero. I don’t know. But the first printing. So you get the, you know, the first one of that. And very often, you know, we provide free updates through the life of that edition.
So, you know, six months in you’ve gotten the, whether you bought beta or not, you bought the e-book version and there’s been some C change. Well, we’re no longer using CoffeeScript or we’re doing this or we’re doing that, whatever it might be. And you get P two, you get P three with, you know, errata fixed and, you know, whatever changes were made. And we will keep that up as long as we can. At some point for any technology, you know, you have to go to a new edition because they’ve changed. You know, it goes from Rail six to seven or whatever it might be. And the author has to put in enough, you know, months of effort. It’s like, okay, that’s a new book now. We’re gonna start over and go from there. But even then, we always give like, a discount coupon for previous buyers. So they’re not, you know, they’re not hit up for the whole amount again. But you know, it’s one of those things where, we wanna be fair to the author for the time they’ve put into it, but we wanna be fair to the customers as well. So they don’t have to do it. So, you know, things like that, we try to balance as best we can.
[00:34:57] Yegor: And who’s making the final decision to publish the book, to accept it or to not publish. Is it you or we have a committee for that?
[00:35:05] Andy: There is a committe. There’s a proposals committee. That’s what they do. They go through the proposals and they discuss the various technical merits, the stylistic merits the clarity of expression, you know, all these sorts of things. They look at the proposal. And, you know, it is rare to get a proposal that’s perfect in every way, right. It’s like, well, this guy really knows what he’s talking about, you know. This girl’s manuscript is perfect, but, and you know, this person can’t write very well. This person writes very well, but they don’t know what they’re talking about, you know. Any combination, you know, we’ve probably seen it. We’ve gotten some absolutely beautiful looking manuscripts that were very professionally done and beautiful graphics and just absolutely devoid of content, you know. Just empty air. And we’ve gotten some really rough and crude, you know, not very well-written but boy, they explained it really well. I really liked the examples they used. I really liked the, the, you know, their thinking behind it, but they clearly aren’t adept at expressing themselves. Well, we can fix that. That’s what the development editor’s for. So, it depends. And literally, we’ve seen everything in every combination you could possibly imagine.
[00:36:27] Yegor: And How large this proposal has to be? If somebody decides to submit to you, this is gonna be 10 pages, 100 pages, how big?
[00:36:27] Andy: The actual guidelines are on The website and they change every few years. But it’s not 100 pages. It’s usually on the order of a sample chapter of, I’m gonna say 10, 15, 20 pages, something on that order. And you know, there’s other questions, you know, why did you wanna write this? Who’s the audience were you writing it for, you know? Why should we be excited about this? I think that question is buried in there somewhere, but that’s really the important. Why are you excited about this? What makes you get up in the morning and be like, I wanna go write on this book project. I wanna go work on this because this is just so cool, you know. I love this, NoSQL, I love this LiveView. I love this, you know, Log4j remediation or whatever your bag is, you know. Why is it exciting? And why would anyone else be excited about it? And that’s really the key question. And if you have a compelling answer to that, you know, that goes a long way.
[00:37:37] Yegor: So You are sitting basically on the stream of the most interesting and the most brave ideas, which people are ready to write about. So you’re like a dispatcher. So you’re accepting them from everywhere in the world and you decide which ideas deserve to be visible and which are, so my question to you, what are the trends do you see?
[00:37:56] Andy: It seems really cool when you put it that way, let me just say. I feel like I should be a, you know, Blofeld in one of the double O seven Bond movies, stroking the white cat and cackling. (both laughing)
[00:38:10] Yegor: But my question is, what trends do you see? You you’ve been doing this for 20 years. So what do you see is happening over the last 10 years, let’s say? Where are we moving? We write more about programming languages, or we write more about management, or we stop writing about management? Like, what trends are obvious for you?
[00:38:28] Andy: Yes. All those. So the thing is, all these topics have sort of their season, you know. They kind of come and go, but they’re never gone forever. So, you know, there was a time where everybody and their dog wanted to write a methodology book. And most of them were frankly garbage because, in fact, we even had a code name for that. I think Dave Thomas coined it, we’d get a book that he’d say, well, this is basically what I did on my summer vacation. It was a summer vacation book. So you know, it was a case study with a sample size of one. And you know, this one person, this one group, did this one project at one place and it didn’t suck. And now they wanna say, hey, you know, the secret is you have to have orange soda at launch ‘cause that’s what worked for us, you know. This kind of thing.
You know, that kind of proposal never goes away, but it’s interesting to see, you know, there’ll be a time span where you’ll get an awful lot of votes and then it’ll sort of die down and then it’ll flare back up and then it’ll die down. And then you’ll, you’ll get things like, I think when Safe was first sort of bandied about as a method, cough, we’d get a lot of proposals saying, hey, here’s how to be successful with Safe. And then people realized that you couldn’t be, and that it was a scam. And then, we don’t get many proposals on that anymore because A, no one’s interested in it, and B, the people who are suffering with it, from what I hear, are suffering mightily. It’s not going well for them. So you get some things like that. New languages are always, everyone’s always interested in a new language, because every language has its strengths and its weaknesses. And sometimes you’re aware of what those are, sometimes it’s a surprise.
So we’re always looking for a language where we’re better able to express ourselves where it’s, you know, you’re trying to balance. You want something that’s less verbose but you wanna be able to understand it. You want something that’s easy enough to pick up, but, you know, you don’t want to be so complicated. Something like, like a Haskell, really scares people off because yes, you can learn it, but it’s a kind of a vertical learning curve and that kind of thing, as opposed to something like Go which is very easy to learn, but then you discover it’s pretty limited. There’s some things you just can’t do or can’t do elegantly. And that’s by design. I mean, you know, none of this is a state secret, right. These are, you know, what the language designers were we’re heading for. And you’ve got things like C++, which I worked in for years and years. And, you know, the old joke we had there was that’s enough rope to shoot yourself in the foot. It is, you know, as Bjorn calls it, a multi paradigm language. You can do anything in it. Should you? Is another matter entirely. So we’re always looking for new programming languages. So something like Rust comes out, you know. A lot of excitement behind that. That’s probably harder to learn than most people think, or at least it’s, again, it’s, trade-offs. You have to do a little bit more thinking just to get the bloody thing to compile. But once you’ve got it, once you sort of passed that threshold, you’re in pretty good shape. You’ve got some guarantees about what is, and is not gonna happen to your code once it’s been running. The a lot of excitement lately in the Elixir space, you know, for a new-ish language, that’s been doing very well. And we’ve got a lot of books on different topics in that space.
And they’ve got this, you know, LiveView thing that there’s a lot of excitement about where you can get, you know, really nice, real-time websites with a lot less effort and heartache than other comparable tech stacks. So you’ve got things, you know, there’s there’s bits of that, that kind of flare up and are interesting. Of course, when Rails first came out, I mean, that was absolutely huge, you know. That was the first big topic that we really were in a position to leverage. And you talk about poaching authors, it was kind of funny who came with the Rails book, and then start coming out with other books on Ruby, in the same series. And one of our friendly publishers expressed dismay that every time they went after a leading person in the community to write for us, they were already writing us a book and then they couldn’t poach them ‘cause we’d already had them. And that’s happened a few times in a few different language sectors. Because yeah, everyone likes the shiny new language and we do publish a fair bit on shiny new languages. And it’s kind of like the place to go for that leading edge cool kind of stuff.
You know, we don’t have any books on maintaining COBOL legacy systems, you know. We’ve had very few books on PHP, one or two and a bit, you know. Kind of a particular niche topic area. And, you know, for a simple reason, we have nothing against these technologies. I mean, these days, if you’re an expert at maintaining COBOL systems, you know, cry to me from your yacht in the Caribbean, because you know, they’re gonna pay you really well, ‘cause it’s a very rare skill these days, you know. Everyone’s kind of died off there.
But, you know, for things like PHP or even Python, it’s such a crowded market. Everyone else has a bazillion books and tutorials and video series and online resources, you know. There’s a lot out there already for that. But as you get beyond, you know, sort of the beginner and intermediate level and get into the more advanced, practical advanced topics, if you’re going for practical theoretical topics, more of a textbook publisher is probably where you’re gonna land. But if this is stuff you’re actually doing for your day job, then that kind of falls to us. And that’s why readers come to us ‘cause they’re in that, you know, more advanced, anywhere from slightly more advanced to very advanced. But it’s their job. It’s not a theoretical nicety. It’s, I need to get this working by next Monday.
[00:44:44] Yegor: So are you trying, like being this dispatcher as we discussed? It’s not an easy job, that’s for sure. But are you trying to be objective at this position, or you just ignore this goal and allow yourself to be subjective? For example, I can give you a practical example. You’re a big fan of Agile, not just a fan, you’re the founder of this idea. So let’s say, and there are many, many people in the market who have different opinions about Agile. So let’s say, a very good author with very good style with very good explanations come to Europe, to you, as a publisher, with a book which criticizes Agile and suggests different approach and criticizes Agile, you know. That’s the first objective of the book will be to criticize Agile. Will you try to be objective? Or you will just say, oh not…
[00:45:26] Andy: It’s, we would be somewhat, but not completely objective. So, they would need to, for me personally, they’d need to convince me of their case, which isn’t hard to do. Because the problem with Agile, of course, is no one’s actually doing it and what they are thinking, you know, what they think they’re doing. and I’ve said this before, right. People come to me like, “Oh, we’re Agile.” It’s like, “Oh really?” They’re like, “Yes” You find out they’re doing half of the Scrum practices badly and they use Jira. And that’s “Yes, we’re Agile, baby.” That’s like, “Mm, not so much.” So I’ll be the first to say that, what people think they’re doing is wrong and is wrong headed. And I’ll be the first to say that Agile was never designed to be a perfect fit in every scenario.
And if you look at someone like Dave Snowden’s Cynefin model, you can see why that is. It’s like it works in the complicated domain. It’s not a good fit for these other three domains. And you are better off using something else in here. So like anything else, it’s about context. But that’s kind of what I would wanna see. So hypothetically, in a book like that, I’d want to see a discussion of any method, really. It says, well, here’s where it works and why? Here’s, where it doesn’t work and why? And here’s what you might wanna do in this case, instead, and here’s what you might wanna do in that case, instead. Anyone who comes to me with a proposal that says, well, here is the software engineering process, you just throw developers in, turn the crank and software shoots out the other side, I’ll delete it out of hand because I know they’re full of crap. Because it doesn’t work that way, right. It is a complex multidisciplinary subject filled with nuance and limited understanding.
And oh, by the way, we’ve only been doing this thing for, depending where you count, you know, 1947, early 50s, you know. 50, 60 years, you know. Some short number of decades. Nothing compared to medicine, legal, law, you know, things we’ve been doing for thousands of years and we’ve got a little bit more adept at. We’ve only been doing this, you know, less than one human lifetime and it’s still embryonic. We don’t know the best way to do stuff. And interestingly, you mentioned the Manifesto. I think everybody forgot the very first line. The very first line of the Manifesto says, “We are uncovering better ways of developing software.” It doesn’t say we discovered the holy grail, you know, written in gold gilt and, you know, on a tablet. We’re discussing, we’re uncovering, we’re discovering, we’re uncovering better ways of doing this. And I think where the industry kind of fell down was, we stopped looking and said, oh, well, we’ll just use Scrum.
We’ll use a ticketing system. That’s all we need. And you know, that’s kind of a favorite pet topic of mine. I’m diverging wildly, but it’s fun. Scrum is a lightweight project management framework. That’s all it is. Well, that’s nice. That’s about 10% of the problem space you’ve got to address. What about all the rest of it, right? It doesn’t cover that. You know, you have to have something like XP. You have to have the good foundation of solid version control. And if you’re doing continuous integration, you know, don’t tell me you’re using PRs and you know, this kind of nonsense. And, you know, having these long running feature branches and you know. Here’s a good technology. Here’s Git, right. Version control, wonderful. There’s ways you can use it well and there’s ways you can use it poorly. It’s not the technology’s fault, by the way. It’s what we do with it. So, if you send a book and tell me to do something stupid with Git, yes, we will call you on it and say, no, that’s, that’s a poor idea. You’re giving out what we think is bad advice. If you can justify it in this context, especially, okay, let’s talk about it. But you know, there’s a lot of nuance out there. And we try to encourage authors to explore, especially on a methodology book, when is this good advice? When should I not do this? Where does this fall apart? Where are the edges?
[00:49:43] Yegor: You know, I was listening to a few of your talks on Agile. I completely agree with you on one important point you making, that people are doing a lot of practices, but they’re not doing one core practice and don’t deliver incrementally. They don’t deliver earlier. They deliver like when it’s ready, then they start delivering. And the question is why it’s happening? Not enough books? Not enough education? What’s the problem with the industry, in general?
[00:50:08] Andy: So How long do we have? (both laughing) Yes, yes. I had forgotten about the story. I was actually looking at something this morning and I ran across this and it reminded me, it was exactly what you’re talking about. A couple of years ago, I was offering some talks and workshops for a team. And they were told that they could not do any incremental or iterative development at all. They were allowed, by management, to do a single gold master at the end of a multi-year development project. No review, no feedback before then, not even internally. And I have discussed it with them. I said, “Well, you realize the whole point of Agile is feedback and fast feedback so that you can steer.” They said, “Well, didn’t matter. This was what the sponsors and the executives demanded. They wanted one delivery at the end of the project.” I’m like, “Okay, fine. Well, let’s see how that works out.” So I went on. Spoke elsewhere. Did other clients, what not. A year or two went by. And I stumbled across this story. I was like, oh, “I should find out what happened to these folks.” And so, I emailed back and said, “Hey guys, just checking in. Wanted to see how this was going.” And the email bounced ‘cause the domain didn’t exist anymore.
So, that’s how that went. Why does this happen? So I have a theory. And again, this goes back to the newness of the field. So at some point in the 80s, 90s into the odds, you know, every mom and pop business, every small manufacturer, every large manufacturer, every company got to a point where they’re like, dang it, we need software. And they, you know, they’re not experts. There’s this thing. Look, they’ve got software over there at our competitor. We need software. I don’t know what is software? Let’s buy one. I wanna buy a software and hook it up to an internet, right. So, you know, you’ve got folks running large businesses, very successfully who were like suddenly, this is something they need and they don’t know. They never read Fred Brooks. They never read “The Pragmatic Programmer.” It’s just a thing they need.
So you do it like any other thing you need in big business. You set up an annual budget and you have managers and sub-managers and squad leaders and team leaders, and you build this whole bureaucracy around it and, you know, you treat it like a manufacturing project because we’ve kind of figured out how to do that. So what I draw as a comparison is, if you look at the beginning of industrialization, when we were just getting, you know, the idea of machines to do labor, it was a horror show, right, you know. You get that, what’s that lovely phrase about the dark satanic mills in England, you know, with the coal mining and the factories and everything. You had the Triangle Shirtwaist fire disaster in the US where these people burned to death ‘cause we hadn’t figured out you needed exits. Right?
So all these kinds of, you know, children getting maimed and killed. And, you know, it’s like, it’d be like going as a fast food worker, knowing that the soft serve ice cream machine could rip your limbs off at any time, just because of the way it was constructed, right. That that was the world they lived in ‘cause it was new. We didn’t really clue out, as a society, that we needed to be a little bit kinder about workers hours and safety conditions and guards. And hey, maybe throwing young children in the middle of something with spinning cogs and wheels was not a great idea. But it took time to sort of figure all that out and come to terms with it and make it so that we could use technology without it destroying society too badly. Whether we ever succeeded on that, is another question. But you know, it was a lot worse early on. And I think that’s where we are with software development, with computing. These are the early days still. This is the phase of the technology where people are getting limbs ripped off because we don’t have proper safety and security. We don’t know how to integrate it well in society. And if you look, you know, especially at the disinformation and all the issues around the pandemic in the last several years, it’s getting a lot worse. As the tech gets more powerful and our understanding of how to integrate it into society without killing ourselves, we’re not there yet, you know. It took a while when the industrial revolution, it’s gonna take a while in the information revolution. These things don’t happen overnight. We’ll figure it out at some point or at least mitigate it to the point where, you know, we can get by and you know, it’s not gonna wreck us. But it’s gonna take a while.
[00:55:10] Yegor: My final question to you. So after these 20 years of telling people about Agile and seeing how people misunderstand that and experiencing this lack of adoption of this really good concept and originally, but as you said, as we all see what’s happening now, people just take some practices, but they don’t understand the full idea, so do you still believe in this idea? Do you still think that this is the right idea?
[00:55:38] Andy: I do with, with some caveats. The important thing, the message that got lost and the important message, I think, that still needs to be out there is, you need an ecosystem not a process. There’s no process that will ever work for software development because software development is a complex adaptive system. Processes are basically linear. So you’re trying to use a linear tool in a nonlinear system. It’s never gonna work. There’s no substitute for talented experienced developers. That’s the big problem. And we keep trying to find some shortcut to that. There isn’t one. Not yet, not in the next 50 years. AI, maybe. That’s a wild card. We’ll see what happens sometime down the road. I still can’t get through self checkout successfully. So we’ve got some time. We got some progress to make on that front. But you know, somebody early on in the Agile movement had a great example. And I don’t remember who said this, so apologies. I can’t credit it, but the picture of this visual that you’re trying to make it across an unknown cave in the dark, pitch dark. You’re down in a cave with a tiny little flashlight. Now, do you wanna go running full speed in any particular direction? No. You wanna take tiny steps, swing the flashlight around, look where you put your foot before you go. You wanna take small steps, right? Get fast feedback. Look where you’re going.
And instead what we have is, people in the same cave saying, okay, this worked great with the one person, you know, with the flashlight, they did wonderful for us. Now we’re gonna scale this up and we’re gonna bring in a tandem tractor trailer, fully loaded and you know, you can’t go less than 80 miles an hour. Hit the gas. Go. And I see them laughing on the Zoom here, right. And how do you think that works out? And that’s exactly what happens. And then you see in the news, another $20 million disaster project that never saw the light of day, or, you know, this giant data breach at some company that we hold dear or whatever it might be. And that’s exactly right. It’s like, something that works well for a small number of skilled people, works well for a small number of skilled people. You’re not gonna scale that to 50 teams or 100 teams or 1,000 teams, unless you’re really good at doing that. And not a lot of companies are.
[00:58:05] Yegor: But they will be. Let’s hope for that. Maybe.
[00:58:06] Andy: Maybe. I mean, I find it funny. It’s like, you know, it’s a cliche to say, but if you look at startups with a small development team and you know, really high motivation, lot of talent, small team, small number of communication paths, they typically do very well. They typically kick the butt of a large bureaucratic company with dozens, hundreds of teams that can’t get out of its own way. And that is always true. That is always going to be true, you know. Borrowing some advanced in AI that we can’t see on the horizon yet, that’s how it’s gonna be.
[00:58:52] Yegor: All right. That’s quite positive to hear that from you, the author of the idea. So we will stay positive. Many things were coming for this podcast are getting a lot of respect for what you’ve done to us, programmers, the books, which you wrote, the ideas which you introduced. Thanks a lot. See you sometime next time.
[00:59:12] Andy: Thanks So much for having me.
[00:59:14] Yegor: Bye bye.
