Programming Throwdown - A Journey to Programming Mastery

Episode Date: September 14, 2019

Every interview we do is such an exciting and unique experience. Patrick and I had great pleasure in hosting Andy and Dave, authors of "The Pragmatic Programmer". We pick their brains on a variety of topics including rapid prototyping, the 10x engineer, tech leadership, and how to get your first coding job. Their new book, "The Pragmatic Programmer: 20th Anniversary Edition" comes out today! I hope that this interview inspires you all to grab their new book; it will definitely be a book-of-the-show for me. Show notes: https://www.programmingthrowdown.com/2019/09/episode-93-journey-to-programming.html ★ Support this podcast on Patreon ★

programming throwdown episode 93 journey to programming mastery take it away jason i have andy and dave tech enthusiasts here to talk about their book, The Pragmatic Programmer. And this is a new edition of a book that's been around for a while, correct? 20 years. This is the 20th anniversary edition. Totally awesome. So why don't you go into sort of your background and what sort of inspired you to write the original book and then maybe what inspired you to revisit some of the things you talked about 20 years ago and we only have an hour right yeah that's true that's exactly you know dave and i could certainly give the the long

answer to that question and we'd be here all day so we'll we'll try and give the uh the quick the quick version because i think a lot of people have heard this by now, too, as we've been talking about the new 20th anniversary edition. But this whole book came out. We really didn't intend to write a book. It was kind of an accidental book. We really just wanted to write a white paper for our clients at the time. So Dave and I were out doing consulting and noticing things people were doing out in the world, out in the workplace that, wow, that really hurts. That's painful. You know, there's a better way. Have you tried thinking of it this way? Have you tried experimenting with

this? Have you tried using this technique? So what does painful mean? Is it painful in the sense that you paint yourself into a corner and now you have to rewrite everything? What would pain be when you're doing software development? Well, I think you have to think back to the 90s. And I know most of your audience probably wasn't born then. But the feeling in software in the 90s was one of really quiet desperation. Nothing seemed to be working. And the quality of software that was being shipped

was honestly pretty much abysmal. And that was assuming it got shipped in the first place. The majority of software projects were canceled before they even got to the end. And a lot of the reason for that is that people were kind of floundering. They were taking on things without really knowing what they were doing. And then they were following some pretty random practices. So we were finding clients who were shipping software out to their clients without testing it, or who were not keeping their source code in version control. And so as a result, it it was like whose machine did we use last when it comes to like trying to reproduce a bug um or we actually had one client who had i think it was like 15 developers and each one of them we actually asked them all to build their product and no two builds were the

same um you know this is kind of sad but but i've heard recent stories that sound just like this. Oh, yeah. It hasn't gone away. But I've got to tell you, I mean, compared to 25 years ago, we're in a much, much better state. We really are. That's good. So, yeah, we were working with clients who were in that kind of – I mean, typically you don't call a consultant in when everything is going well, right? So we were working with clients who were in that situation.

And we always found ourselves saying exactly the same fundamental things. You know, testing, version control, automation, talking to the customer. Taking small bites, not trying to take on too much at once just try this one little thing then try this next one little thing yep and that also means learning from each of those little things oh absolutely yeah it's no point in feedback unless you actually listen to it so uh we sort of we jotted notes down and it grew a little bit we got to i don't know 50 pages or so of notes. And the idea came through,

you know, we should probably write a book because this material is, you know, it's common sense, but it's not commonly used. So how do you go about, or how did you go about, because that's a completely different discipline. You have all of these notes, but how did you go about finding a publisher and things like that well so that's a that's a funny story um they were a little bit more than

notes even in the earliest version i mean we had kind of notes but we had started you know writing them up in kind of a uh you know prototypical tip format like, here's an idea. Here's how you should do this. Here's this other idea. So we kind of had, you know, a loose structure to it right out of the gate. And somebody recommended, I think it was my, one of my brother-in-laws at the time said, because we knew nothing about writing books. We had, we didn't know how to proceed with that at all. But somebody suggested, you know, you go to your bookshelf and see the books that you like, you know, what is, what's the publisher that you are attracted to for professional titles in your, you know, in your area. And so Dave and I looked dutifully, and we both had a significant collection of Addison Wesley titles. They were pretty much,

you know, the premier source for, premier source for computer science software development titles at the time. So we kind of randomly looked up the contact person and sent them an email and said, hey, we got this idea for a book. And they said, sounds great. We'll sign you up. That's awesome. I've heard so many stories like that. I think, I mean, one of the famous ones is I think Steve Jobs emailed the CEO of HP and asked for a computer or an internship or something like that. But yeah, it's fascinating that that really worked out well. You just you did some research, found the right person. And that's awesome. Yeah.

And then it took us two man years, two and a half man years worth of work. No, no, no, no. It was more than that. It was well more than that because it was actually almost two elapsed years. That's true. It was almost two calendar years of both of us working just about full time, not out consulting, not doing any paying gigs, just sitting there concentrating on, okay, is there a better way that we could explain this? Could we make this clearer?

Is there a better word we could use here? And literally, Dave and I would argue over individual words to try to get our point across as best as we could. It's amazing how often Andy was wrong. Amazing what memory does to you over time. So, yeah, I wonder if you had some metrics from 20 years ago. Maybe you could see, you know, maybe the coin is flipped now on the other side or something. Maybe he was right the whole time. It's interesting because when we started this rewrite project, both Dave and I

went away and said, okay, let's just make a list of what you think are the most important changes over the last 20 years. What are the topics that we have to revisit? What do we have to scrap? What do we need to introduce that wasn't an issue 20 years ago. So we each went off separately and made these lists and came back and put them together. And we were within probably 80% of what we had each come up with was exactly the same. So we were very much on the same pages. Yeah, this is a problem now. It wasn't a problem then. This was a good idea. We don't need to talk about that now, whatever it was. So we really had a great starting point to go through and begin to revise the text. Yeah, I definitely, I want to take a bookmark on that, but I think let's go into basically what is a programmatic programmer? What should people expect when they open this book?

They should expect to get better at programming. All right. So what does that mean? Okay. So the thing is that programming is something that you have to do consciously. And a lot of people fall into programming somehow and it becomes a job and they do their work and they go home and it kind of like carries them along. And it's one of those industries where you can be carried along. But if that's all you do, you're never going to, A, you're never going to really enjoy it. And you're probably never going to progress as far as you could have progressed in terms of satisfaction in the job. So what we are recommending is to be more conscious of what you do as you're programming with a view to becoming

