speaker-0: All the things that were always important are still important. And the people who are doing the important things are getting, you know, some big boosts. There are other people who are getting big boosts at doing the wrong things. You know, things that are good for the first hundred yards and then taper off and by the end of the mile they're completely intractable.

speaker-1: you ⁓ We have Tim Ottinger. I'm really excited to have you on our podcast. ⁓ I've known Tim for a while on what was Twitter, now X, and ⁓ who's known as Agile Otter on there. And he's always been a strong proponent of code quality and good collaboration in good agile practices. When we started the podcast, I was thinking, okay, I wonder what Tim is doing with agents. wonder what your view is with AI and agents. So I was really pleased to that you come and join us on this, on the podcast. So, yeah, do you want to just introduce yourself, anything you want to share before we start?

speaker-0: Well, let's see. I'm Tim, Agile Otter or Otter, ⁓ family nickname. It's been running for a long time. ⁓ I'm a long term Agileist, ⁓ old XP guy, so one of the authors of Clean Code and Agile and a Flash and a few other things along the way. And ⁓ I'm happy to be here, still working hard.

speaker-1: Amazing. Cool. And I didn't, I think in the information you sent us, I'd not realised this, that you were actually invited to the ⁓ Agile Manifesto meetup, but you didn't ski, so you didn't go.

speaker-0: That's right. I I didn't ski and of course it was on my own dime and it's like, well why would I want to go pay to sit in a ski lodge and not ski? And I didn't understand what was really about to happen.

speaker-1: You I'm sure, I I kind of think of you as that generation and the same kind of mindset. always kind of include you in that group of people that really did change software engineering. So, hope you've improved it.

speaker-0: Approved it.

speaker-1: Cool. Cool. Okay. So, so today we're, mostly going to talk about the impact of AI, I think. Let's just get straight into the technical side. Tell us about your kind of setup at the moment. What are you, what are you using to develop software today? And I, maybe actually you could start with just a little bit of context on, on what you're currently doing at the moment and your role. Cause I guess that will be important too.

speaker-0: Well, would that would probably be useful as well. So, ⁓ when I was hired, it was as the ⁓ senior technical improvement lead at LexusNexis. They changed my title and and I've ⁓ had a couple of different managers along the way. ⁓ but that's still really what I'm doing. And so I'm working largely with the architecture group and with a number of development groups. I am mostly on the delivery side in all the things I do. So while I have been ⁓ executive coach and such things. That's not my primary role and that's not what I'm doing here. So a lot of meetings, of course. If you get a senior in your title, you have to go to meetings. That's that's part of the game. ⁓ and I try to make them all. Also ⁓ I'm working on the agentic side of things because of course every company is moving boldly into the agentic age. And ⁓ I would like us to move boldly and safely. Hmm Course, I was with industrial logic and so technical safety was a big part of our world. And, you know, I I think that it it can't not be. I'm the the craft movement, ⁓ the clean code thing, all of this has been coming to a point, you know, where we have to think about code not just as instructions, but as knowledge representation. And that goes back to Ward Cunningham when first talked about the debt metaphor. He was saying that. You know, the code has to reflect how we understand it. And if what we learn is not what's in the code, then we owe it to ourselves as a debt to put it back into the code. So it says the things. Well, this was echoing in my head as I got into agentic work. Because the big problem with agentic work is it takes a look at your code, it sees a path to completing the task you gave it. That path could be three thousand lines of if then else statements nested twenty-seven deep. Which, you know, the the agent has been trained on that kind of material. That's that's the natural instinct, right? And that's not what you want. Right. And it may work for a while, but it's hard for you to review, it's hard for you to reason about. It's harder for the agent to reason about, but it is preferred because it's very primitive and you can trace it. Because you can easily keep you know, put in your head, this is a X. Okay, we just changed X to seven. Okay, we just changed X to twenty seven. Okay, and then this sets X back to zero. And while Y has incremented by one, X has gone back to zero, and now it's four. You know, you can keep that in your head, your debugger can track that. So that's considered to be primitive, double colon simple. Mm-hmm. And it's easy for it to write. ⁓ but as we found out from Dexworthy and other people, if you let it keep doing that, pretty soon you've got such technical debt that your code doesn't actually have any design. And anything it actually does is an exception to the design it may have started with. So it has completely lost its place. So back to my setup. What I'm interested in is understanding the code, seeing the opportunities to improve. its knowledge representation or it's ⁓ if you care ⁓ its ecological carrying capacity right so that it becomes more coherent over time so that's my goal and to do that I've been dividing things up. So I have a number of tools I'm helping to build. ⁓ some of them are architectural retrieval. So you can point it at a code base and it or set of code bases and it can describe them for you

speaker-1: Okay. All right. Yeah.

speaker-0: What deploys where? How is it built? What are the units? What are the tests? What you know, what's the technology base have what have you? So that's one of the tools, which by the way is really handy if you want to diff the results over time. Mm-hmm. So one of the things I'm hoping to do is build a really nice architectural tripwire. So I can take a look at, well, what it was it like today? What was it like six months ago? Has it leaned into the guardrails or has it crossed out of the guardrails? Mm-hmm. And that's good for, you know, security and and testing and just all kinds of different things. But then a lot of the tools I'd building are really more internal focused. So getting information from the Git revision history and from the actual code itself about, you know, what what are its shortcomings? So on top of that, we have skills for testing and refactoring. And yes, I do TDD, yes, we do test first. ⁓ yes, I do atomic commits, yes, I do ⁓ have strong commit disciplines when I'm good and slightly weak commit disciplines when I'm not, but we don't take the code and divide it into commits. We commit what it is right now. The version that was actually tested on my machine. So little things like this that help us to focus and of course to manage the cognitive load because You know, if you're trying to do seven things at once, you're gonna give one seventh of your brain to each.

