Crafting Code Podcast

[00:00:00] Allan Stewart: Welcome to episode 11 of 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 using AWS Lambdas for low-use personal projects.

[00:00:16] Dave Adsit: I'm Dave Adsit, a CTO, and I have been thinking about the state of Agile in practice.

[00:00:25] Matt Baker: I'm Matt Baker, a software architect. I've been thinking about my co-host Allan's new event sourcing kata. I'm going to do it this afternoon.

[00:00:33] Allan Stewart: Our topic for today is software education. There are various different ways or routes to get to being a software professional. Some people, like me, went and got a computer science degree. Other people go to boot camps. Some people are self-taught or get on-the-job learning or some other form of mentorship. There's lots of different ways, approaches, and pros and cons. And it's interesting to me because each of us come from a different background. Like I said, I got a computer science degree.

[00:01:04] Dave Adsit: And I am having a hard time categorizing what I did to end up in this position, except that I know for a fact I don't have a computer science degree.

[00:01:17] Matt Baker: For me, I just went right into the workforce.

[00:01:20] Dave Adsit: So I think, you know, this topic came up. While I was ranting recently at Allan, because like I said, I don't have a CS degree, but as a CTO, I feel like I have certain responsibilities to my company. And I want to go work on higher education in the business aspects of running a software business. So I went back to one of the local online universities, Western Governors University, to start a software engineering degree. I went back to some of the other industries. I went back to some of the other industries. I went back to some of the other industries. I went back to some of the other industries. I went back to some of the other industries. I went back to some of the other industries. I went back to some of the other industries. I went back to some of the other industries. That's what's expected for the standardized test that I am taking. And so as I was talking about some of those things, we started comparing what ways we've learned and how we've gotten to the places that we're at. And I am, of course, like I started a CS degree and then dropped out of school because I had a job. And so that's why I don't know what my path really is. Like I could regurgitate it to you, but I couldn't categorize it for you.

[00:02:52] Matt Baker: Something that's coming to mind right now. Like I said, I'm self-taught on the end of the workforce that way and figured it out. And one thing that was interesting, not having a college degree is the stigma that I think is fading very rapidly now, or maybe it's not even there anymore. But I had one manager who hired me. And then like two weeks into my working with him, he asked what college I went to. And I said, oh, I didn't go to college. And he stopped and said, oh, that was interesting. We don't hire people without college degrees around here or something like that. That was his response. And I said, oh, okay. And he said, well, I'm glad you're here and kind of walked off. And I was like, hmm, the exchange didn't feel great, you know? And I think all software engineers have some form of imposter syndrome and as if I needed any more, you know, ammunition for that, but it was okay. And he turned out to be a nice guy and I don't think he meant anything by it, but like there used to be that stigma, I think. But it seems like both just more and more people are, you know, leaving college early or finding other ways. And the industry and the, you know, with the rise of boot camps, we've seen, I think a lot more induction into the, uh, the field from non-college backgrounds. Maybe that's helping out some of the stigma a little bit.

[00:04:01] Dave Adsit: I used to get a similar thing early in my career. People seemed to accept the fact that I had left school to take a full-time job, but there was always the question of, well, when are you going to go back and finish that degree? And at first it was like, oh, as soon as I get around to it, I'm going to do that. And then later I was like, why do I need? A degree? What are you talking about? Like all software development is on the job training. Like the things I learned in my degree are super fascinating and I'm glad I know them, but unless they save all the good classes for the very end, what I had learned in the two years I spent did not in any way prepare me for the workforce.

[00:04:40] Allan Stewart: You missed all the fun classes, Dave. That's the problem, right?

[00:04:43] Dave Adsit: That's what I've heard. I missed all the fun ones.

[00:04:46] Allan Stewart: I look at that and I can kind of come at it from almost the opposite perspective because I went, I got a CS degree and then I started working, which isn't entirely true because honestly, the entire time that I was at college, I was also working writing code as my part-time job. But I also remember getting into the first couple of jobs and thinking, wow, the degree that I got didn't really help me to know what I needed to know. But because I had a degree, people expected that I knew what I was on about. And so there was a kind of a form of imposter syndrome happening in like, like a reverse direction from where a lot of people that are coming in self-taught.

[00:05:26] Matt Baker: I've never thought about that, but that makes total sense. Of course, like you show up and you've got this badge that says you can do a thing, but like you haven't like tested that, right? You haven't gone out and done some things. And so of course you would sit there thinking, oh, I hope I, I hope I can live up to what this is saying.