a better programmer. And so we have a whole bunch of separate topics that we talk about. Some of them are people topics, some of them are team topics, and some of them are technical topics. And there's probably about a fairly even division between those. And with each of them, what we try to do is to say, not you should do this, but instead we list alternatives and we suggest that you should try things. And with everything we suggest, what we're saying is we aren't in your environment. We don't know what you're doing. We don't know how you're doing. We don't know how you're doing

it. But our suggestion is you might want to think about this, this, and this. And as you try them, gather feedback and work out whether or not that's improving or making things worse. And that's the pragmatic part of it because pragmatic fundamentally means doing what works. And so we have a list of suggestions and a list of, I guess, things from our experience. And then we say to people, you know, your mileage may vary, see if it works for you. Got it. But also your mileage may vary, but also you've firsthand, you know, tried a lot of these different strategies and policies in your consulting work, and you've sort of picked and chosen the best approaches? Well, no. I say yes, yes and no. Up until you said that last phrase,

then I would say, yeah. I mean, these are all things that we've done because I really, really dislike consultants, if you like, who go around telling people how to do things that they themselves can't do. I have a story I tell. I was on a bus going to a conference in India from the airport, and I was sitting in the seat behind two fairly well-known industry experts on agile stuff. And they were talking, and one of them asked the other, when was the last time you programmed? And the other guy said, oh, I think it's about 15 years ago or so. You know, the other guy said, oh yeah, me too. And it's like, these are people that are going out and telling programmers every day how to program better and they couldn't code their

way out of a paper bag. So, you know, that's really bad. But when you say best, we don't actually believe that there is a best practice. We don't believe there is a best way of doing things because best is always going to be contextual. And so, you know, what's best for my environment could be totally wrong. If I'm making pacemakers and you're making video games, then I very much hope that our two development methodologies are very, very different. Yeah. It's similar to, you know, my PhD was on playing computer Go, having computers play Go. And there isn't, I mean, technically there's a perfect game of Go, but it can't be found and it's not very interesting. But what's really interesting is starting from random or starting from a not very good player and being able to get better and being able to iterate.

And while you're iterating, continue to move in the right direction. I just feel like this is similar. Yeah, that's what it's about because I think one of the kind of foundational things that we misapprehend about the industry is just how dynamic everything is. You know, people tend to take a very static view of, you know, like you said, the best practice. Okay, I've learned this, now this is the best way to do it, this is what I'm going to do from here on out. That's a very static viewpoint and it's wrong because as soon as you say best practice, you're missing half the statement. Best for who? Under what circumstances? In what context? What are the parameters around that? We don't get around

that. We get this kind of static view of, oh, I'll just do this one thing or I'll just learn this one programming language. When the book first came out, one of the tips in it was to help keep your knowledge up and to keep learning and to appreciate different ways of solving problems, we advocated you should learn a new programming language every year. Just, you know, something random. Learn a new, you don't have to use it in your job or a project, but just learn a new language and see how they approach different ways of solving these sort of common problems, different techniques. And we had people come up and say, well, that's a great idea, I love that, but what do you do after the first three years?

Because there's only, I mean, the only programming languages are pick some Java, PHP, Python, whatever, pick some Java, PHP, Python, whatever, pick some subset. It's like there's hundreds and hundreds of, some of which are really quite bizarre and quite interesting. But even the, what's the TiOB, TiOB index there, the top 50 on that are pretty interesting. Actually, no, I would disagree. I mean, I agree up to the TiOB interest index thing

because what that captures is what's current in fact not even what's current it's what's was hot over the last six months and that is basically if you're doing that then what you're doing is you're aiming at a wave that's already crested well yeah it's a trailing indicator, but it's something. Yeah, when we... I mean, coming back to languages, it's not the language that's important. And, I mean, the point that we both make a lot is that anybody who says,

I'm a Java programmer, is actually saying I'm an idiot. Because you're not a Java programmer or a PHP programmer or a C programmer or a JavaScript. Or, even worse nowadays, programmer or a c programmer or a javascript or even worse nowadays i'm a react programmer right um it's like saying i'm a table carpenter right i just make tables that's it oh i'm a table carpenter slash saw division right yeah right i'm a hammerer yeah yeah exactly and so you're not you're not, you're a programmer. And so what learning languages

does, if you choose the right languages, is give you more depth in your craft. You get to experience different ways of thinking about a problem. So for example, right now I got talked into doing a, I'm doing a class down at SMU here in Dallas. So I'm teaching juniors and seniors. The class is called Programming Languages. And so I'm taking that as an opportunity to basically blow their minds by using languages from the 60s and 70s and showing them that, in fact, those languages were actually as capable, if not more capable, than 90% of the common languages today. Yep. You know, and it makes them think differently.

You know, so I've taught them Snowball, and that kind of blew their minds. This week, in fact, in about three hours' time, I'm going to teach them Prologue. Oh, yes. And I can pretty much guarantee that that is going to open a few eyes, you know. And then what you can do is you can then look forward and look at languages that have, for example, pattern matching today or languages that reify their parameters and say, oh, I see where that came from now. You know? You can look at comprehensions and say, ah, okay,

I understand now why a comprehension is useful. So I think there's a lot of history and a lot of depth that we ignore. I mean, if you're an English major, then you don't spend your time writing, you spend your time reading. I mean, yeah, you write, but I mean, 90% of what you do is studying great works and not so great works and learning to be critical. Whereas when you're a developer, you spend no time reading the history and you spend no time exploring the depth. There is nobody talking about the Jane Austens of programming. Well, and you know why that is? Because

most of the works that we see are not Jane Austen. They're more along the lines of, it was a dark and stormy night. But you know what? Suddenly, a shot rang out. Yeah. But even back then, that was 90% of the work, right? And what happens is history is a really, really good filter. And so if you've heard of somebody from the 19th century or the 18th century, then the chances are you've heard about them because they are better. They've risen to the top of that foam of noise. And the same thing is true for programming languages. I mean, Snowball and Prologue and Algol 60 and all those kind of things weren't the only programming languages

