Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the nature of code changes and the need for tests to act as an anchor.

[00:00:31] Dave Adsit: I'm Dave Adsit, a VP of engineering. And recently I've been thinking about the pace of change in life and how we can act and react well in the face of it.

[00:00:42] Allan Stewart: Our topic for this episode is book recommendations. There are a number of books that we feel have been impactful to us, and we want to recommend ones that we think have stood the test of time. We were discussing a little bit earlier that books, there's a lot of effort that goes into a book. And so although there are also many great blog posts and other articles out on the web, conferences, conference talks that were recorded, etc. Books are a good place to act as a kind of a general recommendation and a good baseline to run off of.

[00:01:17] Dave Adsit: Yeah, I think one of the things that books have is that they either fade very quickly or they tend to hang around for a while. So some of these books have been around for longer than you and I have been working as professionals, but they have content in them that really has stood that test of time. So, yeah, let's just get right into it. Let's recommend some of our books, Allan. Let's do it. Where should we start?

[00:01:48] Allan Stewart: So we're going to start with a few books that are kind of broad thinking about your career in software.

[00:01:55] Dave Adsit: So the first one up for me has to be Apprenticeship Patterns. Apprenticeship Patterns is basically a couple of guys, Hoover and Oshineye and I, they got together and they were like, "hey, here's things we've noticed about our careers and other people's careers." And this book for me, it gives you permission to explore your career as though it is a separate thing. And for me, that was an important reminder that you are responsible for your career and the direction it goes. And there's a lot of different patterns that you can apply at different points to maximize that and maximize your outcomes with your career. And it's not necessarily about the financial side of it, but like the actual doing the career of software development.

[00:02:44] Allan Stewart: Yeah. I haven't read that one all the way through, but I've read sections of it, some of the patterns, the specific patterns. And I really like that concept of basically applying that pattern language, just like we do for other kinds of software patterns. But like you say, thinking about your career and giving you optionality, because I think sometimes we get stuck mentally in, well, this is just how things are. And we're willing to experiment and play around with new technology. But this gives you some ideas of where you can play around with how you want to be in your career. So then the next two that we've got are fairly related. We've got The Software Craftsman by Sandro Mancuso and then Clean Craftsmanship by Robert Martin. They're both in the Robert Martin series, I believe. Software Craftsman came out a little bit earlier. And I really enjoyed it, reading it at the time that I read it. For me, I think Clean Craftsmanship, I think sums it up a little bit better for me, like really hitting the important parts, but both are excellent books that talk about this idea of taking what you do as a craft and being professional about your software work and some of the aspects that really go into to how do you do this well? For example, do you do testing? How do you know that your code works when you're going to deliver it to your company, right? Whether you have an external testing team or not, whether there's external operations team that's going to run it or not, there's still some things that you can be doing to ensure success for that project.

[00:04:35] Dave Adsit: Yeah, I like both of these books as well because they provide you with a framework for what it means to be a professional and also some practical examples from times when the authors actually did these things at places that they work at and the outcomes that they got there. So yeah, the concept of craftsmanship, I think, is critical. And I really like how they approach it in these two books. So the fourth book in the thinking about your career category is Software Craftsmanship, The New Imperative by Pete McBreen. And I encountered this book at a time when I was ready for the concepts. It's been around longer than the others. And it is almost a manifesto. And in the manifesto, he talks about the importance of being trained by someone who is more skilled than you and finding someone who will help you on your career and trusting that software engineers are in fact professionals who deliver value like a lawyer or a doctor, not laborers the way they had been treated by many companies up until that point. And so for this one, it really helps set the stage for what is the career path that you you are on and what are we doing and what is possible in it? Uh, I think it's, um, a really cool book and I recommend it to a lot of people.

[00:06:10] Allan Stewart: Yeah. There are definitely some things in there that, uh, lean more heavily on like old, um, like guild concepts, for example. And, um, how do you become a trades person in the medieval ages, which may or may not translate very well into the, into the current, um, modern day. And I've definitely heard, heard criticism of this book because of that. But if you're willing to look at it and, and say, okay, well, how can we take this idea? And, and I guess this would apply to all three of these craftsmanship books and say, "hey, how can we take this idea of being, taking seriously how good you are at a craft and trying to excel?" And how can you learn and who can you learn from and what are some options of ways that you can expand your reach, uh, for example, like the journeyman concept, I don't, I have yet to see it really play out in a, in a, like, super successful way. But I've also, you know, spent a little bit of time working with people at other companies, and it was very eye opening for me. So I think there are good principles in those books that, like we said at the beginning, stand the test of time.

