Crafting Code Podcast

[00:00:00] Allan Stewart: Welcome to Episode 5 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 considering balancing technical health with building product features.

[00:00:16] Dave Adsit: I'm Dave Adsit, CTO, and recently I have been concerned with value creation and pricing models.

[00:00:25] Matt Baker: I'm Matt Baker, software architect. Lately, I've been thinking about Kotlin.

[00:00:29] Allan Stewart: And for today's episode, we are going to be talking about practice and play. So what is practice in the context of crafting code, and why should we do it?

[00:00:40] Dave Adsit: So I would say that practice is any software development activity that you do that is not directly related to delivering a production feature or value or project. So there's a lot of things that I would include in that, like learning about a new library or toolkit, I would consider to be part of practice, for example. You know, writing a bunch of tests against something in order to understand how it works. Exploring an API or, you know, writing a toy project for your own learning.

[00:01:22] Matt Baker: Practice and play definitely can become blurred for me. An example of that, I was... interested in learning a bit more about Kafka, so I started implementing the wire protocol. Not in any sort of full manner, but just enough to understand how it worked and see it come to life myself. And, you know, I was doing that to practice to better understand it for some stuff at my job. But it also becomes play, you know, because that stuff's kind of fun. It's fun to see how Kafka exchanges its binary format across the wire. And so they're both distinct. Yes, absolutely. There are times where I practice and I play. But then also sometimes I don't. Sometimes I think fortunately they become both.

[00:02:02] Allan Stewart: Yeah. And when I think about why practice, it really comes back around to a couple of ideas for me. One of them is to develop skills. Sometimes it's a new skill. You know, want to try something that I haven't done before. I want to explore a technology or a practice that I've never done. But more often than that, it's kind of refining something that I've already done before. Can I do this a little bit better? Can I make sure that I understand it even better? Is there a practice that I can take up to 11 and just dial it all the way up and say, hey, I'm going to be super strict about this practice so that I understand really clearly when I want to adhere to that practice and when I want to divert away from it and do something a little bit different.

[00:02:49] Dave Adsit: I think that one of the things that comes to mind most readily is the idea of a code kata as a form of practice. We borrow. We borrow this idea from martial arts that you use a kata or a set of specific instructions that you follow over and over and over until you can do it very well. Probably 10 years ago or so, it was popular for people to practice a kata to the point where they could perform it to music. You know, solving a simple little programming problem that's three to five minutes long and you play a song with it. And you have done it enough times that you aren't making missteps in your keystrokes and your tests are smooth and clean. And you stop thinking so much about the code itself and start thinking more about the method of delivering value or the flow of the experience. I think that that has mostly fallen away. At least I haven't seen it in a while, but it used to be popular for a minute.

[00:04:04] Allan Stewart: Well, depending on your circle, it may still be popular. I think if you're a rock star developer, you're probably doing a lot more music than some others. Indeed. You know, as midnight takes your heart and your soul and your heart is as high as your soul, put your heart without your soul into your heart. Things like that. Things like that. Power ballads. As an example. As a wild. Just to take a random example. Whisper my world.

[00:04:33] Dave Adsit: Yeah. Yeah. I've got to say that is definitely an area where things make the jump from practice into play. When you start dabbling in languages like Rockstar so that you too can be a Rockstar developer. It really does make programming into a kind of a fun puzzle. Yeah. Right. It's less about X and. I and business user one and invoice three. It's more about like, what were the types of things we were doing back in the day when we first got into computing and we were trying to hack our games and make them work better or, you know, invent cheats and things like that.

[00:05:17] Matt Baker: Yeah. I, uh, I think some developers are fortunate enough to be passionate about it and I think that can really help out. I'm, I'm thinking of a, uh, an engineer that my friend commented on recently. He, he watched him code for a little while. And, uh, afterwards he came to me and said, you know, I'm just, I'm so impressed with this guy. Cause he didn't have to, he didn't open Google once. He knew everything. Like there were two people coding and he knew every answer to every question the other person had while they were coding on this particular, um, uh, language and kind of stack. And, uh, so anyway, my friend said, I just, I've never seen someone code like that. That was really impressive. And I thought, yeah, that is really impressive when someone never opens to go to stack overflow. You know, stack overflow is great, but, uh, if you know all that stuff that if you know enough to not have to open a browser and you're coding, that's impressive. And I think that it's also a way to, uh, be more successful in your career. You can, you can ship faster when you can work that way. You can also, um, get better jobs or at least, uh, have more jobs at your disposal when, when you're that good. And then typically I think people get that good just over time. You know, when you write code for 15, 20 years, you're going to be put to work. But I, I wonder if you can short circuit that process by practice. You know, I wonder if you could say, well, you really know a lot about maybe iPhone apps after you've made a hundred. So one way could be you do a hundred very naturally in your career as the opportunities arise and you get there eventually. Another maybe way that, uh, maybe is a dumb idea, but could yield some fruit. What if you did an app?