back then, but they're the ones whose names have lasted because they actually have something to teach us. Yeah. I think one of the interesting things about programming is it's a science and an art, right? So if you look at, for example, science, people aren't going back to, you know, eighth century theories on the universe and on physics because science just kind of marches forward and obfuscates things as it goes. But art is a bit more timeless

and people still refer to the best when they say the best poet they still refer to shakespeare who is you know so many centuries ago i don't know i mean so in this case you have both you have a science and an art but math see i got i got two things there first of all mathematicians do go back i mean people are still arguing about euclid's fifth postulate, right? And- Yeah, that's fair. That's fair. People are finding uses for Diophantine equations in quantum physics. There's all these kind of weird things that if you don't have the knowledge of the past, you don't know if you're missing

something. The second thing is, it always worries me when people say, is programming engineering? Is programming science? Is programming art? Because nobody ever says, is math basket making? It's math. It's mathematics is what it is. Why can't programming be what it is? Well, I think the reason for that is, and I agree, it is a problem because people are always trying to draw some kind of metaphor and say, oh, programming is, it is engineering, or it is just like building a house, or it is just like, you know, whatever, fill in the popular metaphor of the day. And it's none of these things. It has aspects of many of these things.

But, you know, fundamentally, if you think about it, the essential problem, I think, is that it's all, it is about thinking. It's about how you think of a problem, how you visualize it. You know, this whole idea of how do you abstract a problem and what parts you use and how are these parts going to cooperate to solve the problem, there's no physics that guides that. There's no chemistry behind that. There's no laws of gravity. There's nothing to sort of bound us in and say, well, you know, clearly it has to be this way or it's not going to work. You can do it any old half-assed way. You know, you can do it very procedurally in PHP. You can do it in a very OO style and in a real OO language like Smalltalk. You could do a functional style. And none of these have any kind of physical constraint or physical analog. It's literally just how you think about it. becomes really your time and your mental capacity of yourself and your team and how that evolves as the project evolves.

As the project evolves, does it get more and more just mentally demanding to the point where to change one line, you have to consult five people or have you sort of factorized it and has it become more elegant? But the constraint always seems to be a constraint of the mind and a constraint of the developer time it is it's definitely a constraint of the mind because one thing that happens the longer you're on a project and the more you're working with it the more you're learning the more you're realizing what you should have done in the first place right you, it's like this graph that starts off and at the very beginning of the project, you know, zero about it, you know,

absolutely nothing. Maybe there's a project title, maybe there's a name, you know, who else has been hired for the team, but you know, almost nothing about it. You know, the most about a project, about how it really should work and how it should have been done after you've shipped it, right? When it's all said and done, it's like, oh, okay, now I know enough about it. Now I realize, you know, maybe what we should have done better. So, okay, great. That's sort of how the real world works. Well, what can we learn from that? We can say that, well, you'd like to make your most critical decisions as late in the process as possible. Because the longer you wait, the more you actually know about it, the more you've learned, the more you can make an educated

decision about what you're doing. So we try to defer decision making as long as possible, because up front, who knows? We have no idea. We haven't done it yet. And also try not to make critical decisions. Yeah, ever. Yeah, a decision that's reversible is not critical. A decision that's small, so you waste a week and not a year, is not critical. So if you can try to make a series of smaller, reversible decisions, then a lot of that risk goes away. One thing I'd say is you talked about, you know, it's a failure of the mind. I'm not a hundred percent convinced that that's necessarily true because that implies that an infinitely smart developer would be able to write perfect code. And that's not true because

no one could. I think it's more, it's a failure of the spirit. It's a failure of courage. Because most developers actually know in their heart that they're hacking. If they're hacking, they know that they could be doing this better, but they're not willing to take a risk and to push back. So bootstrapping on that, this is something that's come up a lot personally.

And I have pretty strong opinions on this, but I'd love to hear what you guys think. How do you deal with, you know, there's a lot of uncertainty when you're building something. And, you know, my philosophy is when there's a lot of uncertainty, you sort of compensate for that by trying to iterate quickly, aka hacking. But then you always remember that you're accumulating this debt and you go back once you have the certainty, maybe you have the product market fit for your app, then you go back and rewrite the whole thing. And you do it knowing that that was the price that you were going to pay. Other people feel that you should never rewrite anything. You should have good standards in place to where you don't have to do that. What's your opinion on that whole tradeoff?

I think that kind of conflates a couple different issues there. You can certainly turn out something very quickly without hacking or having something low quality. You can very deliberately put something together that is a prototype, that you know is a prototype and its purpose is for learning. That's not a waste of time, that's not a waste of engineering, and that doesn't even have to be in software. You can do a prototype with wireframe diagrams for a website. You can use post-it notes on a whiteboard. The idea is to get in front of the user, the sponsor, somebody who can comment on this and learn what it is you're trying to explore.

So you don't have to write a crappy version of the product to do that, to get that fit, to get that information. You can very deliberately say, okay, well, we don't really know how the user is going to handle this or what they'll think about this. So here's a prototype. Let's try this. And then you can go in, you know, sort of armed with full engineering and do the real version. But you can kind of have both. You don't have to write crappy code just to get feedback. Got it.

That makes sense. The other thing is that prototyping is very different from end-to-end developing. In the book, what we do is we differentiate between something we call prototyping and something we call tracer bullet development. So prototyping is when you're unsure of a particular thing. And it could be a UI element. It could be an algorithm. It could be anything. And so the idea of the prototype is to maximize the amount you learn.

And so what you do when you start is you set an objective to say, you know, I need to know, is this algorithm twice as fast as that one or whatever it might be? And you basically ignore all of the niceties of programming just to answer that one particular question, knowing that when you finished, and this is the part that takes an incredible amount of discipline, when you finished, you record your results, and then you throw the code away because it's a prototype. Yep, yep. And that's very hard to convince the stakeholders, but that's something that a good tech lead should do up front.

Well, you can also make it clear that this is not shippable, especially if you're just doing PDF wireframes of a site. Clearly, you can't ship that. That's not usable. Think back to the old days of Detroit when they used to model cars, right? And if they were doing wind tunnel tests, they'd probably build a car out of plywood and clay, and they could stick it in a wind tunnel and see how it behaved.