[00:05:43] Allan Stewart: The more I think about it, I've worked with a lot of different people and I've seen a lot of different situations now. And the more I think about it, it doesn't. Really matter how you arrived at your software development knowledge. I think that there's some benefits. Like I'm personally glad that I have the degree that I have. I'm glad for the things that I learned and they come up here and there in my career. But I've worked with, you know, fabulous developers that don't have that. And so as I've thought about it, it makes me start to believe that there are things that you should learn. There are concepts and skills and things that you're going to need to learn, and it didn't matter if you learned it at school or sometimes if you went to school, they didn't teach it. But you're going to need to know them. For me, some of those things included unit testing, understanding software patterns and development methodologies. Those are things that they didn't teach me in school, but they became very important. The continual use of source control is one of those things. I didn't do that in school. And partly that was a function of when I went to school. It's interesting that there are these things that you need to know, things that you should be able to understand. And I'm curious if you two have found the same thing or what are some of those things that you feel are important that somebody should learn if they really want to be a software professional?

[00:07:08] Matt Baker: Yeah, I think there are some things that you should learn whether or not you come from college or not. There's always an, it depends here for me. It does depend on what kind of software you're writing, but generally speaking, some of the things that you're And I think that's something I did that's very academic that really opened up my mind and improved my craft was writing a parser for the first time. The first time I did this, believe it or not, it was a few years ago, late in my career. And this parsers, compilers and things are an area where like my imposter syndrome can definitely kick up if I don't watch myself. But anyway, I took the plunge and I wrote a parser. Oh my God, I wish I could go back to the first year of my career and tell myself to do this because it helped me a lot. It helped me so much. One example of where it showed up, it showed up in a lot of ways for me, but one example was right after I wrote the parser, I was debugging an error and it included some PHP code and it included a parsing error. Not only did I know like generally, okay, I know what this error is. Like I knew exactly what that error was. You know, I knew the exact token that it screwed up, that it couldn't parse and get into the AST. And like those all came to life for me and meant something. And I felt like I really understood that error. Like I'm getting really obsessed about this error, but I really understood that error. I feel like at a different level. And that was totally from writing that parser, right? Which is not anything my job required of me. Something surely I would have done in college, but there was a cool book. I can't remember the guy's name. It was just called How to Write a Parser and Go. And it was great. And I would do it again.

[00:08:36] Dave Adsit: That's awesome. I think that basically every project I've ever worked on has had something that I've had to learn that I felt like I should have learned earlier, but I never did. I remember early in my career, basically every task or project that I was handed, I felt like, oh, I should know how to do this. And then I would get in and start working on it. And then I would inevitably put in far too many hours to cover up for the lack of experience that I had. As an example, at one point I was writing a VB6 project that was compiled by some aftermarket compiler so that it could run on a computer. I would pick some books. I would pick some books. I would pick some books. I would pick some books. I would pick some books. I would pick some books. I would pick some books. I would pick some books. I would pick some books. I would pick some books. I would pick some books. what? I don't know. So that's why I keep coming back to like all the real learning in software development happens on the job when you're doing it. Well, one of the unfortunate things about

[00:09:59] Allan Stewart: learning is that sometimes you wish you knew the thing earlier, but if you had been taught it, you would have just like ignored it. I think that there's sometimes like you have to experience the pain and you have to get to a certain point where it matters and then it clicks for you. Or you finally see like Matt, with your example, with the parser, if you could go back to your first year writing software and convince yourself, your earlier self to write a parser, would that have stuck? Would it have made a difference or is it only because you hadn't had that and now you see the benefit of it, that it matters to you? A point taken. Yeah. I think

[00:10:40] Matt Baker: it took, you know, a while of writing code without that. Knowledge to then when you see it say, ah, this makes a ton of sense. And then I was fortunate enough to be able to apply it immediately afterwards. And Dave mentioned feedback as well. I think I know lots of people learn in different ways, but for me, like that application will cement something for me. But if not, Allan, I'll experience what you just described, which is, it's just kind of in one ear and out the other and it won't stick, you know?

[00:11:06] Dave Adsit: Yeah. I've had that same experience. I need to use something for it to matter. One of the things that I like to do, as kind of a learning exercise is go to code retreats and code retreat is like a whole day solving the same problem over and over and over. And in fact, it's the same problem, every code retreat. So by the time you've been to a half dozen of them, you're really good at writing Conway's game of life in whatever language you use. Most of the time, that doesn't mean that you stop learning. There's still nuance to how you solve the problem. And you get to try things that you haven't tried before. There's a bunch of basic ways to solve it, but until you've done those, you're not going to understand why you would want to try to solve it in some of the ways that are less intuitive. One of the things that we do a code retreat is apply certain constraints. And so one of the constraints is no method can be longer than two or three lines. You learn something about writing code that you can then take back and use immediately or whatever. Some of the ways of writing code that we do at code retreat have less direct

