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 (Andy asked to take it down).
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.