speaker-1: Okay, awesome. All right, so there's loads to dig into there. I think the first thing that struck me is this, think we've all seen this instinct of an agent to basically do the simple thing, right? Do something that's visible and not actually think about, you know, the abstractions about the architecture. It will generally, you often see it almost explaining its reasoning by saying, okay, I did the minimal change I could do. Right. But that minimal change probably eroded the models, the architecture. It probably wasn't where it should have been. It was just the least risky change as far as it was concerned. Right. And I guess that was the same when we were writing code. Well, you kind of often there, the correct thing isn't necessarily the easiest thing to do. Right. You might introduce a new abstraction or something like that where something new to represent it properly. and it sounds like you're, kind of looking at this already, but Have you, you kind of this point thought about ways, how do you, how do you persuade? How do you guide the agent to actually do the right thing? Not the simple thing.

speaker-0: I find that ⁓ A lot of it is that it needs to know what to reason on. So so you and I, as experienced developers, you know, we have years and years and years of experience. We've seen things go well, things go badly. We have a base of information, an evidence base that we work from. Or if you prefer, ⁓ a well trained intuition, right? Intuition's a great thing, provided you've trained yours, you know, the same intuition that that ⁓ that tells us to to organize our code a certain way. ⁓ in an untrained intuition, it would tell someone that ⁓ you should bet on a horse that starts whose name starts with A on the full moon, right? It's like, well, why is that intuitive? Well, because they saw some connection there at some point and they never researched it beyond that. They just so intuition can be shallow or it can be deep. And the thing I love about people who've spent time at their discipline is their intuition becomes quite deep. Hmm. And ⁓ Merrick talks about that with his wife with large animal veterinary, how they can walk into a field and see the two six animals among the the forty or fifty animals in the pen. Yeah. You know? It's a deeply trained intuition. So the question is, what is the double for intuition for an agent?

speaker-1: Okay. Exactly. Yeah. I think that this is going to be partly the trick, right? It's, it's suddenly, can't just be intuition. We have to somehow describe this as much as we can of this intuition into something that the agent can consume and use to make the right decisions. And I think the trick now is working out in, how do we do that? And what format, what does that even look like? I think that's what people, everyone's talking about context and that's kind of maybe what we're getting at, but, Is that something you've explored? Have you thought about that? yeah. How do you encode your intuition?

speaker-0: Yeah, that's been my past eight months heavily. ⁓ so there's a couple different layers to that, right? So on one hand, we have the ⁓ nowur ⁓ programming as theory development, right? So there's some things that are broad and kind of principles and heuristics at a high level, right? ⁓ that's not necessarily the best place to start. Because any broad principle is lost on the next sub agent. So it's a it's a difficult game. You can give it some. So the more mechanically it could be described, the better off they are. Well, that gets tough, right? The answer isn't, well, when you touch three variables in in three in parameter lists and at least four functions write a ⁓ data object. Well, that's that's not a good rule. It doesn't make sense. It doesn't work very well. So then you think, okay, well, to tie anything that's principled about what is good carrying and down to what is good code, then the difference is ⁓ you you and I know where to look. Right? You open up the code and you go, ⁓ it's something over here is not right. So knowing where to look is half of that. I I remember once I had trouble with something on my car and I couldn't figure out how to get to it. And my dad walked over, grabbed a wrench, took three parts off, and there it was. And it's like, Well, I didn't realize it was underneath there. Well, you he knew where to look. You know, he'd seen enough of

speaker-1: Yeah, that deeper intuition.

speaker-0: Yeah, there's there's a basis for his intuition. So then I got thinking, well, that's that gives us a couple things to work from. And one of them is how do I provide the evidence base for my agents to do the right things? Well, you don't want them to read all the code. That's pretty spur and spending $140 in tokens per half hour. You exactly

speaker-1: Exactly, to extract those important patterns out, don't want to reverse engineer that every time, right? No. must be a more efficient way.

speaker-0: I think it's a perfectly fine first experiment, take a small code base and say, Hey, find where something might be true. but I think that that ⁓ once you went ahead and run out your tokens on that one, you might want to go back and think, okay, what tools could we build that could do this for us? Right. And so far I've found three key areas and who knows where I'll be, you know, by December, but one of them is the version control history. We've got Git, why not use it? Yeah Well, ⁓ what files change together?

speaker-1: Okay.

speaker-0: That's that's a key piece of that, right? So if I find these seven files, when I touch one, I have to touch the others. There's something shared there. And it may not be an include member. It may not have any relation at all in the code, but they keep changing together. So the version control history tells me there is some kind of coupling. And as you and I know, implicit coupling is the worst kind of coupling. Right? Shared secrets. They both know the same algorithm. So I know.

speaker-1: Yeah, okay.

speaker-0: When I go change and add another switch case over here, I have to add one over there. And how do I know that? Well, because I know that. Nothing in the code, you maybe I could grab and find them, maybe I couldn't.

speaker-1: Cause I spend one night trying to work out why the thing that I intended it to do didn't do what it did until I found this other bit of code somewhere else, right? Yeah.