[00:07:28] Allan Stewart: You know, the iPhone came out in 2007. Maybe you did some BlackBerry coding back in the day, but it's pretty different from what we have now. The paradigms and things have changed. And so I don't think you can wait around. Like the industry will have changed by the time that you've gotten enough practice by just doing your day job to get to that level of skill that you're talking about.

[00:07:48] Dave Adsit: Yeah, I think that there's something very key in there. So I've heard that a strength is defined as an aptitude plus an interest. So it's not just enough to have aptitude and it's not just enough to have interest. You have to actually have both together to create strength in some kind of a theme, right? And I've gone to a lot of code retreats, Global Day of Code Retreat, other code retreats at conferences, et cetera. And it often surprises me how many developers don't remember how to start a new project in the language they code every single day. And sometimes they don't remember because it's so simple. Touch a new Ruby file and touch foo.ruby and you are off to the races or foo.rb. But sometimes it's because they only ever work in the same program, in the same big old monolith day after day after day after day. And so they know they're part of it, but they don't ever reach outside of that space. And so those skills start to atrophy. I agree.

[00:08:56] Matt Baker: And they... They are doing something. They're getting really good at the thing that they're doing, right? Like be it the monolith or this thing. And so you kind of have to ask yourself, is this the thing that I want to get really good at? Yeah. Like, is this the tool that I want or is this the only tool that I want to be able to offer for sale, which is essentially what we do. We go out and we develop these skills and we sell them. I think what you're doing in this example you presented, Dave, is really getting good at something that might not be transferable past that employer. Or maybe it is... Maybe it is to a degree. But like, what if you also, in addition, every morning as you had your coffee for 10 minutes, created a program that added some numbers together or did something, right? Like what if you did a little puzzle every day too? Maybe you go to Project Oiler or you go to like... Yeah. We've talked about a few of these websites where you can get toy problems from. You can do those and do that every day for two weeks and then consider how good you are at starting a new project.

[00:09:54] Dave Adsit: Right. Well, and the thing is... is that the developers that you run into at something like Code Retreat or a conference, those are people who are reaching. These aren't people who are just content, but they are actually actively doing something to learn some of the limits of their skillset, whether they intended to or not, they are learning. And so they get an opportunity to identify an area to practice. As you were talking, I was like, oh, math, Project Euler, obviously that's the one to do. And then you get to learn not only the limits of your programming ability, but also the limits of your math knowledge. Pretty quickly, it turns out.

[00:10:35] Matt Baker: One of those is much smaller than the other for me.

[00:10:39] Allan Stewart: You guys are reminding me of all kinds of things from my college days. I remember I took a bunch of math classes and a bunch of computer science classes and the math classes got harder and harder. And the only reason I ever passed calculus too was that at the beginning of the semester, it was packed. The room was like, there were not enough desks for the people standing in the room, but the teacher didn't seem to mind, didn't seem to think that was important. And I found out why, because at the end of the class, there were only like seven people that were still attending. And I'm certain that they held down the curve for me. But I also think about it in terms too of, Dave, you were talking about interest and aptitude. There were a bunch of people in those days, that would ask me about coding. I think they would get kind of in their major, they were getting to the hard parts and they're starting to think, well, I don't know what I actually want to be when I grow up. And so maybe I should investigate this code thing. It seems like a lot of people are talking about that. And so they'd ask, is this something I can learn? Yes, absolutely. I believe that anyone can learn how to code. It's sort of like that thing from Ratatouille. Anybody can cook, but not everybody is a great cook because it takes some, some, some, some aptitude and it takes some diligence, right? So if you've got some natural aptitude, that's great. You can get really far on that, but you probably need to practice to refine it. And if you don't have the same kind of aptitude, or if you are lacking the interest in the project, then you've got to double down on some of these other mechanisms for practice, for learning, if you're going to be able to succeed, because it's, it is a very tricky combination of art form and exacting, and acting science where the computer will do precisely what you told it and nothing else.