[00:12:19] Matt Baker: applicability to your standard work. There are some, like, I think we've talked about the, the get bomb before. And Allan even wrote a little bit of code for this. But one code retreat thing that I've done on the job that I thought was super cool, very impractical. Definitely not like, well, I was going to say not cost-effective, arguable, but what you would do is in the code retreat, you would start writing code. And I think it's five minutes in the code retreat at the five-minute mark, the timer goes off and you have to run a get reset hard. So if you haven't done a get commit in that five minutes, then you lose your whole change and you have to start over again. But if you do a get commit within that five minutes, it resets the timer. Really fun way to like code on game of life and just gives you an interesting perspective. I did that on the job for a little while too, just to try it out, to see how it went. And, you know, it actually, I produced some really good results. I think we, I swear we've talked about that some other time, but I don't know. I don't know how many of those constraints can come over from game of life, but like if you're fortunate enough to work in an employer, like where you can take an afternoon and try one out, that's kind of fun to do. I was thinking silent pair programming is a

[00:13:32] Dave Adsit: challenging one, given that we work in remote mobs. The whole point of a mob is that you're

[00:13:40] Matt Baker: communicating continuously. It'd be fun to try, see what

[00:13:44] Dave Adsit: changes. See what you get from silent mobbing. You probably get at least one person falling asleep in the back if it's a long time till their rotation. That's probably right.

[00:13:53] Allan Stewart: So there are a few other academic kind of things or things that you learn a lot about in academia that I feel like people should understand. Big O notation. I don't know that the notation part of it is that important, but understanding how something is going to perform algorithmically, how much time or space complexity, those are important. Things to be able to understand. You can get, you know, even with a small data set, I think people experience this a lot with relational databases when they're first learning about joins. Like, oh, great. We can join all the tables, join, join, join. And then there comes a point where they make the join incorrectly or in an undesirable state and they get a cross product. And all of a sudden it's like, what happened? Why did this just grind to a halt? So that's one. Data structures, I think is another. You should understand the difference between an array and a set or a hash. I looked to JavaScript for that. Is it curly braces or are they square brackets? There's a big difference there, but you know, some people, they haven't, they haven't learned that yet. And it can really change how you write your code and how it performs. I don't know that everybody needs to write their own linked list implementation, let alone a self-balancing B tree or something like that. I don't think I've ever used the ever used the pumping lemma at work. So there's, there's like these different things that some of them are really important, but important in, in various contexts of what kind of code you're writing, just like you were saying before, Matt. That's interesting to me. One of the thoughts

[00:15:29] Dave Adsit: that I'm having is about the difference between generalist education and specialist education, right? So if you're talking about data structures, algorithms, and the pumping lemma, if someone is working in actual computer, science, trying to optimize our knowledge and increase our knowledge of how to operate in a computer environment, I imagine those things are super useful, but like you said, they don't come up that often. Like, okay. So I talk about big O with my architects often enough data structures, algorithms. Yes. I've also never used the pumping lemma to my knowledge unless I invented it and gave it a different name, which is unlikely. But I've also never used the pumping lemma to my knowledge. So I think that there's a problem in education that you're trying to give somebody enough breadth and enough depth that they can go do whatever thing it is they're trying to do. And the only way to get that depth and breadth that you need is to know what problem you're solving and then go spend a lot of time solving it. It's kind of an estimation problem, right? What things do we need software developers to know before they go do their job? Well, everything. They need to know how to optimize memory. They need to know how to write a parser. They need to know how to analyze the complexity of an algorithm and all of these things, but also they just need to know what is the next line of

[00:16:56] Matt Baker: JavaScript to type. I think there's been some work done to help people who find themselves maybe like from a bootcamp or self-taught, or maybe they went to college and didn't pick up this stuff, like big O and data structures, whatever, you know, but there are some paths now that you can take to get this knowledge. Good books. The Impostors. Handbook is one book that I think is a pretty good one. Another one I really like, maybe a bit left of center of this topic, but it's called Code. It's a Microsoft book that is awesome. It starts from binary and communicating, or excuse me, it starts with Morse code and ends with a computer and like, and then just walks you through step-by-step, like how you layer things to, to get to where we're at today. Super interesting. Great for someone like me. Again, you know, I, it taught me all about big O notation, data structures, and well, maybe there's not a lot of algorithms in that particular book, but it does talk about like how to analyze algorithms like we're talking about. Anyway, what I want to highlight is that that book and some others allow someone who has taken, you know, one of these other paths into

[00:17:57] Allan Stewart: the field to quickly get up to speed. And figuring out which things you need and which ones you don't, it is, it's really hard because you do need almost a taste of everything. Just like Dave was talking about, you have to get that breadth so that you understand that there is this really wide world. And you can figure out which things you need to then go deep on. And then there's other things that you just, you don't need to know. I never enjoyed doing proofs in college and I never want to do one again. But on the other hand, there's like this interesting concept. Dykstra talked about correctness of software programs and proving them was something that you get into in education in, in like a computer science degree. And so you do all these proofs, but there's also some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback as some of the feedback you can sort of by induction, go through the rest of your program and prove that it works. And I've had a practical experience of being able to put a whole bunch of unit tested pieces together and get them working in short order. And so I think it's really interesting where it's really hard to draw these lines of what is in and what is out, what should be part of that education and what should not be.

