Code with Jason
Code with Jason
297 - AI-Assisted Coding with Steven Diamante
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this episode I talk with Steven Diamante about coaching teams on XP practices and AI coding agents. We discuss why change is so hard (people have to want it), his success turning an underperforming team around through weekly learning hours, and how to use TDD with AI—including "predictive TDD" where you have the agent guess if tests will pass or fail.
Links:
Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonnier from Dickinson, Texas says, just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsensemonthly dot com. That's nonsensemonthly.com. I'll say it one more time. Nonsensemonthly. And now without further ado, here is today's episode. Hey, today I'm here with Steven Diamante. Steven, welcome.
SPEAKER_01:Hey Jason. Great to be here. Thanks for having me.
SPEAKER_00:So we were talking pre-show about uh the consulting work that you do and a number of other things. But first I'm curious about your consulting work. Um what is it and how long have you been doing that?
SPEAKER_01:Yeah, so um since April, I've been working with RDM AI, and we build AI into uh businesses' products, and we also help them to use uh coding agents more effectively and things like that. And um yeah, it's been I mean it's been super fun. Um it's like a new skill that I've been learning and totally changed the way that I've been doing software development.
SPEAKER_00:And are you doing that are you doing that independently or working for somebody else, or how does that work?
SPEAKER_01:Um yeah, so that's that's my full-time role. And then on the side, I'm also uh I have my business Diamante technical coaching, where I uh help software teams to use coding agents more effectively and kind of mixing those um technical practices from extreme programming, like test-driven development, refactoring, even kind of like pair programming, those kind of things. I've been pair programming my whole career. So, like, you know, how how can we kind of treat uh an AI coding agent more like a collaborator, not just like as a tool.
SPEAKER_00:Yeah, I think there's a lot to that. Okay, so there's a lot of things that I want to dig into in these topics. Um one, I'm curious from just like a business perspective. Because, okay, for context, you and I have known each other for like seven minutes or something like that. Um so obviously you you don't know any of my my background unless you happen to look at anything online um or listen to this podcast or something. But um I used to do consulting myself um on and off for like 10 or 12 years or something like that. Um and in this most recent stint of consulting for like a year or two years or something like that, um it was less like contract coding work. Like when most people say consulting, they really just mean like writing code by the hour, which is basically like having a job. And that's like fine for what it is, but I was trying to do like actual consulting where people hire me for guidance and expertise and stuff like that rather than implementation work. And first of all, I'll pause there because it sounds like that's the kind of work you're doing too, like write like the more guidance rather than just hey, I'll pay you by the hour to write some code.
SPEAKER_01:Yeah, yeah. I mean, uh at RDM it's a little bit a mix of both. I mean, some clients just want us to come in here and build their product and then just leave. Um, others want more of an enablement, some coaching to actually like kind of like teach them how to fish, so to speak, like not just um just build a thing and get out of there. So those are the kind of engagements I really like. And um yeah.
unknown:Yeah.
SPEAKER_00:Yeah. Um so there's there's a couple challenges that I had when I was doing consulting um that I'm curious your take on. Um so I've been programming professionally since depending on how you count, uh, like for for 30 years. I'm I'm 41. I started when I was really young, and my dad had his own um software business, and so he hired me to do some work when I was really young. Um so but I got my first like real job in 2005. So like a solid 20 years of of being in programming, worked a whole bunch of different places, had a whole bunch of different freelancing clients, and what I've learned in being inside all these organizations is that everywhere, and I mean everywhere is a fucking disaster. Just like everywhere, like it's incredible. Um, you you wouldn't think it it can be true. Like it's like, no, it can't be true that like literally everywhere is this bad, but it's true, it's nuts. I can't believe it. Um anyway, like it it took me a really long time to to come to understand that because even when you're getting like assaulted with reality day after day for years, like it's just so unbelievable that this is how the world can be, that it took me a really long time to be like, wow, okay, like yeah, I guess this really is the truth of it. This is the way things are. Um, and that like shaped my idea of what I should offer for consulting services, you know, because it's like I had naive ideas at at some point of like helping people undergo some like dramatic transformation. And and I slowly realized that like those kind of dramatic transformations, like I don't think they really tend to actually happen. Like at most, you can make like a very small impact. And honestly, it's it's kind of like demoralizing and and depressing. Um, but but also like it's good to have yourself calibrated to reality so you don't have unrealistic expectations. Anyway, uh I'll pause there in in case you have any thoughts on on that topic. I'm curious.
SPEAKER_01:Uh yeah, I mean I have a lot of thoughts. Um yeah, I mean, as consultants, like we're definitely brought in there for a reason. Like if it was all great, like they wouldn't call in consultants. Um and it makes me think back to like um yeah, so I was a consultant for like working out a lot of banks uh uh prior to last year. And um and the first time I actually got on a team where it was not just us consultants, but it was actually like the client devs were there too. I remember telling my wife, like, this really ambitious, like in six months they're gonna totally be changed. And like I I I even like wrote it down like in my phone, and like that, like this is what's gonna happen in six months. And that is totally not what happened at all. Like, and I was just yeah, just that this just dreaming that I could come in there and change this not only, I'm sure I changed a large org organization, but this team that was kind of set in its ways, and that definitely uh opened my eyes that change is very difficult, and you can't change people. They're gonna they they have to want to change for sure.
SPEAKER_00:Exactly. I think that's a great point. Like there's a huge psychological element of this whole thing, like understanding people and understanding organizations. And something I came to realize it's it's like embarrassing how late I came to some of these realizations, but I thought about it in these terms because I was hired one time to to help a certain team improve because they were like I was told that they were basically the the worst team, the worst team in the company. Um, but of course nobody told them that. Um they asked me to help improve this team's performance, but nobody told the team that that's why I was there, and nobody on the team particularly like wanted my help. Again, they didn't even understand like who I was or why I was there or anything like that. And I articulated to myself, I was like, hang on a second, like think about how hard it is for an individual to change themselves, even if they want to change. Now think about how hard it is to change somebody else who wants to change, and then think about how hard it is to change somebody else who doesn't want to change, and it's like forget about it. Like literally forget about it. Like that is just not gonna happen.
SPEAKER_01:Yeah, yeah.
SPEAKER_00:Yeah, yeah.
SPEAKER_01:Um yeah, I was I was in a similar situation. I kind of have a uh it was actually a success story. Actually, it was it was maybe not one of the worst teams, but they said they were like underperforming. And um, and I was kind of known for like spreading XP practices around and trying to um teach people TDD and refactoring, and they were struggling with pair programming as well. And so yeah, I came in there and I mean I'd say within like four to five months, we were just like really hitting our stride, and then uh they were like recognized as one of the highest performing teams in the organization. Oh wow, and um and one of the things that I did there, I I said that we need to invest time in learning. So for two hours every week, we would get together and just learn some micro skill and practice. What's developers don't practice enough? Um it was about like six to seven developers. Yeah. Small team. And sometimes we break into pairs, sometimes we would like mob. Um, but and we mostly just do KATAs and kind of connect it with our day-to-day work.
SPEAKER_00:And like big picture, high-level, what kind of stuff were you teaching them?
SPEAKER_01:Um, we started with TDD um and kind of mixing pairing techniques as well, and just like getting comfortable like working with each other. Um, and I think it really helped just the team morale. People got more familiar with each other and how it took and like it took time away from feature delivery for them really just to like slow down and like figure each other out and figure out like some of the things that they wanted to learn. Like some of them wanted to learn these keyboard shortcuts and how to use their IDE more effectively, but they never took the time to. So there it was like, yeah, like let's let's slow down and practice.
SPEAKER_00:Yeah, yeah, I feel like there's some important things in there. Um one is just like it's it's it's like this meta thing. Um, you know, there's there's like the way that you approach your work. Um, and something that I find myself like trying to teach people a lot, whether they they they want me to try to teach them or not, it is like allocate some of your time deliberately to I I call it sawing versus sharpening the saw. Um most people, developers, teams, managers, they spend like basically all their time sawing and almost no time sharpening the saw so that they can saw more efficiently. Um and just even by giving a little bit of conscious thought to that distinction, you're already ahead of like 90% of teams, I think.
SPEAKER_01:Yeah. Yeah, for sure. I mean, yeah, people kind of find a way, kind of just stick to it and never really change it. But um yeah, we're in a we're in a profession where learning is essential. So you have to take that deliberate time to practice.
SPEAKER_00:Right. Yeah, and I feel like maybe people a lot of times feel like they don't have permission to like take the time to sharpen the saw. But I I always tell people that like you know your your manager probably wants they don't want you to like suck at your job and never learn anything. Like nobody okay, this is the thing. Like, I often tell people, like, hey, nobody's telling you to like uh take shortcuts and cut corners and do a bad job. Like no one has said that to you. So like don't put that pressure on yourself and like do a shitty job just because you are like imagining this pressure. Um like just assume that you have permission to do a good job of the thing. People will put enough pressure on you to make it hard enough to do a good job. Like, don't put more of that pressure on yourself, but I find that people do.
SPEAKER_01:Yeah, for sure. Yeah, I've talked to like engineering managers and product owners, and they mostly say, Yes, we would want you to take your time and deliver the highest quality product that you can. Like within reason, we have deadlines, sure, but please do your best.
SPEAKER_00:Right. Yeah, and I I I do wanna so I I I'm I'm not trying to criticize what you said because these are words that I think I use too, but I have a little bit of a gripe with words like quality and best. Um because like, well, they're kind of vague. Um quality is like what what does that mean? Does that mean like it it it just like has few bugs or like it it looks really good, or like what does that mean? It it's full featured. Um I prefer to think about it in terms of like um making smart investments. Oh so like from a software design perspective. So like instead of cutting a corner and and building something in such a way where it's gonna come back to bite you next month, um make it an investment where instead of duplicating this thing three times in the code base, let's let's put it in one place. That's gonna take some more thought, but it's it's a pretty good it's a pretty good bet um so that we uh so that we won't get bit by it later. I I prefer to think in those terms rather than than just quality. And again, I'm not trying to criticize what you said because I don't think that's fair. And I imagine you probably agree with what I just said.
SPEAKER_01:Yeah, yeah, I do agree. I was just relaying things that I heard, but I totally agree. Because that's that I mean that's the terms that a lot of the product and engineering managers that I've talked to would put it in. But I totally agree and I like I like the term like looking at it from a perspective of sustainable pace. Like what what can we do to make the code more maintainable so that we can not be slowed down and keep being able to add features easily. Yeah.
SPEAKER_00:Yeah. Um there was another thing that you mentioned that I thought was was important, um, another like psychological aspect. You said um getting the team members, the team members were like more comfortable with each other or something like that. I find that interesting. Um because different teams have like different levels of camaraderie and different kinds of relationships with each other and stuff like that. Can you kind of give me a feel for what you've seen and and how the things you have done have helped the relationships?
SPEAKER_01:Yeah, um, yeah, so when I joined the team, I I basically none of you look like you're having fun here. It's like my first week on the team. Um I I I knew I knew a couple of them already, like, and they're like consultants in the same org. I was just like, I'm just kind of seeing the energy and like um like after my first week, I I said I would like to inject more fun in this team and what's more collaboration. And so yeah, um I mean, I was also like on the team, like pairing with them. So I'm rotating and pairing. Um uh in the beginning, we were doing Like one week rotations. Um, so pair the same person for a whole week. And I proposed an experiment where we do like every two days. Um, sometimes it was like three days, but so then a lot of people were working with each other and shifting around. And I think that really helped the team come together. And then also just encouraging them to speak up more in meetings and like let's design together, let's like solve these problems together, not just have one person just dictating everything. So, I mean, there's a lot of little things that came together over time, and really just like being together for those two hours every week, and then we were a team that paired all the time, and the pairing just started to get more effective.
SPEAKER_00:Interesting. So let's talk, let's like zoom out a level maybe for a second. Um, like why is this like relationship and camaraderie stuff? Like, why do you think it matters?
SPEAKER_01:Because I I think teams that have fun like are high performing teams. Like, I think if you're you're having fun and you're happy, you enjoy what you're doing, you have autonomy, freedom to make choices, and you just generally like what you're doing and the people you're working with, like those are like the best teams I've been on. And they like and they're noticed that they're like delivering business value steadily, and yeah.
SPEAKER_00:Yeah, yeah. Um, so I I want to dig into that a little more, a little deeper. Um, and again, I'm uh so you said you said fun, um, and I totally agree. Um I I want to maybe get a little bit more specific about like what does fun mean exactly. Um I read that book uh flow by Mihai Chick Sent Mihai, um, and he talks about the difference between like pleasure and enjoyment. Um and and I can't do it justice, but like pleasure is just like I don't know, eating some tasty food or something like that, like a bag of chips or something like that. Um but enjoyment is like I don't know, maybe you're like uh downhill skiing or something like that, and and you're in a flow state, you know, like skiing is kind of dangerous, and so like you need to be paying attention like literally constantly. Like you can't stop paying attention for even a second. Uh I mean, if you're like going down an actual steep mountain slope or whatever, um you can't stop paying attention, you you you get totally focused and you're like in the zone or whatever. And so for him, that's like enjoyment. Um and to me, I th I think about work in a similar way. Like I I think about well, there's also the the concept of like satisfaction. Like I'm not necessarily personally, I'm not necessarily seeking fun out of my work, but I do want enjoyment and satisfaction and to express it in the opposite way. Like I don't want to feel like I'm doing something stupid, like I don't want to feel like I'm just executing dumb ideas, because that's like that's a real mor morale killer. And I feel like a lot of people are in that place a lot of the time. Um and and all these things come from various different places, and if you have a if you have a good relationship with your team members, I think it contributes to that like enjoyment and satisfaction and accomplishing something meaningful together rather than everybody like in their separate lanes of work. Um yeah, I I don't know, but uh the the enjoyment and satisfaction are a couple labels I might additionally put on that.
SPEAKER_01:Yeah, I think that's probably more accurate than fun. Like we're not we're not just like goofing around all day. We're getting work done, we're like enjoying what we're doing, or we're satisfied with the work we've completed. Um, yeah, for sure. Like, I mean, some some little thing, other little things that I did was I have these like I have these cards with like these random questions. At the beginning of retro, I would just like ask everybody a random question. Like I'd like one of them is like, what's your favorite topic of conversation? Just like these little random questions. And that like no one had done that on that team before, no one's really getting to know each other. So it helps people get more comfortable with each other, and then you're not like you're not like holding back your ideas, or you're not afraid to challenge somebody else's, and and that's where innovative collaborative teams are born.
SPEAKER_00:Yeah, yeah, like um there has to be there has to be, so there's this concept of the emotional bank account from Stephen Covey, the highly seven habits of highly effective people. Um, and if you make deposits into other people's emotional bank account um by, I don't know, saying well, just e even just developing a relationship with somebody uh uh puts a deposit into that bank account. And then you can afford to make withdrawals um by saying like, hey, that idea that you're suggesting right now, like, no, that idea sucks, let's not do that, and let's move on. Um like that is is definitely a uh withdrawal, because that like hurts to get that kind of to have somebody say that kind of thing to you. But if you have like a really solid relationship and most of the relationship consists of of positive things, not just like superficial flattery flattery, but like a genuine appreciation of each other and stuff like that, then you can afford to occasionally be like, no, like fuck your idea. Um and and you can be efficient, you know? Um because when you have to be so like tactful and polite with everybody and and hold back what you really mean and what you really think, it's so inefficient. Um so so developing those strong relate relationships really greases the wheels in that way.
SPEAKER_01:Yeah, and all the teams I've ever been on have embraced like radical candor. Like we I'm just gonna tell you how it is. And it's for the better of the team, the better of the product, the business. Like I just want to be honest and straightforward with with you. Yeah.
SPEAKER_00:Yeah. Yeah, but again, that's that's one of the things that is it rarely gets conscious attention.
SPEAKER_01:Yeah, yeah. I mean, psychological safety is such an important part to have all that stuff too.
SPEAKER_00:Yeah, what do you mean by that?
SPEAKER_01:Um, yeah, I mean, you need a you need people to feel safe that they can speak up. Like, and I think that camaraderie definitely helps, but it definitely comes from like the leadership in the organization as well.
SPEAKER_00:I've heard the term psychological safety a bunch of times. I um don't know if I totally understand it because like I understand like it's the ability to say what you want to say without fear of, I don't know, ridicule or something like that. I'm not totally sure. You know, I I I I'm not sure if it's one of these like very like coddling ideas where where people's feelings are supposed to be protected or something like that, which I don't really buy that much, or if it's the opposite kind of thing where people are free to be candid and they won't be um criticized for being like too harsh or something like that.
SPEAKER_01:Yeah, yeah, I think I think it's the latter. Um yeah, I think I think it's about just feeling that you're in a safe place to share your feelings and you're and that you can challenge somebody else's ideas, um, even regardless of like hierarchy. Um, I mean I see a lot of like uh innovation kind of killed because like, oh, I don't want to challenge him, he's my boss, or my that he's the leadership position. But like I I think at most or uh a lot of organizations that I choose to be at are the ones that those leaders want to be challenged, and it's just a shame that a lot of developers will just kind of hold back because they're scared.
SPEAKER_00:Yeah. Yeah. Something that I think is often lacking at all levels of organizations is honestly like courage. Um, like courage to uh if if you're being pressed with deadlines and you have a choice between like um doing something which I'll call stupid, doing something stupid that's gonna make your life harder in a few weeks and gonna make it harder to meet the next deadline, and now you have to do another dumb thing on top of your previous dumb thing and shackle yourself even more. Um I wish people had more courage to do the opposite and make smart investments. Um I I've talked about a lot of these similar ideas that we're talking about right now on an earlier podcast recording, but I talked about this thing my friend Steven Anderson said uh a surgeon before surgery shouldn't ask you, do you want me to wash my hands first? Um but but programmers often will um well there's there's advice I frequently see of present your manager with options and say, well, we can cut some corners and get it done in a week, or we can do it the right way and get it done in a month. It's like obviously the manager is almost always going to choose the one week option. Um and I think developers should have the courage to not don't present your manager with those options. Like don't ask your your don't ask the patient if you should wash your hands before the surgery, you know. Obviously, like use good judgment and be realistic, but that is like your job that should be all on your end, not a responsibility that you should uh pass to your manager and make somebody else make your decision for you.
SPEAKER_01:Yeah, yeah, for sure. I mean it's a professional thing where we need to uh um yeah, we need to take responsibility of the stuff.
SPEAKER_00:Yeah. Um okay, let's see. So we're talking about like uh the psychological factors of of a team and stuff. I I'm curious in this case, like there are certain things that I do just because it's kind of in my nature. Like on my current team, my role is is tech lead, and I feel like one of my responsibilities as the tech lead is to have a strong relationship with each of the other members on the team. And so I like schedule the one-on-one uh for for every week, just spending some time with the other developers. Doesn't really matter what the time is, it more matters that we spend the time. Um and that's just something that like I don't know, the it it there didn't have to be like a specific problem or a specific goal or something like that. That's just like in my nature to do that kind of thing. Um, and there's other stuff that falls into that category too. And I'm curious, in your case, were you doing these things because they're kind of in your nature to do those things, and you're just like, well, obviously we should be doing these things. Or was were you like asked, was there like a specific problem or a specific objective or something like that? Or maybe it would was a mix of both. Tell me about that.
SPEAKER_01:Um, yeah, I mean, I was presented with the problem that this team is not performing as good as we want right now. And um they're they've been pair programming every day, but it's it doesn't seem very like it's working and they don't have much experience in it. And we want them to be doing test-driven development. So they told me like all these kind of goals, and they gave me the freedom to take the approach that I wanted to. And around that time, I was learning about something called learning hours, where a team gets together and practices like a micro scale. And I mean, these learning hours are great for the kind of things that are hard to learn in like tutorials, like TDD, refactored, these kind of things you have to like just do. And it and it's easier to learn when you learn from somebody who's been doing it a long time, too. I mean, that's how I learned uh TDD is I learned from people that have been doing it for a long time. Um yeah, so I said, hey, can we take two hours out of the week to just practice and learn? And yeah, he was like, Yeah, do whatever you need to. That's that's fine. And um I had the autonomy to make the decisions.
SPEAKER_00:Okay. And what was communicated as far as you know, like what was communicated to the rest of the team? Were they like, hey, Steven is here to help you guys, or were they like not told anything? Like, tell me about that.
SPEAKER_01:Um, I'm not sure. I was just a new member on the team. Um and I was a senior developer. There were like two other kind of tech lead people, and they kind of they kind of took the they were in like more meetings than I was, and I was more focusing on like just cultivating the culture of the team. Um, so I wasn't going to more of those like um stakeholder meetings and like design meetings as much, and I was more focused on like planning these learning hours and and those kind of things. Um but I don't not sure what the messaging was, but yeah, like I said, when I came in, I was like, let's have more fun.
SPEAKER_00:Yeah.
SPEAKER_01:I just like brought the energy to the team and and uh and then we're just trying to teach them stuff, and then they also learn from each other. That's I mean it's not just me teaching them, it's getting them together and practicing together.
SPEAKER_00:Yeah, interesting. Um and like what was the engagement like? I I've you know, I talked about this one specific engagement where like they didn't really tell the team anything, and these people didn't really seem to want my help. And in that case, the engagement was low. Um, but in a lot of the consulting gigs I've done, like the engagement has been a mix. Like some people are pretty enthusiastic, some people are just kind of like not really paying attention and don't care that much. Um, and maybe like kind of don't get it. Um what what was the engagement like in your case?
SPEAKER_01:Um, yeah, so I didn't make it mandatory at all. I said if you want to show up and learn these things, uh come join us. Um and that led to those more senior tech lead developers missing a lot of those meetings. And what I saw was I saw all those other developers kind of laugh them in experience and design skills and like the kind of code they were producing, the velocity that they were um yeah, taking. I mean, but I mean you could say yes, they were kind of doing other things. They were maybe they weren't writing code full time, things like that. But um, anybody that attended those uh learning sessions, they were very engaged um like all the time. Um, and I think maybe the benefit that I had in this situation was they were all consultants from the same consultancy as me. And um we had uh this culture of XP practices and background that like everybody that was hired was kind of expected to more or less definitely pair as much as makes sense and encouraged to do test drive development and CICD, all those sort of things.
SPEAKER_00:Yeah. Okay, that's very different from most of the experiences that I've had.
SPEAKER_01:Um sometimes I I've had I've had other I've had other I've had experiences since then. That was kind of my like first like lucky, I was in a lucky situation that I was like that. But I've definitely been on the other side of it. But um, I've I in my experience everybody that shows up kind of wants to be there because I I create an invitation that like if you don't want to be here, don't be here.
SPEAKER_00:Yeah, I don't make it mandatory. Can you tell me about some of these more difficult cases and how those went?
SPEAKER_01:Um I think I think it's just trying to map what we're practicing back to the code base. Um, and one of the more difficult cases was a team where we were doing a lot of maintenance and we were doing like a cloud migration. And so I'm teaching them like how to refactor legacy code because we've got these legacy code bases, but they just didn't have a lot of uh like like opportunity to actually apply any of those things because it was a lot of just bug fixes, researching bugs, a lot of documentation, like so um, but they felt like like a lot of those developers were like 20 years plus, and um they felt like they felt they definitely told me that they felt re-energized about programming and they wanted to learn more, and that's opening their eyes to some things.
SPEAKER_00:Yeah, yeah, that's always good to hear. Like with this one team, I flat out told them at one point, I'm like, I don't think this is really has been working all that well. I don't think much has changed. And they were like, no, no, no, like this is good, like we've we've actually started to do certain work differently because of these because of the time we've spent with you. And so that felt good. Um but a a a big difficulty of it, and I bet you've had similar things or You tell me. But like there was a great gulf in frame of reference and vocabulary and stuff like that. Um like and it took me a while to even realize that when I would say words like the other people either like weren't familiar with those concepts or those words meant different things to them. Like, for example, they talked about doing refactoring. Um and over the weeks and months, as I looked at their like refactoring PRs, um their refactorings, what they called refactorings, were like experimentation with new design patterns, and they were like adding functionality. And so it's like, hmm, adding functionality using new design patterns, like that is not remotely what refactoring actually is. Like refactoring, of course, is changing the design of existing code. And it's usually not a time to be experimental, it's usually a time to be conservative. You know, you want to make safe bets, you want to make the code better and do what you can be fairly certain is is going to constitute an improvement to the code because the whole point is to make the code less expensive to maintain the next time you have to touch it. But they had a totally different conception of what refactoring was. And that was just one, and like we were just speaking to two totally different languages. Have you had experiences like that?
SPEAKER_01:Uh yeah, definitely for sure. Um, that reminds me of when I I did this um elephant carpaccio workshop, which is all about thin vertical slices. Um, and I had the product manager in there. I I even uh invited the cobalt developer we had on the team, and I was pairing with her and trying to get her to do this exercise in cobalt.
SPEAKER_00:Hang on, sorry. Um what's what's carpaccio? What does that mean?
SPEAKER_01:Um carpaccio is like very thinly sliced meat. Okay, that's like very Yeah, yeah. And then elephant, you know, like it it's yeah, yeah. You're doing these one bite at a time.
SPEAKER_00:Yeah, these tall, thin vertical slices. Yeah, I'm definitely familiar with that concept, but I I'm I'm gonna take that elephant carpaccio thing. All right, continue.
SPEAKER_01:Yeah, so that's uh Aleister Coburn. Um he he uh I think he was the first one that kind of put that exercise together, elephant carpaccio. Um yeah, so I mean it was uh it was about two-hour workshop that I did with the team and kind of explain you know the difference between horizontal and vertical slices. And then we we in pairs we all did this exercise um of you know cool. First we broke down the problem. So the problem decomposition, uh, wrote some little user stories, and then we did the work all in those two hours. And that was the most change I had seen on that team because two weeks later in our planning meeting, they're talking about how can we make this more vertical, how can we slice it thinner. They started talking they started using that language that they had learned in it, and making those smaller stories just uh helped us to be able to kind of pivot and all the other benefits that come from small stories.
SPEAKER_00:Yeah, that's great. Um, so okay, that that seems like maybe a little bit of a different thing, or or maybe it's a similar thing. That sounds like a kind of a success story where like they didn't have the same frame of reference before, but then you worked together for a little bit, and they you you got on the same page. They they understood the frames of reference that you had, and then indeed they like adopted your ideas. So it sounds like maybe that started different, and then it it ended up uh it ended up positive.
SPEAKER_01:Yeah, and and the good thing about that is it was the entire team, it wasn't just the developers. Like I had the product manager come as well, and he like was watching people code, and which he doesn't do like at all. Um he he enjoyed being in there and he was able to learn that kind of terminology as well. Um so fast forward maybe a year later, I run this workshop again with a team that's using AI coding agents. And um maybe not as much of a success story there, but the cool kind of the amazing part, I guess, but was the thing that they built in like the 40 minutes that we kind of did that uh slicing, like because they're just using AI, like was way further than anybody had built in that that other workshop that I did.
SPEAKER_00:Yeah, interesting. Oh, okay, so two things there.
SPEAKER_01:Um yeah, yeah, but like maybe it lost the uh goal, right? Because they're they're kind of finishing it, and it uh the the goal is not to finish that that uh I mean it's like a simple like tax calculator or something like that, um e-commerce thing. Um yeah, it's sorry.
SPEAKER_00:Oh, that's okay. Um so I I I've there's another metaphor that somebody shared with me a couple years ago, which I really liked, um, which is the steel thread metaphor. So basically the idea, I don't know. Here's how I think of it. I saw this documentary one time about like tightrope walkers, and they like did one between the uh World Trade Center towers. Um and the way they did it was like they took a bow and arrow and then like shot an arrow that had a really thin like thread attached to it. They shot it from one rooftop to the other, and then the other person like attached a cable to that wire, and then they like dragged the thin wire back across, and that's how they got this like thick, heavy cable across the two buildings. I thought that was pretty clever. Um, but the um the way that applies is like so many developers will begin building something by building some small part that's not attached to anything else. It's like if they're gonna build a house, it's like they start building the house by building like some random closet first, and then like a sink, uh, and then some stairs, and it's like, whoa, like hang on, like this is creating a big risk because now we have these things that we've invested time into, we've paid something for these, but now in order to get any value out of these things we've paid for, now this huge amount of work has to happen first, or else we'll get zero value out of anything we've done. So it's better to like have the steel thread, this thing that's complete that connects from one end to the other end. And then we like switching the metaphor now, you you like wrap another steel thread around that original steel thread and keep doing it until you have this like big thick cable, which is what you originally needed. Um and so that that um that way of working uh takes out a lot of the risk because it's like you pay for something and then you start benefiting from it. And then you pay for something that adds on to that and you start benefiting from it. It's it's not finished, but it's at least complete. Um I forget if I had a broader point, but maybe that was my point just to flesh out that that idea a little more.
SPEAKER_01:Yeah, yeah, for sure. Yeah, I mean there's a lot of different names for this, like tracer bullets, walking skeleton. You know, it's all it's all about just how can we get this thing in front of a user, figure out what do they actually want. Because I mean, you know, a user will tell you what they want, and they don't actually know until they use the product.
SPEAKER_00:Right. Yeah, and side note, I I don't even think it's the user's job to tell you what they want. I think it's the designer of the software's responsibility to figure out what the user needs. Like you you should find out, um you should learn about their their day-to-day life and their job they need to do and stuff like that, and then give them um it, you know, give them a good guess of what you think they need and then iterate on that. Yeah, way too many developers, and I'm sure I'm preaching to the choir, but like way too many developers think that their role is to sit and let somebody else tell them what they need to build and then build that thing. It's like sometimes yes, but like what should really happen is like you design the software and then build it, like don't abdicate your responsibility and put that responsibility on the user who is who is not um who's not a professional software designer, you should be doing that.
SPEAKER_01:Yeah, I totally agree.
SPEAKER_00:Yeah. Um, okay, so I want to talk about the AI stuff. There's there's a question um I wanted to ask you about that. Um so if you ask AI to do something, like I've been using Claude Code a lot, it can usually do the thing, and that's great. But then it does like a lot of a lot of other stuff too. You know, like it's very it loves to like add all these conditionals and like backward compatibility and stuff, and just like really dumb stuff that I really, really don't want. Um and so it's like you can get what you need in two seconds, but then it takes so long to like go through and like take out all the stuff that you don't want. And if you just pile if you let it pile on all these things, it just ends up being a disaster. So, like, how do you deal with that?
SPEAKER_01:Um, yeah, I I think it it's kind of the the thinking part uh that we need to do first, like before we write code, even with coding agents, like let's plan out what we're gonna do. Um so yeah, that's what I do. Like with Quad Code, it has a great planning mode that you can just switch on and it won't write any code. Um, and then it'll like suggest a plan. And then you know, it's now you need to review the plan, make sure it lines up with what you want to do. And you're like, no, no, no, I didn't ask for that. Like, take that out, take this out. Like, and another part of that is like really small focused tasks. Um that problem decomposition. Um I mean, that's that's a huge skill uh that can be applied with these things nowadays. Uh developers, if they don't if they aren't good at that, it uh it'll be it'll come in handy, breaking these bigger problems into smaller chunks. And uh that's effective because then you have smaller plans, you know what it's gonna do, and you can kind of keep it on a shorter leash and kind of know where you're going. And also um that you can um so I mean you can have optionality and you can kind of shift where you want to go as well. Um and another thing that I've been doing is doing TDD with coding agents. And great is it gives them that feedback loop that they get to see, um, they get to write the test, and once it passes, things should be working hypothetically. Um, and what I've been doing is even adding another layer on that called predictive TDD, where I have the agent actually make uh a guess, a prediction on whether the test is gonna pass or fail. And so it's making sure that that it's tuned in, it's paying attention, it knows what's happening, and it it uh validates its assumptions.
SPEAKER_00:Yeah, interesting. And is the idea there, you know, like with the red-green refactor loop, like you want the test to pass uh sorry, you want the test to fail first because you're testing the validity of the test and you want to see it not just fail, but fail in the way that you expect it to fail. Is that why you're having the AI do it that way?
SPEAKER_01:Yeah, exactly. So I had this situation. I was I was adding I was adding like uh like an input field to a row of already input fields, and um it it wrote it wrote the test, and then it said, okay, it should fail. And then it passed. And it was like, oh wait, so like it slowed down and like was like, wait, why why did it pass? And then it writ and I'm looking meanwhile, I'm looking at the UI on my other screen, and and I and I know that there's like a bug that it introduced from like the last test or something, and that it it it couldn't quite figure out what was going on. And maybe before I would have taken a screenshot of the bug and had it fixed it, but it was so tuned into what was happening because it was checking itself, um, that it was like, oh wait, no, I should check this and this other thing, and then it ended up fixing the bug before continuing.
SPEAKER_00:Interesting. So it sounds like you might have figured out something that I haven't figured out yet. Because I try to do the same thing, like I try to get clawed code to to write uh to practice TDD in the way that I do. Um because I think you would probably agree that like getting a good get getting a good software design is totally inseparable from the behaviors that you follow in order to make that code. Um and and I found that Claude, like by default, its behaviors aren't very good. And so even if it theoretically can write really good code, if it doesn't behave the right way, it's not gonna write very good code. But the problem that I always have is I tell it what to do and then it forgets. Even though I have the Claude.md and I tell it to reread it on every prompt. I have like a dot claudrc that says read claude md. I cannot get it to stop forgetting.
SPEAKER_01:Yeah. Um, so yeah, what I've done is I I I don't have the TDD process in my Claude MD at all. I just have a separate command. And so I I create a plan for like, hey, here's a little thing I want to do. And then right before it starts, I'm like, hey, here's TDD. Follow that process. And and another thing it does is slows it down. Um it will it will kind of make a test list. It'll it'll write comments, like test comments. It's like, okay, I think we want this behavior and this behavior and this. And sometimes it's not behaviors, it's like, ah no, that's the implementation detail, we don't need to add that. Um and sometimes so I could say correct it early and make sure that what it's about to do is actually what I want and will actually be maintainable. Um so it works pretty well now. Um, but I think when you're starting, um, yeah, I mean this could be completely different on an existing code base. I've been lucky to do this with Greenfield applications, a whole another challenge on uh legacy code and older code bases, but I found it effective on a new code base to really slow down in the beginning, really work on a good architecture, um, really work on like um readable tests, uh well-designed tests, um trying to minimize subdupication through helper functions and maybe some test data builder patterns or whatever. But that really, if you can have a pretty um well-defined structure of how you want your test to be written, then when you tell it to write the test or the code, it's following those existing patterns already. So I think it's really important to just keep keep refactoring it, use the agent refactor, um, and just kind of put your own style into it. And yeah. It's it's been fun.
SPEAKER_00:Okay, yeah, that's really interesting. Um, and I don't know why, but like I knew you can do custom commands with Claude, and I wrote one and it worked, it worked okay. Um, but I never like I then I stopped doing it for some reason. I don't know why I stopped. So I should do that again, because it sounds like that's been effective for you. Um we're getting pretty close to time, um, so I want to wrap it up soon, but um, before we go, like, is there anything that we haven't discussed yet that that you would like to go go deeper into or anything like that?
SPEAKER_01:Um I gotta I I gotta I'll just talk a little bit about my my journey, I guess. Yeah. If I could share that. Please do. I mean, I mean, in in February this year, um, if you listen to this, it's you know, November, December, somewhere around there. But like February this year, I was actually sick of hearing about AI. Um I feel like it was everywhere. It was I was kind of like uh it's over hype, and um I was I was pretty sick of hearing about it. And then the next month I see somebody use Windsurf for the first time and at a at a conference um at Agile Open Northwest, where we just have like open space and everyone's doing all kinds of different uh sessions. And so yeah, that started to open my eyes. And then um, yeah, and then I actually like joined a company that's doing this stuff, started to work with clients that are using these coding agents, and really opened my eyes to like this shift. That's happening right now that if you aren't paying attention to it, it might pass you by. But um yeah, it's definitely a huge change in the software development uh process right now.
SPEAKER_00:Yeah, yeah, I hear that. Like it is kind of tiresome to constantly hear about AI. Like I'm kind of tired of it too, but it's like so enormously useful and it's definitely not going away. Um and it's interesting. It's like it's it's I'm not tired of it anymore. You're not tired of it anymore.
SPEAKER_01:Oh no. I'm I'm I'm like obsessed with it. Just so much to learn, too. Yeah.
SPEAKER_00:Well, it's like simultaneously overhyped and underhyped, I think. Like people see a snapshot of the way it is now, and it seems like a lot of people assume that it's not gonna get much better than it currently is. And I don't see any reason to assume that. Like I think maybe LLMs are reaching a local maximum, but like I don't see a reason to believe that like it's gonna stop with LLMs, you know. Like for for all we know, next year there will be something that is just as much of a difference as when we went from no AI to AI, like something that will be so much smarter that it will just be like total insanity. Like I expect that such a thing will happen. That's my default except expectation rather than to expect that things will just get like a little bit incrementally better or something like that.
SPEAKER_01:Yeah. Um I'm I'm actually I'm seeing not as much anymore, but early on in the year, I was seeing kind of the same problem with people that are thinking about or about TDD, like TDD adoption. Like uh you tried it one time, maybe once or twice, and you're like, ah no, this doesn't work. And I'm seeing the same kind of thing, people trying um to to code with AI. Um, you know, maybe maybe last year they tried doing something in Chat GPT and then they made the assumption that uh this is never gonna work. But maybe they haven't tried coding agents because coding agents is totally different. It's it's in your code base, it it has tools to search your files, it has all kinds of tools, even with mcps. You can give it um you can give it eyes if you're working on UI, you give it uh MCP like playwright, and now you don't have to copy paste your uh UI bugs into it anymore, it can see it uh itself now.
SPEAKER_00:I didn't know that that existed.
SPEAKER_01:Yeah, yeah. So there's all these like different levels to it. Um, and and that's why it comes back to what we were talking about in the beginning. Practice, learning, like throw out everything that you know about programming and try just to experiment and see see where it takes you.
SPEAKER_00:Yeah, interesting. I I might differ from that slightly. Like, maybe don't throw out everything, maybe temporarily temporarily suspend your judgments and stuff like that. I do think it's important to like reconcile all this AI stuff with existing like principles that have already proven to be very sound, and ask, like, okay, how does AI meet with these things? Like, how does AI meet with TDD, for example? Obviously, you've been um you've been addressing that question, and I think that's one of the really interesting areas is like taking these principles that are already really powerful without AI and then marrying them with AI and seeing what comes out.
SPEAKER_01:Yeah, yeah, I did this thing recently. I I I pulled up uh claw desktop, um, not cloud code or anything, just talking to Claude Desktop, and I said, how many what's the optimum file length? Like what's the optimal file length for you? Like function length, like what would be best to work with to like best optimize your context window and like the way you work. And it was like it's like, yeah, like like it was basically like under 200 lines in a file is better. Um, it was like methods like under like 50 lines is probably better. Like, and so I just started like asking more questions about like cognitive complexity and stuff like that. And um yeah, I mean, I think like some of these practices that that um XD community software craftsmanship they've been doing is really finding a lot of success and working with these coding agents.
SPEAKER_00:Yeah, well, something something I love and hate about having guests like you, Steven, is that I I just want to talk with you for hours and hours and more, but we we can't have like a four-hour long podcast, it at least not right now. I I have a job. Um and so I want to go so much deeper into so many of these topics, but I'm sad because we have to bring it to a close. Um, but I really hope that you'll be up for coming on the show again so we can talk more. Um, but in the meantime, uh do you have anything you want to share, the links, places people should go to learn more about you and your work?
SPEAKER_01:Um yeah, so um yeah, you can find out about um the kind of workshops and events that I'm doing on Diamante Techcoaching.com. Um, and you can reach out to me on LinkedIn, Stephen Diamante. Um very active on there, posting um daily on there. And um yeah, uh if you're a software team that's thinking about using AI coding agents or are using it now and maybe not having the best results, um, I can come in, help your team, do some training, and I'd be happy to help you uh really unlock the true potential of these tools.
SPEAKER_00:Awesome. Well, we'll put that stuff in the show notes. And Steven, thanks so much for coming on the show.
SPEAKER_01:All right, thanks a lot, Jason.