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 what makes a book enjoyable for me to read, ignoring author intent.

[00:00:33] Dave Adsit: I'm Dave Adsit, a VP of engineering, and recently I've been thinking about effective workspaces. Specifically, how can I set up three external monitors and two laptops on my desk all at once and actually make it usable?

[00:00:49] Allan Stewart: The topic for this episode is impact on our careers. So in a previous episode, we discussed how, as a developer, you can do more to make an impact at your company. And this time we're turning it around and talking about things that have made a significant difference on our careers and could be useful for other people as well.

[00:01:13] Dave Adsit: Right. And we're going to start off by talking about different work experiences. One of the things that happens is you have a lot of work experiences. I know that I've worked at at least 15 companies in the last 25 years. And each of the companies that you work at is going to have some kind of an impact. Some of them substantially more impactful than others. So, Allan, why don't you tell us about one of those work experiences that impacted you?

[00:01:37] Allan Stewart: Yeah. Early on in my career, I had the fortune and I'm going to, I'm going to phrase it this way. I had the fortune of working at a company that went bankrupt. And I say that that was good fortune in my case, because it was very early in my career. I was not yet married. I did not have much in the workforce. And so it wasn't a it wasn't a big problem for me. You know, I was financially secure as much as a young single adult needs to be. And so it was a good opportunity for me to learn about what does it look like when a company is not doing well? What kinds of things do I need to understand or know about a company that I had just never it never crossed my mind before? I was a programmer. That was what was important to me. And there were a bunch of other things about how you interact with people, how you understand the health of the business that had never occurred to me. And then I saw I saw the problems like the writing on the wall. And I was just conscious enough to be able to say, Hey, I think there's writing on this wall. And so. So I kind of escaped a few months before they went bankrupt. corrupt. And it turned out to be really good for me in the long term of my career.

[00:03:04] Dave Adsit: Yeah, some of those lessons are hard, but they are important to learn. And if you get to learn them in a time and place when it's not going to have a drastic negative impact on your life,

[00:03:13] Allan Stewart: that's fantastic. Yeah, absolutely. If you learn about what it's like to get laid off suddenly, unexpectedly, and you do have a bunch of obligations and you're not in a good financial position, then it can be very nerve wracking. To say the least, right? Well, I also want to

[00:03:33] Dave Adsit: talk about one of my early experiences, but it's kind of from the opposite perspective. This was one that was a really good experience for me as well, but I got to learn a lot through some unexpected inputs to my personal system, right? So I was working at a company that wasn't in the software business at all. We did... Physical goods distribution. That was our primary business. And I was brought in to help build a software project. And this was... I had been working on teams for several years, different companies, whatever. And I came into this one and I thought that it was going to be a similar situation where I was getting a job, I was working with a team, I had a manager who was a programmer, and it was going to be great. I was going to just be another developer on the team, and it was going to continue my learning journey. And I got there, and we... We all learned pretty quickly that I was the only truly serious professional programmer, and everybody else was just kind of dabbling and not really that interested in it. They were doing it out of obligation and necessity versus interest. And so after a month or so, the other programmers on the project stopped, and I was left to build this system all on my own. And it was using technology I was unfamiliar with. I was somewhat familiar with, right? It was using... I had to stretch in a few ways. I got to do some interesting things. But it was a really good learning opportunity because I learned that I actually could build what I look at now as a fairly small system, but a system nonetheless, on my own. I could work through the challenges and figure things out, and I could figure out how to deploy it, and I could... figure out how to support customers and I could do all the things we needed to do with this small software system. And it ended up being a pretty big success in the end due to the work of a lot of other people who were part of the program. You know, we had people selling it and people supporting it in the field eventually and all that kind of stuff. But it was, it all started off as kind of my, my creation and most of the code, almost all of the code that was in there was mine. And it was, it was one of those things where I felt like I was thrown into the deep end and I was, I, I had to sink or swim. And I remember pulling some, pulling some late nights and some long hours learning how to swim. And it was a really good opportunity for me.

[00:06:09] Allan Stewart: Yeah. It makes me think about a lot of the things we talk about now as being important from the perspective of say DevOps are the same kinds of things that you were kind of talking about. Thrown into you, you had to, because there was no ops.

[00:06:25] Dave Adsit: There was no one. Yeah. It was yeah. In fact, the, my manager who was a pro who had done some of the initial prototyping on the product, he once he saw that it was in good hands, he just kind of walked away from the project and focused on other areas of the company and other things that needed his attention more. So.

[00:06:44] Allan Stewart: Yeah. I remember there was a company that I worked at that had a, where I had a similar experience afterwards. I was working with them for a little while. I, I just kept doing a really good job and they took more and more programmers away from that project to put on a different project. And they just kind of, so I didn't start it all by myself, but I ended up taking it over myself. And it was a good experience. It was also a very, it was the first company that I worked at that was really big, like international company, thousands of employees. And so. Yeah. That was, that was a pretty big impact on my career. Not because it was maybe the, it's definitely not my favorite company that I've ever worked for, but there were a lot of really good learnings that I had there. There was a lot of opportunity for travel and conferences and trainings that I had not had any experience in previously. So that was a, that was a good impact on my career as far as seeing a broader horizon of what, you know, what I was doing. Yeah. What things could be when you're not just in a really small scrappy company trying to get by?