speaker-0: So the things we learn by actually maintaining it, I think are a kind of deep wisdom. ⁓ So that's one piece of it. And I think that's important. ⁓ so we recognize that co-change is meaningful. So I have a clump of files on my right hand side. It's 15 files that tend to change together. And on my left hand side, I have seven files that tend to change together. And between the two groups, they have one shared member. There's a bridge.

speaker-1: Okay.

speaker-0: Between two big change groups, and both of those chain groups change fairly frequently. What bridges them together? What strings them together? What is the one piece that keeps is it injecting the changes or is it a firewall between the changes? How is it working? Does it have dual purposes? Is it an adapter or is it something else going on, right? So seeing bridges is a thought.

speaker-1: Yeah, so I mean, I guess you're using AI to analyze this as well, I would imagine, right, the Git history. So what kind of things are you, obviously the patterns of what changes together, mean, how have you discovered any efficient ways of representing that in a way that the agent can then use effectively? This is going to be the trick, I guess.

speaker-0: Yeah, so ⁓ I've built a number of tools that are are purely deterministic tools. Python scripts, they don't use any AI themselves, and they spit out tables of things. So I build a number of commands. I'm not yet converted into MCP servers. I I know that's the next thing. I know I gotta do that. But right now you can invoke them and ask them for things, and these tools will come back and give you a a table of results, typically in JSON, but That's not always the best form for an agent to use, oddly enough. I started in JSON thinking, well it's a program, it'll ingest that better than text and it's like nope, nope, costing more money to read the JSON than it is to read the text. Yeah. Who knew?

speaker-1: format. We thought JSON was a lightweight format, but it doesn't even need that, right?

speaker-0: No, no, it's it's too heavy. So ⁓ I it's producing things like ⁓ change neighborhoods. Here these are this is a set of files that change together with a ranking of how tight the affinity is within the group. ⁓ this file, if I change this, these are the other files it has the greatest affinity to. And affinity is I I come up with an algorithm, I'll I give it away for free. ⁓ it's really simple. You have a commit, it has more than one file. Because if there's only one file, it's completely uninteresting. Just nothing to tell about it. But let's say it that has one other file, a commit, two files in it. Well, it's one over the number of files is the affinity factor. So one over two, I apply it to each of the partners in that group. If I have seven files, it's one over seven for each of the files. And this is the most obvious algorithm in the world, I know. But the bigger the commit, the less meaningful it is as far as affinity. Okay, so we add those all together and at the end the ones with the highest affinity are the ones that are, you know, highly correlated and co change heavily. So producing these neighborhoods, then the code can look and see that. Also, you know, I we've edited this file. What are the files that change with it? Did we look at those yet? Maybe we need to make changes there too. So prov providing that, then the LLM looks at this information that it's just been given. And if I'm doing a a full refactor run, it's like, find me a good target. And I'll say, well, this file is the most changed in the past twenty days. So it it's it's heating up. It's getting a lot of change. And its neighborhood includes these other files. Two of those are cooling down. So we're not really interested in that. They're drawing fewer and fewer changes, but three more are changing with it. Okay, well now the LLM is like, why is that? And now it starts looking at other evidences to dig in a little deeper, and it'll probably come up and say this file needs to be split, or these files need to be combined, or here's a common factor between these three files. We need to extract that into a fourth file so it can change by itself. And of course, that is guided by having a sense of hexagonal architecture and understanding the code virtues.

speaker-1: Okay. Okay. So I think, you know, it's, certainly going to be some great tooling, I think that would provide, provide this, this abstraction. What about the actual developers? You know, if you're a, if you're a tech lead on a team or one of the experienced developers on a team, we don't necessarily need roles. How do you impart some of that intuition that you've developed on that code and put it into, for example, the Claude MD and things like that. Have you seen engineer? Yeah, yeah, yeah. What kind of ways? It's so tricky, right? Because it's so hard to even identify what is going to be the useful bit of intuition generally. And then perhaps even prompt level as well, right? So when you're working on a task, you know that when you're working on the task, you're going to need to change why or you're going to be super careful about this bit of code. I guess, you got any advice for developers when they're working as a senior developer? How do you impart that knowledge? Because I think it's too easy as a developer just to get lazy, I think, in a sense, and just the models are getting so good, right? They just seem to kind of work it out and they produce this code and you're like, yeah, it's okay. But I think over time, you know, you always, it takes much longer to fix it, especially if it's something architectural, right? And you don't really want to catch it at code review, right? So how, have you got any tips for developers on how to guide the agents in the most effective way?

speaker-0: So a lot of what we've been doing is building it directly into the prompts and skills. So ⁓ for instance in the development skill, one of the first things that we'd we'd do is we'll run a skill that will help us divide it our work down into end to end deliverable, deployable slices. And you probably do five of those in an hour. Not not too bad work. So that's built in to begin with. And since it's end to end, all the tests have to run after every change. And so we'll do we'll have a a fast test suite that we do periodically and then a full test suite every time we think we're kind of done. And so any changes have to be fixed immediately. And the rubric for the changes and the rubric for the tests that's written into skills. So for instance, if I'm going to start a new slice, the first thing I do is I call preview, which is a script that we have, that updates our environment. So if you're in Node, you may do a

speaker-1: Okay.

speaker-0: The UV sync, whatever, whatever the tool is, catch up your environment first thing. And it also checks to make sure there's no leftovers from a prior slice, no files lying about that aren't part of the work you're doing. So you've got a basic discipline. And then when it starts to do the work, it's like, well, before we do the work, the first thing we do is we go to write a test. Now, if that test is hard to write, and we have this coded into a skill. We'll take a look and say, should we refactor first? And basically, you know, the posts that ⁓ Kent did on Canon, T D D, and Tidy First, that goes into it. And the stuff I've done on code virtues goes into that. So it's doing a check first. Should and it's going to use my tools available. And it's going to say, Well, this code block, it's fine. I can write this test easily. There's no problem.