No one would want to take a plywood and clay car out on I-95. So, you know, clearly that's a prototype and that's what we're aiming for when we do prototypes. However, the other side of that is sometimes you actually need a way of seeing how your whole development hangs together. So maybe you're using a new front-end technology you've not used before and a new backend web framework you haven't used before. And you need to know how that hangs together in your particular context. And for that, we recommend doing something different, which is to do an end-to-end thing extract, if you like, of your actual final application. And you don't worry about anything apart from getting the database

to talk to the back end, to talk to the front end, to talk to the user, whatever it might be. So there'll be no error checking. There'll be no anything apart from this, let's get a crack in this wall that's in our way. And you make that crack and you see if it's the right way of doing things and then you build from it and we call it tracer bullet because it's the same way that you know if you watch these old war movies when people are firing machine guns in the dark

they use you know every nth bullet will be a tracer bullet that glows and so they can see where their bullets are heading and that's exactly what we want to do in software development. Yeah, that makes a lot of sense. I think, yeah, as you kind of said, the biggest thing is when you have the wood and clay car, because with software, the wood and clay car, it's not as transparent, but that's where, as I said, a good tech lead will say,

no, this thing is being held together with uh with with clay you know we need to go back and rebuild it well that and that comes back to a matter of communications that we haven't really talked about yet but you know the biggest things that that you do as a software developer right the job is problem solving you know it's not coding java it's not coding javascript whatever it is problem solving. It's not coding Java, it's not coding JavaScript, whatever. It's problem solving. But in order to do that, there's an awful lot of communication going on. And it's not just talking to a user or interviewing a user, but it's communicating with the team,

communicating with the sponsors. It's about learning all the time from the system as it's evolving under your fingers, learning from the team as you work together and build this thing, learning from the users, because they may not know what they want before you show them something, right? There's that kind of like, you know, Heisenberg uncertainty principle with users. As soon as you put software in front of them, they realize what they really wanted was something else. So, you know, this is all, again, it's very dynamic, very ongoing process where you're communicating, you're learning, and you're solving problems.

That's what the job sort of comes down to, I think. Yeah, that makes sense. Let's jump to something else. What about another sort of, I'm going to go through basically a lot of the great debates that I've seen over the years and get your take on it. And I feel like a lot of them will relate to the book, but feel free to tell me it doesn't. But how do you handle

interviewing? We have this great debate where what we do is we bring candidates in, we ask them to invert a binary tree, solve some NP complete problem that has some trick to it that makes it polynomial. And then they never have to use those tricks ever again. And so you end up with almost this secret language. You have to come into the company, do the secret handshake that shows that you have this algorithmic genius from, in my case, I don't know, 10 years ago when we were in college. And then you get the job where you do nothing like that. How do you interview better? I think that's not, I mean, I think that approach in general is nonsense. Because again, you're not testing for competency

on what your actual expectation is. Because the job is not sitting around inverting binary trees or you know whatever the interview questions might be i think if if you can make the investment if you've you know identified a strong candidate and you want to see if they're if they have the the chops for it you invite them to sit with the team for a day and you watch them work and you see how do they get along with people how do they they work? What style do they have? At the end of that day, the team gets to decide whether they hire this person. Oh, interesting. Yeah, exactly. You know, ironically enough, we do exactly that for internal transfers where that's rather frictionless.

But at least in my experience, it's never been practical to do that with an external candidate. But yeah, I agree with you. For internal, that's definitely the way to go. I feel like that might be tough, right? I've done it for external. What makes it hard? Well, I mean, there's kind of a ramp up. Also, I guess it might be good as like a final round.

A lot of candidates might not want to come back for that day. I guess it depends on the job market and many other factors. If a candidate doesn't want to do that, then you don't want to hire them. It's true. Because a candidate who doesn't want to know what it's actually like to work there is like crazy if you ask me and you wouldn't want to hire that person that makes sense so but let's say uh you know i do think a lot of companies you know want to have the person in for one day um oh i guess so so if you could only have a person for one day that that would be the day they would just sit with you and then and you

would do that instead of in lieu of all the other interviews. I think you'd have one, maybe a 20-minute. Okay, so all the research I've read have said that you can pretty much sum up your feelings about a candidate in the first, it's ridiculously small, it's like two seconds or five seconds, right?

And they've had people actually record their opinion at those very, very small times and then go through the entire rest of the day. And it turns out their initial impression is typically the correct impression. So you have them come in and talk to whoever, you know, HR, someone in a suit, whoever it might be, just to weed out the clear whack jobs, the people who you wouldn't want to hire just because. And use your instinct, use your intuition. If you're good at this, then your intuition is the best judge, right? A programming test is irrelevant because you don't turn up at work

and have your boss say, okay, everybody in the team, here's an NP complete problem. You know, it's that way. So what's the point of doing that during recruiting? But instead, you know, what you do have to do every day is to turn up, learn new things, work with a team, not be a jerk, you know, and, you know, generally have hygiene. And to do that, the only way I can see to do that is you overcome the initial hurdle of being acceptable to HR, and then you actually work with the team. Yeah, that makes a lot of sense. You say there's a ramp up. Of course, there's a ramp up.

But the reality is the time of people that you want to hire, typically you want them to be able to ramp up. You want them to be able to go into an environment and learn what's needed to be learned. Now they're not going to be experts in the domain and the team is not going to throw them into the most mission critical part of it, but they are going to have to show that at the end of the morning, at least, they now know enough to be productive at some level so i mean i think this is fascinating i haven't thought about this you know this this method but to play a bit of devil's advocate um you know that um there might be some people who are sort of slow starters but sort of get in a good rhythm there might be other people who kind of have a lot of energy early on and then kind of get burnt out. Would you be sort of favoring that second group, which is not really a good thing? Well, it's a different axis because the, you know, solve the trivia question on the board isn't going to tell you that either. That's true. If anything, that favors the people who prepare to interview, which is probably worse. That's all it does. That's actually all it does. It's the people who found the cheat sheet on

YouTube or wherever. It said, okay, here's the questions. This is what Google asks, or this is what Netflix asks, or whoever. And here's the good responses. Here's the answers. So, okay, you can identify that they've got some initiative and some research capability that they bothered to look up the answer. But that's all it's going to tell you. Yep. I have a friend who has a pretty morbid view of this. His view is basically that you can't hire effectively. And so all you can do is fire effectively. And so there's some companies, I won't name any names, but there's some companies where that's kind of their strategy, where they're relatively loose on the hiring. But then there's a pretty, there's sort of some unwritten rules about, you know, firing what they consider the bottom 10% after a year or something like that.