[00:07:57] Dave Adsit: Yeah. I would say that I had a different experience at the first really big company I worked for. I learned that the bureaucracy does not want you to do anything, period. Anything you do might introduce risk. And so the bureaucracy doesn't want you to do it. And so I learned about filling out documents. I spent more time filling out documents, and I did writing code. And that was on purpose. And, you know, when you're in a small company, you're like, well, why would you waste your time? You got to get stuff done, get stuff done, ship features, ship features, ship features, build value. But in a big company, I learned that risk is something to be avoided at all costs. And so you do everything you can to mitigate and avoid risk, which includes, unfortunately, not letting your programmers do much actual programming. But I did get to learn how to operate within a bureaucracy. And, you know, I was able to get things done despite the best efforts of those around you. So that was interesting. But I did actually leave that job fairly quickly when an opportunity arose. So I wouldn't say that it was my favorite either. Yeah. The cab meetings. Oh, my gosh. Nightmares. You're going to cause flashbacks. I will say one last thing, and then I want to move on from the big company because I don't want to have the nightmares. We found that our cab, which had 11 members and a 10-person quorum. So they would have meetings, but if they didn't have 10 people there, no decisions could be approved. No changes could be approved by the board that day, but they would still hold the meeting even if only eight or nine people showed up. Oh, wow. Good thing it's not very hard to schedule 11 people. 11 extremely senior people in a gigantic company. Yeah, it's super easy. But we did come up with a solution. I mean, I wasn't part of the solution committee. I'm sure the solution committee made more for this solution than I will make. You did a committee to make a solution? Oh, well, let me tell you what the solution was. See, what we found was too many changes were sent to the change approval board for approval. And that was really a lot of work for them. And so we created a pre-cab, which was the pre-change approval board that would pre-approve things so approval board didn't have to spend so much time approving them. And so then anything that wasn't prepared to go before the board was rejected at the pre-board.

[00:10:28] Allan Stewart: What you're saying is, yo, dog, I heard you liked cab meetings. So I put a cab meeting in your cab meeting?

[00:10:35] Dave Adsit: Basically, yeah. I mean, I don't know how they ever got out of that nightmare. I left before they had announced it and had a couple of meetings when I was like, you know what, I'm going to take this other job that seems less crazy. Anyway, let me tell you about a story that was actually really positively impactful for me. I went to a job that I felt way in over my head, way out of my depth. This seemed like these were serious programmers and they really knew what they were doing. And I wasn't sure that I was ready, but I wanted to try. And so I did an interview. I was offered the job. I was surprised to be offered the job. I was thrilled to be offered the job. I took the was a company that we were doing all the new things. The company had just gone through a ThoughtWorks transformation. They brought in a bunch of ThoughtWorks consultants and trainers, and they set up all kinds of things like CICD. We had continuous integration. It was back in the days when you set up continuous integration with the leftover computers that you scavenged from the help desk. And we had like a physical light on top of one of them that told the status of the builds. We did pair programming, which I had heard of, but didn't even know what that was. We did test-driven development. We were doing inversion of control, which I understood in theory, but didn't understand in practice and had never used. We were doing all of these things that were pretty cool. I was pretty excited about it. And it was actually, it was actually a job that was pretty transformational for me in terms of like, what is possible as a software engineer? What can we do? I would say we were one of the companies that we were doing C-sharp. This was early on. I would say we were one of the companies that was kind of part of the movement of alt.net, where you were like doing .net stuff, but you're doing it with all of the learnings that people got out of the Java community. And I want to say the Ruby community, but I don't know if there was a Ruby community. I don't know if there was a Ruby community. I don't know if there was a Ruby community really at that point. I think that came later. Sometimes I get my timelines messed up, but we were, you know, we're doing all of the things that really allow you to go quickly. Like we did one week sprints, you know, Monday, we would say, Hey, this is what we're going to do this week. And Thursday afternoon, we would ship it to production and give it to our customers. And it was amazing. And that was a real, that job, that job is where I became test infected, where I learned that all code can be unit tested, if you want it hard enough, and you're willing to do some refactoring, which has taken me through the rest of my career. Like since then, I've, I have been a big champion for unit testing, all the code everywhere so that we can know that what we're doing is actually working.

[00:13:38] Allan Stewart: On a similar vein, I think the job experience that was probably most transformative for me is when I joined a company and met, you for the first time, as well as a whole bunch of other just amazing people. It was a great group of people that we were working with. And for me, it was it was especially nice, because I had struggled a lot in a previous job. As I had been learning, there was things I had been learning about, to write better code to do testing, to do DevOps to, you know, lots of these things, I had encountered them. But they were not happening at the company I was at. And it was very difficult to get people engaged in that kind of a transformation. And so then, you know, coming to that company, I was suddenly stepping into that transformation. And I had learned about some of those things. But in, but suddenly, I was steeped in it. And I was learning from a lot of other people's experiences and learning from what we had going on at the time. So it was really a great experience. To be part of.

[00:14:51] Dave Adsit: Well, and we had at that company, we had, we had basically created a culture where we were doing all of those practices, right. And where we were, those practices were what enabled us to deliver consistently and quickly and high quality. And, and those were the those practices were core to the engineering culture. And so we all wanted to learn from each other. And yeah, definitely, it's a lot easier to go deep, we kind of created our own echo chamber. And that is a way that you can bring your knowledge, bring new depth to your knowledge, and to your practice in a way that you're not going to get if you are swimming against the stream of whatever the culture is of your company that doesn't care about testing or CI. I mean, I've worked, let me say, I worked at another company that taught me a very important lesson. And they taught it to me by what as what not to do, right. So I went into the code, base, and I was told, Oh, man, you're gonna hate this code base. It's super weird. And I go in there. And I'm like, looking at it, I'm like, Hey, I've told this story before, right? This is the code base where they had followed all of the practices that I would have introduced. And I'm like, I bet it looks like they structured this code so that there could be unit tests. And I'm like, Oh, I wonder if there's unit tests. It turns out there were unit tests, they had been excluded from the project for so long, that they no longer compiled. And it would have taken me forever to resurrect them. But this was the company that also taught me, a more important lesson, which is that it, it does matter what you're building. I know a lot of people that that's pretty obvious for them. For me, I often for a long time, up until that point in my career, I thought, you know, as long as I can do good engineering and do it in a good way, it doesn't really matter to me what we're building. And that company was building a product that I did not believe in. And in fact, I don't know, I would say it's pretty close to an evil product, all things considered, they, they built software to do MLMs. I won't tell you the name of the company, but they built software to run multi level marketing, aka pyramid schemes. And I just, I, so many times people said things that just were so slimy and scummy, and just made you feel yucky about the code you were shipping, that I, I learned a very valuable lesson that you, you have to be aligned with the product you're building, or at least not anti aligned. example of how we can do that. And I think that's a really good example of how we can do that. And then we have to stop having most of our customers. So I'm certain that that company never adopted it, I did not stay around long enough to find out. I think it's, I think it's interesting, as we