[00:07:34] Dave Adsit: Right. And so those are a collection of books that are very specifically about the career of of a software developer, a software craftsman, a software engineer, right? One of the critical components of that is writing code. What we do, the work output that we create, the work product we create is, it's solving problems, but it's also typically writing a lot of code. And so we've got a collection of books that are all about writing code that we recommend to just about every software developer. The first one is Clean Code. Once again, Robert Martin from the Robert Martin series. This was the first one. This one's all about the Robert Martin style of writing clean code. And again, he hammers home. This is an opinionated way to write code for your on teams. And I really like that it is opinionated, but also acknowledges that as opposed to saying context-free, everyone should always do this my way all the time. He says, no, this is the way that I have found success and encourages people to pick up those practices, but also find additional practices or alternate practices that allow them to find success.

[00:08:53] Allan Stewart: Yeah, and he definitely covers code from a lot of different angles, from how do you structure functions and like lay them out on a within a file to how do you format your files and whether you should have code comments and things like that, which, like you said, I don't agree with everything that he has in that book. But I really like that it covers a lot of ground making you think and say, "oh, well, if I disagree with this, why do I disagree with it? What do I want to do?" And sometimes there are things that trumpet. For example, I know in the C# world, we've never let go of the idiomatic letter I prefix on our interfaces just because it's so ubiquitous to how C# is written. And it's not what he says in the book, but I think it's very valuable to have read the concept about how do you name your interfaces versus your concrete classes and decide for yourself, whether, whether you're going to follow that advice or not.

[00:10:04] Dave Adsit: Right. And I will say, uh, I always tell people there's things in this book that I don't agree with. I will say that in general, most of it, you can assume that I do agree with, and I use it in most of my code. I think the one thing that stands out is the interface naming. I do not like naming my concrete class foo-imple so that I can have a plain foo as my interface. So, you know, in general, I would say do what's in that book, unless you have a good reason not to, at least on my teams. So very similar to that, there's The Clean Coder, which we could have easily put The Clean Coder in books about your career. But it also feels like it fits in books about writing code because it's very much about the interaction of people who are writing code, right? Right. I would say that the two sections or chapters that stand out most to me is "saying no" and "saying yes." Even if you don't want to read the whole book, go read those two chapters. They are critical for anyone who wants to have success writing software in a professional

[00:11:15] Allan Stewart: environment. Yeah. I also really like how he opens the book with some experiences that he had where he thought he was right and he thought he knew how code should be written and had some bad attitudes honestly about how he was interacting with with people and had some rude awakenings, which him sharing those was very valuable to me. I know there are people who go back and forth about you you know, how well they agree with Uncle Bob and his, his ideas. But I think, again, it's well worth reading. And, and looking at it, because he's not, he's not, how do you say, he's not putting up a facade of, "hey, this is how great things are." He does leave it pretty raw and say, "hey, I've made some bad mistakes. And this is what I've learned from it." And I think that that is valuable to learn from.

[00:12:14] Dave Adsit: I agree. So one of the things that you mentioned in the section on thinking about your career was pattern language. And not everyone may be exposed to the concept of a pattern language. And for me, Head First Design Patterns was my first real introduction to those concepts. And I recommend that book. It's easy to consume. It doesn't have a ton of patterns in it, frankly, but it teaches you how to use them and how to of think in terms of patterns. And then from there, you can go into all of the other pattern books. There's tons of books on patterns that are also highly recommended. But Head First Design Patterns is a nice place to start. They give you a good intro into the concept and some of the more useful patterns so that you can actually use them in your code base to deliver a high quality

[00:13:08] Allan Stewart: product. Next on our list is Refactoring by Martin Fowler. I read this one really close to when I read Clean Code, and between the two of them, it made a huge difference in my career. And part of that was just the timing for me personally, but reading through Refactoring and around that same time, I was also really pushing myself to learn how to do unit testing. And it gave me language to look at that code and say, "this is why I think it should change." Prior to it, prior to reading and Refactoring, I was just kind of like, "well, this code is bad. I don't like it. There's something yucky about it that is, that I can't describe." And I just, I can only just project these, like, negative, you know, value judgments against it rather than being able to say anything more concrete or objective about it.

