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, et cetera, 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 don't. 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:47] Allan Stewart: So we're going to start with a few books that are kind of broad thinking about your career. And software.

[00:01:55] Dave Adsit: So the first one up for me has to be apprenticeship patterns. Apprenticeship patterns is basically a couple, a couple of guys, Hoover and Oshie 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 it, for me, that was. It 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. 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, 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 some. I think it 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 how do you do this? Well, for example, do you do testing? How do you, how do you know that your code works? When you're going to deliver it to. To your company, right? Whether, 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:36] 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, the, the concept of craftsmanship I think is critical and I really like how they approach it in these two books. Yeah. So the, 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. And so for this one, it really helps set the stage for what is the, what is the career path that you are on and what are we doing and what is possible in it? I think it's 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 lean more heavily on like old like guild concepts, for example. And how do you become a trades person in the medieval ages, which may or may not translate very well into the, into the current 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 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? 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. Sure. But I. I've also, you know, spent a little bit of time working with people at other companies and it was very eyeopening for me. So, 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 a software, a software developer, a software craftsman, a software engineer. Right. One of the critical components of that is writing code. We, what we do, the work, 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 book series. This was the first one. This one's all about the Robert Martin style of writing. And so he's 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, 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, I don't agree with everything that he has in that book. But I really like that. It covers a. A lot of ground. Making you think and say, oh.

[00:09:23] Dave Adsit: Yeah.

[00:09:24] Allan Stewart: Well, if I disagree with this, why do I disagree with it? What, what do I want to do? And sometimes, sometimes there are things that trumpet, uh, for example, um, I know in the C sharp world, we've never let go of the idiomatic, uh, letter I prefix on our interfaces just because it's so ubiquitous to how C sharp 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. Same. I think the one thing that stands out is. The interface naming. I do not like. Naming my concrete class. Foo. Emple. 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. Um, 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 into. The. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation.

[00:11:21] Allan Stewart: 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 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 how well they agree with Uncle Bob and his ideas, but I think, again, it's well worth reading and looking at it because he's not putting up a facade of, hey, this is how great things are. He does leave it pretty raw and say, 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, headfirst 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 does. It teaches you how to use them and how to 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 headfirst 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 product.

[00:13:09] Allan Stewart: 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 code and say, this is why I think it should change. So prior to it, prior, 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 judgements against it, rather than being able to say anything more concrete or, uh, objective about it.

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

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

[00:14:06] Dave Adsit: Oh, yeah, of course you have to rewrite it. That's the only answer. Okay. Okay. And the only bad code is re rewrite it, start over from scratch. No. And then refactoring teaches you the alternative. And I, I mean, I really like refactoring as well. Uh, 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:02] Dave Adsit: Right. And then one of the books that's on the list is refactoring to patterns specifically by Joshua Triovsky. Is, 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 it, 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 something.

[00:15:42] Allan Stewart: And you get the, the pattern inception where you, 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. 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, what are you talking about? You leveraging those to do things and that's fine. Maybe you will ever come across that, that need. But it's fine. 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.