[00:17:39] Allan Stewart: discussed this, and people I've talked to in the past, when you consider the impact to your career, nobody wants the bad experiences, right? But those bad experiences, make a huge difference, right? Like they're, they're very valuable to have for what you learn from it. And so it is, you kind of have to have some of the good and some of the bad. You know, when we were working together at that really great company that we were enjoying, I would be surprised sometimes, because I had struggled so much at these other companies. I'm like, I want to be better, I want to do better. I want to get other people around me that want to do these same And then we would hire some junior developers, and teach them in in the ways that we thought were best. And you know, trying to be more, I won't say bleeding edge, but ahead of the curve, for sure, in the industry. And then sometimes those junior developers would look at what is in the average going on in the industry, and you know, books that are being written, targeted at companies that are in the laggard space, and start asking, Well, why don't we do this thing? And I'd look at that, and like, that's a step backwards from where we are. But it's hard to see that if you haven't had those other experiences that give you a sense of perspective, and you know, the context that that lets you know, you know, actually, you are in the green, the field that is greener. Yeah, you just haven't explored very many fields before. Yeah, I, I wondered about

[00:19:15] Dave Adsit: that many, many times when we were working there is like, are we? Are we actually doing a disservice? To these people we bring in and only teach them the what we consider the right way to do these things? You know, like everybody has their own way of doing software. And I think, you know, this is the way that we were doing it at that company, I felt like was the way that we thought everyone should be doing it. And if, if you didn't have other experiences to compare to, it's really hard to, it's really hard to know whether this is better or not. And, and so I mean, I'm going to repeat that. I'm going to repeat the same advice I've given in the past. When you are on a, at your junior to intermediate level in your career, you should be on a journey. There's a reason why there was apprentice journeyman master, right? As an apprentice, you learn some stuff. And then you go out on a journey and you learn from a bunch of different people in a bunch of different places. And some of the learnings are going to be, I know what I do like, and I also know what I don't like. And that'll help you both find and create the environments that you want to work in and you want to bring other people into with

[00:20:26] Allan Stewart: you later in your career. Yeah, I totally agree. And in fact, one of the, the last one that I wanted to mention, as far as my working experiences was an application of exactly that. After I had worked at several places, some better, some worse, and I had finally learned enough about what was a good fit for me. I ended up at a company. That just was not a good fit there. It was a good company. Like in, in many ways, it was a really great company to be at. It just wasn't the right fit for me. The timing, I don't think was quite right. As far as some of the technology and especially, you know, internal politic transformations that were going on, just made it so that I was not able to contribute how I wanted to contribute for that company. And having that understanding, allowed me to see like, Hey, I'm just not going to be happy here. So I start looking for a new job. And I was able to move to something that fit me better because I had had that experience of, you know, seeing both sides of the coin. Yeah. I like that a lot.

[00:21:38] Dave Adsit: So the last job experience that I want to share is when I transitioned from one role to another, I had been working in architecture for probably close to a year. Close to 10 years by then, you know, I'd been in my career for quite a while and I wanted to, you know, I was at that point where I was like, you know what? I want to be the boss now. I know what, I know what my boss is doing wrong. I'm going to go be the boss and I'm going to do it right. So I took a job at a much smaller company as the CTO. And that was a phenomenal and humbling learning experience, right? Luckily it was a small company for my first, first true leadership role. I mean, architecture is a leadership role, but as the architect, you can stand up and be dogmatic in meetings and you can be, I was certainly reactive and aggressive in many situations where my boss, who was the, the CTO at the, at that time, he would have to be a lot more level-headed in politic and whatever, you know, he'd have to keep things even in the room and keep things moving. Even if his architect was basically lighting things on fire. And then I went into the CTO role and I got to learn very directly the responsibility that you hold in leadership to the team as a whole, including all of your engineers and your product people and every other role in the company, right? You have a responsibility in that leadership role to be a lot more level-headed than I was when I was head of architecture. And you have a responsibility to maintain and develop the morale and the skillset of the organization of your engineering organization in a way that I had previously been disregarding. You know, some of the things that I thought of as weak leadership were actually an attempt to maintain and manage morale and the team. And you have to worry about different things when you're in that, in that leader role, that CTO or VP of engineering, you have to worry about different really valuable for me. And I got to in through that role, I got to help rescue the code base and the team and get things moving in the right direction. So I was able to validate some of my prior, my, you know, validate some of my assumptions and priors about how software should be done. And I was also able to bring in some really good engineers and truly transition from that player coach role to the true leadership role where I was hands off on the code and letting my team actually do the work. And I will say, talking to a lot of other CTOs and VPs of engineering that actually delegating and letting people make those decisions and have responsibility in their space is one of the harder things to do. When you've been used, when you're used to being hands on and doing the work yourself and doing like, you know, I did a lot of ops at that work at that company. And I did a lot of coding at that company until I had enough people in place that I finally, stopped doing both of those roles and focused on leadership and developing the organization. And that was a really, really impactful transition for me. And one that I am very glad that I had.

[00:25:03] Allan Stewart: Speaking of transitions, let's talk about some other different kinds of things that have made impact on our careers. Let's talk about books.

[00:25:11] Dave Adsit: Oh, yes. Books. Okay. So I would say that early in my career, I didn't do a lot of reading. Certainly not books. I would rely on just, you know, searching the internet for things that I needed when I needed them, you know, is a lot more on demand versus proactive and developmental. And so at some point I took a job that there was a learning stipend and there was an expectation that every senior engineer would read two books a year and they would pay for them and buy them for you. You just had to put in the time. And I, I'm like, okay, great. I'm going to take advantage of this. Okay. So I started reading and got into some books like Clean Code, which was super impactful at that point in my life. I was already test infected, if you will. I already wrote unit tests. I already thought that was an important thing. I wanted to learn more. I wanted to develop my team. And so I, I went into and read Clean Code, bought copies for my team. We read it together. We really tried to put those things into practice. We had debates over which things made sense in which, in our so that I prefix for interfaces was you could pry it from our cold dead hands. In fact, we always kept that I interface that I prefix for interfaces because it's the language convention. So anyway, Clean Code was super impactful for me at that point in my, in my career. I have a copy. My first copy of Clean Code is still here in my office. I did that thing that we did in college where I got the clear contact paper and wrapped it because it was a, it was a very, very good way to get the paper back. If you flip through my copy, the pages are worn. The pages are highlighted in many colors of colored pencil. And I have gone through that book probably a dozen times with different teams helping to level them up and skill them up.