[00:19:37] Dave Adsit: You know, the only thing I like about proofs is that two of the members of my staff were TAs for the class in their college that does all the proofs. And I like to say by induction, we know that just to get a rise out of them, because I don't ever use induction in those assertions. And I'm not sure that I could do so correctly. And I know that each of them has written use induction in red ink on an incorrect proof thousands of times. I do think that unit tests and acceptance tests and basically any other type of tests like this, that we run against a system in its production environment are the only way we can come close to proving the complex systems that we currently run.

[00:20:33] Matt Baker: Yeah, I agree. And I wish this was. Something that was taught in tandem with writing your first line of code, honestly, but I do mentoring time occasionally. And I've been working with someone and now I reach for TDD to like to write the first line of code. Like I say, okay, we're going to write this little function that adds these two numbers. I want to write a test that proves that it worked just to get him used to that feedback loop of write a little test a little. I think that's going to be such a boon for your career if you can adopt that. And I, this. Is one of those things for me that I don't think should come later in your career. I think like I'm saying, you know, day one, you should start writing your code this way. And I've been, you know, coaching people that way a little bit and they respond positively to it. Most of the time. Sometimes it, I, you can see it's a little frustrating for him. Like, oh, I don't want to write a test to test that stupid little thing. Like I want to get on with it, you know, and TDD can somewhat feel like minutiae. But aside from that, it seems pretty good. And I definitely think this is something we should be teaching earlier.

[00:21:34] Allan Stewart: I wish it was something that. I had. Learned earlier as well. I'm pretty sure I took a class in college where we talked about unit testing. We talked about patterns and we talked about agile. But talking about it, experiencing it as part of one class wasn't enough for me to really get the concept. And then the very next class, or even within the same semester, I was taking multiple classes and some other class did not care about that at all. And so it didn't get into my head as this is the kind of a thing you should. Be doing as a discipline. This is how to write code for me. It is now. That's how I write code now. Not, not all the time, not a hundred percent, but generally speaking, I use a lot of TDD to flesh out my code. That wasn't something that was ingrained with me. It was like, it got this little taste of it. But I wish formal education programs would cover those things more as these foundations in every class, you should be doing test driven development or some other kind of. Testing. And I know that they, uh, I have heard it said that these kinds of concepts are slowly creeping into formal education and certainly bootcamps are an example where some of these practical things come into play. But then it's hard to balance them because bootcamps sometimes don't get theoretical enough. And they just, they teach you here is how to node with, you know, your Jasmine tests and your angular or your react or something. We. Gave you a very, very specific tech stack and trained you on that. But then sometimes they don't, the graduates don't understand other just general purpose concepts that turn out to be really important.

[00:23:17] Matt Baker: Yeah. I think there's kind of like a, you remember that movie, the matrix that the whole, there is no spoon. I think there's like a, there is no spoon moment for bootcamp devs when it's like, Hey, you can do it without react. Right. Or you can do it without angular. And, and that's totally fine. One of the things I I've seen with bootcamps is. Like. You said, Allan, you get a very opinionated set of instructions on how to deliver and you get good at that. Like make no mistake about it. You can take that and go get a job with it. Like if you were to just throw a dart randomly at a hundred tech companies, chances are, you're going to hit someone doing a react on the front end. You're going to be okay. But there's also going to be a point where you should step back and try something else or try the job without the tool. Yes. It's true that maybe you would never write a. JavaScript web application. Without a framework, but it's good to know how to do it. Calling back to what we've been talking about earlier. It's like a, maybe like once removed application of knowledge, right? You're, you're not going to do it, but like when that framework blows up on you, um, or you're having something that doesn't make sense, let's say like manipulating the DOM. If you know how the, the quote unquote, bare metal JavaScript in the browser works, you'll navigate that a ton quicker. And I would wager too. You'll be able to make more intelligent choices when using the framework. If you have that backing.

[00:24:33] Dave Adsit: Totally agree with that. I think. That there are a lot of pathways that will teach someone how to create code. There's a lot of ways to learn how to write code. I have yet to find a substitute for experience when it comes to learning how to ship software. Now I think about the assignments that I did when I was in college back in the nineties, every single one of them was disconnected from every single other one of them. You know, there was. There was never like, we're going to build a system and you're going to build it iteratively over the course of 13 weeks. There was just this week. The assignment is this. Build it and sign it off and come back next week for the new assignment and start from scratch and build it and turn it in. That is a very different mindset from delivering a software product.