[00:12:30] Matt Baker: You know, I've been playing this game. I've mentioned it a few times. I'm just obsessing over it in small increments. As you're playing the game, you're, you're sort of competing against people. And then it's a five minute round and, you know, at the end of the game, you're done. But in the round, you get to observe all the ways in which you screw up. You know, if you do some things wrong, you'll see it in some replays and stuff. And so when I play it, I see, you know, I'll watch a replay and see one thing I did wrong. And then I'll just go into the free play and I'll do that thing 10 or 20 times. And I might do that each morning for a week. I really get into it, man. But at the end of it, you know, I've got the skill, then I go back into the game and I deploy it and it works. And I get super excited and I go back and I do it again. You know, it's a real good feeling. And I think we do a real similar thing when we code. You can find these spots that you're weak at and you can practice them. Like if you, maybe you are really good at lots of things, you know, but you struggle a little bit with SQL syntax, let's say. You can isolate that in practice. Every morning, you know, you can take 10 minutes and it'll do wonders for your confidence on the job. Like wonders, you know, and you will feel, you'll feel strong in your position when you say, you know what you know, and you'll be able to navigate better if you're struggling with SQL skills. And I think it's very, very serendipitous and nice when you also are passionate about SQL syntax. But that's not always going to be the case. Sometimes you're just going to have to force yourself. And that's what I heard you say, Allan. Sometimes like the passion and the ambition isn't there intrinsically, but you got to do the job. But you can still isolate and practice to get through it as painlessly as you possibly can, you know? And I think that's valuable.

[00:14:16] Allan Stewart: Yeah, some of us are passionate about SQL, but still also angry that they called the project operator select. Yes. Yeah.

[00:14:25] Dave Adsit: Let's not get started on domain specific languages and how ineffective they are at teaching receptionists to code.

[00:14:39] Allan Stewart: As we talk about like these different ways that we get into practice and how it often blurs into play and the distinctions between that and work, I think maybe that is why sometimes some people have a hard time. with practice at the coding level. I know for example, as when I was in high school, I would finish up my code projects real quick so I could spend the rest of the day with my best friend writing stupid computer games instead of, you know, the assignment that we were given. Cause I was done with it and he copied from me. And so we were both done. And then we would play. And so I can understand why some people would balk at the idea of, well, are you actually working? Like, should you be working? Like what? What is the value of that?

[00:15:24] Dave Adsit: this thing. I think that part of that comes in developing enough skill so that you can enjoy your actual work. I find it hard to believe when Matt says it, that not everybody is passionate deeply about sequel, but it turns out that I've met people and they're not. What? I was just bluffing. I'm glad that was true. So you can develop an interest in something by getting just enough skill at it that you're starting to have some success. And that kind of creates that feedback loop of success brings excitement, brings practice and trial, which brings success, which honestly, I never got past that point with piano lessons. I never got to the point where it was fun. It was just always tedious and hard. I never could do what I needed to do. And so I quit. But when it comes to software development, it can be really fun. There's a lot of ways that we play or that the groups of people that I hang out with play when it comes to code. We've already mentioned Project Euler, which can be fun and frustrating at the same time, depending on how much math background you have. There's other things like exorcism.io. And that one, you just pick projects or whatever. The little activities are that are at the level that you want to practice and interesting to you because there's a lot of them, right? It's not just a linear progression of hard to very hard to I should have dropped out of math way before I ever learned how to do this. So recently we started doing an exorcism team at work and it was fun to just throw some stuff together and then look at Other people on the team came up with and give each other feedback on, oh, I like what you did with this one. I hadn't thought of solving the problem like that, that kind of thing.

[00:17:34] Matt Baker: That's when it kind of turns into play. Dave, your story reminded me of an experience I had at work a few jobs ago. It was a place that had just started doing some mob programming and they had setups for it. They had TVs. It was a good spot. And I was working on a team that, I don't know, a little bit tense. I was struggling a little bit. And the org wasn't one that was much of a practice org. They did katas occasionally, but it really wasn't there. So I had an idea to do a kata from exorcism and we did it. And it was the whole time we were doing it, it was kind of being poo-pooed by everybody. They were like, why would we practice this? And like, why we were writing a function to calculate whether or not what given year was a leap year. And they're like, that's the dumbest thing in the world. Why are we going to do that? It took us an hour to do it. And then we had to write a function to calculate leap year. Most of the time was spent arguing. And at the end of it, I realized what started out as play became practice and as practice that taught us how ineffective we are at communicating as a team. And all of a sudden it was a really interesting moment for me where I thought, whoa, so we just isolated a thing that a team does all the time, code, you know, and deliver something. And we isolated that into a tiny little thing, right? A leap year function. And we went through the process of shipping that. And what should have taken five minutes took an hour because we couldn't talk to one another. And there was all this, and it unearthed that. And I had one of the team members come up to me afterwards, pull me inside and say, hey, you just showed me why our team is struggling so much. And I hope you keep doing that. And I thought, oh yeah, absolutely. I felt the same way. And it's just an interesting example of, you know, both practice and play at work, you know, being rewarding, not only for the team members, but for the bottom line of the company, because that team, that team straightened up and they started shipping better and, you know, it definitely worked out well for the business. That's awesome. Definitely experienced things like that too.