speaker-1: Okay, there-

speaker-0: The test needs to be fat, you know, first principles. Bret Schuhhart and I came up with the first principles a long time ago. ⁓ so, you know, is it fast, independent, self validating, timely, you know, all that good stuff repeatable. ⁓ so it's it it tries to write a test that meets the rubric against the code, and if that meets with any friction, then it's gonna try to refactor the code to make it easier.

speaker-1: Wow. Okay. Okay. So you're so, so you've got to, you've got a signal there for the actual agent working on the task to, start a refactor before they even try and apply something. Right. It's okay. That's super cool. And do, and do you then, do you then review the test before they work on implementation or is

speaker-0: So here's the funny bit. I thought I would because I was super, super focused on I have to make sure I know every line, but as it happens, I'm actually right now, I'm letting it go with with refactors. It will recommend the refactor and then stop. So I'm gonna know what kind of a thing is it is doing? What data type is it gonna extract? What function is it gonna extract? And and I can look at that in the preview window where it shows the diff. And I and I I'd give it a glance, I see what it's pointed at, and I think, well, either that's a good experiment or that's a stupid idea. So I'll answer accordingly. ⁓ and if it usually is pretty good. I've been surprised how often it's been good. So I let it do that, and then it comes up with a test, which I could then stop have it stop after the test and read that, but I tend not to, because the rubric is that you don't write the test against the code, you write the test against the requirement and connect it to the code. And of course it's going to run and go red, because that's part of the rubric. And then it's going to go make a change to the code, make it go green, and then it's going to do one more refactoring run and stop if it has recommendations.

speaker-1: Okay. I really like that. your, your stop signals are generally, I'm going to refactor. Like whether that's before, before or after the test. think I've not heard that at all before. That's completely, that's, that's the first time I've heard that. think that's great because that's some of the most critical decisions, isn't it? Right. Do you just plow on or do you refactor or is the refactor, you say, is refactor a terrible idea? They're the most critical decisions on, for as far as not accumulating tech debt.

speaker-0: There's a when I when it's not grounded in the tools and skills very well, ⁓ it'll start picking up things that are just coincidental duplication and suggesting to refactor those out. And that really upset me because I didn't like that. So one of the tricks I've been doing is I have my skills in a as a project. And when I get to a point like that, I think, you know what that's missing is the article we wrote on coin spot. Yeah, single point of of truth and coincidental duplication. Anthony Shimana and I did that one. ⁓ I'll get that article, I'll pull it in, and I'll ask it to apply that article's advice to my skill. And then I'll try it and see if it'll reject the stupid refactoring that it would have perfectly, you know, reasonably done that would have been a bad idea, and see if it now comes back and says, ⁓ those are different facts. Those are those are just different implementations. They're not, you know, they're textually similar, but they're not the same thing. We're not going to do that refactoring. And I go, yes. And I check that one off when I push my skill to the repo. And so I built up a number just by feeding it articles in the past.

speaker-1: Okay. It's really interesting. Yeah. Cause it sort of occurred to me that, you know, the engineer's role is the developer's role is really changing now. And, and all of the, writing that's been done, the writing you contributed to, you know, all of that, the stuff that really came out of XP, think, right. lot of it from my perspective came from that era era. It's now more relevant than ever because these are the critical decisions. And if you could teach the agent to code in that way. then you're going to get a better experience all the way through. So in future, are we not going to be writing books, we're just going to be writing skills for the agents? Or is it still the engineers job to read the book?

speaker-0: Yeah. Well, you know, that that goes back to how we always did things, right? Because you and I would read the books and we would bring the the the the learning to our coding session. and we're still doing that. We're it we just do it in a different way. It's a little bit more ⁓ it's a bit more durable, ⁓ you know, and and shareable. And it used to be that I would send people articles and they just wouldn't read them. And then we'd end up pairing together and I'd say, ⁓ this is a good place for that progressive admission idea. And they're like, what's that? ⁓ did you did you read the thing I sent? And they ⁓ no, of course not. And then we would go on. You know, because I you you write a lot of things and a high volume feed is not necessarily the most productive thing to give people. ⁓ so that's fine. So we can, you know, embed it. But still when it comes up and it says, ⁓ I was looking at this, I was going to refactor this, but I've d I've realized I don't want to do that. So now the top refactoring, if we're going to do one, would be to extract. this piece of this method and make that a method on this data object rather than where it is. And it will show that to you. You can say yes, you can say no. You can think it through. Hopefully you've read the book, you know what you want, ⁓ and you can say no to to trivial nonsense. But you can also say yes to things that are actually going to make life easier. But there's a filter on that that again, articles, right? So I had the seven code virtues that were out there for a long time. Mm-hmm. And then I started using it agentically in last fall, maybe winter. And it didn't seem to quite land the way it ought to.

speaker-1: Okay.