[00:25:27] Matt Baker: Yeah. Yes, I agree. So I've seen this in both college grads, new, new college grads and new. Who can graduates alike and self-taught people like the chasm between knowing how to write code and knowing how to ship code is vast. Right? So a few things that I, in particular that I mean, we've been talking about testing. It's becoming more and more like a requirement. If you're shipping code in, in a. I was going to say at scale, I don't even want to say that. Like if you're shipping code for a company, it's tested, you know, test your code before you ship it. Don't make your customers test alive for you, but it goes deeper than that. Like for instance, when you're shipping your code, chances are you want to use a CI CD pipeline for it. So you get, uh, hopefully deterministic shipping or more deterministic shipping. Anyway, you're not going to learn that in college or in a bootcamp, but it's critical to the way like modern shops are writing software. You need to know how to use those. Similarly, like how do you monitor the stuff that you wrote or potentially set up alerting? Those are things that you're just going to have to learn on the job. And then maybe a little bit different thing. How do you confirm that what you built is what you're doing? What your customer actually wants? How do you know how often to do that? Like, how do you know how to approach a customer and say, I want to show you this low fidelity mock-up and see if like, you can give me some direction before I go write code. Like those are things you learn after probably screwing it up for a little while, but they're definitely not taught, you know, in either college grads, bootcamps or the, you know, the self-taught individuals. I'm, this is something you just pick up after you learn how to write code.

[00:26:58] Allan Stewart: And in some ways I feel like it can be even worse than that because sometimes the things that these. Formal educational programs, whether it's bootcamp, whether it's college, these programs teach you sometimes are arguably just wrong. This is where Dave's rants that he was mentioning earlier kind of came in. Sometimes what the answer is to get the high score on the test, isn't the right answer of what you should actually do.

[00:27:24] Dave Adsit: I will tell you that in the test I was taking, I knew that the correct answer, according to the computer, when a QA tester finds a. Bug, what should they do? I knew the answer they wanted me to put in was fill out a complete bug report and submit it. And I will tell you, you do that one time on my team and we're going to have a talk about collaboration, communication and getting up and walking over to where the dev is that wrote the bug so that you can help him reproduce it and he can fix it immediately. Because we strive for zero bugs, not. Compliance with the bug tracking system.

[00:28:07] Matt Baker: What about shops without QA, Dave? What about those?

[00:28:10] Dave Adsit: In that case, you turn to your teammate and you say the code that we co-wrote together in our mob seems to have a defect. We should immediately fix it before we ship this version to the production environment.

[00:28:26] Allan Stewart: Something about writing a test to prove the bug and then fixing the bug and then knowing that it doesn't come back.

[00:28:33] Dave Adsit: Something like that. Yeah. Working code is more valuable than a stack of completed bug reports.

[00:28:41] Allan Stewart: Even sometimes the conditioning that you get through these formal programs, it teaches you the wrong thing, that there are right answers. Just that there could be right answers at all. No, incorrect. There are no right answers. It depends all the time because everything's a trade off. You're trading off something to get something else. And that's just how it is. Or that you'll have all the requirements in front of you. Dave and I were talking about how there was a class that he and I both took where we had a very similar experience of not attending lecture and just going in once a week to the lab, looking at the requirements and coding them up within a couple hours. It's just like, okay, done with that class for the week. Didn't do any of the readings or any other things. But that's not how real life works in the industry. You don't have all the requirements in front of you. You won't know what the right thing is to build. There's no test harness or check these boxes and then you've got 100%. That's not a real thing.

[00:29:48] Dave Adsit: As soon as you start pushing your product managers or product owners to complete the developer readiness checklist, you are down the wrong path. You should walk back and remember. They don't. You don't know what's right either. And you need to collaborate on discovering the right solution and probably even collaborate on finding the right problem to solve.

[00:30:13] Matt Baker: Yeah. All this talk of right. You don't mean it this way, Dave Allan. You brought it up in this context. Right. As in like there's a right answer in software as opposed to tradeoffs. That one gets me right in the feels a little bit. Early in coding, I got hooked on pattern books and read a bunch of those. And oh, my God. I must. I'm a miserable person to code with because I would just all day. I'd be waiting for a chance to use the decorator pattern and I would like go through contortions to use that thing. You know, the singleton that was kind of like that was pretty lowbrow. I whatever everyone knew singleton, but decorator like it got me to this point, honestly, where when I would approach a problem, I think, okay, what's the pattern to solve this? And like right there, I'm already in like a hellish place. Right. I'm in this. There's a right answer. I just got to find it. I know that there's the perfect. Pattern here. And it's total bubkis for me. In my case, it was picking up these pattern books and not really like contextualizing them, but just reading them and taking them as gospel. That kind of got me for a few years. And I was actually on a hike with a friend of mine and we were talking about software patterns and I must have been saying, well, I don't know what I was saying, but he made the comment. Like, how do you help people get out of this mindset that there's a right answer? There's a right pattern to a specific problem. And that stuck with me ever since he said that. And I changed that. That helped like precipitate this. You know, what for me is a better way of thinking of, Hey, like there's no right pattern. There's no right solution. Like Allan's saying you just, you bounce trade offs. If you get out of it, not dying and not getting fired, you probably did. Okay.