[00:19:30] Allan Stewart: Mob programming can be exhausting. Same with pairing. You know, you do a lot of interaction and you just, you get worn out at the end of the day. And so when we think about, you know, some other areas where people do practicing, you know, it might make sense in other disciplines. You say, oh, well, obviously athletes have to practice because they need to work on their teamwork. Well, like your story showed, you know, you might need to work on your teamwork in a team that does code. Athletes might exercise to build up their endurance or train their muscle memory. Well, we need endurance. There's plenty of times where I've ended off the day of coding, whether in a mob or whether just solo where I'm just exhausted from all the mental effort, you know, even though I've just been basically sitting or standing around my desk.

[00:20:19] Dave Adsit: And I think that one of the interesting things about, you know, practice is that every time you do it, it starts to get easier to do the same thing over and over. You are, you're building those mental muscles for lack of a better metaphor. When we practice, we make every future thing easier. And I think about like your, your model of the athletes or the musicians or whatever you, you practice to get better at certain things, like some of the fundamentals. We do TDD practice a ton at the Utah SC meetups, right? Almost every time we do TDD or pair programming, often both. And, you know, there's a lot of people out there that don't have any, they've not developed any talent or skill at pairing or mobbing remotely because it never mattered until 2020. And so you can, develop brand new things through practice outside of your work hours. And that actually makes it safe to fail. Practice is a place where to me, it's safe to fail. None of us wants to fail on the job, even though we definitely will because programming is complex.

[00:21:44] Allan Stewart: And that kind of leads into a discussion about when is it practice? And when is it for real? Oftentimes the opposite of practice is defined as the performance, right? So if you are a musician, you do a lot of practice so that you can get up at Carnegie hall or wherever and perform to your best ability. And oftentimes we talk about, you know, the job you are working and getting paid money. So that, that is where you are expected to perform. So you need to do the best job that you can.

[00:22:15] Dave Adsit: So I have done at various points in my career, various, intentional practice. Once upon a time, I was one of those developers who had no idea how to start a new project. And then I created a whole bunch of projects from scratch, little command line apps, little, little desktop apps, whatever, until I knew how to do that in the toolkit that we used. And I had a similar experience learning shortcuts. I worked with somebody who was playing the role of coach and he took away my mouse. He's like, learn how to use your IDE. If you can't use your IDE well, you can't perform well in the role. And we did that on the job at the office while pairing. And that was, that was practice, but that was also performance. And so it got all kind of muddled. And I think the thing that for me is the biggest difference between the performances that we do and the performances that a musician does is that, they get one shot at doing it well in front of the audience. And we get a lot of shots. We get to take a lot of shots and eventually the compiler and the test suite will tell us you did it. Now ship it to staging and let's see if you really did it. Right. And there's, there's a concept there around risk and reversibility and all these things that is key to when the performance becomes, critical.

[00:23:51] Allan Stewart: I like that. And it makes me think about the role of leadership in a software development team. I mean, I want the developers on the teams that I'm managing. I want the people that report to me to be doing their best work, but I don't necessarily expect them to be on their a game all the time, you know, all eight hours a day, 40 hours a week. And so, because I know that practice helps, I am willing, I actually, I actually want my teams to do practice and not every employer is going to be that way. I think that some of the best ones are some of the best employers are going to recognize that if they allow the team to spend some time practicing, they're going to hone those skills. They're going to get better. They're going to find those places where they can innovate in their process and come up with new ways, better ways of doing things. And so I think that's fabulous, but it does remind me. Yeah. In the book, the software craftsman by Sandra Mancuso, he talks about practice and also this concept of who owns your career. At the end of the day, you have to think about, do you own your own career? Do you need to do some practice for your own sake? How's that going to help you as a professional? How's that going to help your employer? Because not every employer is going to give you the time on the job. And maybe it's not because they don't want to, you know, sometimes the realities of business. Yeah. Get in the way. It's like, oh, well, sorry, you can't practice today. You can't practice right now because we need X or something else is going on that is preventing us from doing that at that time.