speaker-0: And so I came up with coherence after I did a bunch of research. So by the way, there's another AI use. Go to consensus, ask what what studies do we have? What are the authoritative papers on such and such a topic? Weed them down to the ones that seem to make a lot of sense to you. Bring those down. Actually go through them, read every word, figure out where you want to be, bring that into your your skills. So I realized that I landed on this carrying capacity and knowledge representation idea that, you know, which I've known for years, but it became tacit. I just never thought about it. It was just there. Digging into that, it's like, well, this has actually been very well explained, right? And the principles for modularizing systems and again, software as programming as theory building and all these wonderful places. So I pull those in and chomp chomp on them with a couple a LLMs and with myself and with every first thing in the morning waking thought for a while. And it dawned on me that there has to be an eighth one and that's coherence. And coherence is that that the longer you work on it, the more it fits together. It's like, well well how do you describe that? And we came up with the idea that if you learn something in one file, you can apply that in another file. Every place you go, you can apply the knowledge, which goes back to my naming skill book and even before that we talked about profitable labor and unprofitable labor. And I'll I d detour to that for just a second. Okay. So you give me a function to read, and I open it up, and it's nested deeply and has a whole bunch of primitive variables and booleans all over the place. And as I read it, I'm not encountering anything that's unfamiliar, but I don't know why the heck is it put together this way and what is it trying to do. So I I puzzle through this whole thing and I put, you know,

speaker-1: Yeah, go. Man. Okay.

speaker-0: my five thousand intellectual credits into it, right? And at the end I know what this piece of code is doing and I can make a change. What can I leverage when I go to the next piece of code? Nothing.

speaker-1: nothing is all primitive. it's kind of, yeah, you haven't learned anything about the system really.

speaker-0: Yeah, I've I've just deciphered while loops and for loops and ifs and complex Boolean expressions and I've learned nothing except how this one function works. Well, that's pretty worthless. Now let's say you give me a different function and I look at it and you're using a language feature I've never seen before. So I look it up and by golly, it's in the standard language definition. It's been there for seven years, but I've never seen anybody use it. Now I've got to figure out how that works. So I gotta go read the man page. I gotta go read the article, the little explainer article. I have to go see what sonar source says about it, because you know I can look things up there too. ⁓ and turns out it's actually pretty handy and it works well in this situation. When I leave this function, that stays with me. That was a profitable labor. Okay. So the idea of coherence is

speaker-1: Okay, yeah.

speaker-0: That as much as possible the labor is profitable labor, that you what you get here you can spend somewhere else. Hmm. Or what you spend here gives you something free in the next spot. Well, that's the s that's the essential concept of coherence in a code base. Right? I don't shy away from having it use brand new language features that I don't know. I think that's fine. Because it's quick to learn ⁓ now.

speaker-1: Yeah. a good example of using that language feature then that's the best way to learn it in a sense right you saw the problem i was like ⁓ great this is an elegant way to solve this problem in this case right yeah

speaker-0: And if the use of it and the naming of the function are good enough, I learned something that I can now use in many places. That name means something in the domain. It's consistent with usages elsewhere in the code base. The idiom it used is consistent with how the language can be used well. So coherence is just about making this a a valuable experience, minimizing the wasted labor so that all the things you learned you can apply. Okay.

speaker-1: Okay. So the, I guess there's, two, the usual scenarios. One is you're working on, let's call it a legacy code base, right? It's been around for a while. It's not in the, not in the state that you would like. I think that that creates a real problem for an agent in a way, because the agent will mimic what it already sees, right? It will continue to follow those patterns. So one way we've got to try to guide the agent to, to to take a better way. spoke to someone else last week and they were like, okay, this is the point where you just have to start on refactoring. You've got a refactoring job to do. The agent can help you with the refactoring. you, you tried that on legacy code basis? I'm guessing you're probably working. How much, how much kind of fun have you had refactoring with an agent?

speaker-0: I love it. So it is probably the most fun thing. So we take it so I mentioned, you know, I have some special tools. So I I take a code base I've never seen before. I run the architecture recovery tool on it. So it gives me a sense of basically what's there. I try to digest that as well as I can. I dive in to to make a change. Of course it's gonna say we we're gonna need a test for this, you know, once we find it. And there's a whole bunch of good navigation tools.

speaker-1: Okay.

speaker-0: that are on the market right now. I'm I'm trying a few of them. Graphify is not a bad one. but there are others. ⁓ so you know I try try to find the place where it is. And then the the rubric is to not write the tests against the code, but to derive the requirements from the code. Which is a little trickier. and Mm i if if perfect was a hundred percent, it probably gets somewhere in the course of fifty to sixty-five percent backed away from the code, which is actually an awful lot to ask for from anybody. So the first few tests, you know, it's gonna write some tests on it to cover the code I'm going to write. ⁓ and it'll do a pretty good job. It'll do a pretty good job. ⁓ I can get ⁓ ask it to be comprehensive. And cover all the paths. And it mostly does. We're like 70, 80%. But you know, 70 or 80% is a pretty good place to start. And now, you know, that's probably enough to do some refactoring. Yeah. And then the refactoring makes the test easier. So you you start re-reshaping that a bit. You get your new tests in place, right? And now it's now you're in a a comfortable position and you can move forward. But what you've done is weird because you've cleaned the bottom left corner of Fibber McGee's closet, you know. Everything is piled in there except for that one corner. And does that make the room better or worse? Hm. And it could actually be that you've made it worse.

speaker-1: Yeah, so you did the coherence is now it's almost lying the new bit right because the rest of the code isn't the same right.