Yeah, I've heard about that. And I think the problem with that is that a company has to be a safe place, I think, in order for a team to be effective. If a team is spending their whole time worrying about a set of performance numbers, then that's going to be their focus as opposed to solving the problem. I've heard about a company that does exactly as you described, that at the end of the year, the bottom 10% get culled, which technically is decimating, which is kind of fun. And I've heard of managers in those organizations that adjust their priorities in order simply to make something by the end of the year that gets them back up into whatever the performance goal is. And that totally destroys what the team was doing.

So, yeah, I think there's merit in that, and I think a company has to be able to reposition or fire people that just do not work for that company. But at the same time, I think this kind of like mechanical, you know, the slowest 10% we just, you know, leave behind is the wrong kind of motivation. It's the danger. It's the danger of metrics. And I mean, there's literally whole books written on how you can kill your company by slavishly following metrics. Because as Dave was indicating, any metric you set up, people will find a way to game it. And they will work only toward that metric and lose sight of the actual business value, the actual reason the organization is there. Just look at standardized testing in schools. Yeah. Yeah.

Teach to the test. Exactly. That's right. Yeah. I feel the same way that you do, Dave. I feel like my team is kind of my family. I wouldn't go and tell one of my children, well, you got an F on this test. Why don't you go down the road and live on that house over there? you're out of the family um uh and uh so yeah i totally agree um

so actually let me ask you this and there's this sort of idea of this you know pareto distribution when it comes to engineering talent like everyone says oh i want this mythical 10x engineer and so i'm going to hire like crazy fire like crazy do this this really bizarre thing because i'm trying to look for that needle and do you believe that that there is sort of that sort of Pareto distribution that some people are just you know coming in doing 10x there is but they're kind of looking at the wrong axis because the way that that's commonly interpreted is you're looking for the individual performer who can be 10x better than anyone else,

and that's actually not what you want because that person is probably a phenomenal jerk. Not easy to work with. For real, seriously. What you want is you want the performer who can come in and make the team work at a 10x level. So why is the 10x person a jerk? I mean, I know people like that, but just broadly speaking,

why are those people jerks? Because the slow people get in their way, right? They know that they could be coding really, really fast. But having to fill out all these stupid forms gets in their way. Having to, or even worse, having to answer all these ridiculous, stupid questions from people who could just look it up, right? That gets in their way. And quite often, there's actually a little hidden problem, and that is when someone gets to a certain level of expertise, the knowledge they have, okay, there's a whole bunch. I could go on for a long time about this, or Andy could better than I could.

But it's all to do with the fact that the real processing power in your brain is the non-conscious part of your brain. And the conscious part is just kind of like window dressing that lets you interact with the rest of the world. So when you're first starting, in a particular area, all of your processing is being done by your conscious brain because you're having to think about everything you do, like when you learn to drive or whatever it might be. And that means it's slow. And that's why when people first start to drive, they're very jerky and they're slow to respond and all that kind of stuff. But after a while, the information starts to get embedded in your non-conscious brain as tacit knowledge. And at that point, you start to operate more by reflex.

And that's why an experienced driver can drive without even thinking about it. Same is true for experts in any field. So if you become an expert programmer, then it's because you've put in the hours and you've used the feedback and you now make decisions, not at the conscious level, but down deep somewhere in the lizard brain. And as a result, when someone says, why did you do that? The answer is probably, I don't know. It was still a good decision, but it was made without conscious thought. And that is also very disruptive to a team because you have this person who can just basically do things and not know how or why, which means he can't tell or she can't teach the rest of the team what they're doing. But Andy's point is a really good one. If you want to make a team 10 times more effective, or sorry, if you want to get the equivalent of a 10 times increase on a person's performance, if you have a team of 10 people, all you have to do is bring

in a manager who can make each individual in that team twice as effective. And you can do that. So maybe just to recap, I think what you're saying is if you're off using your lizard brain, using your unconscious memory and writing code like crazy, and you're not taking it to the conscious space, that's what's giving you the 10x, but that's also just blowing up the people around you because ultimately you need to communicate and you need to be conscious to sort of work as a team. And also sometimes your unconscious is just going to do things because it has seen this situation in the past 17 times and it's going to say, okay, this is the way to do it. And it might not be appropriate the 18th time. Yeah. That's, that's the big risk because you know, you're the expert is relying on intuition and lots of the time they're right, but not necessarily, they could be very wrong and they could develop something now that no one else on the team can understand and can't fix.

Yeah. This is, you know, this is a bit of a tangible, bring it back, is I know somebody who was working in finance, and they were using rather old machine learning techniques. And I said, what about using some of these newer techniques? What they told me was that they tried it, and for six, seven months, they were making more money. But then the eighth month, they took a huge hit, just had some really bad decisions.

And there were decisions that were unexplainable. And so because of the lack of explanation, lack of interpretability, they ended up dropping back. They would rather make less money, but at least know what was going on. And so that's another example where, yeah, someone has to sort of really kind of communicate. Another thing is there's a lot of people who don't want to do good peer reviews.

And, you know, my sort of philosophy on that is if you read your code and the peer reviewer reads your code, right away that's twice as many people reading the code than writing it. So it's only going to multiply more than that. I would say, actually, if you read your code, that's an infinite number of more people reading it than typically happens. I don't know. No, seriously, how many developers stop and reread their day's output the next day?

Yeah, not very many. Not very many. Think how much, given that peer review or code review is the most effective way of finding bugs, just think how much more productive people would be if the first thing you did in the morning was get a cup of coffee, sit down, and

read yesterday's code. Yeah, that makes sense. With a clear head and fresh eyes. Fresh eyes can make all the difference. Yeah. What about, how do you sort of reward, you know you know this is getting more into the social part of it I guess maybe the corporate part of it but how do you serve reward good engineering you know like you could say that it rewards itself but then the problem is now assigning that reward becomes difficult right it's almost like the person who