[00:27:06] Allan Stewart: Clean Code is a great book. And it is also one of the early books for me. I'll mention it again a little bit later, but that book and around the same time, I read Martin Fowler's Refactoring book. And kind of between those two books, I started to see like, okay, there, I had started to build up a little bit of my own code sense of what I thought was good and what I thought was bad. And in reading those books, I changed some of my opinions about what, what was good and bad, but it also gave me language, kind of a rubric by which to judge code instead of the code. I always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always always

[00:28:14] Dave Adsit: Yeah. Refactoring also a very impactful book for me early on in my career, just learning the algorithms and the techniques for changing code without breaking it. A lot of early in my career, especially, and probably still to this day, a lot of the changes that I made to code would accidentally break things. And I didn't ever know why. And refactoring helped me to learn how to change code in its structure without changing its behavior. In other words, make it smell better without breaking anything. So along those same lines, when it comes to code, one of the books that I read around that time was Domain Driven Design. That book for me was, it's a tour de force, it really teaches you about the intention behind the object-oriented movement. Movement in software development. In fact, I heard Domain Driven Design described a few times as, oh, oh, the way we always meant it. People who had been doing oh, oh for a while are like, I don't know why you even had to write this book. That's obviously what we meant.

[00:29:22] Allan Stewart: You know, right? So it turns out that what you obviously meant is very rarely what people

[00:29:31] Dave Adsit: receive when they hear. Yeah. At least the first time. I've heard that communication actually... Actually occurs at the listener's ears rather than the speaker's mouth, and that may have been part of the problem. So Domain Driven Design, again, you said, what you said about language is applicable here too, right? Domain Driven Design gives you the language to talk about code. It introduces a lot of patterns. It introduces concepts around what is the solution domain of your software and what are you trying to do there and what parts of it are, what's core to the software? Yeah. And what's accidental or incidental? And what are good abstractions? Where should you bring code in versus where should you push code away? It basically takes the two fundamental concepts of software development, coupling and cohesion, and gives you a lot more language to talk about those things in a way that makes it easier to reason about as a people. And I think that it reinforces... Yeah. And communicate with each other effectively and quickly as they are building the system. Yeah. Yeah.

[00:31:14] Allan Stewart: I really agree with that. And in my case, I kind of came around to it backwards. So I eventually read Domain Driven Design, but it wasn't as impactful for me because I first went and lived Domain Driven Design. Right. And I was being taught it by example. Yeah. Yeah. Yeah. Yeah. And I was working with people that were teaching me the concepts so that by the time that I actually encountered the book and some of the books to help you get through the blue book. Yeah. Then I kind of... At that point, I was solidifying my understanding instead of learning it for the first time.

[00:31:55] Dave Adsit: Yeah. Yeah. Well, and that's interesting because that goes to one of the concepts of when you encounter something and where you are and how prepared you are is going to influence how impactful it is. Yeah. Yeah. One of the books that was really impactful for me early on, but probably wouldn't be now and probably wouldn't be for most developers who work on a product team with a UX designer and a product manager was Don't Make Me Think. Don't Make Me Think was a book all about the importance of good UX on your website and not letting your website become overwhelming. It was written in the era of... I want to say GeoCities. I think it was actually quite a bit after that. But that's how I remember the internet. from that era. You would go to a company's homepage and everything in the entire website was trying to get space on that homepage and fighting for attention and fighting for real estate. And people started doing more and more animations. The internet was a ridiculous place. It was. And we've learned a lot since then. Like now the concepts like negative space and white space are very important to the design of software. We actually have an entire role on many teams, the user experience designer who understands how people interact with software and understands the common design language of software and tests things with actual users regularly. We didn't have any of that back then. And so it was just kind of like a wild west, right? And we've joked about... User interface poisoning from user interfaces designed by engineers. Well, we all had it back then. And Don't Make Me Think was super helpful for me to shift my perspective from what's easiest for me as a developer or how do I get my thing used to what is the best experience for a user? How can I help the user accomplish their goal on our website, in our product, in our software? Users come to our software with a reason and a purpose. How do I help them accomplish it the best possible way, whether that's quickly or easily or whatever, right? And so Don't Make Me Think helped me change my focus from what's good for me as a programmer to what's good for you as a user. And I really think that that helped me improve my products that I've built drastically since.

[00:34:30] Allan Stewart: The book that helped me with that same concept is one that you recommended for me. The Design of Everyday Things.

[00:34:38] Dave Adsit: Yes.

[00:34:39] Allan Stewart: And it teaches similar concepts. And I remember learning about things like affordances and signifiers, which helped me to kind of better understand how do you interact with the system, but also helped me with an understanding of how if a system isn't working, it's a failure of the system or a program like code. If it's not working, it's not because your user was dumb and they're doing it wrong. It's because you didn't make the system good enough that the design becomes obvious. It's like, well, this is how it should function, right? It's like, I don't know. You grab a shovel and you understand how it's supposed to work because it's shaped like a shovel, you know, sort of a thing. And you warned me, you warned me before I started reading that book, that life would never be the same. I did. And I still can't see light switches in houses and hotels, especially. Hotels are particularly bad. The very same trip where I read that book for the first time, I was at a hotel where the light switches were sideways. And I was just like, I can't believe it. This is the book,

