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 on you. 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 phrase it this way. I had the fortune of working at a company that went bankrupt. Route. 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 way of obligations. And so it wasn't a, it wasn't a big problem for me. You know, I was financially secure as much as a, you know, 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. I wanted to write code. 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, uh, so I kind of escaped a few months before they went bankrupt. Uh, and it turned out to be really good for me in the longterm 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, 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.

[00:03:31] Dave Adsit: Right. Well, I also want to talk about one of my early experiences, but it's kind of from the 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 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. We had people selling it and people supporting it in the field eventually and all that kind of stuff. But it all started off as kind of my creation. And most of the code, almost all of the code that was in there was mine. And it was one of those things where I felt like I was thrown into the deep end and I had to sink or swim. And I remember 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, dev ops are the same kinds of things that you were kind of thrown into you you had to, because there was no ops, there was no one. Yeah, it was, uh, yeah, in fact that my manager

[00:06:29] Dave Adsit: who was a pro who had done some of the initial prototyping on the product, he, um, once he saw that it was in good hands, he just kind of walked away from the project and focused on other areas of of the company and other things that needed his attention more.

[00:06:44] Allan Stewart: So, yeah, I remember there was a company that I worked at that had a, where I had a similar experience after 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 the first company that I worked at that was really big, like international company, thousands of employees. And so that was a pretty big impact on my career. 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 good impact on my career as far as seeing a broader horizon of 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 than I did writing code. And that was on purpose. And when you're in a small company, you're like, well, why would you waste your time? You've 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 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.

[00:09:38] Allan Stewart: Good thing it's not very hard to schedule 11 people.

[00:09:41] Dave Adsit: 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 that the Change 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 job. It 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 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#. 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're 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 really at that point. I think that came later. Sometimes I get my timelines messed up. But we're doing all of the things that really allow you to go quickly. Like we did one week sprints. 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. Since then, 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 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 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 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 not to do, right? So I went into the code base and I was told, "oh man, you're going to 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 does matter what you're building. I know a lot of people, 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 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 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 learned a very valuable lesson that you have to be aligned with the product you're building or at least not anti-aligned to it, right? In that case, it felt like "don't be evil" would have been a good mantra for us to adopt, but then we would have had 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.

[00:17:35] Allan Stewart: I think it's interesting as we discuss this 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, 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 things." And then we would hire some junior developers and teach them in the ways that we thought were best. And you know, trying to be more, I won't say bleeding edge, but 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 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 I was 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 experiences that give you a sense of perspective and the context that lets you know, actually you are in the field that is greener. You just haven't explored very many fields before.

[00:19:12] Dave Adsit: Yeah. I wondered about that many, many times when we were working there. Are we actually doing a disservice to these people we bring in and only teach them 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 the same advice I've given in the past. When you are on a, at, 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 to work in and you want to bring other people into with you later in your career.

[00:20:27] Allan Stewart: 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 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.

[00:21:34] Dave Adsit: Yeah. I like that a lot. 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 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 it's like, "you know what, I want to be the boss now. I know what my boss is doing wrong. I'm 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 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 CTO at that time, he would have to be a lot more level-headed in politic and whatever. 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 skill set 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 role. And so it was really, really valuable for me. And I got to, 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, 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're used to being hands-on and doing the work yourself. I did a lot of ops 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, politicians, let's talk about some other different kinds of things that have made

[00:25:08] Dave Adsit: impact on our careers. Let's talk about books. 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, there's a lot more on demand versus is 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'm like, "okay, great. I'm going to take advantage of this." And 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 went in 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 our language versus which things didn't. We were .NET. And 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 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 paperback. 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, uh, what was good and bad, but it also gave me a language, uh, kind of a rubric by which to judge code instead of the gut gut feeling that I was using before. And the Refactoring book was great because it gave me tools that I could use to change the code. So if I encounter some code that doesn't behave the way that I want to, it's, it doesn't feel good that I can identify what those things are and make the changes so that now it is the way that I want it to be.

[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, 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, right? It really teaches you about the intention behind the object-oriented 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:25] Allan Stewart: It turns out that what you obviously meant is very rarely what people receive when they hear it.