manages the the nuclear power plant you know, it just becomes someone that doesn't really get thought of a lot. How do you sort of develop the right incentives and the right sort of structure to really reward people for taking that extra time to be conscientious? What do people want? What do people want? Yeah. See, I'm doing the consultant trick there. I'm taking your question. They want autonomy and mastery, Dave. Oh, thank you, Andy.

I mean, that's exactly right. I mean, if you want to give people motivation, you give them more of the stuff they enjoy, right? And you make it, you create an environment in which it's enjoyable to create cool stuff, good stuff, the stuff that you want created. And if that's the case, then you can reward people by giving them more of it. I think you have a bit of a tragedy of the commons where what people want is to sort of do things that have some impact. So maybe people want to use a new framework. Someone else wants to get more people to visit their website. And what happens is people might want to write good code,

but that want ends up becoming secondary to some of these other wants. Those motivations are all facing exactly 180 degrees away from where they should be right what people i believe what people really really want most people who go into software development do it because they want to produce something that other people can use they want to be useful right they want they want there's a thrill involved in shipping software and knowing that two people are using it, or in some cases, a hundred million people are using it. And you're making a difference. If you're a Twitter or a Facebook or whatever else, you are changing the world. People are organizing revolutions on your platform, right? People are organizing hate campaigns on your platform. Whatever it is, you're changing the world. And so people who are in those

environments should be given that feedback. They should get to know that, yes, you are making a difference in the users of your software's lives. Because once you know that, I can't think of anything more motivating than getting out there and helping out. You're in know that, I can't think of anything more motivated than getting out there and helping out. We are kind of like little godlike beings on this planet in that we're one of the few industries that can take nothing and create something from it. I mean, yeah, we use But it's sort of an opportunity cost. So piggybacking on that, someone can say, well, you know, I just wrote this this this prototype. I built it out of wood and clay assembly code and I can go and do the have the discipline to go and rewrite that. Or I have this new idea for changing the opinions or changing improving the lives of these hundred million people.

And I'm going to do that instead. And then a year later, the wood and clay thing falls apart, right? So yeah, Kent Beck, have you seen Kent Beck's talk on that? The three X's? No, but I'll add it to the show notes. Okay, because Kent Beck has a talk about his time at Facebook where he talks about the different cultures of the different parts of the organization.

And you have the people building the clay prototypes, right? And you have that high churn, high risk, high return kind of experimental side of it. And then you have at the other side of the curve, the we better not screw up because it will kill the business part of the company, right? And they have very different objectives, very different ways of managing it, very different ways of measuring success. And the interesting part is the curve that goes between the two of them and how things transition up and down that curve. And I think that that addresses what you're talking about. I think if you have a person or a team that really, really enjoys churning out ideas and are really, really bad at all of the polishing and everything else that takes place, that's

great. You have yourself a little factory of really cool ideas. Then you have on top of that people who can filter, who can do the A-B testing and all the other kind of stuff, at the end of the day say, you know what? That really was a really great idea. Let's make it look good or let's make it manageable or maintainable or whatever else you need to be able to do. So don't kill the team who's being imaginative just because they're using clay. And this goes back to what we talked about right at the very beginning.

It goes back to context, right? One size doesn't fit all. It's perfectly okay to have one team that is the imagination factory and one team that is the solid, reliable, engineering with Erlang never fail kind of, I mean, whatever. That's what's best for them is not best for the other. And that's as it should be, right? Every context is different.

That makes sense. So, I mean, with that in mind, yeah, you really need to have a good engineering discipline all the way up through the stack of, through the leadership in the organization, right? Because there has to be somebody high up that says, you know, we have all of these prototypes. Now we need, we need a team that is that has a different incentive to make sure that, that you know, that, that, we don't end up with just wood and clay when we're done that we have,

that we have the solid foundation as well. Well, unless your business is making wood and clay, in which case you're all set. Sure. Yeah. Fair enough. Fair enough. I mean, it depends, right? There are companies that do that. Like Xerox PARC, for example, right? Yep.

They spin off the skunk works and, you know, they spend their entire lives producing nothing more than prototypes. And then the rest of Xerox looks on and say, hey, we could productize that, you know, and do so. So let me ask you this. So what do you know, so someone who runs, let's say, you know, a lot of the people listen are, you know, fresh out of college or changing industries or things like that. And I remember when I first got into the software engineering industry, I kind of thought in my naivete, I thought tech leads were just people who didn't work as hard. And I thought managers were people who didn't do anything. And directors were people who posted on social media about the company.

That's obviously not true. But, you know, so we talked about one thing that, let's say, directors, maybe even vice presidents or CTOs have to do, which is sort of setting up teams with different incentives. What do you think, just more broadly, that tech leadership at a company does? They support their team. The point of a tech leader, I think, is to run ahead of the team just a little bit and sweep all the debris out of the way so the team can move smoothly and efficiently through to completion. It depends on what phase of a project you're in as to what that involves. At the very beginning, it could well be setting architectural overall directions. A good tech lead will act more as a referee than as a dictator when it comes to that. But then later on in the project, a tech lead will be running interference with management. We'll be making sure that the team is producing whatever artifacts are necessary and fighting back the requirement to produce artifacts that aren't necessary. Fundamentally, the tech lead is a servant of the team.

But notice, notice again, that's a very dynamic description. It changes over time. It's not a static, just do this one thing. You know, at this one point, the role changes depending on, you know, the life cycle of the project and even the organization. It's, you know, once again, it's a very dynamic approach. Yeah, that makes sense. What about somebody who wants to get into the industry? We get a lot of emails from people who, you know, they want to know, should I go back to college, get another four-year degree in some cases? Should I do this boot camp XYZ? Should I just go on GitHub and start cloning, you know, forking repos and learning that way?

You know, but ultimately the goal for most of the people who write in is to get a job, right? So with that as the goal, how could somebody, you know, get started if they didn't, you know, get a CS degree or they didn't go through that process? May I? So I think that there is a use for CS degrees, but that use is not preparing someone for a job in the industry. There is a theoretical side to computer science that you probably need to learn if you want to go into research and move the goalposts a bit further forward. For getting into the industry, I don't think you're particularly well served by a CS degree. I see people graduating CS degrees who have never written a unit test in their life. Oh, yeah, Probably the majority. Yeah. Who couldn't organize, you know,