[00:35:56] Dave Adsit: writ large. Here it is. Yeah. I think about On the Design of Everyday Things every single day when I go in my garage, I have two garage doors and they're side by side as garage doors tend to be. And yet the controls for the garage doors are stacked on top of each other. I had to go in with a Sharpie and label them. This one goes to the left door. This one goes to the right door because instead of being side by side, like the doors themselves are, they're stacked on top of each other, giving you no indication as the user, which one you should push to open which door. And, um, You never moved them. I, I actually tried to move them at one point and realized that I was going to have to like rip big holes in the drywall to make that happen. And then I gave up. So, uh, yeah, it's, it's still a to-do list item for some point in the future, but yeah, it's when you learn about good design, you realize how uncommon it is and how valuable it is when it happens. I think, we were, I think we just gone through a, a, a training on this book for some of our product teams that hadn't gone through it before, right before we moved into our new office at one of the companies we worked at together. And, um, the new office very much had what is referred to as Norman doors, which is to say glass doors that have a push pull handle on both sides. And you don't know what, when you walk up to it, do I push this? Do I pull this? How do I open this door? And go through it. That is the Norman door is one of the common tropes that came out of that book that people who are familiar with the design space all know about Norman doors. Yeah. Uh, one other thing that's super valuable from that book. What other lesson that I took away from it is that when you set out to solve a problem or more often when you're working in software development, when someone comes to you with a solution, they want you to build the most critical thing for you to do. So you have to step back and understand the problem that they're trying to solve. And if you have time, you should take that problem as the start point for ideating around the problems in that space. And then you should select a problem to solve, which may not be the original problem they brought you, but is the one that you think is the most impactful, right? So you start with a problem, ideate a problem space, select a problem to solve, and then ideate potential solutions, and then select a solution to solve. And if you implement the solution that you were originally brought, you are, that was originally brought to you as a software developer, you are phenomenally lucky because most likely the solution you were brought is ignorant of many technical opportunities and challenges. Right? So, um, so once you do that, you, you now have the double diamond. That's the double diamond of product discovery, ideate problems, ideate solutions. And now you've got two points. So you've got two points to go back to whenever something goes wrong, like solution doesn't work. I'm going to try a different solution. Okay. I've tried five or six solutions. Either none of them is going to work or I don't know how to solve it, or I have got the wrong problem. Now I can go all the way back to the beginning, pick a different problem from my list and try to ideate solutions for that and come up with solutions there. And so it gives you a lot of power for iterating and finding the right solution for your user base. And that, that to me has also been hugely impactful. Throughout my career.

[00:39:36] Allan Stewart: It reminds me of a story that I heard, uh, where I want to say it was Dave Thomas, uh, author of, oh, what's that book called? Pragmatic programmer. The pragmatic programmer, him and Andy Hunt, I think.

[00:39:50] Dave Adsit: Yeah.

[00:39:51] Allan Stewart: Um, I think it was, I think it was him went to a company because they wanted him to do some like OCR programming so that they could sort their mail. And he went back to the problem. And, and suggested colored envelopes instead. And so they did no writing of code and everyone was very happy.

[00:40:13] Dave Adsit: Yeah. Right. That that's where you go back to, Hey, instead of starting with the solution, let's start with the problem we need to solve. Yeah. And yeah, I remember that story. Uh, uh, that reminds me of Dan North when he says the way you win at software is by not writing software. Right. Because. Functionality is an asset and code is a liability.

[00:40:38] Allan Stewart: Another book that, uh, was pretty impactful for me is this is lean. Um, I had heard all kinds of things and trained and learned about different ways of doing software methodologies. Uh, I had been through all the scrum trainings. I had been through learning about agile. I had been through a lot of different things and. And I had heard about some stuff that was related to it. And I had heard about some stuff that was related to lean like six Sigma and like these things that are going on. But none of it really stuck with me until I read this as lean, which is a fabulous book. And it's a fairly small book. Quick read, but just stuffed with very practical information that once I had read it, I was like, oh, oh, this, this is lean. And it made a lot of sense. Yeah.

[00:41:29] Dave Adsit: Do you remember the, uh, the paradox there? The, the lean paradox. The efficiency paradox from that book.

[00:41:35] Allan Stewart: Yeah.

[00:41:36] Dave Adsit: The efficiency paradox. The efficiency paradox, which is, um, that the more we try to be resource efficient, in other words, the more we try to keep ourselves and everybody else busy, the less work actually gets completed. Uh, that one for me, I love this is lean. This is lean is it's kind of the, the one-on-one or the, the primer on how to think in terms of flow and delivery. And I don't even know how many copies of that book I have caused to be purchased by companies I've worked for.

[00:42:12] Allan Stewart: Yeah. Great book.

[00:42:13] Dave Adsit: So the, uh, the, the last book on my list is the two Oh two on lean thinking, which is principles of product development flow. This one is a book that is also not terribly long. It's only nine chapters. Um, there's about 125 principles. And it's a book that has a lot of principles in the book, each of them, a page and a half or two pages. And it is a deep dive into how to think about getting work done and how to stop wasting time. I have, I have personally purchased a case of principles of product development flow that I kept in my home office to give out to people at different points. Uh, I think I have. I've got about eight of them left on my shelf. to keep everyone busy or do we want to get work done? And getting work done, maximizing flow efficiency, basically maximizing the amount of effort we're putting on each thing while it's in process is a way that we maximize our value and our utility in our organization for our customers, et cetera. And the principles of product development flow will teach us how to turn our thinking around from the way that I get things done is by being very busy to the way that I get things done is by focusing on the thing that I've started and not starting something new, not context switching until I've gotten the thing that I've started finished. And there's a lot of things in there. There's definitely some conflicting concepts in principles of product development flow. Some of the principles are like, do this thing. And the other is do the opposite of that thing. And then you have to apply your of the problem and the context to know which of those is going to increase your value, your flow in that case. So you definitely need to have a basis in understanding what is lean anyway, when you start in on principles of product development flow.

[00:44:39] Allan Stewart: Yeah. I think the only thing that I would disagree with you there is that you said that it was like the 202 version, right? So like, if this is lean as a introductory, college text, in fact, I think it could maybe even be like a high school level text. Like it's, it's pretty approachable. Sure. But principles of product development flow is more like a master's level thing. What was the quote? Something about every single word in the book