[00:31:47] Dave Adsit: Well, I mean, that's the whole concept behind best practices, right? Is that some smart person somewhere sat down and thought really hard about a context free solution to every problem. Which is why I. Often rail against best practices because best for what context. In fact, when you talk about patterns, part of every pattern is the context of applicability. That's how, you know, when this pattern is appropriate. Uh, I've heard people say that patterns are discovered, not designed, or they're extracted from multiple co multiple code bases where you are solving similar problems. You get to extract the pattern.

[00:32:30] Matt Baker: And they're like observed, right? Yeah. You just observed. Yeah.

[00:32:33] Dave Adsit: You see the pattern in the software over and over. And I think that everybody who reads a pattern book, which by the way, you should definitely do whether it's you're formally educated or not, you should definitely read a patterns book. Everybody who does will inevitably spend some time trying to figure out where to put a strategy pattern or a decorator pattern or factories. Lots of. Unnecessary factories.

[00:33:05] Matt Baker: The term factory and code for me now is almost a smell at this point. Like if I see a class that ends in factory, I'm a I'm critical.

[00:33:13] Dave Adsit: The next time we work on a project together, I'm going to rename the inversion of control container, the object factory, just to see if you find it.

[00:33:24] Matt Baker: Maybe if you could go with like object factory mother, that would be, then you get it all lumped in there.

[00:33:30] Allan Stewart: Impal. Impal. That's right. One of those bits of context of how you apply a pattern that is becoming more and more obvious to me that that really matters that I don't think I've read in a pattern book is the people. Sometimes that's just glossed right over. If I'm going through Matt's code circa a few years ago, several, hopefully a bunch of years ago where he was writing decorator patterns and I don't know what a decorator pattern. Is. I don't understand it and it doesn't click with me. Then I'm going to have a bad time. And it might actually be a really good solution for the problem technically. But if your team doesn't understand the pattern and why you're using it, it might be worse than something else that you could have done.

[00:34:21] Dave Adsit: Oh, I can't even express the number of times I've run into that problem where someone wrote some really good code based on their knowledge and understanding. And then handed it off to someone with different knowledge and understanding who effectively had to rewrite the entire code base because they could not understand why it was the way it was. Inversion of control is actually one of those concepts that until somebody teaches it to you and you get some experience with it. It's difficult to understand why everything is being passed through constructors and you never call new. And why is this so hard?

[00:35:00] Matt Baker: Yeah. I like that this is an example of a tradeoff. We were talking earlier about tradeoffs. This is a great one. You find a pattern that fits the problem just right. But I love what Allan said here. Amen. You absolutely have to consider the people that you're saddling with that solution. That's one of those things that makes it a more right or less right option. And that is totally absent in any of the code, but it will change context to context. So definitely a tradeoff. That's a. I think we've called out.

[00:35:32] Dave Adsit: I remember a few years ago, Matt, we were at a conference together and we were in a microservices workshop and it was in microservices were so hot. And one of the things that people tend to miss.

[00:35:47] Matt Baker: Wait, they're not. Are they still hot?

[00:35:48] Dave Adsit: I don't know. I haven't been to a conference in at least a year and a half. And so I don't remember if microservices are so hot right now.

[00:35:55] Allan Stewart: They're still pretty.

[00:35:56] Matt Baker: I think if you say. I think if you say event driven. Microservice than your current.

[00:36:02] Dave Adsit: Oh, event driven microservices were the hot new thing. Despite events and encapsulation existing since before most of the people at the conference were born. Event driven microservices were just the rage. And one of the key pieces of context that seemed to go unnoticed was how big is your team or your organization? And. How good are you at doing operations? Are you using infrastructure as code? Are you good at that aspect of it? If you're not good at that aspect of it, and you still treat your servers as pets, maybe microservices isn't for you. I think Allan and I have built some fairly complicated systems together. And we've also significantly simplified some of the patterns we use because of the team that we're working with. Okay.

[00:36:59] Allan Stewart: Yeah. It's something that I had to learn the hard way. Even just about a year ago, Dave, you and I, we had decided that we should use a messaging system. We were using Azure service bus. And for every type of message, we were going to create a separate topic. But unfortunately at the time, the SDK wasn't very forgiving of what you could do with topics in service bus. It might've been two years ago, but whenever it was, I remember we were going through the code. We had to go through the code with one of the other members of our team. And there was a bunch of boilerplate that had to be put into place so that we could use all these separate topics. After an hour or so, I kind of turn and look at this other developer. And in my mind, like we flashed into the old west, Dave and I were on horses and we're looking back at this other developer who we've tied up and dragged through the sagebrush behind our horses at going, you know, as fast as these horses could gallop. He just, he wasn't there. He wasn't ready for it. And honestly, our project wasn't ready for it. We've spent a bunch of time doing a bunch of dumb code that we knew how to do, but it wasn't important. It wasn't getting us any closer to our goal. And so we unwound that. I ended up going in and changing and saying, you know what? Let's do the boilerplate once. And we're just going to funnel everything through a single topic. And now we want to change it again because the context of our people has shifted at our company. And now we really want to go. To using. Multi-topic again, but it wasn't right at the time. And it certainly wasn't right for this poor developer that we gave rug burns to by dragging him along so quickly.