who couldn't be part of a team to save their lives. So you hire someone like that, you know that they have the resolve to sit through four years and, you know, pass some tests, but you also know you're going to have to train them pretty much from scratch. I think a bootcamp is, if you're looking for people who you can actually employ, a bootcamp is a better bet. But I think you also, if you're just starting out and you go to a good bootcamp and you learn both programming and also project stuff, then I think you're way ahead

of the curve. The trick there is to realize that seven months does not count as experience or as, you know, it doesn't make you an experienced developer. And so once you graduate from a bootcamp, you get your job. That's fantastic. Don't forget that you now have to catch up with your colleagues who have a lot more experience in terms of a whole bunch of stuff, algorithms, languages, techniques, tools, all that kind of thing. And so your bootcamp is basically a way of bootstrapping you into the industry, but that only gets you so far and you have to keep learning after that. Well, and that's really the key right there. The chief ability you need to pick up, whether you do it on your own or from college or university or some other program, you need to

learn how to learn and how to do so fairly quickly, given the pace of our industry. So, you know, that's one of the advantages, I think, that getting any sort of degree, it doesn't have to be in computer science or information science or anything, but just the, you know, going through the process of getting a degree, you know, usually you'll at least pick up on your own if they don't explicitly teach you how to learn things.

You know, make yourself crib notes. Make yourself cheat sheets. Do whatever your technique is. And once you kind of have a feel for that, then the rest of it's much easier. Okay, here's a job you want, and they're using a language you've never used before. All right, well, let me go. Now let me go learn that. Let me go take a course on that or download some YouTube videos

or buy some books or whatever it might be. Because even once you've gone through that sort of that first hump and gone through the HR process to get you in the door for the first job, that doesn't mean the learning's over, right? You've literally just started. Now you've got to learn the domain and this framework that they're using and this other language that they're using that you didn't know about and on and on and on. So, you know, you really need to be prepared for the constant learning and the constant upkeep, kind of no matter where you start. That really is just the beginning. That makes sense. And I think it ties into the interviewing,

you know, discussion we had earlier where, you know where the sort of corollary to that is how do companies evaluate all of these different boot camps that don't have sort of this rubber stamp from, I guess, the government, whoever accredits the college accreditation board. board? And I think the answer is then that you have a better interview process so that if someone, if over time you learn that bootcamp XYZ is not really preparing people, you could learn that in the interview. Well, actually many bootcamps now will actually organize for their, typically the last iteration, whatever they call their kind of three or four week cycles, the one before the last will actually go out and work in industry. And they'll have like, you know, companies that are interested in evaluating people and also are prepared to like train them to some extent. And so that's actually a really good way of recruiting, right? So you volunteer, you know, you say to them,

I'm looking for whatever it might be, a Rails developer. And you go to the bootcamp and say, I'll take one of your Rails developers for three weeks and I'll give you a review at the end on how well they did. And you know what? If you like them, make them a job offer. Yeah, that makes sense. That makes sense.

This happens a lot with interns with interns so it's the equivalent of an internship where somebody is in their final year at university they spend a summer at company xyz and then they get a it becomes more frictionless to to get a full-time job there exactly yeah cool that makes sense what about um i had a topic on top of my mind. Oh yeah. What about working remotely? Um, does the book cover that or is that something that's kind of out of the purview of the book? I know there's a bunch of unique challenges there where you're sort of, you know, the only person in Kansas on your team. That's, that's not something we, we really speak to, um, by itself, but we've done an awful lot of it. Um, I haven't worked, I've not worked in an office for

25 years now or so. Okay. So, you know, that's, we're well acquainted with it, but we didn't, we didn't really address it specifically of, you know, here's the tips and the techniques. I mean, it kind of, it kind of falls under the purview of the other topics of good communication and, you know, those sorts of things. Yeah, that makes sense. Cool. Yeah, this, this is absolutely fascinating. I think, you know, we didn't do sort of this broad overview of the whole book, but I think actually, you know, anyone who sort of listens to this should be extremely inspired to go and read. This is a fascinating book. I'm about, I think, three chapters in.

My plan was to have read the whole thing. I said, oh, while I'm on paternity leave, taking care of this newborn, I'm going to have this book read by today. And that was a bad plan. I think by the end of the book, I'll realize, you know, how I actually messed that one up. Is this your first child? Second one. So. Oh, so you didn't learn the first time. No, that's right. Yeah. I didn't iterate fast enough there. Need to take a bigger, bigger step in the gradient. Well, well, the problem, the problem, of course, with a newborn is you start getting that sleep deprivation

hallucinations going on. So yeah, that's right. We'll give you a pass. We'll give you a pass on that. But that is an example of one of those irreversible decisions as well. Yeah, that's true. Definitely a critical decision. There's no going back. So is there a part of the book that you wanted to highlight? Oh, actually, we did want to talk about what's new.

So for people who have the 20th, who have the original version, what can they expect to learn that's different to the 20th anniversary version? Well, to some extent, really, it's a whole new book. We added, I think what we're saying, about a third new content, but there's changes literally on every page from the original, some small, some more major. But you have to consider that the world today of 2019, 2020 is really very much different from the world of 1999 or year 2000. So we tried to reflect that. You know, a lot of stuff changed in technology, a lot of stuff

changed in attitudes, how you approach certain things. So I, you know, of course, I would say, yes, go out and buy the new book. But and some people say, well, should I get that? Should I read that instead of the first one? And really, it's a it's a I think it's a different experience. I would say you don't need to go if you've never read it you don't need to go out and buy the very first one no i just got the new one but but it is it is not like you know a jack reacher book where you have to read them in order or something you know it's just yeah right it there's a lot of there's a lot of uh i guess let's come back to the original question you say say, you know, what would I learn from reading the book?

And the answer is really exactly what Andy and I learned over the last 20 years. Yeah, that makes sense. I mean, one thing that I think personally I've felt very – has changed a lot is open source. I mean, in 2000, there wasn't the kind of open source community that there is now and and some of these silicon valley companies like google um were just way way ahead maybe even a decade ahead of everybody else um now the open source um communities has gotten so big and now i mean most of the big companies are in the open source community so they're pushing it forward that i mean now it's a lot of looking at what's out there versus yeah in 2000 there wasn't that much out there well and it's funny

