Andy Hunt and Dave Thomas wrote the seminal software development book, The Pragmatic Programmer, were original authors of the Agile Manifesto, and started a publishing company.
Andy discusses the book, their publishing company, the future of agile development, and even sci-fi novels.
Transcript for episode 69 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
Welcome to Test and Code podcast about software development, software testing, and Python.
In this episode, I talk with Andy Hunt. Andy Hunt and Dave Thomas wrote the seminal software development book Pragmatic Programmer. They were original authors of The Agile Manifesto and started a publishing company. Andy discusses their book, their publishing company, the future of agile development, and even scifi novels. I think it’s a fun episode and you’ll get a lot out of it.
Thank you to PyCharm for sponsoring this episode. Just the other day, PyCharm saved me tons of time with its super powerful debugger. I had some fixtures to set up, my system under test into a certain state and a test that depended on that state. But after the test was done, the state was wrong, really didn’t know which command was causing the problem, and I was on a tight deadline.
A few clicks in the gutter placed breakpoints at the beginning of each fixture and at the test. Now I ran the test under debug and watched the system change as I continued through the breakpoints. As soon as I saw the state change, I knew which fixture was causing the problem and I did it all again, this time stepping through each line of the problem fixture bambound the problematic command. Once I saw it, it was obvious how to fix it. But within five minutes I was on to the next part of my day. And one more thing I want to bring up. The Python’s team knows that we all hate it when our code runs slower in a debugger than out of the debugger, so they squeezed every optimization they could into making the debugger blazing fast. And that’s awesome. Try it out yourself by going to Testingcode.com PyCharm. That link will give you four months to try out pie PyCharm Pro today on Testing Coda. I am supremely honored to have Andy Hunt on the show. If there’s an off chance that somebody might not know who you are, could you introduce yourself?
Sure, Brian. Well, let’s see.
I wrote a little book once with Dave Thomas called The Pragmatic Programmer that a lot of people like.
We were two of the 17 people who wrote The Agile Manifesto back in the day.
We run the Pragmatic Bookshelf Publishing Company, which has gotten some award winning and best selling books for developers and their managers. And mostly I try to keep busy and see what things I can screw up and get in the middle of and play with and that sort of thing causing trouble mostly.
That’s awesome. I actually love that sort of an attitude. The Pragmatic Programmers was extremely important in my career. I read it early 2000s at a time where I was getting a little frustrated with my work at the time, and just a lot of the tips inside there gave me inspiration to change my environment, changed my processes to make it work, and I referred to it at the time as a guerrilla process improvement, because I just did it.
Instead of asking for permission, I asked for forgiveness.
Yeah. And that was really sort of the point at the time because I’ve told the story, I think just about every interview. But Dave and I started off we didn’t intend to write a book at all. We were just writing like a little white paper for our clients at the time because we kept seeing these sorts of same issues and same problems time and time again. So I figured, all right, well, we just give a client a little head start before we got there with just a little list of tips and think about these things, try to do these things that sort of business. And unlike any software project ever, the project grew in scope beyond a little white paper to a full on book. But I think it’s been so well received and continues to be so well received because this was real. This was our experiences in the trenches with real users, real clients, our hands dirty in the code, a lot of stuff that gets written about processes and philosophies of programming at best. It worked for somebody once in one company.
Maybe one of the things I loved about it was a couple of things.
Well, one, I reread it, I think, last year, and it’s held up fairly well against time. It still is pretty relevant. There’s not a lot of language specific stuff in there or anything.
It’s both amazing and I suppose reasonable that it hasn’t changed much if you go back and read it.
Yeah.
I mean, a lot of the tech references are pretty outdated.
Showing it to one of my kids, it’s like you have to explain what CORBA was that hot language Eiffel that no one’s ever heard of or Tom, these things that were like sort of leading edge cool at the time and now dustbin of history sort of thing.
But if you take away that sort of crust, it’s kind of like going back and reading Mythical Man month, and he’s talking about mainframes and operating systems that no one’s had their hands on for decades. But all the issues are exactly the same as they are today. You could replace OS 360 with the latest Mac OS or Linux or Windows, pick some contemporary tech and the rest of the book works complete. It’s exactly the same because people haven’t changed. We’re the same.
For better or worse, we haven’t changed over 2030, 40, 50 years.
Just the tech has. And even then, not as much as you might imagine.
The other thing I already mentioned this before, but the fact that a lot of the other process improvement books, things like writing about XP, even in Scrum and others, they involved having you to get the entire team to buy into it. And that’s one of the things that the Pragmatic is great, is you don’t need team buy into improve your individual process.
Yeah.
And it’s an interesting thing because if you wait for the entire team to do something or you wait for the organization to buy in to do something, you may be waiting a very long time.
There’s an awful lot you can do on a personal level to make things better.
And I like the idea that you can do that and sort of lead by example, because other people will see that you’re not suffering. You’re not spending hours in the debugger or you’re not getting paged at midnight paged. Listen to me. You’re not getting that slack or text in the middle of the night kind of deal. And then they’ll be like, Dude, what’s your secret? What do you got? And then you can start sharing that.
And as much as I appreciate that and I’m glad we’re able to step into that niche, it also occurs to me that you can only go sort of so far with that kind of a model. And I think this is where a lot of current organizations might be falling down on their Agile adoptions or their process adoptions. There are some things that if you want the full benefit, you’ve got to get the whole organization to buy in. And that’s where we run into trouble, because you might have a very nice set of very agile, very responsive teams, but they’re butting heads with traditional accounting methods, traditional scheduling, traditional budgeting, whatever sort of the rest of the infrastructure of the organization is not Agile in the least.
And that causes a lot of friction and a lot of difficulties. So there is a certain point where if you want to get beyond and get to a higher state, you do have to drag in the rest of the.ORG.
Yeah, but what Agile means really is kind of different to a lot of people now.
Oh, I will take that one further. I think it means anything you want it to mean at this stage of the game. I mean, I’ve been quoted from saying this before, but it galls me. It frustrates me beyond belief to find out that a large number of people I won’t say a majority. I’m hoping it’s not the majority, but a very large percent of people. To them, Agile is. Well, we have a stand up meeting, and we use Jira.
Well, yeah, agile is a Jira ticket. It’s like, oh, my goodness, no, not that. There was just on Twitter the other day, somebody posted a picture of the Safe process model. Oh, my gosh, right. It looks like, I don’t know. It’s a cross between Monopoly and Candy Land. It’s this big board with all these little blocks and arrows and stuff on it. And way over at the right, there’s this tiny little dot labeled the customer.
Some people are kind of forgetting that.
I think one of the names thrown around before Agile came along was Lightweight methods.
Yeah. So what happened there the folks who booked the facility for us, which was some combination of Aleister Coburn and Bob Martin and those folks, we booked this room in the hotel for the 17 of us, a conference room and stuff. And they needed to know, what name do you want on this conference? Because we’re basically handling like a miniature conference.
And so that and some of the Wiki and materials at the time, we called it lightweight methods, because the idea was we wanted to just get at producing stuff, at writing code, at shipping code, producing value, and not getting all hung up on all the bureaucracy and all the paperwork.
And that was a big discussion at the Snowbird meeting when the manifesto was created was, well, what do we call this?
And lightweight was reasonable. But folks clearly thought, well, the problem with that is that has the vision that you could get your clock cleaned by a heavyweight.
They would just come in and deck you and floor you kind of thing. So that really wasn’t quite the right tone we wanted to set. So we considered words like adaptive, responsive.
And I think in hindsight, I think we might have been better off if we’d gone with something like adaptive or some word that meant something closer to that. Because again, just seeing how people sort of misunderstand and misapply what Agility was trying to get at is really very frustrating, and they typically really miss out on the whole adaptation part of it. And this is one of those things that’s been a frustration really my whole career, because it used to be you had the same sort of superstition in the waterfall days that, well, all we have to do is follow this process and everything will turn out okay.
And I distinctly remember one of the first captive jobs that I had before I became a consultant. They demanded detailed design documents in pseudocode for everything that you wrote that they filed away on the backs and no one ever looked at. But you had to sort of go through the motions.
And it’s that same sort of slavish devotion to a process.
It’s a superstition, it’s a cargo culty kind of superstition, thinking, well, we’ll just do this and everything will be okay. And no, it won’t. You actually have to think. You actually have to try stuff, you have to experiment, you have to get data, you have to try things and accept it. Okay, well, that didn’t work out. Well, let’s try it this other way and see if that works out.
It’s a very organic process.
And all these folks who think, well, we just follow the process. It will be fine. No, it doesn’t work. Whether it’s safe, whether it’s scrum, whether it’s waterfall, whether it’s rough, you cannot just follow the process and expect that to save you. It has never worked that way. It will never work that way. That’s just how the game is played.
Yeah. My experience with that was a project where we had tons of meetings and reams and reams of documentation, documenting all of the class hierarchies in UML, and all the interaction bounce diagrams before any code was written.
And it was a nightmare. As soon as we started writing the code, all of the documentation that we spent months writing just was irrelevant at that point.
Yeah, absolutely. And sadly, I mean, that’s a very common experience, because what that does is that exposes the actual dynamic of writing software, that it is very fluid. Everything you do sort of impacts everything else. It’s chaotic in that sense and in the chaos theory sense, not the running around screaming, although that does happen. Right.
But the folks who don’t have experience, so the rest of the organization, the managers, the stakeholders, the users, they assume it’s a very linear process. And what’s funny is a lot of times you’ll see people saying, oh, software construction should be like building construction. That’s a totally linear process. Right? You get the architect and they draw the plans and then the builders just build it and you move in and it’s straight line linear.
No mistakes. None of the stuff we put up with. Yeah, it doesn’t work there either.
The house we’re in now, this house was built when we moved in. It was being built and watching the construction process, watching the errors, the omissions, the rework, the difficulties, actually, I guess we are kind of a lot like building construction. It’s pretty messed up, too. They put the staircase in backwards at one point.
So this idea, this kind of like ideal engineering fantasy, doesn’t even exist in the real world. But from the outside, that’s how you kind of think it works and you’d like for it to work that way. But as anyone can tell you, the real world is a lot Messier than that.
Well, is gross.
Your answer to a lot of this, that’s the intent.
So the story behind the grows method ideas.
I actually had the notion for this back around probably 2006 or so.
I was starting to do the research for the Pragmatic thinking and Learning book, and I was giving talks and lectures on that. And that published in 2008, if I remember.
Right.
So for that sort of two, three year period, while I was really working on that material of neuroscience and cognition and learning and how the brain works, these kinds of things, I’m looking at this thinking, wow, we really missed the boat on a lot of this process discussion and a lot of methodology.
By not taking into account the limitations and the functioning of the human mind, we sort of assume people are like code or people are robots. We say, do this and they go do that. Well, they don’t. They never have.
We don’t work like that. We’ve got significant cognitive biases, we’ve got significant processing errors. And none of our approaches really take that into account. They don’t take into account our limitations. So I had the idea back then like, wow, it really would be powerful to develop a methodology that, for instance, had learning as a first class part of the method, because that’s something we have to do all the time, right. We have to learn the domain, we have to learn the new tech.
It’s Tuesday. There’s been 37 new JavaScript frameworks just came out today, right.
There’s always new stuff to have to learn, but you’re also learning from the evolving system itself, what its characteristics are, what emergent properties are coming from the system. So we’re learning from everyone all the time, but we’re not really taught to do that or we’re skilled to do that. And that’s not part of any of the methods. They just assume that that’s something that’s going to happen on its own, magically.
And it’s not if you don’t schedule it, it’s not going to happen.
What I wanted to do with Growers was sort of meld a couple of big ideas.
The notion from the Dreyfus model that you can’t treat beginners and experts the same way because they approach a problem with very different mindsets, different problem solving models, different skills.
You have to really hand hold a beginner and give them step by step instructions, and you can’t do that with an expert or you will bring their performance down to the level of a beginner. And they’ve actually done studies on this, which is really kind of interesting.
This isn’t just hand waving. People have actually studied this, and it’s a fascinating area. But you’ve got to treat beginners differently.
You have to be mindful of the problems in human cognition and the need that we have to continually be learning, continually be aware and revisit what we’re doing. And all these things have to be sort of baked in and part of the method. So that’s what I’d started doing with the Groves material.
And I think even now it’s baby steps.
This is the very embryonic kind of notion. But they’re also very powerful base ideas that you have to experiment. An experiment is a first class part of the method. You try something, see how it works, get the feedback.
Really. A lot of it comes back to getting and applying feedback. And this is where things like waterfall, the superstitious devotion to a process, the reason they fall down is they don’t want to change because of the feedback they get.
And that actually is the entire game right there. If you want to summarize agile, if you want to summarize modern, successful development, if you want to summarize a successful Darwinistic experiment. Right. You get feedback, you adapt, and then you move forward and you can continuously do this in everything.
And that’s really the secret.
Yeah. The adapt part is where it gets missed a lot. I think we’re adding feedback a lot, but not doing anything with it.
So I’ve tried to jump in sort of half heartedly into some of the grows documentation and stuff.
Is there a good place to start to learn? If I wanted to add some of this stuff to my team, where would I start with that?
So we have the website growsmethod.com and there’s a couple of nice articles and some essays, a few older videos, then sort of explaining the framework and the basis of our thinking. And then there’s a set of practices that are just online for you to look at and try. And what I wanted to do there a lot of things will say, for instance, do pair programming or do TDD or pick some practice and they’ll say, go do this. But they don’t really give you the guidelines on how do I know if I’m doing it right?
What are the warning signs if I’m doing it wrong?
So on a very simple level, takes something like version control, right? That’s like the level zero easiest. You have to do this safety and hygiene level kind of practice. You have to have version control. How do you know if you’re doing it right? Blow your disk away and bring everything back and build a project from version control. I mean, it’s an easy test, delete everything, get it all back using nothing but your version control client. If that works, hey, you’re doing it right? Okay, now you move on and do the next thing. So you extend that kind of thinking. So it’s like a little pattern language for each practice that follows that kind of idea. It’s like, here’s what you should be doing. Here’s how you can tell if you’re doing it. Well, here are the warning signs to watch out for. Here’s ways to do it really badly that will kill you. And the funny thing was, in an early version of the website, we called that something like spectacularly stupid ideas. And some guy was going through and reading material and he wrote, he said, I love you all’s material. I want to try these things. This is great, but I can’t show this to my management because everything you have under spectacularly stupid ideas is basically their business plan, batteries load, basically their business plan. So we renamed that a little bit. But you find these incredible examples of taking an idea and just mangling it again, version control being a simple example, I’ve had people tell me they use Outlook for version control, how they email each other all the source code at the end of the day. So there’s a copy on the server.
Okay. It’s interesting to pick apart some of these. For instance, version control. I’m totally on board, but one of the things that I’ve always struggled with is the concept of pair programming and why I’ve never seen a study to show that two people doing one job can work faster than two people doing two jobs.
So that’s an interesting topic. I know back in the day, Laurie Williams at NC State had done some studies on pair programming, and the early studies showed productivity gains and improvements, fewer bugs, that sort of thing. I haven’t looked lately. I don’t know if they’ve done any more recent studies or expanded that. And now you’ve got Mob programming, which takes that to sort of the next level.
It’s an interesting question. So on the one hand, there are definitely some advantages to having pair programming, and one of them I kind of touch on in the Pragmatic Thinking and Learning book. When you’re sitting there typing and you’re concentrating on symbols, the ASCII symbols, the Alphabet, the curly braces, the parens, that kind of stuff, that mode of thinking kind of locks out the higher order creative processes in your brain, if you will.
So if one guy is the Navigator typing, and then the other person is not typing and is able to sort of look out the window, pace, walk around the room, the one not typing is able to better be creative and inventive and say, hey, this thing we’re talking about, isn’t this the exact same as that other code over there? Are we duplicating that? Do we really understand this requirement? Is this the right thing to do? Your brain is sort of freed up a little to better process the higher order concepts, and you lose that when you’re stuck sort of typing and doing symbol manipulation. And one of the examples that I tell people is you’ve had this happen to you, right? You’re sitting there, you’re struggling with a bug, you’re struggling with a design issue, something, and you’re typing away and it’s not happening. You’re not fixing it, you’re not seeing the problem. So what do you do? You get up, you walk away, you’re halfway down the hall, you’re halfway out to your car, whatever, and bang, it pops into your head. Right? Here’s the answer. It’s because you’re away from the keyboard. The best thing to do when you’re stuck on a problem is step away from the keyboard.
There are physiological reasons for that, but in terms of pair programming, there’s advantage right there that you’ve got one person locked in that sort of detail mode to make sure your parents are balanced and your semicolons are there and that sort of thing. And then the other person is not burdened with that sort of cognitive load while you’re doing it. So from that point of view, two heads are better than one. In terms of peer pressure, you’re much less likely to use a variable called Squidward if you repair programming, because then the other person is going to make fun of you, whereas if you’re just doing it alone, all kinds of things can just creep in there. Oh, Foo. Well, I’ll just name it something better later and later never comes, of course. So you’ve got a certain amount of not falling into bad habits because it’s pretty much instantaneous code review if you do something really snarky or silly or just plain wrong. Oh, no, you shouldn’t put a try catch there. The standard in this project is to blah, blah, whatever else.
So that helps.
I think it’s helpful just because the scope there’s so much you have to sort of keep in short term memory to be successful.
The more eyes you have on it, the more hands you have on it, probably the better. And that’s why I think for some hard problems, for some cases, mob programming is a natural extension of that. You’ve got twelve people and one person’s typing and driving, and everyone else is looking at the screen and commenting and qubitsing on it. I definitely think there are some cases where that’s a viable way to go and a better way to brainstorm and get through the problem.
But the thing is, all these techniques are context sensitive.
There are some things where that would be a terrible approach, and you really want to be you know, I want to be heads down on my laptop, headphones on, no distractions. I need to concentrate on this thing.
And then there’s other times where no, I’d like to talk to ten people about this because this is really weird and there’s things to discuss and get your head around. So that’s part of what makes practices a hard way to go is they’re not always the best choice at the time. Everything’s very context dependent. I mean, some stuff you get to the lower level, things like a version control or a build system that’s pretty non controversial. You need it all the time. Just do it.
Don’t complain about it.
But then you get to things like TDD or pair programming or other kinds of testing, other styles of development. And it depends.
It kind of depends.
When I asked the Twitter verse about what they thought of pair programming, the answer wasn’t that it’s productivity gains, but it’s learning gains. You can spread out the knowledge amongst the team better when you’re sitting like two at a time or three at a time. And I think that’s a great reason to add it. I’m going to try to add that to our team now in small doses, but I also want to honor it’s not just how people learn and beginners in advance, but it’s also introverts and extroverts and different personality types and flex hours. I mean, if everybody’s working different hours in different locations, how do you pair program? Those sorts of things are a little difficult, sure.
And that gets back to the context.
If you really want to do some technique, but it’s not going to work in your environment, don’t beat your head against it. Do something else. Do something different. If no one’s around for that kind of knowledge sharing, prepare programming, have a lunch and learn.
Have people Brown bag of lunch and say, hey, here’s this cool new thing I discovered and chat about it over lunch. I mean, there’s other ways to get that kind of result. And that’s where you have to be a little bit creative. It’s like, okay, well, we can’t do XYZ for whatever reason. Well, what can we do to get these results?
We want this, we want that, we want the other thing. And that gets back to the Grow’s idea of, okay, well, let’s experiment. Let’s try it. Let’s try doing this for a while. Hey, that’s working great or that’s not working so swell. But if we changed it like this, maybe that would work better.
Folks forget. But the very first line of the manifesto says something to the kin that we are uncovering. We’re discovering new ways of better ways of building software. It doesn’t say we have reached the mountaintop and we have found it and you peons kneel before us and do this now. It doesn’t say that. It has never said that. It says we are uncovering ways of doing this by doing it and fiddling with it and experimenting. And to me, that’s one of the biggest things that’s been lost.
People don’t want to experiment and find a better way to do it. They want to pay their jillion dollars for their certifications or their model or whatever and say, okay, we’re done. We’re going to do this now.
Well, maybe speaking of experiments, was the Pragmatic Publishing Company kind of an experiment?
I think it still is.
I think it started that way and it still is.
It’s kind of funny. Again, when Dave and I founded the bookshelf, that really wasn’t our intent.
What we actually wanted to do, the MVP, the first product we really wanted to put out was a developer starter kit. So we got this team together. We’re starting out Greenfield. What do we do? And the idea is we would ship you a box with a pile of books and like some office toys, some Nerf guns, some rubber Ducks. Oh, awesome, that kind of thing. And we had lined up a manufacturer of rubber Ducks that would drop ship. And we had boxes and we had all the infrastructure worked out. But what we didn’t have was enough was enough writing enough books of the basics. Beyond the Pragmatic programmer, we needed stuff, at least on how to use a specific version control system, how to do unit testing, how to do automation. Right. So we decided, well, let’s write a couple of those books ourselves. First, Dave and I wrote the first two books on version control and unit testing and then had our friend Mike Clark write the third book on automation. Then we had at least the three books that were the pillars, the foundation, if you will.
And then by then people were like, hey, can we write a book for you? It’s like, I suppose, okay.
And now we’ve published. I got to look at the stats. It’s like, I don’t know, 400, 450 books.
It’s been a large number of titles over 16 years. We were found in 2003. So it’s been what, 16 years?
That’s been a bunch of books, and it was sort of accidental. And the funny thing is, we built the business like you would a software project. There’s a continuous build machine. Everything is in version control. Everything is in plain text.
All the sort of precepts that we live by we did because we didn’t know any better. I mean, how else would you do it right?
And come to talk to other publishers, find out how they do it very differently. And publishing as an industry kind of has the overall idea that it was good enough for Gutenberg damage, and we’ll still do it the same way.
So they’re kind of very resistant to change and resistant to technology. And here we come waltzing in with continuous builds. In version control, we’re actually able to do an awful lot with a fraction of the staff of other publishers because so much is automated and so much doesn’t require handholding. An example, we were just talking to another huge publisher, and their standard mode of operation is you go home and write in Word, and when you’re done, you send them the Word file, and then they send it somewhere to have it re keyed or imported into a design program like InDesign or something like that. And then they type set the book, layout, the book from there. So there’s this transcription and error and effort, and we do everything all in the same source files. So you’re offering it. The development editor is actually working with you as you go along, helping you out.
The copy Editors, index, they all work in line. It’s all the same files. It’s all inversion control.
Nothing gets lost. You can go to the build machine and see, when was this author last working on this project? How much progress have they made? All these kinds of stats sort of come for free, and other publishers don’t have any of that information. They have no access to that.
Authors lose manuscripts regularly because Word wasn’t built for large scale projects. So we’ve heard from people who had 3400 page books that got corrupted and they couldn’t get it back. It’s like, wow.
So, yeah, we have none of those issues.
Well, if they used version control, they could go back.
That’s a big if.
One of the things I really enjoyed. So I really enjoyed writing the Pie test book with Pragmatic. And I really liked having the source code be the source code that shows up in the book starts out as source code, and the actual code that ends up in the book. I can run tests across it. I can make sure it works as I expected. I can make sure the output still works. And so, for instance, we did a second printing of it, and I went through with a new Python version, a new Pytech version and made sure it all still works like it did before and fix the things that didn’t. So that was awesome.
But that’s a huge advantage that you can’t do that with other publishers.
When we first wrote Pragmatic Programmer, there were, I don’t know, twelve, 810, 1215 different languages in it. There was Ifil, C Plus plus Java, all kinds of different languages for examples in the book. And we made sure each one of them compiled and ran out on disk. And then it got sucked into the text. And that was wild. At the time we talked to the publisher, it was Addison Wesley published the book, and they’re like, no, usually you write it in Word, you write the code in Word, and we’ll have someone Retype it and re key it. And it’s like, no, that’s ridiculous. Bad idea.
You also treat authors a little different. I don’t know what other publishing houses do.
We do.
The profit share, at the very least with the authors, is, I think, completely fair. And you’re not secretive about it. You got it up on your website.
When we started off, these were our friends writing the books. And really, it still is the Pragmatic author community. We still considered you all are our friends. It’s a small world. We could not be one of these big publishers that churns and chews through and pisses off all of their authors because there’s not that many of us. It’s a small world. And I was really surprised when we first started out, especially.
And still to this day, we will get refugee authors from other publishing companies, and they will tell us literally horror stories of what they went through with some of these other publishers, anywhere from benign neglect to outright fraud.
Oh, yeah.
Really horrible goings on. And I mean, to me, that’s just astonishing, because for a publisher, the authors are the raw material.
This is why you’re in business. If you don’t have good authors who want to write for you, why are you in the publishing business?
That’s kind of the whole point. So, yeah, we’ve always been very careful to be very transparent and very upfront. The contract gave our lawyer at the time an absolute heart attack because it’s like, this is written in plain English. You can’t do this. Don’t understand it.
Yeah, that’s kind of like. That’s what you want, isn’t it? No.
We had to fight very hard to keep the contractual language very simple, very straightforward, very clear.
And I’ve read ones from other places that are it might as well be in Sanskrit. You have no idea what it’s talking about.
Well, one publisher that approached me included a clause in the contract that would make them on my website. Wow. And I’m like, I’m not giving you my website. No, that’s harsh.
But anyway, you’re working on Groves. You’re also a Sci-Fi author and a musician, so you’re doing a lot. How much time do you spend at Pragmatic.
It really varies.
I like to say, oh, well, as the big boss, I do very little, and everyone takes care of everything. And that’s mostly true. And it’s taken years to get to this point where all the routine stuff is handled by folks who know how to handle it, and I don’t have to do it. And that’s wonderful. But there’s a side effect to that. And this is the same whether it’s you’re talking about a project or running a company or whatever. As soon as you solve that one, the biggest problem you have, as soon as you solve that, the second biggest problem is now your biggest problem.
And that just kind of keeps going. So by effectively automating or delegating all of the usual stuff that happens, what ends up floating up to me is the weird stuff, the one off the things. It’s like, wow, nobody knows what to do with this. And it goes to handy. So I get a steady stream of X Files meets Twilight Zone of what really. Okay, well, let’s see.
And having to go from there. So that varies tremendously.
Well, I loved having you be involved. So even in stuff that one of the things that authors get is insight as to what’s going on with other authors, because there’s a mailing list that includes some other authors, and somebody will say, hey, I got this question about the build system. How does this work? And it’s cool when really even other authors can jump in and say, oh, this is how I fixed it.
And that’s a very software, open source, sort of software centric sort of thing. But then also you jump in sometimes and help out, which is great.
Definitely. Like I said, it’s a small world. We try to do what we can to keep the community talking and working together because we’re all in this together.
So we try very much not to get that sort of us and them mentality that a lot of companies get because there’s just us.
Yeah. When I was a kid, I read a lot. I was bored a lot. So I read a lot. And my litmus test for what book I could carry around with me was it had to fit in my back pocket. And I liked scifi stuff. So usually I read a lot of smallish Sci-Fi books, and I haven’t read any of the Is it conglomerate.
Did you read a lot of scifi as a kid?
Because you had said that as a question. And I was trying to think when I was younger, younger, I think I tended more toward the Sci-Fi fantasy side, so more Lord of the Rings, Dune, wizard of Earth, Sea, that sort of stuff, but with a little bit of like, The Moon Is a Harsh Mistress kind of more classic scifi things.
And then these days, my favorite current author would be John Scalzi, and the fellow who writes the Bob Averse books. We’ve got this AI named Bob, who is reproducing out in the Cosmos and taking over. And I like both of those. I like the Scales books and the Bob books, because there’s a real healthy degree of snark and sarcasm to them, which for some reason just resonates with me.
That comes out in my writing and in my talking, I suppose.
So I put a lot of that into the Conglomora books, so there’s two of them. There’s Conglomera and conglomerate, and there’s a third one to complete the trilogy that I haven’t started yet because I got distracted and I wanted to first write a book about a haunted house.
But then I’m thinking, okay, what can I do to make that a little bit different or a little bit cooler? So it’s set after the second Civil War future.
Well, hopefully it’s in the future.
Yeah, maybe next year.
It’s supposed to be the far future, but we’ll see how that goes. But, no, it’s a really interesting exercise, especially when you’re used to writing nonfiction and trying to explain stuff to people.
You really don’t want to take that voice when writing fiction. So I really don’t like the sort of hard Sci-Fi where you get pages of extraneous detail that make no difference whatsoever.
Oh, this is an XJ 37 y model Starship that was built in the and it goes on for a page and a half, and then the ship flies by and you never see it again.
What was the point except to fill pages? So I try to avoid that level of extraneous detail, but instead put in the detail that makes it feel like you’re there. Okay, one of the things I like about Sci-Fi is it’s one thing to think of, well, we’ve got this great new tech, or there’s this new ability or this new thing we made up for the book. Well, that’s great. So you’ve got your transporter, your Warp drive, your gene editing, whatever you’ve got. But what would the consequences of that be? What would it be like to live in that world? What difference would that make to civilization, to your day to day interactions with people? Would that make a big difference? Would it not make a big difference? So kind of playing around with that is a really enjoyable exercise to sort of build out the world your characters are living in and extrapolate from. Okay, if we took this technology and really beat it into the ground for all it was worth, what would that do to us? Would that be good? Would that be bad?
These sorts of questions.
Well, I don’t know.
I don’t know if I just lived in a really boring town or what, but the part I loved about Scifi was, like, the first half of the book, usually. So a book will usually do create a world or create some technology around it, and you’re immersed in that, and then you learn the characters and you do a little bit of character development, and then they’ll have some sort of problem, and then they solve the problem.
The big boss battle kind of thing.
Yeah, that part of it I never hardly ever cared about. It was just this escapism of imagining a different reality than we have now. Absolutely.
So one of the things that I wanted to do that I did in the Conglomerate series, the scope widens continuously. So when it starts off the first couple of chapters of the first book, it’s almost claustrophobic. It’s this guy who’s sort of a loner in this one section of a vast array of ships that are glued together, and it’s really sort of tunnel vision, and things happen. This stranger from Earth shows up and all hell starts to break loose, but his world starts to through his eyes, you see the world start to expand, other concerns start coming in, and the stage gets bigger and bigger about every half book or so. And suddenly it’s starting to evolve a lot more than it involved in the beginning. So the world in their stage keeps expanding as the books go on. And I think that’s a nice for me. That’s a nice way to be like, okay, I get to invent more of that world now and explore that with the characters.
Okay, well, you’ve sold it.
As soon as my Kindle reader comes back with my daughter on spring break, it accidentally went off to College with her.
But when it gets back, I’ll start reading that.
And then while I was preparing all these notes, I was listening to some of your music.
What instruments do you play?
I play synthesizers, keyboards, trumpet flugel, Horn, a little bit of larger brass. I’m trying to pick up the trombone, but it’s kind of heavy, so. Yeah, mostly brass and keyboards.
A flugelhorn. I thought that was some sort of Danish.
Yeah, it sounds it right.
If folks of a certain age would remember, Chuck Mangion in the 70s played it, and you see it in jazz bands.
It’s like a trumpet, but it’s got a conical boar and it’s got a larger bore. So you sort of play it like a trumpet, but it’s got a much mellower, rounder sound.
Oh, nice. Yeah. Well, I really had fun talking with you today and hope to talk with you more in the future.
Absolutely. Well, thanks so much for having me.
All right. Well, thanks a lot. Have a good day.
Thanks again to PyCharm for sponsoring the show. Get an extended four months to play with PyCharm at Test And Code. Compaarm that offers only good through the end of March, so take advantage of it ASAP. The PyCharm link is also in the show Notes at testandcode.com 69, where you will also find links to everything Andy and I talked about. Thank you for listening, for spreading about the word about the show, and for continuing to support me through Patreon hey trans supporters. Keep the lights on. That’s all for now. Now. Go out and test something.