[00:14:04] Dave Adsit: And I need to rewrite it all.

[00:14:06] Allan Stewart: Yeah. Oh yeah.

[00:14:07] Dave Adsit: Of course you have to rewrite it. That's the only answer. That's the only thing you can do with that. And the only way bad code is rewrite it, start over from scratch. No. And then Refactoring teaches you the alternative. And I, I mean, I really like Refactoring as well. Whether it's the first edition or the second, you're going to have a good time when you go through that book and learn those concepts and learn how to internalize them.

[00:14:28] Allan Stewart: It's another one where you can just read the first few chapters and you will get a huge amount of value from it. Um, because the first few chapters really talk about the concept of refactoring and how you do it and how you can make small changes, incremental changes that will affect your, your code base. And then there's a lot of pattern language stuff that comes after that. It's like, "Oh, here are some specific refactorings that you can do." And those are also valuable, but, but it's really front loaded with, with a lot of the concept.

[00:15:01] Dave Adsit: Right. And then one of the books that's on the list is Refactoring to Patterns, specifically by Joshua Kerievsky. And that one is the intersection of, "hey, we have patterns that we want to use, and we have code that doesn't follow them. How do we make it happen?" And that book will teach you, it'll basically hold your hand as you go through some of the actual refactoring step by step by step and result in code that follows patterns in a way that is more elegant and easier to work with and doesn't smell as bad and you don't hate it for some unknown reason anymore.

[00:15:41] Allan Stewart: more. And you get the pattern inception, where you use refactoring patterns to refactor your code into code patterns.

[00:15:50] Dave Adsit: That's right. It's fantastic. So speaking of code that we don't like and code that needs to be updated and fixed, most of us, most of our career are going to be working on existing systems. We talk a lot about how fun it is and easy it is to get started from Greenfield, blah, blah, blah. And then almost never work there. We almost always work in brownfields. And so a critical book for every serious software engineer is Working Effectively with Legacy Code by Michael Feathers. There are going to be some things in there that you find are super archaic. And you say, "I don't even have a compiler, let alone a compiler with a separate linker. So what are you talking about?" You're leveraging those to do things. And that's fine. Maybe you you will ever come across that need, but it's good to know that there are techniques for working effectively in any kind of legacy code base that you happen to encounter so that you can make improvements to it safely and reliably and behave professionally. Yeah.

[00:16:55] Allan Stewart: Yeah. I particularly like what that book has to say about getting code under test and figuring out ways that you can test test different styles of testing that might not be how you want to do your testing in the long term, but they can get the system under test so that you can make the changes so that then you can improve the tests. Even if it's just sticking like a, basically a testing shim in there that allows you to do something and get started.

[00:17:23] Dave Adsit: Well, and I will say, spoiler alert, there is as if a definition of refactoring in that book that's fantastic and very much aligns with the previous two or three books we just discussed.

[00:17:38] Allan Stewart: Our next book recommendation is The Pragmatic Programmer by Dave Thomas and Andy Hunt. This one is, it's just full of a whole bunch of interesting ideas and good ideas that relate to how you're going to sit down and write code. Where you're going to automate things, what, how you make decisions, or like I'm thinking about some of the chapters like "tracer bullets" where you can add in some measurement to see, hey, are you actually hitting your target or are you just firing wildly out there? And just lots of lots of ideas and patterns in there. Some of them, again, so some of them may have more utility than others. I remember in the first edition, particularly, there was a lot of talk about domain-specific languages, which I'm not a huge advocate for, but it's a good place to learn about them and how they can be useful, for sure.

[00:18:39] Dave Adsit: I thought you were going to talk about the importance of calling free if you call matter from the first edition.

[00:18:47] Allan Stewart: Yeah, that's also in there.