[00:38:39] Dave Adsit: We basically had a big switch and a type for each message. And I know a lot of you are thinking that is a bad solution, but it was the right solution in the context we were in. And if you think that's controversial, let me tell you about the time I used Microsoft access as a backup. I think.

[00:39:12] Matt Baker: I think. I think. I think. I think. I think. I think. I think. I think. I think. I think. I think. I think. I think. I think. what if they hate this? If they hate it and they don't use it, did your solution work? Like, no, of course not. You know? And so I, I think this gets missed a lot. I'm just going back to what Allan said about the patterns book, not calling this out, you know, your technical choices and the social arm of the place that you work, those aren't disconnected. And I think that's what we're highlighting here is that a good technical solution has to, has to include like the social implication. And the example I was giving it's, you know, if you change a tool that someone's using, will they like it? You know, Allan and Dave are talking about, well, if you implement this topic per message pattern, will it be held for that developer that's getting getting dragged through the desert? That was a very like a illustrative picture. Yeah. Those people are there and they're impacted by your choices. You know,

[00:40:13] Dave Adsit: we should be thinking about. So with all of the things that we've been talking about in terms of education for software developers, one of the things that I can't help but think about is the, the value of apprenticeship or mentorship in all of these, all of these pitfalls. If you have somebody who's been working on the project for even a month more than you, they might know some things about how it was put together and why that would help you. And in that case, it is somewhat of a mentorship type of a scenario for you. My dad was a general contractor. And so he always had tradesmen working for him. And in the trades, they make that a very formal thing. and then a master, and you have to have certain amount of time on job and you have to have certain experiences and pass certain tests. I can't help but think that that would be a better way for us to do software education. If the goal is to produce software developers who can create high quality systems, there's just too much to learn all at once in any other way.

[00:41:27] Matt Baker: That rings true for me. Definitely think regardless of how you got where you're at, mentorship and apprenticeship, you're lucky it helped. It's been a part of your career. If not, then seek it out. For me, I jump at these now. If I can, anyway, I'll take someone up on pairing on any project and then I'm sure to learn something from them. And that's what me being mentored has looked like most in my career is just sitting and coding with people who know more than me. And then through the course of solving the problem,

[00:41:55] Allan Stewart: powerful thing. I think some of the skills that I've learned as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these industries as I've been in some of these And so by the time that I found kind of a peer group that I really respected, I was like, oh, these are the people that I want to keep working with. I'd already learned a lot of things, but they did things differently and they knew some other things that I didn't know. And so you can get that with almost anybody that you work with because they have those different experiences and they don't have to know more than you. In fact, sometimes it's okay if they know less than you, like demonstrably less because they'll do something a little bit different that can still teach you something.

[00:42:59] Dave Adsit: I used to spend a lot of time speaking at the local and regional software conferences and pair programming was one of the things I would often advocate. My experience, which is still true to this day, is that everyone on the team knows. Something that the other people don't. Everyone on the team can teach you something, even if it's just a keyboard shortcut or a shell hack that they do that you haven't seen before. More or less, you know, whether you know more or less is less relevant than knowing the right thing in the context that you're in right now. That's part of the reason why I think it's important to have collaborative teams working together on problems. But it's also. One of the reasons why I like to provide mentorship where possible or apprenticeship even. I think that it would be better for the next generation of software developers, not to have to learn everything the hard way, like I felt like I did.

[00:43:58] Allan Stewart: The trouble, I think, is that the demand for good experienced mentors far outreaches the supply. We see in the industry that there's so many people coming in. You know, Stack Overflow does those surveys. Every year or two or whatever their cadence is. And it seems like we're always seeing that there's a lot more people who have been in for a shorter number of years than there are people who have been in for a long number of years. And so that's one of the things that I think gets tricky. We find people getting promoted and they have senior titles at their company when maybe they don't have the experience that makes them sort of globally senior, as it were. And it's so hard. To measure like putting these labels, senior, junior, mid level. They're kind of bogus. But there's some kernel of truth kind of lying under there that they're useful abstractions, even though the model is so horribly wrong. And so I think you have to look at yourself and say, as a developer, can you have that humility to say, am I one of the people who needs to learn more? You've got to check yourself and not assume that you are a really great developer and know a lot. And on the flip side. If you are a new developer, you know, that can be kind of scary because it's hard to find the right mentor for you. But on the other hand, just because somebody else has a senior title, that doesn't necessarily mean that they know it all. You don't have to be overly intimidated by them and just take whatever they say at face value because they might not be right.