[00:29:33] Dave Adsit: Yeah. At least the first time. I've heard that communication 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, 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 What parts of it are, what's core to the solution and what's accidental or incidental? And what are good abstractions? Where should you bring code in versus where should you push code away? Like 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 lessons from Clean Code and Refactoring in that Domain-Driven Design is about how the software communicates with other software developers versus how the software communicates with the machine. Because the machine doesn't care. The machine is going to turn it into binary eventually, right? Right. And so you should have a ubiquitous language in your system that allows you all the people to talk about the code in the same way and communicate with each other effectively and quickly as they are building the system.

[00:31:13] Allan Stewart: Yeah, 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. And I was being taught it by example, you know, through 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. 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 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 for you. 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, 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 or 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

[00:34:29] Allan Stewart: since. The book that helped me with that same concept is one that you recommended for me, The Design of Everyday Things. Yes. And it teaches similar concepts. And I remember learning about things like affordances and signifiers, which helped me to kind of better better understand how do you interact with the system, but also help me with an understanding of how, if a system isn't working, it's a failure of the system or, or a program like code. If it's not working, it's, 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 it should function. Right. It's like, I don't know. Yeah. You, 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 it would, that life would never be the same. And I still, 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 writ large.

[00:35:58] Dave Adsit: Here it is. Yeah. I think about on The Design of Everyday Things every single day when I go in my garage, because 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 you never moved them. 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 yeah, 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 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. Other. And 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 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. One other thing that's super valuable from that book, one 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 is step back and understand the problem that they're trying to solve. And if you have time, you should take that problem as 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 implement. And if you implement the solution that you were originally brought, 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. So once you do that, 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 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 where I want to say it was Dave Thomas, author of 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: 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. Yeah, right, that that's where you go back to, "hey,

[00:40:16] Dave Adsit: instead of starting with the solution, let's start with the problem we need to solve." And yeah, I remember that story, uh uh, that reminds me of Dan North when he says, "the way you win at at software is by not writing software, right? Because functionality is an asset and code is a

[00:40:37] Allan Stewart: liability." Another book that was pretty impactful for me is This is Lean. I'd heard all kinds of things and trained and learned about different ways of doing software methodologies. I had been 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 lean, like Six Sigma and, like, these things that are going on, but none of it really stuck with me until I read This is 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 from that book? Yeah. 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. That one, for me, I love This is Lean. This is Lean is, it's kind of the 101 or 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 last book on my list is the 202 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. There's about 125 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 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. I think I have, I've got about eight of them left on my shelf. And this book is one that I have run a dozen training programs on, just taking people through the content of this book, to think about the difference between resource efficiency and flow efficiency. And the question is, do we prefer 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, you know, 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 understanding of the problem and the context to know which of those is going to increase your value, your flow in that case, right? 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, the two Oh two version, right? So like, right. 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 is pulling its weight, doing a lot of work.

[00:45:15] Dave Adsit: 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, right? Like going to conferences or attending meetups or seeing specific presentations at different times in our career. Air. 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 Poppendieck's presentation at QCon titled "Tyranny of the Plan," which is an hour and goes through a lot of the concepts around how to 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 a hundred 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 I didn't understand why that wasn't working. I just assumed we didn't have smart enough people breaking it up until I watched "The Tyranny of the Plan" and learned 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 gonna ship it. Let's just make smaller scopes and smaller scopes and we're gonna always ship to scope." And Mary said that I was thinking about it backwards and I should think about it in terms of time boxes complexes and that we should, 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 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 think that, of course, you have to couple that with things like iteration. But that presentation and that in-person training were 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 closed 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 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 manual testing. And it just, it hit me at the, at the right time in my career where I was trying to learn more. I was open to hearing some of these things and thinking about, "oh, huh, how about that?" Which led me to go on to pick up his Clean Code book and read that. And so prior to that point in my career, I had done lots of coding, but I hadn't always understood how to code well. And so that presentation was particularly impactful for me because 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 what I learned at that presentation specifically so much as it was the impetus for me to go and make additional change.