[00:18:48] Dave Adsit: That's also in there. And not necessarily a concept that we're ready to give up, but maybe that particular implementation. So, now, I also recommend Pragmatic Programmer to everyone, every software engineer. So, the last book that we have in this section on writing code is more specifically about how to get started with testing and how to use testing to improve the quality of your code. And it's Growing Object-Oriented Software Guided by Tests by Steve Freeman and Nat Pryce. I recommend this book to people who think, "my system is too complex to test. I don't know that I even need tests because everything I'm doing is so straightforward and trivial." Um, Steve and Nat have an approach to testing, sometimes called double loop testing, acceptance, test driven development, whatever, that is very, a very powerful tool that can help you with any scale of system that you happen to be building and help you understand how to build that system in a way that is, once again, reliable and extensible. Right, so that book, I will say, if you choose to tackle that particular book, grab a book club, maybe your team, maybe somebody else, get three or four of you together and, and go in, go in and, in a group so that you can get through that, the content of that book. Yeah, and I would also say that even

[00:20:21] Allan Stewart: though the title is talking about growing object-oriented software, most of the ideas there, especially around some of the test-driven development concepts, work great in other paradigms, functional paradigms and other things.

[00:20:38] Dave Adsit: For sure. I would say that the objects in that book are most often at the level of what you might call services or microservices in other architectural paradigms. So that's a collection of books we recommend for anybody who's writing code. The next group of books is books that we recommend for people who work on teams or work with other

[00:21:03] Allan Stewart: humans in any capacity. Yeah, and the first few books that we'll mention here are all written by Patrick Lencioni. He works at the Table Group, and they put out lots of different books books. And his books tend to be written as fables. So he tells a story that, that helps you relate to the concept that he is talking about. And in the course of the story, they figure out some ideas, some concepts that you can apply. And then at the back of the book, it summarizes it just into, here are, in more of a business book format. Here are are the concepts here. Here is how you might apply them. So I like them. They're pretty quick reads. The ones that I want to call out, The Five Dysfunctions of the Team, Death by Meeting, The Ideal Team Player, they're all in that parable style. He also has one called The Advantage, which is, I think that's the only one that in that group that is not actually written as a, as a leadership fable, but is also a good book.

[00:22:12] Dave Adsit: Yeah, I agree. I recommend all of his stuff, including his podcasts, of which there are multiple ongoing at any given time. So definitely would put Five Dysfunctions of a Team high on my list, regardless of what type of team you're dealing with. So beyond just those, the Patrick Lencioni books, there's also Making Work Visible by Dominica DeGrandis. This book is, I highly recommend the concepts from this book. Some of it you will read and you'll think, "oh, I already got this from X, Y, or Z, other location." But bringing them all together and talking about the criticality of keeping all of the work that a team is doing visible to all of the members of the team is super, super helpful, super insightful.

[00:23:09] Allan Stewart: Yeah. I think when you're reading part of this book, you might think to yourself, "well, I already have a Kanban board," but the book really dives deeper into the concepts. And as you go through it, you'll realize, "oh, you know what? There's actually a whole lot of things that get done every day that are not on the Kanban board." There this invisible work and exposing that and figuring out how you can make that visible then suddenly you're able to start having a dialogue about it. You can start discussing it and you have, instead of the vague notions, which we often just kind of rely on our gut to, to figure these things out. Now we've made them visible, we've met, we've started measuring them, and I think that's very valuable. The next book that we want to mention is The Mythical Man-Month by Fred Brooks. This might be the oldest one on our list, but it is still very good. This is the book that leads us to remember things like we can't make projects go faster by adding more people to the team, which is a problem that was identified in the 70s and continues to be repeated to this very day. So I think it's the one of the books that we're discussing. It's probably the one that requires the most mental translation to take the idea and say, "okay, how does that apply to modern day software development?" But once you establish that mapping, a lot of the principles

[00:24:46] Dave Adsit: hold true. Okay. So one of the other books on our list is Crucial Conversations, which is very much much about exactly that, how to have a conversation, how to get to a decision, a direction, whatever, when the stakes are high. And often in business, the stakes are high. For example, if your manager says, "hey, we're going to add three more people to your team because it's running late." Now you have to have a crucial conversation with your manager about why that's not going to actually have the outcome that they desire. Right. And so Crucial Conversations is the kind of book that you can reread every year or two. I know, I know a couple of people who make a goal of reading it at least once every year, because it's so important to be reminded of the concepts in this book. Yeah. And that's one that you can recommend to people, whether they do software or not. It's about every type of human endeavor. And then the last one that we have in this section, which may be the only book on the list that vies for oldest, I don't remember exactly which came first, Mythical Man Month or The New Economics, but the last one is The New Economics by Edwards Deming. And this book talks about, again, it's about how to work with teams and people and how to deliver quality consistently and reliably and what things you need to avoid doing and what things you need to focus on doing if you want to have good outcomes for your organization, whatever scale that organization is.