speaker-0: Yeah, it's reflecting its partial understanding of this partial area. So then you have to run a bigger refactor sweep. So it's going to use the the tools that it has to to build up a base that it can then infer a good change from. And it's going to suggest things. And I'll be saying, Hmm, yes, that is a high value change, and we're not going to do that. That's absolutely That that's out of bounds. And what's this next one? Well, this one is good. Well, this is very, you know, low effort. And it's like, yeah, it's also low, low reward. You know, so you I'll pick out of the top five, I might pick one or none. But I remember I'm gonna come back here someday if this is still working. You know, it we needed a change today, we'll need one later. This is still changing code. Yeah. So I will take good enough for now, quite often. ⁓ but every once in a while, man, it comes up with a whopper. It it really is like, you know, this there should be a concept because these seven variables always appear together. And there's a bunch of functions that take nothing but this set of seven variables together. And it's like, ooh, what's going on with that? So trace that. Tell me where that's being used. Where's it come from? Where does it go? Give me a sense of what it's about. Okay. Yes, we definitely need to pull this out and make this a named class that carries those variables. And these functions that Only take one instance of the class, those are instance methods. Move them in, you know. Let's let's just do this thing. And sometimes when you do that, you know, you end up with ⁓ you've made a l an improvement in your code and it's now five hundred lines shorter than it used to be. And I just

speaker-1: Yeah, yeah, those are the best bits. It's kind of interesting. think refactoring was always an expensive business. It was hard to justify. It was always the job of the team to go, no, no, we need to invest more time refactoring. And we would try to find ways of trying to hide that cost a bit, you know, and just kind of do it incrementally so that it doesn't look like a cost. But it was always cheaper than the rewrite, right? The rewrite was always multiple times more expensive than anyone ever estimated. Now, agents potentially changing the economics of refactoring is really interesting, right? It's kind of like, we could actually see those legacy systems finally actually start improving and that becoming a viable thing with the right guidance, right? And I guess it's, it's how, you know, with the agents, the models continue to get better, better and better at this, then it just becomes more viable.

speaker-0: Yeah. So I think that's probably the the key, right? The agents make you not afraid to try. ⁓ And partly that's because there's git underneath them. Yeah. You know, the fact is I could just do a git reset hard. Everything it does is disposable. Even if it does like a twenty seven hundred line change across five hundred files, get reset hard and try it again.

speaker-1: Yeah. And it's relatively fast. mean, you could create a, you create a Git tree and just get it to go and run on this and come back and see, try three or four different approaches at once. Right. If you've got the tokens available, you can, you can take quite, you know, relatively expensive routes, but still a lot cheaper than humans kind of working through it and, and experimenting more cheaply.

speaker-0: If refactoring was hard, testing was even worse. Everybody's like, ⁓ I'm not gonna change my code in order to write a test. I've got it working, I'm not gonna touch it. And now it's like, Yeah, here give me give me give me a a comprehensive set of tests for this function. Five minutes later, you know, you've they're all running and everything's cool and you know where you are.

speaker-1: Yeah. Yeah. I think it's, it's an exciting time for software engineering, right? There's so many things, good, good engineering practices that are now more viable and more economic than they were previously, right? Where there just wasn't enough good engineers to do them before, but now we can kind of multiply that, that it's, ⁓ it's really good. Yeah. I guess, I guess that leads us to

speaker-0: Friction out.

speaker-1: We're going to a greenfield, right? A greenfield is another interesting one, right? How do you set the agent on the right path in the greenfield? It's probably another episode there, I guess. That's something we'll come back to. But what about, think more about the human side as a developer. If you were a young developer coming in now without necessarily the years of experience working on code bases, how do you get up to speed? How do you learn what you need to learn to become a good software engineer? Especially as you're not. I don't know. Maybe you are still feeling the pain of, of, sure. Maybe you're feeling it faster, but I think everyone's kind of worried because they're not writing the code, right? Or they're probably not writing the code, right? Maybe they should be writing the code, but that's going to be super slow on boarding. How does, how do new engineers and have you got new engineers that you're working with, sort of trying to bring them up to the right level?

speaker-0: There's a lot more experienced hires now than than than freshies. So I would like to see more fresh people straight out of school. ⁓ in my prior gig with Industrial Logic, a lot of what I did was running boot camps for companies that have hired people, you know, straight out of college in the past year. And so I would get twenty of them at a time and put them in a room and we would work together. And ⁓ you know, the same things that used to work still work. Reading a lot of code. Reading a lot of material, ⁓ writing a lot of tests and running them, building something, working with another human being is huge. Hm. Right? And, you know, well, why did you do it that way? Is always such a good question to a I always get people picking on me because I always had a book in my hand for my first fifteen or twenty years. ⁓ you know, it it's a lot of work to learn. There I think now What's useful is we do have tools to tell us what to read. You know, if if we can ask a smart question, they can give us some good answers. Mm-hmm. And and that's still part of it. You know, some of the things I've dug dug into, if I didn't have, you know, consensus and chat and GPT and and Claude, I don't know if I'd have found the right papers. Yeah. You know, I'd have probably read a whole bunch of books I didn't need looking for the things that weren't in it. ⁓ again, it takes the fear out, you know. It's like, well, this is This is likely where I can find these things and also I can ask other people 'cause we have social social and AI and Git together are are it's it's what we didn't have in the eighties.

speaker-1: Yeah. No, exactly. Yeah. Yeah. And I mean, the agents are generally very good at explaining the code, right? They do. They do have the knowledge, right? They have the good engineering knowledge. They're just not necessarily going to apply it in that context. I think that's the thing.

speaker-0: They can look everything up when you ask. Hm. They don't necessarily go looking things up before.

speaker-1: Yeah, yeah, yeah, yeah. Yeah. If you don't ask them to look up, you'll get something dated usually, right? When the mod from when the model was trained or or missing some, some important things.

