This episode of Code Newbie is supported by Compiler, an original podcast from Red Hat discussing tech topics big, small, and strange. Check out their brand new series, Legacies, and listen to Compiler in your favorite podcast player. We'll also include a link in the show notes. Our thanks to Compiler for their support. Is your company looking to reach developers? Maybe you're hiring, hosting an event, or launching a new product?
Dev has new pro tools to help companies understand and reach our developer community, with no creepy tracking scripts. Dev is open source, so you can check on that. Visit dev.to slash pro to learn more. Send this message to your DevRel or marketing team. Welcome to the Code Newbie podcast, where we talk to people on their coding journey in hopes of helping you on yours. I'm your host, Saran, and before we kick off the show, I want to tell you about our incredible sponsors.
So this is our 50th episode, which is so incredibly exciting. In honor of that, I wanted to get someone really special on the show. So I found someone who's done a lot for the coding community and the code newbie community, and has done a lot of things that you've probably heard of. So I am so honored to introduce, programmer, and publisher Dave Thomas on the show. Dave, you want to say hi? Absolutely. Hello, and the honor is totally mine. I mean, 50 episodes is absolutely fantastic.
I mean, it's a fantastic job you're doing. So congratulations. Hopefully we'll get another 50 more. I hope so. So what is most interesting to me about you, Dave, is that you've done a lot of things that I think a lot of code newbies have heard of. They've heard of dry. Don't repeat yourself. They've heard of the code Cata. They've probably heard of the pragmatic programmer series. They've heard of Agile.
But when you had to introduce yourself at Lone Star RubyConf, which is where we met, was that last week? Oh my goodness. So, it feels like so long ago. You described yourself as just a programmer. Why is that? Because that's what I am, fundamentally. I guess in your head, everybody has some idea of, you know, what is they do or how they would think of themselves or like them themselves to be thought.
And in my case, everything I do is fundamentally to do with programming, which makes me sound an incredibly boring person, but it's kind of like just who I am. I kind of fell in love with programming when I was 16, I guess. And I think it's probably fair to say I programmed every day since then. And that's a lot of days. No, the Haitians? Well, I mean, yeah, but even then I code a bit because it's kind of like, you know, I have, for me, it's, let's try and think about it.
For me, programming is how I express myself and therefore it's kind of like, you know, turning the programming off is like, you know, turning off your site or your ears or your mouth or something, you know, it's difficult for me if I'm not being able to do that. I sort of like things bubble up inside and the pressure grows, you know. So yeah, I'm fundamentally a programmer. And I enjoy just kind of, you know, talking about what I do. So you know, I enjoy hanging with the developers.
I enjoy sharing new stuff that I've found and I've, you know, enjoy learning stuff. So has that identity of being at the core of it? Does a programmer has that changed or shifted over the years from being 16 and learning it for the first time until now? Yeah, I guess so. I think probably it is solidified a lot. And I think as I got more experienced, I started realizing that the things that I was learning in programming, actually a lot of times had a larger, you know, life impact as well.
And so I think in a way, the programming I'm doing now is not just necessarily computer programming, but I'm using the same kind of techniques when I'm, you know, doing stuff around the house or whatever else. So I guess yes, in that way, it has changed. And I think it also, when I was just starting out and so I went to college and then I got my first job. And at that point, you know, job titles were a big deal because you're, you know, 22 years old, whatever it was.
And you need to think of yourself as something. So you start as a junior programmer or whatever and you work your way up through the crowd. And it was only later on that I realized that the job titles were meaningless and that, you know, it's fundamentally what I do, not what I'm called that matters and what I do was program. And then people would say, but wait a minute, you do architecture or you do design or you do whatever else.
And to me, they're not separate fields, they're not separate disciplines. It's all fundamentally programming. And a programmer who cannot cover those bases is missing, you know, some skills and really some fulfillment. So you know, ultimately, I think we should all strive. If we're in this industry, we should all strive to be rounded programmers. I don't think that's a tool pejorative. I don't think that's less than architect. I think it's, it subsumes architect.
So tell me about Dave at 16, how did you find out about programming and what got you interested and at what point did you decide that that was going to be your career? So it's 16. So in England where I grew up, or at least I had secondary schooling, there are two sets of exams that you take one, you take when you're 15 and when you take when you're 17. And at the school I was at, you could take the 17 year old exams, they're called A levels a year early, at least some of them.
And if you're going to take more than three, which is kind of like the standard number, you pretty much have to take some early just otherwise the workload is too much. So a friend and I had taken some of these A levels a year early and so that was maybe beginning of June and the school basically had nothing for us to do, but the school was still quote in session so they couldn't just send us home.
So instead they asked if we would be interested in going across the road to a local, I guess it's kind of like a vocational college or community college. And they were running, or they were about to run a course on computer programming and they wanted some guinea pigs to try some stuff out on and they wanted to food come over. So you know, just at that point I was going to go and do mathematics or maybe physics. So but I was interested in it.
So I popped across the road and I spent a month learning basic programming and I fell in love with it. I mean it was just I don't know what it was, but there was something about the feedback and the idea of creating you know, worlds for yourself, abstractions that you could create and then use was just absolutely fantastic.
So I came back at the end of that summer and actually enrolled just to do that one course in that community college while I was still at school doing the rest and got deeper into it.
And then the end of that year, it was time to go to college and I looked around and I went to a place called Imperial College which is part of London University and it was the second year that they'd offered a they called a computer science course which meant that they were still finding their way which is a student was fantastic because there was a lot of flexibility.
And again, just carried on just doing deeper and deeper stuff and falling more and more of becoming more and more enamored was put that way. So that was the that was a spotty day of at 16 to 20 or something. And then when I graduated, I started doing a PhD in computer science and at the end of the first year of that, I kind of got a bit disillusioned with the concept.
And I still don't know if this is just rationalizing it or whether I just wasn't good enough but I was of the opinion that there were no true PhDs in software that what people were doing wasn't really genuine research as much as implementing complicated stuff. And so I got kind of like I'd be frustrated with that. What's the difference between real research and implementing complicated stuff? I think to me research by and large is trying to find I was going to say truth but that's not true.
It's trying to find underlying patterns in things. So if you're researching physics, for example, you're trying to understand why things interact the way they interact and not just put together more complicated structures or whatever it might be. Similarly with mathematics, you're not just trying to say, hey, it looks to me like all the prime numbers are infinite but you're trying to prove that by looking for the underlying structures.
And I think there are some research topics that are like that in software but there are a few of them between and I certainly wasn't stumbling across any of them. So I was, and it felt a little bit sterile. During the college year, actually before that too, I'd had summer jobs programming in different companies and I really enjoyed the getting software out there for people to use.
And that was a big part of the thrill of software to me is that you can create something and then see people interacting with it. And in a way, they're interacting with you when they do that. And so it's kind of like it deferred gratification or something but it's kind of fun to see that. And so when I was doing my PhD, I wasn't getting any of that. So the two things kind of combined and I had a long heart to heart with my supervisor.
And he introduced me to a friend of his who had just, nowadays it called a startup. Back then it was a squared shop. So I was their first employee and they were basically just scrabbling for work doing software development. And so basically if a client said, you know, can you do, they wouldn't even get to the end of the sentence before they'd say, yes, of course we can do that. And so I got dropped in at an incredible number of deep ends doing all sorts of random stuff.
And it was, I think probably the best introduction to the industry you could possibly have. I always advise people when they get a job initially, don't think you're going to be in it from all the year or two. Because when you're just starting out, you really have to put your dip your toe into lots of different palms until you find the one that's nice for you. And I think it's very easy to kind of become complacent. You fall into this trap of, you know, I'm working here.
This is defines my identity. And that's just not true. That's not who you are. But I had the same kind of effect because I was just, you know, one day I'd be writing low level interrupt handlers on a PDP 11. The next day I'd be writing a cobalt runtime system, it would be just absolutely wild stuff. And I'd be traveling around Europe and the States to some extent, seeing clients. It was just fantastic. And I was very lucky that I had the guy who hired me kind of became a mentor for me.
And he mentioned me not on the software stuff as much as the rest of it, the how to behave in a business side of things. And that was invaluable. So when you're being thrown into the deep end and doing all these random things, how much of that are you learning on job and how much did you come in knowing how to do? That's a difficult question. I think the answer is depends on what it was, but by and large, what you or what I learned at college was surprisingly applicable.
Oh, that's great. Yeah. And I say that particularly as I'm now somebody who really does not necessarily think that a college degree in computer science is the best start for a programmer. But back then, I think basically there were fewer things to learn to be honest with you. I mean, the industry was way, way, way less complicated. And so in college, we were able to cover the data structures and the techniques and the algorithms and the concepts that I was actually using.
So for example, when I was writing interrupt handlers in a similar on a PDP 11, I was actually using some stuff that I'd learnt in college. I'd learnt the PDP 11 assembler, for example, in college. I'd learnt operating system techniques, I'd learnt memory management, I'd learnt interrupt handlers, and then in data structures, I'd learnt things like ring buffers, which are ways of holding incoming data until it's ready to be used.
And all of these kind of things I had actually learnt in college, and then I got to apply them. But it's in college, you're in a very kind of rarefied and protected environment when you're doing your for a client. Then suddenly all of those assumptions you make in college like nothing can go wrong, don't apply anymore. So you have to change your mindset a little bit. But yeah, I would say that a good education is actually really, really valuable.
I think that once you start working on a day job, then the chances of you learning some of the fundamental stuff, some of the fundamental data structures, some of the fundamental algorithms, that kind of drops away a bit because you're kind of constrained, I'm going to be writing in JavaScript or I'm going to be writing in Ruby and I'm going to be doing this, this and this. And you don't really get down to that kind of lower level, which is okay.
But at the same time, I think knowing it will really greatly enhance both your abilities and also your enjoyment of what you're doing because you're no longer just relying on magic, but you're actually understanding why these spells that you're casting are actually working. Yeah. So if a college degree, particularly in computer science, isn't quite as applicable now, what does a good education look like for someone who's looking to get into code?
That is the, well, I guess now it's more than 80,000 isn't it? It's probably like the $180,000 question given the cost of education. So let me turn that around a bit. I think that there are a number of reasons that people get into software.
Some of them are pushed into it fundamentally, maybe not so much in this country, but I know in other countries, it's seen as being a good secure, it's kind of like a countancy walls, a good secure job that you should go into and you'll do well and get to wear a tie. So a lot of people are in it because basically their parents said you should go do this.
There's a group of people who are in it almost by default who were kind of like didn't really know what to do and cast around and just basically said, okay, this looks like I'll get a decent job at the end of it. And then there were people who are in there because they want to do it. They're passionate about it, they care about it. And the education you give the three of those sets is kind of different, I think.
I think that if you are in the first set, if you can push into it, then what you're looking for is basically a vocational education, which a lot of colleges, that's what they give. I mean, typically, if you look at a college, which is not like one of the top 50 or whatever, then a lot of their computing courses will be fundamentally how to program. And they will give you the skills that you need to be able to go and get a job. And that's great. That's absolutely great.
The second group, probably the same kind of idea. My personal belief is the second group should not be allowed into the industry, but I mean, you can't really stop them. So just basically find somewhere out of the way to put them and put them there. The last group of the passionate people, here's the cool thing. As you know, I went down to you had a get together in Austin, when I was down there. And so we sat outside and swetted a little in the 95 degree heat.
And I got the opportunity to talk to, I don't know, maybe it was a couple of dozen of your code newbies. And I came away from that absolutely pumped up because everybody was there because they wanted to be there. And everybody was there because they wanted to invest the time to be there. Right? They weren't going because their boss told them they were going because, you know, they had to organize babysitters, whatever else it was, to be there to talk about code. And that was unbelievable.
That's fantastic because I think that's the primary thing that you need if you're going to be successful as industry. And that is you have to want to be in the industry. You know, you have to be passionate about it. So if you've got that passion, then what's the best education? And to some extent, it's following your passion. The industry is big enough nowadays that there are all sorts of different things you can do. And frankly, coming into it, you probably don't know what those things are.
Right. I mean, I don't anymore. I mean, it's so broad and so specialized that is really, really hard to know exactly what you want to do. And the trick is, if you are passionate about it, is yes, you need a basic understanding. You need to be able to program competently in at least one language. You need to understand some of the basics, the data structure, the algorithms, how does a computer actually work? What's inside it?
Just because you will bump into those kind of various times and it's nice to know. You also need some business skills. You need to be able to talk to people. But once you've got that kind of basics out of the way, personally, I think the best education you can give yourself is to expose yourself to as much variety as you care. A lot of people say, I want to become an expert in this.
And yeah, maybe at some point, but in the industry, as rapidly changing as hours, by the time you become an expert in a particular technology, you're fundamentally a maintenance programmer because everybody else has moved on. So I think that the trick is not to focus so much on deep learning, at least initially, but to look at broad learning, to look at different techniques, different languages, but also different problem domains.
One of the kicks I really get out of when I was doing freelance work, I would be switching clients maybe every four months, six months. And I would have to learn an entire new industry from how satellites are built to banking, to communications, to airlines, whatever it was. And I absolutely love that because it's partly I enjoy like, you know, partying the curtains and looking behind the scenes to see how they do it.
But I also like it because in an area like that, I have skills I can bring to bear. And they have problems that they have always done since a certain way and they've always thought about things a certain way. And when you step into a new environment like that as an absolute beginner, you can ask all of the stupid questions, right? Just like a three year old. And my favorite question is consultant is why? You know, why do you do it that way?
Well, we go to do it this way because I mean, you go why? And you keep asking why? And by doing that, by being totally ignorant and not being afraid to show people that you are, you actually solve major problems. You can offer solutions where they go, hey, we'd never thought of that before.
And coming back to career and education, I think that by doing that kind of hopping from stone to stone, at least initially, you get to, you know, you're not going to be able to both maximize your value, but also maximize your value to other people because you get to trade on the fact that this is all new to you. And that's actually surprisingly valuable skill. Now, what happens in terms of later on?
Well, while you're doing all that stone hopping, you have to remember that just every profession whether it's a lawyer or a plumber or a programmer has to keep current. And the problem that we've got is that current moves way, way faster for us than it does for a plumber. I mean, but at the same time, plum is a way better than us because plum is actually have to go to recurrent training to keep their license. Programmer's done.
But if you want to keep looking at the interesting jobs and if you want to keep a career which is where you can choose what you want to do, you really have to make sure that all the time you're doing all this day to day, interesting cool development stuff for clients, you also have to be developing yourself and you have to be training yourself. So coming back to your question, you say, okay, so how do we, you know, what's the education that we need for passionate people?
Like I say, you follow your passion. And so the education is the one that you give yourself. It may well start off with some kind of, you know, 12 week code school or it could be, you know, learning every week in a study group or whatever else it might be. But it doesn't have to be a four year degree. It's, I think personally, experience and passion, Trump, any formal education in that respect. So you talked about breadth versus depth, right?
And you talked about how being an expert in a particular coding language or framework may not be the ideal thing and it's good to have different experiences and different problems and different technologies. At what point does a code newbie say, you know, I've done Ruby and I'm ready to move on to JavaScript. At what point have we gotten enough depth that we can move on to the next thing? That's an excellent, excellent question.
So what actually, I mean, I guess we could start by saying what's experience and a lot of the models that I've been reading about in kind of learning theory and the like say that what we're doing is when we gain experience, we're basically internalizing stuff that we had to think about previously. So for example, if you're learning to play the violin, I have no idea. I'd never look to play the violin.
You know, you have to be told how to hold the bow and how to put your fingers onto the strings and where each note is and what the techniques are and etc. etc. etc. Right? And so for your first month worth of lessons, you are sitting there gritting your teeth, concentrating, and you sound like someone just killed a cat because of that. But if you do what your mother says in practice, then that practice is what that's actually doing that practice is it's burning neural pathways.
So at the more you practice, the more you are teaching your brain how to do this. And at the end of a certain period, you will discover that you're no longer thinking about the position of the notes on the neck. It's just automatic. And you are no longer looking at them, sheet music saying, that's an A, and that's a C, and that's a D. You just basically, your body is acting as a translator from the sheet music to your fingers.
And that's because you've internalized this stuff and it's now part of your kind of like automatic response in the same way that when you first learn to drive, right? You're thinking about the whole thing and everything is like, you know, you're sweating and you're gripping the steering wheel so hard you actually leave indentations in it and you know, no one could talk to you and everything else.
Now, if you're driving along, you're having a chat, you probably don't even remember a whole bunch of the driving that you did because it's being done inside your subconscious or you know, behind, behind your consciousness. And that's what you're attempting to do when you learn to code in that you're moving a lot of the work that you do from your consciousness into a more automatic part of your brain. Because only then do you free your consciousness up to think about what you're doing.
And basically, the more experience you get, the better you get at being that angel on your shoulder, all the time looking at the kind of more automatic you doing the coding. And that's the process that basically makes you a good programmer. So I would say that if you say coding Ruby, when is it time to move on?
When you catch yourself looking at what you're doing, when you catch yourself saying, you know, when you have that kind of like, little kind of like uneasy feeling that is like comfortable. Yeah, but you're coding along and then suddenly something goes, that's something's wrong there, right? And you don't know what it is. When you get that feeling, then I think you've got enough experience to try something else.
Because that means that you've internalized it enough that at least part of that is now buried in your subconscious somewhere. And that's really cool. So here's the trick though. And here's the really cool part because you talked about not being an expert necessarily. If you were to do, if you were to get to that level in say Ruby, yeah, and you're probably going to be doing that in your day job as well.
So you get to that little experience and then you keep reinforcing that and getting more practice on your nine to five job. If you then start investing in something very, very different, I don't care what it is, anything, Lisp or, you know, elixir or Haskell or Elm or any different language or not even necessarily a language, but let's say language for now, right?
And what you get yourself to start working in that language, what's going to be really frustrating to start with because you've just gone through all of this with Ruby, right? And it's been, you know, you've been like swearing at the screen because it's not doing what you think you should do. And now you've got to a certain level of expertise and then suddenly you're back to zero and you've got to do the whole thing again.
But the cool thing is that almost all of these languages share, you know, a whole bunch of DNA. And so once you've learned something and say Ruby, then a lot of it will transfer a cross into the new language, not all of it by any means, but a lot of it will. And so learning that second environment will take you less time. And you will get to that same level of proficiency quicker.
And you will also have made, and this is the cool thing, you will have made, when you refer to it as a new Ruby, you're making correlations and connections between things in Ruby, right? So you'll say, oh, that full loop, that's the same as doing a dot each, isn't it? Yeah, okay, I understand that now. Now when you're learning a different language, you're making those connections inside that new language, but you're also making the connections between that language and your Ruby programming.
And what that means is you'll be better in both. You'll learn techniques that we'll, you could apply back to Ruby in your day job and you'll be a better programmer because of it. So you talked about two levels of, I guess, breath. Here's breath in terms of the types of technology you use and breath in terms of the types of problems that you're solving. Once I start having that feeling in Ruby where I'm kind of comfortable, I have that little voice.
Should I try to solve different problems, but stick with Ruby or should I go to a different language? What would you recommend? I don't know if you would have that kind of choice necessarily. I think what I would advise is that you're open to both things and take it when they come along. It's very hard to have a plan that says, okay, so a year from now, I'm going to switch into banking and then a year after that, I'm going to switch into aerospace.
Or alternatively, I'm going to be coding Ruby for a year and then Elm for a year or whatever else. It just doesn't work that way. But at the same time, if you have the confidence and if you are actively keeping your eyes open, then you will see opportunities and they'll be scary, but have the courage and jump for them. Whether it's a new language or a new environment, the key point there is new. The rest of it is kind of like, whatever.
The other thing I'd recommend is not just new problem domains, but new places as well. I think everybody, and this is not just programmers, really owes it to themselves to travel a lot more than we do. When you're young and single and you've got that opportunity, it's a great time to see the world and to see how other people do things and to get different perspectives. Not just on programming and business bills, but just on life.
I think it's really a question of, we are in an industry that has phenomenal opportunities. My fundamental recommendation is to take them. You can't necessarily plan, but if you can get yourself out there, get yourself known, go to the user groups, chat to people, put yourself out of it. Things will happen, things will fall in your lap, and you just need to be courageous enough to go, okay, I'll try that. I think the plan is not like a detailed, do this, do that.
As much as to plan to say, I will keep an open mind and I will keep looking for new stuff. I think one of the things that you've done to help more people become better programmers is as publisher and founder of Pragmatic Programmer. He tells us a little bit about that. Back in the mid-90s, my wife and I, we've been living in England. She's American, but she'd come over to England. We decided to move over to the States.
I landed in Texas and had basically nothing in terms of like, I didn't have a job or anything. I just basically called around the network of people that I knew and started doing freelance work. That actually went surprisingly well. I was getting to learn America at the same time because I was traveling a fair amount of different projects. I ended up on a project with a guy that I knew from England. He was now a VP in a credit card debit card company. They had some software that they were paying.
I can't remember what's ridiculous amount every year for the license on. He said, I told my boss we can rewrite that and not have to pay that license for every year. I said, okay. He said, yeah, I said, and the license is coming up in six months and we'll be done well before that. I went, okay. He says, so you can do that, right? I said, no. We had a look at the work and we decided it was just too big for one person. He said, oh, no, my, I got another friend I know who's really good.
He brought along a guy called Andy Hunt. The two of us spent, I think in the end we spent the six months and our office was actually a storage closet. Had no air conditioning. We were in Florida. No windows. No windows, no air conditioning, no nothing. We got to know each other really pretty well. At the end of that time we'd actually written something like quarter of a million lines of C code and it went live.
It was a stunning thing because we were switching debit card traffic and we built some little hooksings who keep an eye on like total amounts of money we'd switched and within a few out of camera and we wasn't minutes, we got to a million and then miles too long after that we got to a billion and it was kind of like, you know, this is our software doing that and we felt really, really good about ourselves.
And so we kept saying, we said to ourselves, what was you probably trying to lose again and find other bits of work? And so we informally started doing that. We went and we did consulting for clients. We did a lot of project salvage work. You know, when things go wrong and they call us in and we ask awkward little questions like, did you test that before you shipped it and things like that? And what was the answer to that question? Oh, invariably. I think Steve did that.
Yeah. It would be the typical answer. But yeah, we saw some absolutely horrendous things. We saw companies where it's actually some really interesting ones. One company had this gorgeous, gorgeous office for their developers. They had like, I think it was 15 developers on this team and they had a, a window. The office had just a glass wall looking out over the mountains and it was curved, right? So it was this big arched curved wall and each developer had a desk that looked out across.
I actually know they had a cubicle. Sorry. And their desk looked out the window to the mountain, right? And they are having big, big problems getting software out. So we started at one end of this arc and we said to the first developer, what is it that you're actually doing? And they said, oh, we're writing the front end code for blah, blah, blah, blah, blah. And we asked each developer internal to do it in this arc.
And by the time we got to the other end, the message was totally absolutely different. And it was clear that the whole team never managed to communicate it. Instead, things got passed from one person to the next, down the line, just like that game of telecom. Exactly. Yeah. So that was fascinating. We saw that. We saw teams where there were, you know, two dozen developers and no two developers could create a build of their product the same way.
It would always be different because they had different tools, different libraries, whatever it might be. So we kept seeing these things and we kept telling people, you know, you should really be thinking about automation. You should really be thinking about testing. You should be thinking about communication and et cetera, et cetera. And we're doing that on every single project we went to. So we decided to take a break.
And the original idea was we'd write like a 50 page pamphlet, which when we turned up on site, we could hand out and say, here, read this and then we'll talk to you. And as we're software people, 50 pages very rapidly became, you know, 150 pages. And at that point, I was my wife who said, you know, you should think about publishing that. And we said, oh, no, we're not authors. We can't possibly do that. It sucks. Bluff up. And so we came up with this really clever plan.
We looked around for the best publisher we could find. And at the time, we felt that was Addison Wesley. And we said, okay, we will submit this to them. And they will turn it down. But when they turn it down, they'll tell us why. And that will help us make it better. And that was our clever plan. So we sent the manuscript in and they actually totally destroyed our plan by accepting it. And so at that point, yeah, exactly. So at that point, we actually were committed to finishing off a book.
So we did that. And that book became the pragmatic programmer. And it enjoyed some success. So at that point, we decided to formalize our up to then informal arrangement. And we actually formed a company called the pragmatic programmer. And we then did consulting work based on that. So that's how the pragmatic programmer book got started. Pragmatic programmer, the publisher got started because so we finished the pragmatic programmer book. At that point, I was just getting into Ruby.
I discovered Ruby while I was writing pragmatic programmer and I was really enjoying it. And for various reasons, I won't get into. We decided to write a book on Ruby. And so I wrote that. And so at that point, by the time we finished that book, I'd been pretty much writing full time for three years, maybe. Oh, wow. And so children were getting hungry and the shoes had holes in them and stuff. So I had to go and get some actual honest money. So we spent a few years.
Karen, do you want to one with Dave Thomas? Yeah, I know. I know. Who knew you? You know? I thought they could just go out on the streets and people give them money, but no, apparently not. So, yeah, so we did a couple of years of consulting to basically refill the bank account. And then we got this urge to write books again. And so we thought about going to Addison Wesley, but then we said, well, wait a minute, we did all the work to create both the Ruby book and the pragmatic programmer book.
We did all the, obviously the writing, but we also did all the layout and the diagrams and the indexing and all the other kind of stuff. So why don't we just do that and cut out the middle man? How hard could it be? We thought. James Lutzworth. Right, which is, well, I mean, yeah, how hard should it be? Could it be is the kind of question where everyone needs to carry a plank around with themselves. And anytime they find themselves saying, how hard can it be?
Heat yourself on the head with the plank as hard as you can. So it, but having said that, being totally absolutely naive, having never, ever even thought about what a publisher actually does. We launched into this and did what we knew and what we knew was how to do software projects. And so we constructed a publishing company based around, basically the principles of code. So all our books were in plain text. We kept them in a source control system. We had automated builds.
We had automated tests. The whole thing was basically push button. And that meant that we could, you know, basically take on the work of a fully fledged publisher with just two or three people. So for the longest time, it was just the two of us. And it was, you know, we did everything and we could do that because we ran it as a, I mean, give you an example. If you deal with a regular publisher, then the chances are that they will interface to you. They will send you information in spreadsheets.
Oh, no. And that's because that's where they actually have the information. Right. And the offices like those Victorian pictures, you see, like, you know, 8,000 people all sitting in a nice little rectangular grid. They have offices full of that of people doing things like entering, you know, there will be a spreadsheet for each book and they will be entering sales figures into those spreadsheets. It is stunningly inefficient and stunningly stupid.
And you know, so that's, you know, they're very surprised when you ask them, you know, couldn't you give me this in some kind of, you know, format like I can actually use like, you know, XML or JSON or something like that. And they're kind of like, you know, you're talking, you're talking new stuff now. We don't do that. Oh, no. How dare you? Yeah, scary talk. So basically, we were, we were kind of, we lucked out by being ignorant. And so we produced a system that basically was what we wanted.
And the nice thing about that is as we were programmers, then other programmers also kind of caught on to what we were doing. And so it was quite easy to get friends and people would spoken at conferences with and was going to be able to write books for us. And so we, we kind of took off with that and that was, that was fantastic.
And we got, we got the opportunity to, to use some of the ideas that we had while consulting on particularly some of the learning theory ideas to kind of guide the structure of the books.
So we, if you read our books, you'll find that a whole bunch of them are written in a particular style and have a particular structure where the reader is basically on, on an adventure where, you know, we start off with some problem and you have become that problem and you get deeper and deeper into it until you're no longer a beginner, but you're actually a partner with the author. And so if you look at our books, you'll find the language changes as the reader becomes more experienced.
I love that. That's great. It's kind of, it's kind of fun. So that's, you know, so that's basically where we got to the publishing. And the rule is basically if we're interested in it personally, then we'll write, you know, we'll publish your book on it. So you have, I'm looking at your catalog now, you have lots of books. Yeah, yeah. I mean, it's not, we're not like an Addison Wesley, but I think we've probably got a 250 or something. It's pretty real, but yeah, that sounds pretty good.
How do you pick what to publish and are the things that you pick primarily for intermediate developers? You have a nice range. Who's the target audience for the program, the pragmatic series? We have a range, actually. We go from beginners. We actually have two or three books that are aimed at teenagers, for example.
So Andy actually wrote a book on writing plugins for Minecraft because a whole bunch of kids are, you know, using Minecraft, Rich turns out you can write bits of code and, you know, change your environment in the Minecraft world. So he has a book on doing that. We have a book called Learn to Program, which is actually one of our best sellers, which is aimed at teenagers. Yeah, I love that book too. It's really engaging, which I think is fantastic.
And there's also some other things that we aim at that audience. We have a fair number of books for, you know, straight beginners. And then I guess our bread and butter is the books that are slightly more specialized and maybe intermediate. But not, I mean, we typically, you know, we don't write the academic, you know, in section three, you'll read or we'll discover how we don't do that kind of thing. So I think we never really write a book that's only for advanced people.
We write books that will take you from a particular level in a subject, you know, up two or three notches in that, you know, so you'll move up, you'll level up two or three times as you're reaching through the book. Yeah. How do you pick the topic? So in the old days, Andy and I would actually largely go out and ask people that we knew who were doing something interesting to write a book about it.
So we would, we would say, you know what, there really needs to be a book about X. And then we'd go out and find the person that could write about X. As we started growing, then we started inviting people to submit manuscripts, well, actually not quite, we used to submit proposals. And then we would basically just look over them and say, that's interesting, that's not interesting.
The problem with that is that Andy and I, although we have a fairly varied background between us, we still, you know, only cover, you know, a small part of the whole, the overall industry. So about that kind of time, we also were working with a bunch of editors. And here I have to start a little rant. In the technical book publishing industry, an editor is fundamentally a sales person or a marketing person.
So their job is to bully you to get the book in on time and make sure that what you've got meets their editorial guidelines and is sellable. So quite often, you know, you will have a minimum page count for your book because the feeling is the bigger the book, the more they can charge for it. Our editors are typically English majors and most of them are already working on their own book, you know, the great next great American novel.
And so we give them like an induction where we talk about our style and our procedures and stuff. And then they work with the editors with the authors purely on the writing, you know, how to structure the writing, how to get the voice right and et cetera, et cetera. So we started bringing these editors into the meetings to discuss the proposals we had. And that was non technical, non technical people. Yes. And it was fantastic.
It was the best decision we made because a lot of the books when you think about it are written for people who don't know about the topic until they read the book. Okay. That's a good point. Yeah. So the editors would sit there and say, well, you know what? That doesn't really seem very interesting because I don't see how I could use that or, you know, yeah, I really got engaged by this. And I think we should do this.
So they were fantastic at helping us to understand, you know, what we're going on. Now every now and then, you know, we'd nudge them by saying, this is going to be a really hot topic. You know, so I think we should think about this. But really, a lot of the time it was their decision and the cool thing was we had kind of like the ultimate incentive slash distance incentive scheme. That would be if one particular editor said, yeah, I think this book is going to be really, really great.
And the others were like, well, I'm not too sure. Then we give that enthusiastic editor the book. And it was then their responsibility to edit it. And so, you know, we got some really well thought out decisions because of that. That makes a lot of sense. So one of the other things that I would imagine a publisher does is help with marketing and getting the book out there and, you know, making sure everyone knows about it. How did you all do in that category? Was that a totally new skill for you?
Yeah, we suck at that. It's actually, yeah, I mean, okay, to be honest, we do. We kind of like, we kind of like had the field of dreams of publishing, you know, write it and they will read it. And it actually is true. We don't do a lot. I mean, we do some marketing. We support user groups. We support conferences. We encourage our authors to talk to conferences.
And we actually kind of like mediate quite often conference organizers will say, hey, we need someone to talk about Scala and we'll put them in touch with, you know, one or two of the authors and away they go. So we do that kind of thing, but we're not really into the 17 city book tour and the, you know, it just doesn't seem to me. We've tried it. We've tried paying bookstores back in the old days when there were bookstores.
You could pay for various promotional things like they charge you extra to put the book so that cover faces out, not just looking at the spine, but you look at the cover. Right, that costs you a lot. You know, they charge extra to put you in an end cap. There's these little dangly bits of paper that they can put on the shelves that hang down below the book. They're called shelf talkers and they charge you for those as well.
And we tried all that and we monitored it and we can see those statistical correlation between sales and the amount we spent on that. So we stopped doing that. Ultimately, the one thing that we found that correlates best with how successful a book is going to be is how enthusiastic the author is about it.
Because a good enthusiastic author will get out there and they will talk to people and they will go to conferences and they will blog post and they will do all these things just because they're so, they so much want to share what they've done with other people. You know, it's not they want to make money off it. It's because they are really enthusiastic and they want to evangelize about it. And that's the best indicator of how successful it was going to be.
But you see now you've derailed me and we're talking about publishing but really we should be talking about programming because that's the cool stuff. And we'll do just that in part two of this interview with Dave Thomas coming out next week. If you're interested in supporting Code Newbie and all that we do check out our Patreon page. That's patreon.com slash code newbie and tune in next week for part two of this interview with Dave Thomas. Thanks for listening. You helped do a good job.