[00:26:25] Allan Stewart: And I really like how The New Economics goes into a lot of systems thinking concepts around, well, why are we getting the results that we're getting? And instead of looking at individuals and saying, "oh, well, this human, it's because of them." We look at it and say, "oh, well, this is the system." And we say things like, "oh, well, humans make mistakes." So instead of blaming the person who accidentally deleted a file or a database table or whatever, we look at it and say, "well, okay, how do we change the system so that the things that we don't want to have happen don't happen?" And also so that you can guide towards having the good outcomes that you do want to have happen occur more frequently because it's systemic to your organization. Jumping back real quick, one other comment with Crucial Conversations, just to plug that one a little bit more. I think a lot of people who are writing code didn't get into that job because they wanted to do a lot of people interaction. There's definitely the stereotype of a developer who sits at their keyboard and writes code and possibly is wearing a hoodie and has the lights off and the sunglasses on and the hacker gloves on and, and interacting with humans wasn't high on their list. I know for me personally that is an area of weakness for me. I feel like I can communicate fairly well well, concepts and ideas, but as soon as things get emotional, then Crucial Conversations is a great book for me to help ground me down and say, "okay, how can I deal with this well and not let emotion take over?"

[00:28:15] Dave Adsit: Excellent. So the next group of books is about building a product product or making whatever it is that you make as a software developer. So, and the first book in there is The Design of Everyday Things by Don Norman. I have liked this book and recommended this book for a long time, not just because it will teach you about the importance of how you design things for use by people, but also because it teaches about how to conceptualize and think about building systems, building solutions, building whatever, right? So it takes you through a process of discovery. How do we decide what to build? And then how do we make sure that what we built is the right thing? And I think that this book is critical for that. And also it's just fun to introduce more people to the idea of the Norman door. And, and honestly, if I have to be frustrated by doors that are built wrong. Maybe everybody should be frustrated by doors that are built wrong until we just fix them as a society.

[00:29:26] Allan Stewart: Yeah. Yeah. I really love some of those concepts, especially not blaming the user, right? If, if the users do things in a way that you did not anticipate, it was not their fault. Correct. So the next book, Accelerate, uh, by Nicole Forsgren, Jez Humble, and Gene Kim. It represents a collaboration between them that they did researching what makes some organizations high performers and what make others low performers. And so they went through and they did a bunch of studies. I think out of this came a lot of the ideas for the DORA metrics, which is the DevOps Research Association. Association. Is that what it is? Anyway, I don't remember. So it's got a, it's got some really interesting ideas, in kind of the same vein of what we were saying with The New Economics, where you're looking at how you write software systemically and looking at what are things that people can do. For example, if you have a automated deployment pipeline and you have a really fast mean time to recovery, that might matter more to you than the mean time between failures, because when something goes wrong, you're able to quickly get a fix out there or get a redeployment or whatever it takes, or a rollback. And so, um, there's, there's some really interesting ideas in there that I think I haven't had as much success as I would like in the actual measurement of those in organizations that I have been in, but thinking about the concepts has been invaluable. I agree.

[00:31:15] Dave Adsit: If you run a system, a software system, Accelerate is a great book to get you started in the right direction for how to make that product system work effectively. So to me, Accelerate is kind of the culmination, the data-based, science-based culmination of a lot of the things that came out of the Agile Software Development movement. And so one of the books that I recommend is Agile Software Development by Alistair Cockburn. I often refer to this as the "Purple Tiger" book because it's purple and has a tiger on the cover. This book is all about, the subtitle is, so it's Agile Software Development, a Cooperative Game. And it's all about the rules of the game that we play when we work in groups to build software. And it goes into a lot of detail. If you like game theory at all, this book is a book for you. If you like systems that are effective, this is a book for you. If you understand, if you want to understand deeply that sociotechnical systems must change as they scale, this is a book for you.