speaker-0: I worry about with the the young engineers is though, you know, it is an expectation of of doing so much so fast and so many things simultaneously. And I think that that's quite harmful. ⁓ you know, if I'm not really paying attention and I'm in three meetings or on three screens, I'm not learning anything. ⁓ So the ability to stop and do one thing at a time, that's what Michael Feathers said. programming's all about. It's the art of doing exactly one thing at a time.

speaker-1: Yeah, folks are one precise problem at a time. Yeah.

speaker-0: Yeah. So, you know, with working with somebody who knows the area or knows the language or stack. I still go into stacks I don't know or don't remember. ⁓ having someone there and when we look at the things, well, why or why not? Why would you not do this? ⁓ well, because in Angular it's not like in React, you have to do it this other way. You know, why would you do this? ⁓ this is Rails and Rails does it this way by convention. If you go against convention, you have to fight with it. And you know, so there's reasons why and you have to acquire those by paying attention. Yeah. And what you learn each day tells you what to learn for the next day.

speaker-1: So if you doing the boot camps today, would you be letting the students use an agent or would you be teaching them to hand code?

speaker-0: We would probably do a bit of both, ⁓ but I would certainly allow them to use agents. And ⁓ we would we would learn to temper those agents, right? So one of the things that I didn't used to do, and now that that we're all agentic and all all fancy and shiny, ⁓ mutation testing has become really important. Yeah. You know? Yeah. That's one of my problems with boot camps is people would write the code and they wouldn't write the test and then it would fail in CI. And I would go take a look and I'd say, You haven't added any new tests with your code. Well, I figured I'd do that once once it got working, I could come back for it. And it's like you you you think that because you're young in the in the field that you're gonna come back to it. But all of us know that that doesn't happen. If you don't do it while you're there, you're never gonna do it. And it'll always become the reason not to go back, because if you go back, you'll have to do it. So, you know, people quit their jobs sometimes just so they don't have to go back into that code. ⁓ so if we can, you know, automate the mutation testing, incremental mutation testing, you know. And and use tools, you know, like like Sonar Cube's ⁓ clean issue code is I think a a great idea. It just looks at the stuff you've been doing. It's not looking at everything and visiting the sins of the grandfathers to the third generation. It's just looking at what you're doing. ⁓ that kind of incremental work I think is key. Lint is one of the best teachers I ever had. When I was learning C, I ran Lint in strict mode and I read every warning because I knew I had a lot to learn because it's telling me things that it can figure out, being a dumb program that me as a smart human didn't know. So this is acquirable knowledge. And I think that everything we do that that takes away from focus and curiosity is an inhuman task. You know, agents are good at working without curiosity. And and they're good at working without principles and they're good at working without focus. You can have them do that kind of stuff because they're machines. But all the most important things you need someone thinking and learning the whole time.

speaker-1: Have you used codecs and the GPT models or are you on the Claude site?

speaker-0: So most of mine is co pilot, Claude, and whatever warp two is doing.

speaker-1: Yeah, it's interesting on codecs. So on the codecs app, it gives you these kind of snippets, which you can't, you can't like break down and look at afterwards. But it looks like it's the reasoning of the model. And, and they have it expressing in a very human way, which I imagine is a, is a kind of artificial thing, to some extent, right? It says things like, ⁓ this is interesting. And, well, that was exciting and stuff like this. It kind of does that. But it's not like Claude's just completely like random words. is actually, looks like it's like, ⁓ I've been waiting a long time for approval here. And you could see the expressions on it, but it's interesting you said about the curiosity that they almost faking this kind of curiosity. Like this looks, it does say this looks interesting when it goes down a path, which I guess they're kind of layering somehow, you know, on the, when it's going back into discovery mode or something. That's interesting. I think. I think, I mean, from this conversation, two of the things we've really picked up on. Right. The beginning you mentioned about the slicing is really important, right? And that was always one of the hardest things for a developer and we're working with a product manager or a product owner or whatever actually getting down to sensible slices. And I think I hear that a lot, right? It's so easy to let an agent go off and do way too much, right? And then you cannot verify it, right? So that kind of guiding it to work in a good increment and then having the skills to verify there become the most critical skills for a developer now? Is that kind of what you're seeing in a sense as much as the actual coding?

speaker-0: ⁓ yeah. ⁓ yeah. There's even a mandate, you know, that and our company has one that at the end of you know a certain period of time, you have to demo the work that you've completed. So if you go into this and you start doing brick making, you know, and now I've got, well, I've got five hundred and eighty-three bricks out of the thousand I need to build the wall, how are you going to demo that? There's no way to show that. Well, that's always been a problem, right? It's always been we wanted to use the Walking skeleton, tracer bullet, pick pick your name. ⁓ because you can show what you're doing and instead of the fact that w a hundred percent of the work is now eighty percent done, you know, it's now eighty percent of the work is one hundred percent done and I could show you every day what I've completed. I never have to go dark. You can always take a look at it and it's like, Well, hey, do you have this in yet? Well, here, pop it up, show it to ⁓ Here it is running. ⁓ so it's all done? Well, no. Th but this much of it's done. It does these things. Well, what's left in it? Well, these these other seven steps. You know, it it's not doing those yet. You know what? I don't think I care about those. Let's go on to something else. And letting people be able to steer around things as opposed to committing to the full course and having to complete it all by a certain date and until then it's all a disaster. Who needs the pressure, man? Slicing makes it all so, so much more pleasant.