[00:25:31] Matt Baker: This one's interesting for me. I agree with what you said, Allan. I also agree that those are some of the best employers. I think if you can find an employer that is going to turn a blind eye to the, I'm bending it a little bit to what I'm going to tell, but one mark of a really good employer for output and judge you on that. Assuming you're not doing anything, you know, questionable, but assuming you're not hurting anyone, breaking the law or anything like that, you know, you're there, you're being paid to deliver. And if you can find a place that'll pay you to deliver and not try and control the way you deliver, try it out. You know, I worked at a place one time where we, my pairing partner and I decided that we were going to, we were going to work in tiny increments. We saw that like, you know, tighter feedback loops and smaller iterations were, were effective. And we thought, well, how can we take this to the extreme to find the boundary? So one of the ways we did it was for a little while, we coded with this pattern and the pattern was we'd start coding, you know, we'd start, we were in Git. So we'd start our, we'd open up our Git repository and start coding. And we'd also have a timer. And if we committed the code we were working on, we would reset the timer. If the timer reached 10 minutes, meaning that we hadn't committed in 10 minutes, we would run a Git reset hard and delete all our code. And then we'd go again. And we would go and go and go until we got what we needed to, we learned how to express what we needed to in a little bite-sized chunk. And I, I swear up and down that coding that way on that code made better code for that employer in a shorter amount of time. Absolutely. We got the job done quicker. We knew the problem, a lot better, a lot quicker. And the code, when we eventually shipped, it was pretty tight. It was tight enough that, you know, you had to be able to write it in a 10 minute window. And it, again, it's this concept showing up where we were practicing. We, but what we were practicing was expressing the business problem. That's what we were being paid to do. And that's what we were practicing. And by the end, boy, we could express it better than anyone else there. I believe that particular problem we knew inside and out because, we got punished every time we did it in that 10 minute thing. And so you had this practice and that's also absolutely play. My pairing partner, I'm a pretty playful person when I work and my pairing partner was as well. And so we did, we coded well together because we both just took it lightly and had a lot of fun with it and also delivered. And just for the record, that project went off earlier than scheduled without a hitch. It went really well. The whole thing just to comment on, you know, the way that work might go, but, or the way working that way might go. That's an example of it. But anyway, I'll, I'll, I'll put a ball on that and say, that's an example of taking care of your employer, doing the best you can for them while practicing

[00:28:28] Allan Stewart: and playing. That's excellent. And employers want the things that come out of practice. They just don't always recognize that practice is the way to get to that outcome. Right. So like there's a lot of companies that talk about the need to have slack time, or we need to have more innovation and, you know, come up with clever ideas. But if, if you're not allowed time, that's not going to happen. I worked at a international big company. And I remember one time we had a big internal conference and people are flying in from all over the globe. And, you know, one of the leaders pretty high up in the company was saying, go out there and do some good stuff. And she's talking about like, build your, your pet project, your skunkworks project, and it'll be okay. Beg for forgiveness. Don't ask for permission. And, you know, this was a big company thinking, in this way, because they were craving that kind of innovation that comes from practicing from learning, or even just like you were saying, Matt, being able to understand the business

[00:29:29] Matt Baker: problem inside and out. Yeah, I, you know, I'm going to speak just in broad generalities, it could be condemned later. But I want to highlight something. So many employers spend so much time trying to figure out how to motivate their employees. So much money. Spent on this point. I don't know how much but I know it's a lot. And I want to just say something to them. You can find people that are intrinsically motivated to do what they love, which also happens to be the thing that you need to pay someone for. They exist. You know, there's people out there in each discipline that's needed to ship software, not just the code. There's people in product that are that way. There's people in design that are that way. You can find them and put them together they're motivated by just a desire to excel at what they do.

[00:30:55] Dave Adsit: It's a lot easier to stop demotivating people than it is to motivate people.

[00:31:04] Allan Stewart: Yeah. Maybe you don't need a whole hackathon or hack day or whatever. Maybe you just need to tell them go and code up the bowling kata. Yeah. Or yeah, there's a lot of, there's a lot

[00:31:17] Dave Adsit: of ways to have fun at work and play at work. We've done more than once a mini code retreat internally. You know, you get the developers together and you say, Hey, we're going to do a code retreat. Maybe it's the whole day. Maybe it's half a day. It's more fun if you can get to the whole day because you get to try more things, but we're going to do the same problem six or seven times in a row. Thinking through the problem isn't the problem, We're going to apply constraints. We're going to take different practices to 11. You know, that metaphor from that mockumentary spinal tap and, you know, we're going to take something that is a good idea. And the more you do it, it's a better idea becomes. And then we're going to take it so far that we break it. Like one of the constraints, a code retreat is almost always no function can be longer. than two or three lines of code. And then you do that for 45 minutes and you see what the limits are of small functions, small functions being better than big functions, but there's probably a power law distribution. So if you just only do small functions, you'll find out where small functions breaks down. And there's a bunch of different constraints that you can do there. Right. And there's some that are common and some that you only encounter once or twice. But, you know, that's the kind of thing where you play with the idea enough that you actually get to understand where it's useful in your production work and where it's only useful in play. I really like going to the Utah SC meetup because I know that at least once a month, I'm going to write code on something that's just for fun. At the end of an hour, I'm going to throw it away or never look at it again. Or I'm going to go home and keep coding on it furiously for the next three or four hours because I want to see where it goes. Right. It's just play, except that I come away from every one of those experiences with more knowledge and better opportunity. I had never written a Diffie-Hellman implementation until our meetup this month. And I would say that I'll probably never do one again. And if you ever catch me trying to put one into production that I wrote, I want you to take away my keyboard and tell me no. But I felt like I learned some cool stuff and it was interesting.