[00:32:21] Allan Stewart: Next, we have This is Lean, Resolving the Efficiency Paradox, by a couple of people who I don't know if I want to even try to butcher their names by saying them, but they are amazing people because this book gets into the core of lean. Lean. There was a while where Lean was going around a whole bunch of different industries. So it kind of came out of the automotive industry. And so it was taking a lot of the world by storm. And then people started applying it in other places. And you start talking about things like Six Sigma, and there's a whole bunch of related stuff. And I think it can get really confusing, especially when you want to apply it to software development. And so This is Lean draws everything back and says, "look, this is the core concept of lean, what it really is, so that you can then build on top of that and start moving forward." And you can apply it to whatever industry you happen to be in. And I think for me, this was the one that made the most sense because it scales back to the core principles. And then I can apply that to software, which I understand, rather than trying to take something about building cars that I don't quite understand because I've never worked in that industry, and then try to cargo cult that over into software.

[00:33:46] Dave Adsit: Right. And that is an excellent primer to get you ready to read Principles of Product Development Flow, which is, once again, diving into product development and saying, "hey, let's apply the concepts of lean to product development so that we can maximize our flow efficiency of our system. Let's maximize delivery of value." And I don't know how to recommend Principles of Product Development Flow enough. I've probably bought a hundred copies of it for different trainings that I've done. And I've been in communication with the author on a couple of occasions. Equations, and I've run training for every member of my team at the last couple of companies that I've worked at, because I think that the concepts are so critical for us to understand if we want to actually deliver value in an organization.

[00:34:46] Allan Stewart: What you're going to need to do, Dave, is figure out the U-shape optimization curve for recommending this book.

[00:34:53] Dave Adsit: book. I do need to figure that out. Luckily, once I get into the bottom, I won't have to worry too much about going too far because I won't come out the other side very quickly. So that's the collection of books that we had for the concept of building a product or building whatever it is that you building a product to service, whatever it is that you do, whatever it is you sell, right? Whatever you're using all of your skills to create. So we talk a lot about this concept of of the "career trident." You go along building software for a long time, and then at a certain point, you have to make a choice. "Do I want to continue to go deep into coding and become kind of the distinguished engineer path? Do I want to go towards the architecture track where I'm working more on the system level? Or do I want to go in the management direction?" And you've got kind of that choice that you make after quite a long while of being on the same path. There's a branch that that you can take. And of course you can jump back and forth between them at different points, but you need to be ready to do so if you choose to. And then, so one of the sections that we have is specifically about leading. This group of books is about leading people, teams, groups. And I've got two that I recommend together. One is Management 3.0 and the other is Managing for for Happiness by Jurgen Appelo. Management 3.0 is definitely more focused on managing software development teams. And Managing for Happiness is more general purpose, managing people who you want to succeed, right? If we go back to the concepts from Drive, it's people, you assume people are motivated unless you've taken away their motivation, and you give them autonomy, mastery, and purpose, great. Okay. Now we want to give people happiness in their work. How do we do that? So Managing for Happiness and Management 3.0 are all about how to do that well with teams of software developers. Yeah.

[00:36:58] Allan Stewart: I haven't had as much experience in the management side of things because I've tried to stay more technical, tried to stay more on that architecture path, but I have found these books to be really great. And I appreciate when that human centric approach is brought into an organization at the management layer, because I've always had managers.

[00:37:21] Dave Adsit: True. This is very true. Right. So I've got a couple of other books in the leadership track that I'd like to recommend. One of them is Strengths Based Leadership, which is the basic concept here is that everyone has strengths, and they're different. And you shouldn't try to do the same thing. You shouldn't try to cargo cult whatever the most relevant manager of the day is. We shouldn't try to cargo cult Elon Musk or Jeff Bezos or Steve Jobs. And in fact, we'll find that they have very different management styles and very different strengths that they apply when managing people. And so this book helps you understand what are your strengths and how do you maximize those as well as how do you leverage and maximize the strengths of the people on your team? And how do you avoid falling into the mediocrity that comes from just trying to overcome your weaknesses all the time? And the last one in the leadership group is An Elegant Puzzle, Systems of Engineering Management by Will Larson. And this is a very practical hands-on guide. If you're getting started in engineering management and you need somebody to give you some instruction, I recommend this book. Pick it up, read it, follow it, develop your own opinions by doing the things in it and maybe finding areas where you're going to break away from these rules. You know, we talk a lot about developing over time and the concepts of, like, we've talked before about Shu-Ha-Ri. There's, there's follow the rule, uh, break the rule, and then become the rule. And if you're at the Shu level in in leadership for software engineers, pick up a copy of An Elegant Puzzle, read through that. It will be invaluable to you at that point in your career. And even if you're beyond that point, it will be helpful for you to understand what one other person and what another accomplished leader thinks about different leadership scenarios.