[00:50:17] Dave Adsit: 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." Like, yeah, I'd 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 it isn't just attending 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 a thing that to me was like, "oh, I'm actually 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 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?

[00:52:08] Allan Stewart: Yeah. Yeah. So a good friend of ours, Mike, 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. 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." And that helped change my mind about how I would present. Um, so I did some present presentations from that point. Um, I've done a few conference presentations at, uh, various places. Um, Agile Roots was one of the first conferences that I presented anything at, um, that wasn't an 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. Which was a great meetup just generally for me, both in attending and presenting, 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 entrenched in the ideas of the one company that we're all working for. But now I'm getting these experiences and questions 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. It wasn't the original intent. I didn't go there to find a job. I was happy with the job I had, but 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 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 a lot better, a lot faster. We were able to build a really interesting team. And I got to participate in Agile Roots as well, as a participant, as a speaker, and for one year, even as a co-organizer, as a junior assistant to the organizers, I would say. 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 It was a lot of fun and a good opportunity to meet some people, broaden my community once again, and challenge some of my preconceptions about things. Agile Roots is no more. It was a regional conference here in Salt Lake that ran for several years, six, ten. I'm not exactly sure how many years it ran. Quite a few. You. But 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. 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 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. You can go to conferences that are local and usually free. I don't think anybody pays to attend Utah Code Camp, or I think now it's called Big Mountain Dev and Data, or Big Mountain Data and Dev. One of the two. One of the two. I'm pretty sure it's Data and Dev, because the developers, you know, no, we always get ours, but the data folk, they get fewer opportunities. So, 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? That was a thing that for me, not only did it help me develop my 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, I, 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, high impact situation. And so 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. Yeah.

[00:58:05] Allan Stewart: 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. But even if it's a 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 a similar thing, even if you were just presenting the same thing that you might have presented at a meetup.

[00:58:48] Dave Adsit: Yeah.

[00:58:49] Allan Stewart: 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 experience I had on a different team, but the same company was learning about distributed systems when I worked on the architecture team and worked closely with our platform team. And 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 systemic concepts that would help us as we started to do different kinds of communication. When should we use REST APIs? When should we use messaging? What kinds of databases do we want to use at certain times? Really, really great experience for me.

[01:00:04] Dave Adsit: Yeah, that was a good experience for me as 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 they were 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 the team 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 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 code and all of those things, right?" We were 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 like all those things? Right." And 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 him being willing 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." You know, and he was somebody who was super helpful for me for a long time because he was somebody who showed that he 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.

[01:03:24] Allan Stewart: So I like that a lot. I never had anybody take my mouse away. So you were already really good.

[01:03:31] Dave Adsit: You're already really good with ReSharper by the time we work together, or I totally would have.

[01:03:37] 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, 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:51] Dave Adsit: I agree. I learned to, so the very first time I was introduced to test driven development was at a super big company and one of our tech leads, some, for some reason our team had two tech leads. One of our tech leads was doing it and he was trying to teach us 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. There. 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 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 gray beard curmudgeon in the corner office 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 grabbed 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 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 code was in a deployable state because it was never going to get deployed or would eventually get deployed one time, right? 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 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 it 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. You, which leads me to the last practice, DevOps, very similar kind of vein where you've got to actually have an understanding of how this thing operates in production. And it affects how you write code. So understanding how your code goes from the initial concepts, ideas, first first characters that you're typing out 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 some of these other departments like your operations team and understanding 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. You and I have worked on projects together where the 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 so that 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. Other. And I've done that on several other projects since where it's just like the 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 is a lot of it is about consistency and reliability of the system, but also building those connections across departments and across functions within in 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, development about craftsmanship, about systems and buildings, both technical systems and socio-technical systems. And I think it's just really good for me personally to kind of do a review of some of these things to see, remind myself where I was before some of these things happened and how I thought about systems at that point. Absolutely.

[01:12:57] Allan Stewart: And I've noticed that a lot, there are a lot of developers and 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, you know, the last thing I wanted to say about that is like, 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 are available to everybody to have impactful experiences that help them grow in their career.