[00:33:58] Allan Stewart: Don't write your own crypto, kids. It's a public service announcement.

[00:34:03] Dave Adsit: Also, that PSA applies to adults and anyone with a team of less than about 50, because you're going to do it wrong. It's going to be real bad. But this time.

[00:34:20] Matt Baker: This time it'll be different. You know, I've been thinking a little bit about, rather, over the holiday break, I've been working on my home a little bit and, you know, I was away from the computer and doing other stuff. I was tearing up some tile in my kitchen. And it was interesting. I read about it online and everyone said it was a big job, super dusty. You have to do all this prep work and then try and get it done in a day. And none of that sounded like anything I wanted. I wanted to take it slow a little bit at a time and get it done in months, not days. And so I started to think about the problem. And at some point in thinking about the problem, it became a shipping problem where I realized that I wanted to be using the kitchen while also refactoring the kitchen. And I know how to do that. One of the things I need to do is keep it all as green. Okay. Well, so to me, that looked like I take one tile out at a time. And every time I create a little bit of a, like dust from hammering, I vacuum it up. So I don't have to like tape everything off. And I work in the small and the kitchen stays usable and I'm getting what I need out of it. And I think anyone in life is going to learn that lesson. However, they're going to learn it. I happen to learn it through coding first, that idea of keeping things green, keep them usable while refactoring them. And it showed up somewhere else. And, and it was just interesting. So it was cool to be able to practice a programming skill in a completely different detached domain, you know, hammering tile and tearing it up. And it was, and it worked, you know, my kitchen's slowly being relieved of tile.

[00:36:00] Dave Adsit: Question is, will you be able to do that in reverse when you get to the next step?

[00:36:06] Matt Baker: No. So I will not be able to do it in reverse. Speaking of working on my home, I've been trimming some trees and this is new, new thing to me. I've never trimmed trees before. Uh, in any meaningful way, but I'm trimming a lot of, uh, uh, uh, a handful of trees now. And over the break, I was doing that and the first tree I did went okay. And the second tree I did, I climbed into it and I had my headphones on, uh, and I was, uh, I was cocky. The first one went all right. And so I was like, I've got this, I was listening to kind of fast, aggressive music and just zoned out and started trimming a tree. And I while trimming that tree out of this tree and look at my progress because I can't tell I'm I'm I actually was up I climbed up into the tree um and was cutting branches off above me which is probably a huge like no-no in the arborist world but here it is I survived eventually I got out of that tree and I stepped back and I looked and I thought okay and then my wife came out onto the porch and she said so are you just going to cut it down now and I said okay I think I might have gone overboard I cut pretty much every branch off that tree I cut the main limbs like it's down to a nub it's in trouble and so I spent the morning thinking about why that happened uh and what took place that I didn't you know catch and I ended up texting Dave about it a little bit and I I it showed up for me finally as this idea of planning I in software I tend to err on the side of less planning and so when I headed towards the tree I thought like planning sucks it's Saturday I don't want to plan I'm just going to go for it that was not the right choice so so the question became well how what criteria do you use to determine like degree of planning what model can you put something in to make that decision like how should how can I be better next time you know other than just knowing not to do that is there a way I could a framework for that decision that I could use uh somewhere else and so I looked back to coding and thought well planning yeah and so Dave and I were texting back and forth and the conclusion we arrived to mainly is that the point point point point point point point point point point point point point point point point point point point point point point point point point point point point point point point point point If you cut that tree too much, you can't reverse that. You can't glue those limbs back on. You have to plant a new tree. That's a capital H hard thing to do. Maybe while you're trimming, step out after every few branches and look at the tree before you give it a lobotomy. And then it feeds right back into coding, right? Like that spurred a conversation with Dave. Now I have this like model that I'm going to think about the next time I look at a problem and think, all right, like how long do I need to spend planning this? Well, how hard is it going to be if I get it wrong? If the answer is not hard at all, I'm not really going to plan as much. You know, I'll plan, but it's just not as much. But if the answer to the problem, how can I reverse this? As you can't, you'll get fired or you'll can't, you'll cost the money or the company a lot of money or something like that. Then I'm going to take a bit more time. And that model came from practicing coding, not coding.