[00:39:19] Allan Stewart: Then our last section of books that we want to to recommend are all about software architecture, exploring that third prong of the trident, the "career trident."

[00:39:30] Dave Adsit: Yeah. The one where you live in.

[00:39:32] Allan Stewart: Yep. By choice. By choice. Yes. And the first one that I want to plug here is yet another Uncle Bob book. This one's Clean Architecture. And this one takes a lot of concepts that have been written about over the years and kind of distilled them in a way that really worked for me. It took some ideas like, well, there's SOLID principles of programming, for example. Well, how do those actually apply to code? And then what does that do to your system architecture when you do apply them? Where are important boundaries in a system, and why? And what does that do to your system? So I really like Clean Architecture as a general purpose overview of how software systems can be coded up and how, how it works, how you deploy them. And it, it has worked for me for all different kinds of projects, web projects, and ones that you install on premise, and ones that you can, uh, run on mobile app, all those kinds of things, that there are really good principles that that apply in all of those situations.

[00:40:47] Dave Adsit: So the next two books are Domain-Driven Design by Eric Evans and Domain-Driven Design Distilled by Vaughn Vernon. And these two books teach very similarly. They teach you a way of thinking about software development and how to design systems that can be built and maintained over time. They bring concepts like the ubiquitous language. Which, and various different domain concepts of solution domains and problem domains. And a lot of concepts that really help you build systems that are reliable and maintainable. And I've read both. I recommend both. Domain-Driven Design Distilled is substantially easier to get through than the "big blue Bible." But I think that there's a lot of value in both, particularly if you want to move into the software architecture space.

[00:41:49] Allan Stewart: Agreed. The next one on the list is The Software Architect Elevator by Gregor Hohpe. And where the other ones that we mentioned are about how you design things in the code and how you draw up boundaries and how you create bounded contexts and whatnot. Not. This one is more catered around, okay, so you are an architect. What do you, as an architect, the person, do? And so I really enjoy that. And I really like the metaphor that he uses in the title of the book, that architects are the people who go in this metaphorical elevator up to the business level, down to the engineering level, and the various stops in between.

[00:42:35] Dave Adsit: Yeah, I think this one's an excellent reminder that architecture happens at a variety of different levels. Sometimes architecture is how this method is defined and written. And sometimes architecture is how all of these systems talk to each other in this product suite.

[00:42:51] Allan Stewart: And it does a great job of helping you understand how do you tie these back to business objectives or financial goals, things that people care about that are outside of the strictly technical coding space.

[00:43:05] Dave Adsit: So the last five books in our list are all about distributed systems. And I've put them in order from most generic to most specific. And I thought that would be an interesting way to talk about them. The first one is SOA in Practice, The Art of Distributed System Design by Nicolai Josuttis. I don't know. I've read this book many years ago when everything was SOA and service-oriented architecture was all the rage. And this book was a very practical guide to some of the more esoteric things that were being taught at the time. And he talks about a lot of the design trade-offs and considerations that you need to make in a service-oriented architecture system. The next book on the list I added as well, which is Patterns of Enterprise Application Architecture, which basically says, "hey, we're doing SOA. We've got all these service-oriented architectures. We noticed there's some common patterns, and some of them work and some of them suck. Let's talk about how to make the, how to pick the ones that work and use them in your system." And this one's a Martin Fowler book. So, you know, it's going to be a high quality, high quality writing. It's going to give you a lot of good examples and a lot of good patterns that you can follow to make better and better service oriented architectures or systems, distributed systems of whatever type.