[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 different styles of testing that might not be how you want to do your testing in the longterm. But they can get. You 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, that allows you to do something and get started.

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

[00:17:38] Allan Stewart: Our next question. The 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. and add in some measurement to see, hey, are you actually hitting your target? Are you just firing wildly out there? And just lots of ideas and patterns in there. Some of them, again, 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, yeah, 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 Price. 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. Steve and Nat have an approach to testing, sometimes called double loop testing, acceptance test driven development, whatever, that is 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 go in, go in and in a group so that you can get through that, the content of that book.

[00:20:18] Allan Stewart: Yeah. And I would also say that even 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. For sure.

[00:20:39] Dave Adsit: I would say that the objects in that book are, 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. Yeah. On teams or work with other humans in any capacity. Yeah.

[00:21:05] Allan Stewart: And the first few books that we'll mention here are all written by Patrick Lincione. He works at the table group and they put out lots of different 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, 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 the concepts here. Here is how you might apply them. So I like them. They're pretty quick reads. Um, the ones that I want to call out, uh, the five dysfunctions of the team death by meeting the ideal team player. They're all in that parable style. Uh, he also has one called the advantage. Uh, 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, uh, is also a good book.

[00:22:12] Dave Adsit: Yeah, I agree. I recommend all of his stuff, uh, including his podcasts of which there are multiple ongoing at any given time. Yeah. Um, so definitely would put five dysfunctions of a team high on my list, regardless of what type of team you're dealing with. So I, I, I. would. would. would. would. would. would. would. would. would. would. would. would. would. would. would. would. would. would. would. 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. Yeah. I think

[00:23:12] Allan Stewart: 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. They're 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 seventies and continues to be repeated to this very day. So I think that it's the one that of the, 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, once you establish that mapping, a lot of the principles hold true.

[00:24:48] Dave Adsit: Okay. So one of the other books on our list is Crucial Conversations, which is very, much. About. Exactly. That. How to. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. 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, that's one that you can recommend to people, whether they do software or not. It's, it's about every type of, of human endeavor. So, and then the last one that we have in this section, which may be the only book on the list that, 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 Edward 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, 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, 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, to your organization. Jumping back real quick. One, one other comment with Crucial Conversations, just to plug that one. Yeah. 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, 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, 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, you know, the things that we have been talking about. building a product or making whatever it is that you make as a software developer. 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 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 the users do things in a way that you did not anticipate, it was not their fault. Correct. So the next book, Accelerate, by Nicole, Forsgren, Jez Hemble, and Jean 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 DoraMetrics, which is the DevOps Research Association. Is that what it is? Anyway. I don't remember. So 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 to 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 there's some really interesting ideas in there that I think you can, 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: Okay. 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 Coburn. I often refer to this as the Purple Tiger book because it would work. Yeah. Thanks. Thanks. Thanks. Thanks. sociotechnical systems must change as they scale, this is a book for you.

[00:32:22] 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. 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 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.

[00:33:45] 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, 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. And I've, I've run training for every member of my, 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 the product that we're trying to deliver. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. Conversation. 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 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 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 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 One is Management 3.0, and the other is Managing for Happiness by Juergen Apollo. 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. If we go back to the concepts from Drive, 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

[00:36:55] Allan Stewart: of software developers. Yeah. 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, human-centric approach is brought into an organization at the management layer,

[00:37:18] Dave Adsit: because I've always had managers. 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 Strength-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? 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 the things that You would take it. You would take it. You would take it. You would take it. You would take it. You would take it. helpful for you to understand what one other person and what another accomplished leader

[00:39:16] Allan Stewart: thinks about different leadership scenarios. Then our last section of books that we want to recommend are all about software architecture, exploring that third prong of the trident, the career trident. Yeah. The one where you live in. 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 it works, how you deploy them. And it has worked for me for all different kinds of projects, web projects and ones that you install on-prem, and ones that you can run on mobile app, all those kinds of things. There are really good

[00:40:44] Dave Adsit: principles that apply in all of those situations. So the next two books are Domain-Driven Design by Eric Evans and Domain-Driven Design Distilled by Von 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 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. The first one. The second. The third. The fourth. The sixth. The seventh. The. The.

[00:41:50] Allan Stewart: The. The. The. The. The. The. The. The. 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. 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,

[00:42:32] Dave Adsit: and the various stops in between. 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

[00:42:50] Allan Stewart: in this product suite. And it does a great job of How do you tie these back to business objectives or financial goals, things that people care about

[00:43:01] Dave Adsit: that are outside of the strictly technical coding space? So the next or the last five books in our list are all about distributed systems. And they go, 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 and Practice, the Art of Distributed System Design by Nikolai Josutis. I don't know. I've read this book many years ago when everything was SOA and, you know, 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 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 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:40] 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 messaging, 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 are some techniques and tools, right? It's refactor. It could have easily been called, refactoring to microservices. And then it would tie back to the concepts from refactoring code, et cetera.

[00:47:02] Allan Stewart: Well, 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, 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 that.

[00:47:54] Dave Adsit: Right. 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 dog fight 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? Yeah. It goes all the- Sounds easy. Let's persist some data. Yeah. Let's just save some data. We've got these disks and we can write data onto a disk. It takes you all the way from, well, let's write it in a file. Oh crap. Well, here's the problem, to let's build out a database. Okay, great. Now we've got a database. Oh, now here's some new problems. How are we going to replicate this? How are we going to shard it? How are we going to make it work across multiple things? At every point in this book, it gives you a deep dive, into how these things work, the fundamentals of how database indexes work, which is really fascinating to look at. Because 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

[00:49:30] Dave Adsit: harder. 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, 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. I've learned a lot by reading the, the, 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:22] 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, 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, that same chapter or that same section that you're reading.