because yeah the net was still new there was no google we used alta vista we used lycos you know those were the search engines um and every time in the in the first edition of the book we would talk about the internet you know with a capital, because it was this new, you know, awesome thing. And so, yeah, we had to tone that down. It's like, oh, of course, just go grab this on the net. And, you know, little things like, you know, in the old days, we'd say, okay, if you wanted to learn this language, hey, this is great. There is an open source implementation of it. You can go and download it and do, you know, make, config, make, make, install, and play with it. And you don't need to do any of that nonsense now, right? You can go online and play in a REPL

in any language that you want. Yeah. Yeah. Yeah. It's just there. So yeah, there was a lot of that, those sorts of changes, you know, not having the build machine over in the corner, but being able to do a, you know, just push in your version control system and have a pipeline in the corner, but being able to do a, you know, just push in your version control system and have a pipeline in the cloud, do your continuous integration, build, test, you know, whatever it is. So yeah, there's definitely, I would classify that as sort of added almost attitudinal changes because it is a technical change, but it feels fundamentally different from having, you know, a build machine in the corner versus I'm just doing a commit in my version control and it's just happening. Yeah, there's a scalability or a scale-free nature to that.

I mean, we have one project I work on. Every time there's a commit on any branch where there's, I don't know, there's probably thousands of them or at least hundreds of them a day, it goes through and in the cloud does an integration test. That'd be totally impractical if you had to have the machines yourself by your desk. Sure. I think there's another side to it, though, and that is that the proliferation of open source has meant that choosing technologies has now become something of a nightmare. And many developers are faced with this.

It's the start of a project. What is the JavaScript framework this week? Yep, yep. And I think that in the face of this bounty, this like excess of opportunity, it takes a lot of discipline to say, I don't need to be using the latest and greatest. And the teams who are the most effective

are the ones that find something that works for them and obviously periodically review to make sure it is still working. But don't worry about the fads. Don't worry about this latest thing they read about on Stack Overflow or whatever. And just to keep thinking about the fundamentals. The fact that nowadays you can

put together a thousand node cloud computer system managed with a database and with an operating system and with compilers and with libraries and with everything else and not spend a cent apart from processor time. It's unbelievable. It's an incredible opportunity. And the trick to utilizing that, I think, is to be efficient and effective and really pretty intensely focused on what it is you're trying to do and not how you're trying to do it. Yep. I know personally, I get a lot of analysis paralysis when I start a new project, especially something in, let's say, web, where there's so many different technologies, and you could spend an entire day reading about React versus Angular, and people have probably a whole career based on writing about that. And what's even worse, I find, is that I'm in

the middle of a project, and it's not working. And there's this human reaction, which is, well, it can't be my fault, right? So it must be this framework. And it's really hard to resist that temptation to say, okay, I'm going to dump React and go to Vue and see what happens if I do that, you know? And I see a lot of people doing that. And I got to say, actually, I don't think that's a bad thing at a certain point. I mean, obviously, if you're far down the path and months and months into the project, maybe that's not such a great idea. But if it's early stages and you're prototyping and you're learning and you don't know, well, would Angular be best for this particular application? Or should I use Vue or should I use React or whatever today's latest entry is, you know, try something simple in each one. Try something

complicated in each one and, you know, give it a go. See what you learn from that. See which you think would be easier to maintain, which would be easier to, you know, to deal with. You know, too often, whatever we are faced with, whether it's an architectural decision or a design decision, we kind of go with whatever our first instinct is. Okay, well, here's a way to solve this. Let's do that. And that becomes the direction. So I'll leave you all with a challenge.

You know, when you're in that situation, think of at least three different ways you could do it. Think of three different frameworks. Think of three different algorithms. Think of three different frameworks. Think of three different algorithms. Think of three different approaches. And try as much of each one as you can and see what that tells you. See what you can learn from that. Yeah, that makes sense. I think also things are much more transferable than we believe. I think when we start out, we have this big fear of missing out. That if we don't do it and react then we'll get to some point we'll be totally

stuck and the reality is it never really works that way um you know most of the even if worst case you have to completely rewrite it in a different language that's going to be much much faster than yeah because because now you know what it's supposed to do and you know they call it software for a reason it is soft soft. You can change it. Oh, I thought it was because it was wearing. On that note. Cool. Well, this is amazing.

So if people want to, you know, get the book, where would they go? If they've read the book, how can they contact you folks? How does that part work so the ebook is available directly from us at pragprog.com which is short for pragmatic programmer you go to pragprog.com and that's our publishing business we've got hundreds of titles in print that other authors have written that we've published over the years. And you can get the 20th anniversary of the Pragmatic Programmer in PDF, Mobi, and EPUB format, all for one price, directly from pragprog.com. And then on September 19th, 2019, the hardback, we're going hardcover this time. Oh, really?

Yeah. Well, we figured so many people kind of complained that, you know, their books were getting all dog-eared from lending it out to folks and rereading it and reading it again and carting it around. You know, they were taking some heavy damage on the cover. So we figured, all right, we'd give it a fighting chance this go-round. So the 20th edition is a nice hardback, you know, suitable for stuffing in your backpack and kicking around the coffee table. Nice. And that'll be in all the sort of regular Dead Tree bookstores, Amazon, Barnes & Noble. If you've got a local bookstore, please patronize them.

We like to keep them in business. Cool. And how can people reach you and Dave if they want to talk to you folks? You can find us both on Twitter. Dave's at PragDave. I'm at PragmaticAndy. That's probably the best way to get a hold of us. Cool.

Cool. Thank you so much again for coming on the show. And yeah, everyone, so check out pragprog.com. And we'll put a link to that in the show notes. You can grab your copy of the book there or at your local bookstore. When does it, when does it hit bookstores? Uh, the, so September 19th is the official publication date. It'll be available on, uh, informit.com at least at that date. And I believe Amazon within a few days or a week after that. And then it sort of

diffuses through the ecosystem. So, you know, other places in the U.S. will have it within a week or so. Internationally, it might take a few weeks to get to your country. Cool. Cool. So for that for that for that boss you have who still wants people to invert a binary tree for the interview, you could give it to him for Christmas. It'll be there. Absolutely. Makes a great Christmas present christmas present all right cool thank you again for coming on the show thanks for having us the intro music is axo by biner pilot programming throwdown is distributed under a creative commons attrib Share Alike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work,

but you must provide attribution to Patrick and I and share alike in kind.