[00:44:39] Allan Stewart: And then the next two come from Sam Newman. And I think just reflecting on my own experience, there was this idea of service-oriented architectures, and then it evolved, and there were enterprise application architectures and pub-sub messagings and these kinds of things. And then microservices kind of emerged as almost a natural consequence. It's like, "hey, we've learned some things, and here is a way, here is a particular architecture that builds on that." And although I don't recommend everybody just rush out and build their systems as microservices, because I think there's a lot of value in monoliths, Building Microservices, the book by Sam Newman, has some really great concepts in there that can help with a lot of different teams, even if you are in more of a shared monolithic space. And you can start to identify places like, should these two teams be sharing a database and what does that do to your ability to make changes? So yeah, Building Microservices really gets into the heart of what microservices are supposed to be and avoid the hype or the misunderstandings. For example, making your microservices far too micro and not big enough.

[00:46:02] Dave Adsit: Right. I really like Building Microservices as an exploration of a set of constraints on a service-oriented architecture and the trade-offs you get with those constraints. I think if there's one thing that you should learn about software architecture in general, is that it's always trade-offs and there's always constraints. And you need to understand where you are coupling and how to maximize cohesion and minimize coupling across your system and what the trade-offs are that you get from that. So the next one, Monolith to Microservices, say, "hey, you started with a monolith. Congratulations. You built something successful, presumably, and people are using it. And now it needs to scale. Here's some techniques and tools, right?" It could have easily been called Refactoring to Microservices. And then it would tie back to the concepts from from refactoring code, et cetera.

[00:47:01] Allan Stewart: I think that book in particular, Monolith to Microservices, has a lot of great ideas around how to change code at scale. How can you transform code from running in one particular way into another way? So in this case, going from the monolith to the microservices and scaling out independently independently, and how does that affect your team compositions, et cetera. But underlying there, there's a lot of information about things like branch by abstraction, which gives you the power to reverse all those decisions. And so if you don't want to be in a microservices environment anymore, or you want to make a change to some other pattern that is yet to be discovered, the ideas in this book can help you to get to there. Right.

[00:47:55] Dave Adsit: I could probably talk about this one for an entire podcast episode, but let's move on and let's talk about the last book on our list. Quite likely the hardest one. Maybe, maybe not. Principles of Product Development Flow might have that title as well. It's a dogfight between the two of them, but Designing Data-Intensive Applications by Martin Kleppmann.

[00:48:16] Allan Stewart: Yeah, this book basically takes you on a journey. It's like, "hey, what if we would like to persist some data?" Data and it goes all easy, "let's persist some data. Let's just save some data. We've got these disks and we can write data onto a disk." And it takes you all the way from, "well, let's write it in a file." "Oh crap. Well, here's the problem too. Let's build out a database." "Okay, great. Now we've got a database." "Oh, now here's some new problems. And how are we going to replicate this? And how are we going to shard it? How are we going to, you know, make it work across multiple things?" I think, and at every point in this book, it gives you like a deep dive into how these things work, like the fundamentals of how database indexes work, which is really fascinating to look at. Cause I know a lot of software developers like myself have used these things a lot, but I've never written one. And so getting additional information about that has been great. And then, like I said, at every step along the way, it's almost like you're just waiting for the next shoe to drop because it always comes to, "okay, but now here's the next problem." And in order to solve this problem, it's going to get exponentially harder.

[00:49:31] Dave Adsit: Right. Yeah. I really enjoyed going through this book with our architecture group years ago. It was eye-opening how complex data systems can be, especially once you start introducing multiple computers. And basically everything we've talked about for the last 10 minutes is, "what if we had to run our system on multiple computers?" I'm like, "well, how do we, how do we keep the data in sync and how do we keep it from drifting and how do we access it quickly and reliably, et cetera, et cetera, et cetera, et cetera." And so, yeah, that book, highly recommend that book for everyone who wants to go into software architecture. So that's a lot of books. Books. I've learned a lot by reading the books on this list. I've learned a lot by discussing these books with other interested professionals at different points in my career.

[00:50:23] Allan Stewart: Yeah. I would say, regardless of your personal preferences around how you learn, if you pick out even just a couple of these books that you haven't read and just skim through them, you're going to learn a lot from that. But if at all possible, have those discussions, find somebody who has read it and ask them about it or get a book club together. Because, like you said, talking with other professionals that have also experienced these things can shed a lot of light on it. And some of these books are quite complicated, or they can be very dense as well. And so to really pull out the value from that, it can be really helpful to have other people's perspectives on that same chapter or that same section that you're reading.