[00:45:33] Matt Baker: I think it's good to highlight that mentoring is a skill all on its own. You can be the best software engineer around that doesn't have any. So there's a lot of applicability to how good you can mentor. I think I'm thinking of when I first started mentoring, how much of I was very sure of myself on certain things. And I'm, you know, looking back at those times, I feel bad for the people that were on the receiving end of it because sometimes, you know, I was not a good mentor at all. And it took me a little while to realize, like, hey, you know, this coding stuff real well doesn't mean you know how to tell other people how to do it. And so I had to go out and start reading some books and do some soft skill stuff and get good at that, you know, as an extension of my software. And who knows where I'm at now? I'm definitely not saying I've got that thing down, but I just want to highlight that it's a skill. You know, there's good mentors and there are bad ones. And just like Allan was saying, you check yourself with your technical knowledge. If you're the senior engineer on a team and you're treating everyone like crap, like check yourself a little bit, you know, and remember that part of your job as a senior is to figure out how to effectively mentoring. And that looks like taking care of people. I'm sure we all know the person who jumps at the chance to tell you you're wrong in the meetings or coding any chance you get. And I'm sure we all know the senior person that does that. I'm sure we've all been that person.

[00:46:46] Dave Adsit: Everybody really appreciates that person too, right? You're like, oh, thank you for helping me feel worse about myself and the coda that I produced.

[00:46:54] Matt Baker: Yeah. It's like, we pretend they're like, oh, you've illuminated me. I'm going to take your like lashing away and like go incorporate it into my learnings. Like, no, you made that person go like drink an extra beer. Get a little angry that evening.

[00:47:10] Dave Adsit: You pushed that person one step. Closer to sending their resume. So one of the things that we are kind of dancing around, but haven't really stated directly is that education is a lifetime pursuit in software development and many other fields. You don't just do it at the beginning. And you certainly don't just buy whatever education is for sale and expect that to be sufficient to what your needs are. I'm really glad that there's a lot of options now from go buy a couple of books and be self-taught to go get a university education for who knows how many tens of thousands of dollars to go get a bootcamp education in significantly less time and somewhat less tens of thousands of dollars. I think all of these are great options, but I do think it's important to remember that you can't just buy your way into. Knowing software development and you can't just do it at one point and be done.

[00:48:16] Allan Stewart: And sometimes you have to just fill in the gaps. Sometimes what's available or what's for sale educationally is not exactly what you need, but it still can be really useful. There's still value there. And so it becomes like a question of what progress can you make looking at where you're at now and say, well, where was I so that I can understand, am I progressing? And then how do I go forward from here? It reminds me of a story that's written down in the book. This is lean. There's a factory and they really wanted to prove that like they were the best at lean. And so they got one of the guys who was involved early on at Toyota, the Toyota production system or whatever that was called. They bring him and they show him all these parts of their plant. And they're like, oh, look how great this is. Isn't this isn't this good? We're very proud. And. And he would just say, interesting. And so they show him around some more. It's like, OK, well, this was this impressive. And he just says, interesting. And finally, they ask him, it's like, well, look, what do you think? Are we the best at lean or not? And he says, it's impossible for me to say I wasn't here yesterday. His point being, of course, that you have to measure that progress. You have to look and say, am I progressing? Can I look back at yesterday and see where where am I lacking so that I can go forward and do something, something to learn, something to improve myself into tomorrow? It's really important when you're getting started because that's what you've got. You don't have the experience to draw on. You can't pull from your past as much. And so you're really eager and it's necessary to get a lot of that education up front that puts you on the path. But eventually you just have to kind of walk that path for a while, build up that experience that teaches you what it is you need to know. And then you have to look forward and say, there's still something else for me to learn that would be very helpful for where I'm at. I've never met anybody who wasn't that way. And the people who thought they were, I think, are the same people Matt was talking about that he didn't like working with.

[00:50:33] Matt Baker: Yeah, I really like that lean story for me. It helps me when I get overwhelmed. I'm overwhelmed with having to go learn a thing. Like some of these topics are big, they're heady, they're going to take you a long time. And it's hard. But what I like about that lean story is that it kind of frames in a way that says, look, be better than you were yesterday and you're on the right track. You know, having said everything we've said about college boot camps and being self-taught, I just want to say for the record, if I had the chance today to maybe pause my work life and go to college, I would take it in a second. And I'm jealous of those. I think that the college experience like outside of tech at all sounds interesting. But then specifically being able to spend all that time in a classroom, poring over some of these subjects with peers. I got to say that sounds pretty great. I'm sure that there's a lot of crap that comes with it. But I just want to say for the record, I would take the chance if I had it right now. And I really admire people that put in the work.

[00:51:31] Allan Stewart: Well, with that, we will wrap up our topic for today. And as always, recommend that you join a community of professionals. By attending a software crafters group or meet up near you. Here in Utah, the Utah SC group at utahsc.org meets the first Wednesday of each month in Draper. And we hope that we will educate each other there.