[00:39:33] Dave Adsit: Yeah. The way I think about that is there's things that you can do that are low risk. Like the final production is high risk. I go back to the space program. I think about putting three men in a steel tube and throwing it at the moon and hoping that they'll come back alive. I'm going to practice as many of those steps as I can ahead of time so that I get good at them. I'm not going to take my very first rocket and put people in it and hope, right? I'm going to send up as many rockets as I think I can afford. for real. I want a certain number of successes. You know, we look at the, the SpaceX and they've had a lot of rockets explode, but typically they explode after the point where they learned what they were hoping to learn from that rocket, which is good news because if it explodes before you learn the thing, you're out of rocket and you didn't learn anything new.

[00:40:34] Matt Baker: Well, you learned. It's just not what you wanted. Well, you learned.

[00:40:38] Dave Adsit: You learned something. It wasn't what you were hoping to learn. It wasn't, you didn't answer the question that you started with. You still have that question and probably a lot of other questions, right? So practicing actually increases our skill and gives us the ability to do things in a more reversible way. Like if you have higher skill in coding, you don't have to worry quite so much about reversing the decision you made. First of all, if you have high enough. Skill and coding, you know that you put everything in source control and one get reset hard later and you have done away with all of that mistaken code that you were working on locally that you haven't pushed yet to the rest of the team.

[00:41:25] Matt Baker: There's something there that you said, Dave, that's sticking out to me and this idea that success can look like learning what you needed to before failure. And I don't know how to apply that, but that's really interesting. So I'm just going to have to think about that a little bit. You know, I'm thinking about the engineer that we've been talking a lot about senior engineers. Maybe this is where I want to go with it. And, and the skills you develop over time that does nothing for the junior engineers or the new engineers. And as I start to think about them, maybe one of the things. Nope. Right off the cliff. I don't know where I'm going with this. Cut it all out.

[00:42:02] Allan Stewart: I like what you're starting to say there. I think there's an application. Practice. Practice and reversibility. That's what I want to say. So oftentimes as a senior developer on a team, you'll just want to tell people, well, just do it this way because it's the right way. And it's can be hard to explain why. And the junior developer, you know, it's not very helpful to them to just be, be told that. But what they need is practice. At that point of time in that production code. That's maybe not. The right place to practice your new idea or learn this concept that the senior engineer already understands really well, because you are launching your people to the moon now. And it's not a good time to try a new rocket booster. That's right. But you can move it over and you can say, okay, look, if we do a code Kata, if you do an open source project, if you do a pet product, these are all places where you can safely experiment to start building a new rocket booster. So you're building up that ability. And I think if you are a good senior developer who cares about mentoring the people in your team, you need to look for those opportunities to stop down and say, okay, I'm sorry. I had to tell you that this is just the way we're going to do it. But now we're going to go and practice so that in a safe space, a reversible space, we can understand why we did that. And then that helps them gain the experience so that they're no longer a junior developer, or at least not in that area. And they've grown.

[00:43:38] Matt Baker: I really like that. You know, I think of another thing, a junior developer, someone who's growing or maybe just hasn't acquired the skill can practice is just this consideration for reversibility. You know, sometimes I like to call this intentional engineering. So often I feel like engineering, I'll say a typical company, it's like people sort of mashing the keyboards until it works and then shipping. And I don't mean that they're just, I don't mean that so hyperbolically. But sometimes when I've coded with people, it's like, oh, well, try this. Did that work? No. Try this. Did that work? Restart it. Clean the build. That work? Okay. Something works, ship it. Those environments exist. So what I want to say is when you do intentional engineering, you are intentional in your decisions. You know, every, every move you make, you, you have a rationale for it. You say, well, I want to test out this. I'm going to do that. So what I'm trying to say is one thing you can do is practice observing the reverse. The versatility of the decisions you're making. When you are an engineer and you come to a variable name, let's say, and you're been engineering for two years, you might be tempted to spend quite a bit of time naming that variable. And you should over time, but, but it's easy to change. So maybe you don't have to spend it all right there. So that's a decision, right? You're making a decision. What should I name this variable? Should I spend the next four hours thinking about that? Which I think some people have. What I'm saying is maybe you don't have to. Cause it's reversible. So maybe the planning on that variable, name it just foo, or I don't know what to name you. And that's going to be uncomfortable at first, but it will keep you moving. And then you can come back later and change it. Whereas other things like, uh, if you're logged into a customer's production SQL instance, and you're about to run like an update or a delete statement, that is not a reversible decision. Like take your time without one. That's the time to plan.

[00:45:33] Dave Adsit: That's a great place to practice. So you can practice by running a select statement with the exact same where clause. Yeah. And eventually when Allan gets his way, a project statement with the exact same where clause. Thank you.