[00:45:11] Dave Adsit: is pulling its weight, doing a lot of work. I think that, I think that is true. The book was heavily edited to be concise. And to the point, there's not a lot of fluff in that book. And it's still 300 pages. So it may take you a couple of tries to get through the concepts. So obviously, reading books and implementing the content in them has been super impactful on our careers and on our personal development. But there are other things that are more discreet or more, you know, time boxed, like going to conferences or attending meetups or seeing specific, presentations at different times in our career. So for me, one of those, and this is in the same vein, right? This is in the lean software development vein. The first one I want to share is Mary and Tom Poppendick's presentation at QCon titled Tyranny of the Plan, which is an hour and goes through a lot of the concepts around how to deliver with a flow versus, you know, one of the things that I saw a lot of companies do is we would try to scatter gather a software project, right? We say, okay, we've got the smartest people in the room, and they're going to take this big project and break it into 100 little pieces and give each of those tasks to a developer. And those developers are going to all do their task. And they're going to bring all the tasks back, and it's just going to work. You know, once the last task is finished, the whole project is finished. And I don't think I ever saw that work. But I didn't understand why that wasn't working. I just assumed we didn't have smart enough people breaking it up. And I didn't understand why I watched the tyranny of the plan, and learn about how a flow based system can create delivery in the absence of pure planning. And I was later fortunate enough to have Mary and Tom come and do an in person training for a week with the company I worked at. And it really opened my mind. In fact, I will say one of the key takeaways that I got from that I had, you basically have two ways you can build in software. development, right, you can build to scope, or you can build to a time box. And I was a scope guy, tell me the scope, and I'll build to the scope. And as soon as the scope's done, we're going to ship it, let's just make smaller scopes and smaller scopes. And we're going to always ship to scope. And Mary said that that I was thinking about it backwards. And I should think about it in terms of time boxes. And that we should the I believe what she said is real engineering occurs when you decide what you can get done in the time you've allocated, right. So we set up a time box, and we have a budget for what we want to deliver. And then we decide what's most important and do those things and get as much done as we can in the time box. And then we ship what we have at the end. And it took me a long time, a lot of time thinking about that to actually flip the way I think and now I actually agree that that is a more effective way to build software in most cases. I I think that of course, you have to couple that with things like iteration. But that presentation and that in person training. I think that was super impactful for me in how I think about the way we scope and deliver and build projects.

[00:48:30] Allan Stewart: I think the single most impactful presentation for me was having Robert Martin, also known as Uncle Bob, he came and did a presentation at a company I was working for. And so it was, you know, it was close to that company. But I'm pretty sure he's given the same. presentation many times. And he talked about the futility of the second system, and trying to write, you know, you've got all this bad code. And so now we're gonna we're going to rewrite it with all the things that we know now. And we're going to get the tiger team together. And you know, I just remember him up on stage very animated talking about this process and why it was ultimately futile. He also talked about things like the immorality of but I hadn't always understood how to code well. And so that presentation was particularly impactful for me because it, it was kind of a pivot point and the content of the presentation, much of it I have forgotten over time, but it wasn't really, it wasn't really what I learned at that presentation specifically so much as it was the impetus for me to go and make additional

[00:50:16] Dave Adsit: change. Right. Yeah. I remember also seeing a presentation from Uncle Bob early in my career and thinking, oh man, I wish I cared about code as much as this guy. Yeah. Like I had written a lot of code, but he actually knew about it and cared about it. And I felt like I needed to learn a lot. So, so it isn't just attending that a conference that is impactful sometimes, sometimes you and I have been fortunate enough to Go to conferences, attend conferences, absorb the content from other speakers, but also speak at various conferences and share things with people. And I feel like one of the conferences that for me was really impactful was the Saturn conference, the software architecture conference. And I went to Saturn one year as an attendee. And the next year I submitted an experience report and was selected and I got to get up and give an experience report. And that was, that was a thing that to me was like, oh, I, I'm actually part of this community. I'm part of this community. That helped me feel like I was part of a broader software community. It was really an opportunity for me to grow beyond just my local team, my local company or team, or even the, you know, the community we have here in Salt Lake. That was for me where I got to share for this first time on a bigger stage with a broader audience about things that we were doing and ways that we were adopting practices and techniques in our companies. And that, that to me kind of set me on a path of, oh, I can do this. I can be part of this community. I don't have to be, you know, in the shadows, hidden in the dark, like, you know, wallflower. I can be out on the dance floor with the rest of the cool kids, um, being part of the community and developing the software community as a whole. That was the first one for me. And of course I've spoken to many other things. I know you have as well. Why don't you tell us about one of those? Yeah. So, uh, a good friend of ours, Mike, uh,

[00:52:15] Allan Stewart: He encouraged me at kind of a pivotal time to start presenting. And it wasn't something that I had really thought about very much. Um, I felt like I was still doing a lot of learning and he pushed me to say, well, just take some of these things that you're learning and go and present. You don't have to be an expert in order to share. Um, and that helped change my mind about how, uh, how I would present. Um, so I did some present presentations from that point. Um, I've done a few I've done a few presentations at, uh, various places. Um, agile roots was one of the first conferences that I presented anything at, um, that wasn't a internal conference, you know, with a small number of people that actually had people I'd never met before. Um, and also I started presenting in the, uh, Utah software crafters meetup, um, which was, which was a great meetup just generally for me, uh, both in attending and presenting. Uh, because suddenly I was participating in more of a peer group again, outside of the confines of my company. It's not just a brown bag meeting where we're already, you know, entrenched in the ideas of the one company that we're all working for, but now I'm getting these experiences, you know, and questions and insights from a bunch of different companies that I was not working at.