speaker-1: Is this going to be an agile revival? We know we've seen agile sort of tailing off a bit in the last few years. It kind of see that's a whole different episode, right? But, but actually it seems like those fundamentals that were that were there in the core of agile and now more important than ever, right? It's really about it's about the understanding the system while breaking it down into the right size, really good verification through tests and things as now absolutely critical, right? Well, it was always critical, but it's now more of the developer's problem. say, right.

speaker-0: Actually, accessible. It's not such a high shelf. I think that ⁓ I think you're right. All the things that were always important are still important. And the people who are doing the important things are getting, you know, some big boosts. ⁓ there are other people who are getting big boosts at doing the wrong things. You know, things that are good for the first hundred yards and then taper off and by the end of the mile they're completely intractable. And people are gonna do that probably still, you know, and Let them. Let them. somebody was talking about how they're concerned they are because they have people who have no coding background, you know, maybe they're a product manager or something and and they're cloud coding up and one-shotting an app and go, look, this thing works. Let me show you how it works. You know, and of course it's it it probably does. ⁓ If you stay on the on the paved path and And don't think too hard and and don't go too deep, it probably does the thing, you know, in a shallow way.

speaker-1: Well, it's 80 % correct probably, and it's that final 20 % of correctness that is 80 % of the work.

speaker-0: It's absolutely not production ready. But you know, it's there. And people are like, ⁓ that's just terrible. And and I'm thinking, no, ⁓ we had that with spreadsheets. We had that with ⁓ what was what was the Microsoft thing? ⁓ access. Yeah. And and Power Builder. And you know, we we've had this a million times as some technology comes through and some people have been able to solve their problems using spreadsheets. Yeah. And per

speaker-1: Yeah, there's perfectly good applications. I think, you know, I've talked to a lot of people and they're like, okay, well, the big, the early win that I got the low hanging fruit was basically vibe coding a whole bunch of like internal kind of apps that I could never justify spending time on in the past that gave me a bit of data analysis or looked at some logs and brought something back there in a good enough way to give me the signals I needed. And it wasn't mission critical. But it was really useful and it helped me do my job, right? And, and I just run those overnight and use them in the morning. I didn't worry about the code at all. That's super useful, right? But you're not going to do that for your production banking system with billions of pounds going through every second. right. So it's a different, the right, right, right. level for the right, for the right application, I guess.

speaker-0: I think that's I think it's a fine thing. And I think it will bring, you know, some new people into the ranks. And maybe at some point they'll some of them will decide, well, that's as far as I want to go. Some people are happy with spreadsheets. And then let ⁓ let ⁓ And then there's other people who are gonna be like, you know, what would it take for this to be commercial? And it's like, Okay, now now come on in and suit up and that's that's let's go to work. Yeah, yeah, yeah. And and that's a cool thing. And probably now with the tools we have already. We can take a look at their vibe coded app, figure it out, get it get a good solid summary of it and requirements that they've written, then take a look at our actual app and start having it help us reason about how to bring the two together. You know, how can I re implement this in a production worthy way in our system using our patterns. And if we find ways to reconcile their one offs with our actual production systems, how is that not a win win?

speaker-1: Yeah, absolutely. You've got your prototype. Let's turn that into something production ready in a reasonably efficient way. Whereas before that was a big mountain to climb, right? It could be a lot easier now. Yeah.

speaker-0: Yeah. I I think that the lack of fear is a beautiful thing.

speaker-1: Yeah. Yeah. It's good. Excellent. All right. ⁓ I don't think I've asked you any of the questions I plan to ask you, but we've had a fantastic conversation. I think we're good. I think we're great. I'd love to do it again. Is there anything before we finish that you'd like to share or anything we've not talked about or any other interesting things going on with you that you'd like to talk about?

speaker-0: In Clean Code, I wrote the book on the the chapter on naming. It it's an anthology, you know. A lot of people don't know that because only the primary author and editor's name is on the front cover. ⁓ but it wa it is an anthology. And a number of people contributed I contributed a paper that I'd written earlier on naming and that that's chapter two and people really like that. And then people have had come to me saying, you know, I I like your chapter, but I don't like the book. And if I could just have the chapter, it's like, well, I could give you the chapter. But then I looked at that and I thought, A, why would I cannibalize, you know, an existing work? A, and and B, that's not nearly enough. That's just a chapter. So on Lean Pub, there is a short guide to naming, and it totally reworks it instead of being a rule based, don't do this, do that, yes, no. It really is based on principles and heuristics. And ⁓ It's not only fun to read, I hope. ⁓ it may still have some defects. I I haven't been through with my professional editor yet. It's it's young. ⁓ but also it's pretty good to convert into a skill if you ask your agent to take the content and build a skill from it. People who've done that have been pretty happy so far. ⁓ so you can build your own if you don't want mine. I'll release mine later this year, probably somewhere on a public place. think

speaker-1: Okay.

speaker-0: Think about these things. There, you know, most of us who are authors, we could have agents start condensing our work down into skills that we could publish. And whereas, you know, we couldn't get people to buy and read our books, I bet you we can get people to run our agents and skills. And maybe that's the new publishing realm. You know, maybe doesn't there was no money in books to begin with. So why not?

speaker-1: effective skill and here's what you should read if you're using it, right? You need to understand and you've got something more directly applicable and here's the background you need to understand, right? Yeah. So it was the documentation for the skill. yeah. I like it. Cool. All right. That sounds great. Okay. Well, thank you very much, Tim. It's been fantastic. And thank you for sharing that. It was super interesting and hopefully we could do it again soon.

speaker-0: So see you soon.