[00:45:48] Matt Baker: The point I want to make is you can practice sizing things up. All of this stuff you can practice. Sometimes it's just as simple as becoming aware of the decision you're making. You know, we all name variables all the time, but if you, if you make it a habit to say, I'm going to practice not specifying. I'm going to use this variable name because I've been spending extra time on this variable name right now because I don't need to. And it's reversible. So I'm just going to name it food and move on that's practice. And that will make you better at your job.

[00:46:14] Dave Adsit: So I would like to share a quick story that Allan can maybe expound on, but you really only get one shot at having a good clean holiday break. Right. And if there was a year where we all needed a good clean break for the holidays, it was 2020. And so in the days before everybody started to disappear into holiday mode, my engineering team took time to practice handling production alerts by triggering a couple of artificial ones. And then as a team, they went in, led by one of our architects, and dug into logs and dug into monitoring tools to figure out what the problem was so that they could all quickly and easily resolve problems if an unfortunate thing happened and we had an alert come through our alerting tool triggered by something bad in production. So they practiced that. For several hours, at least one day when the whole team was still together. And then they fortunately didn't have to perform. Well, no, that's not true. One engineer picked up one alert and resolved it during the holiday break. And he knew how to do that because they had practiced it.

[00:47:42] Allan Stewart: It was super successful. I really liked it. And it makes me think about the fast feedback that comes back from. Practice. Because a lot of times the real thing is hard to do. Like you want to practice something like those alerts. You don't actually want to take the thing offline in production and create a real incident just for practice. And it's complicated. And so if you can find a way to practice on kind of a toy problem or an example alert, then you can make a lot of progress there. If you're trying to introduce something into your code. Maybe your production. Code where you work all the time. That might be a really hard place to introduce something. You want to try a new pattern. You want to add the, the maybe monad into your C-sharp code base, or you want to try abstracting things into a repository pattern or something like that. If you're taking that in your production code, it might be a really long time to apply that kind of a change. And if you're still learning about it and uncertain, whether that's the right thing to do, then going off to a safe place to practice lets you get that. Feedback much, much more quickly. In his book, the clean coder, uncle Bob talks about practice and about how in the early days of computing practice was very different. And we didn't think about practice in the same way because you know, you had to write all your stuff down and, you know, put them on punch cards or something and wait for your turn on the mainframe before it's ever going to get run. And that's changed a lot with everybody having their own processor. And so now everybody. Can practice on their own computer on their own time, you know, whatever makes sense to them. And really that's all about fast feedback. We don't really have to think about that too often these days. Like you don't even have to have your own processor anymore. You just rent one from Amazon these days and you can have one or any of the other cloud providers, but it's the fast feedback that you're really looking for. And if it's a small toy project, nobody's going to care about your Yahtzee implementation or your bowling. Cod. Or your coin exchanger or, or any of those. But they are going to care about what you learned and we're able to then like build up that confidence that yes, we should do this in our production code in a way that actually makes a significant difference for the maintainability and the speed of building features for your product.

[00:50:10] Dave Adsit: One of our friends is kind of a master at turning practice into play when it comes to. Software development. He comes to Utah, see all the time and he regularly presents fun and unique ways. Or coding exercises that are, they open your mind in a different way. He's got one that's called X or tag where everybody has to code their own little bot that has to determine where it is on the board. Who's it, whether or not the bot is it, and then try to play tag. With. On a shared server and it's really challenging. Especially against someone who's thought about it for more than 45 minutes before writing the program. He has participated in competitions for retro coding, retro video game coding. His name is John and he's even written this program. Legend of Griselda, which is a retro D make. Bootleg. Legend of Zelda clone. Which is hilarious. And it's all made with ASCII art. And it's super hard to play. It's harder even than the original gold cartridge. But man, it is. A level of art, how, and he makes it fun. And it's, he. He's kind of inspiring as an example of someone who. Does practice and play in order to be a better software developer.

[00:51:49] Matt Baker: I will say, I also want to say that John's awesome.

[00:51:52] Dave Adsit: Yeah. Legend of Griselda. Holy cow. Taking, taking software play to a whole new level.

[00:52:00] Allan Stewart: Well, with that, I think we'll wrap up our topic for today. Practice and play. It's an important part of professionalism. If you want to be able to craft code well, then you're going to need to do some practice. We can't just assume that we're going to just sit down and slam out some code and that it's going to be great. So we'll end by recommending that you join up with a community of professionals by attending a software crafters group or meet up near you. Find a place where you can experiment and practice and play with other people who are also in the coding space. The Utah SC group at utahsc.org meets the first Wednesday of each month, and maybe we will practice with you there.