[00:53:40] Dave Adsit: Yeah. The, the Utah SC came around for me at just the right time. Um, I wasn't there for the first meeting, but I think I was there for by the third. And, um, it was at a point where I was really looking to join that community of professionals, of practitioners who are trying to level up and be better. And so participating in that and having discussions led to actually multiple job opportunities for me. Uh, it wasn't the to find a job. I was happy with the job I had, but I, I got to meet people who were much more interested in doing things the way I thought they should be done than the company that I was working at at the time. You know, I was, I was that person swimming against the stream. I was, you know, swimming upstream, cutting against the grain, whatever at the company I was at. And it was fun. I mean, it can be fun to be that person pushing everybody to improve, but you can go a lot further a lot faster. If everybody is rowing in the same direction. And so when I took that job that was offered to me based on attending Utah SC, it, things got a lot better, a lot faster. We were able to build a really interesting team. And I, I got to participate in agile routes as well, uh, from both as a participant, as a speaker, and for one year, even as an org, a co-organizer as a, you know, like junior assistant to the organizers. I would say, uh, the people who were running it, they knew what they were doing. And I was just there as free labor more than anything, but it was a lot of fun and a good opportunity to meet some people, broaden my community once again, and challenge some of my con, uh, my preconceptions about things, you know, agile routes is no more. It's a, it was a regional conference here in Salt Lake that ran for several years, six, 10. I'm not exactly sure how many years ago, but it was a local community events, local events, community events in your area. Those can be super impactful, like super fun. You get to meet your local people who are also thinking about things the way you are. Uh, in addition to participating in the Utah SC meetup, there was the Utah code camp for a lot of years and also a Boise code camp. Mike dragged, drug me off to Boise to give a presentation there. That was a lot of fun. I went there for a few years in a row. Um, you can go to conferences that are local and usually free. Uh, I don't think anybody pays to attend Utah code camp, or I think now it's called big mountain Devon data or big mountain data and dev. Uh, one of the two, I'm pretty sure it's data and dev because the developers, you know, we always get ours, but the data folk, they get fewer opportunities. So, um, you know, participating in those local events, first of all, it's easy to get on stage. And easy to share something in terms of getting accepted. It's still pretty nerve wracking to be up there in front of a group of your peers saying things in a way that, you know, somebody in the audience is going to disagree and question you. Right. Um, that was, that was a thing that for me, not only did it help me develop my understanding and go deeper in some of the technical things that I was sharing, but also develop the confidence to present to a group. You know, that was, that was super powerful for me. I, um, I know that I've heard that at least Americans fear public speaking more than death. And I get it because I've done it. I haven't died, but I have done public speaking. And the first few times it's pretty awful, but when it's low stakes, like a local code camp or whatever, it's a good opportunity to like build that skill, practice that skill so that you can do it in a more high impact opportunity, a high impact situation.

[00:57:43] Allan Stewart: Absolutely.

[00:57:45] Dave Adsit: That, that was, that was actually what was most valuable for me about code camp. I don't, you know, I, a lot of the same people attended Utah SC and the Utah.net meetup as a go to the Utah code camp. And so I knew a lot of the people already, but actually getting up there in front of them and presenting that was a way to build a new skill.

[00:58:04] Allan Stewart: Yeah. And it has a little bit of a different feel to it, which is something I like about something small, like a code camp is that it doesn't feel like just a meetup. It feels like, Oh, especially like if, you know, if there's a conference agenda and people are picking between tracks and they're choosing your track, like that definitely has a different feel to it. Even if it's a small gap, relatively small gathering that isn't that much different than your meetup group in the first place. It's still because your mindset is different. It kind of forces you into a different experience of, you know, a similar thing, even if you were just presenting the same thing that you might've presented at a meetup. Yeah. Well, moving on, we've got another category is people and mentors. We already talked about the company that we both worked for, which was really nice to have a lot of like-minded people and not having to swim against the stream. But another, another experience I had on a different team, but the same, same company was learning about distributed systems when I worked at the, worked on the architecture team and worked closely with our platform team. And that was, that was a great opportunity for me, a big impact on my career because it gave me the opportunity to look at what was going on at the system level and working with these people who knew so much and were able to teach me so much about, uh,

[01:00:09] Dave Adsit: well. And it was a good opportunity to put a lot of things to practice that I had only read about up until that point. The one that I would like to share, and we don't often call out companies by name, whether we're saying something nice or something not so nice about them. But I would like to call out one person by name. He was a very, very important mentor for me for several years. His name was Rich Watts. And he was our tech lead at the company that had just gone through the ThoughtWorks transformation. And Rich had what some would call an abrasive personality. But he was definitely someone who cared about his team and the product and the code. And he made things happen, right? Rich was the first person that I'd ever paired with, like all day for 10 hours. And I remember after a few weeks when he had, you know, I'd gotten acclimated to a little bit. Rich said, you don't know our tools very well. And you need to learn them. So I'm going to take away your mouse. He probably didn't say it in quite such a polite way. I think he probably said, no mouse for you and took my mouse away. And so we were sitting at one monitor with two keyboards and two mice, and I didn't get a mouse. And he's like, okay, now you have to use all of the keyboard shortcuts to navigate this code base, and to run the tests and to write new using pretty, we're using the JetBrains refactoring tools and the JetBrains tools for our programming language at the time. And they were really powerful. And I didn't know how to use any of them. He's like, I'm going to take away your crutches, I'm going to take away your training wheels, and you're going to learn how to program like a grownup. And so I was hands on keyboard, and I had to ask a lot of times like, okay, how do I go forward? How do I navigate to the definition? How do I go back? How do I implement? All those things, right? And pretty quickly, I was able to learn the tools, and I was able to earn my mouse privileges back. And that experience is one that sticks with me today. I mean, that was easily 15 years ago. But it sticks with me because it was someone who was willing to slow us down in order to build me up as a person. I was able to enhance my skills by And to pay what eventually ended up being a fairly small cost to teach me new skills. And so he was someone who I relied on for a long time after that. I would reach out to Rich and say, hey, I've got this problem. This is how I'm thinking about solving it. Is that going to work? And he would say, yes, no, or I think that you also need to consider X, Y, and Z. And he was somebody who was super helpful for me for a long time because he was somebody who cared about me developing my skills so that I could be better at our craft. And yeah, I still think about that. I still think about whether or not I am being that kind of a person for those around me. And I hope that I am at least to some extent. So I like that a lot. I never had anybody

[01:03:26] Allan Stewart: take my mouse away. So you were already really good. You're already really good with resharper

[01:03:32] Dave Adsit: by the time we worked together, or I totally would have.

[01:03:38] Allan Stewart: So as we kind of wrap up with our last section, this will probably go a little bit quicker because we've already talked about some of these things in many previous episodes, but practices. Practices have impacted our careers quite a bit. The first one that I want to mention is test-driven development. I think I've shared before about teaching myself how to unit test because we had a CTO who wanted us to do that. And he kept saying, you should be unit testing. And I was like, you should be unit testing. You should be unit testing. You should be unit testing. And nobody seemed to do it or understand what he was asking. And so I taught myself. And kind of on the heels of teaching myself to unit test, I just jumped into test-driven development. I had already had people tell me that I was a backwards thinker anyway, because when they wanted to go outside in, I'd go inside out or vice versa. And I remember doing a restructuring using test-driven development on a small project. And seeing it really come to life, it worked really great. And that's one of the practices that has stuck with me for 15-ish years now that I don't think I'll ever go back on.

[01:04:52] Dave Adsit: I agree. So the very first time I was introduced to test-driven development was at a super big company. And one of our tech leads, for some reason, our team had two tech leads. One of our tech leads was doing it. And he was trying to teach us how to do it. And I was And I didn't get it. And some of the other guys with more experience than me were like, they didn't get it either. And so we all came away with, I came away with a fairly jaded attitude of why would I write twice as much code? That doesn't help anything. I already know that my code works because I wrote it, right? And so I didn't, the first time I was introduced, I didn't even attempt it. And then later when I went onto the ThoughtWorks project, obviously we were doing test-driven development. And that is where I learned to be test-infected and test-driven development became a core aspect of how I do code to even today. Just yesterday, I was working with my chief architect and we were working on a bit of code and we wrote some additional tests for cases in the code that were uncovered. And so that was something that I think is super important. So speaking of, one of the things that both of us have mentioned is collaborative programming, AKA pairing or mobbing. That is, a practice that has changed the way we think about software and the way we do things, right? For me, it's all about delivering a higher quality product or it's about delivering a higher quality product sooner versus being the most resource efficient that we possibly can be.

[01:06:22] Allan Stewart: Yes, absolutely. And additionally, I think that it teaches you how to collaborate with people better, especially with code, because you have to start learning, how to communicate well. How do you get that nebulous thought that, yeah, you could type it up, but how do you actually say it in words that mean something to another developer?

[01:06:44] Dave Adsit: Yeah, I like to think that pairing and mobbing is one of the best tools we have for improving the skill and quality of our teams and team members. It does teach you communication in a way that, you know, we all think about that, that gray beard curmudgeon in the corner, or the corner of the office who just barks at everybody all the time. And that is the stereotype for software engineers or was for a long time. And it's changing because we are learning that we are part of a bigger system and it's a socio-technical system with people. And so we have to be good at communicating with and working with people. And it improves the quality of the software. It improves the quality of the people. And I've said for a long time, If you want to improve your code, start testing it. And if you want to improve your team, start pairing. I add mobbing to that now. You're always going to learn something from working together. So one of the other things that I learned about early that kind of changed the way I think about software is CI, trunk-based development with continuous integration. We grab some leftover computers from the help desk and we set them up in the corner of the office, and they were our build master. And our build agents. And we had a physical light on top that would go yellow when it was building and green when all the tests passed and red when something went wrong and everybody would jump on and fix it. And that helped me think about software in terms of quality and delivery and always shipping some, always being ready to ship something. Don't let problems sit. And so I'd worked at companies where we only did one deploy a year. And so it didn't matter if your if it was in a deployable state because it was never going to get deployed or would eventually get deployed one time. I also worked at companies where we said we were doing things like QA environments and staging environments and testing and all these things. And it turns out we really weren't because every developer would just log into their favorite web server and just change the code right there on the fly using a text editor on that web server. But actually doing CI helped me start to think about software delivery and how I could use that to do things like delivery as part of a system of value creation. And I really like having a CI system. I mean, now we're at the point where we also do continuous delivery, not just continuous integration, right? But it's been an evolution and it allows us to be better at what we do.

[01:09:22] Allan Stewart: Yeah. I would add to CI the delivery side of that as well, right? So a lot of times with the CI server, I mean, I guess, first of all, there's the actual, integration of the code and making sure that that's all working, but then you can also start moving into now, how do we deploy? And it might be automated, semi-automated deployments. And that has made a big difference for me in that same vein of being able to get stuff done, see it actually realize the value, which leads me to the last practice, DevOps, very similar kind of vein where to actually have an understanding of how this thing operates in production and it, it affects how you write code. So understanding how your code goes from the initial concepts, ideas, first characters that you're typing out and in the text editor to now it's actually running in production. And I understand why it works and what the failure modes are like is very important and also helps you have a better relationship with the code. your operations team and understanding how, how it impacts their role rather than just throwing it over the wall and saying ops problem now.

[01:10:43] Dave Adsit: Right? Yeah. The, you and I have worked on projects together where the very first thing we did was set up a CI pipeline so that we could deploy to our staging environment automatically or create a staging environment automatically deploy to that environment automatically deploy to our production environment automatically before we wrote the very first feature. Yeah. And we could maximize our opportunity for learning by delivering sooner. And that allowed us to build some really cool software when we were working together. And I've done that on several other projects since where it's just like a very first step is set up the full pipeline and it might take you a day. It might take you two days. It might not take you very long at all. If you've done it a few times, if you've done your, your DevOps katas where you've practiced setting up pipelines, setting up environments. And it changes the way you think about software. It's not, I need to build this big batch and then deliver it. It's I need to put something in the hands of my users as quickly as possible. How can I make this, how can I deliver value sooner and more consistently? And that to me is what DevOps for me a lot is a lot of it is about consistency and reliability of the system, but also building those connections across departments. And across functions within engineering, which are super valuable. So I'm sure that we could go on all day about experiences that we've had and things that we've done that have been impactful to our career. But I think these have been some pretty big ones for each of us. I'm sure that everybody who has been in software for a while has experiences that really change the way they think about software development.

[01:13:01] Allan Stewart: especially some of the developers that I most admire, have a lot of similar stories, right? There are similar practices and things, and we're still evolving. We're still growing in this industry. But I would recommend to any of our listeners to think through some of the things that have made a big impact on you and maybe listening through this list or looking at some other people that you would like to emulate, find those things that have made a big difference to them in their career to see if there's something else that you could be learning, something else that would make a difference for you. Because these things tend to make a difference for you personally, but also helps you turn around and make a bigger impact in your job, in your local community, and so forth.

[01:13:51] Dave Adsit: Yeah, and the last thing I wanted to say about that is none of us sprang forth fully formed. We are not Greek gods. We all went through many learning opportunities to become the developers, software coders that we are today. And those opportunities will be different for everybody, but they're available to everybody to have impactful experiences that help them grow in their career.