#195 - Working Effectively with Legacy Code and AI Coding Assistant - Michael Feathers

Legacy code is code without tests. If you have code and has lots of tests, and it's relatively easy to change if you don't have the test, you're really in serious trouble. It's a strong qualitative difference between those two different types of code bases. If you want to teach good design, basically teach people the things to avoid and everything that's left is good design. I was kind of shocked in the beginning to see her vendors basically go and say, hey, we're

going to write all. Your tests for you, yeah. You know, as the TDD guy, you're looking at this and you're saying, Oh my God, no, right. But for characterization testing, it's really kind of powerful because for people getting much more realistic now, I think in the very beginning people started going and extrapolating and they just get completely. Freaked out by the possibilities, right? But I think many.

Developers now have enough experience what they are and they realize it's not going to replace many times at. The end of the day, in the legal system, you can't go and say, oh, the algorithm did it. It's like, no, a person who works at a company did this. At the end of the day, we are responsible for what we do. Hello, guys.

Welcome back to another new episode of the Technical Journal Podcast. I'm very excited today to meet Michael Feathers. So we kind of like met nine years ago in one of his workshop back then in Singapore. So I think today is the first time we met again after that such a long time. So Michael, really great to have you here. Welcome to the show. Great. Thank you very much.

Right Michael, for people who may not know you, so maybe in the 1st place, can you help to introduce yourself, maybe telling us a little bit of highlights or turning points in your career that we all can learn from? Sure. So my name is Michael Feathers and I guess the thing I'm best, whoops. Here's the thing I'm best known for within the industry.

I was writing a book called Working Effectively with Legacy Code and I was involved in the early agile movement before it was even called Agile. Right. And I spent a lot of time since then just helping people with like legacy code and refactoring issues. And yeah, that's just been a thing. I've been very much interested in fighters that I spent about 9 or 10 years programming, worked in various roles through the technical hierarchy and. Yeah, just sort of kind of gone

on from there. Yeah. So I think your book working with the legacy code, right. I think now it's like the in the 20th anniversary. So Congrats for that Saturday I think. Yeah, thanks for reminding me. I forgot what year was in the 20s. Yeah. So I think it's one of the so-called classic software programming books, I would say especially people who are dealing with legacy code. So maybe let's start from that

book first, right. So since you're well known about that book, so legacy code, right. So in the 1st place, why did you write something about legacy code? I guess people back then may have started working on some legacy code that is difficult to work on, or that's something that you learn along the way. Well, it's kind of interesting with that. So I went to a conference and I met Kent Beck and Ron Jeffries

back in like 1990. 9:00 or so. And I started to go and get some notice of the people that were elected balls in the very early agile movement, as I mentioned. And it was interesting because I learned so much from them. It was interesting because at that time I was a good programmer and everything, but they had really thought deeply about how to become better programmers. So I wanted to refactor. And I was doing a bit of that back in my workplace.

And they were also saying things like, you should write your test first, why would you do it any other way? And I thought this is kind of like a very, you know, bold thing for them to go and save. Then I understood after I did it for a while, and it helped me realize I could reduce the stress of programming a great deal. And so after that, I was fired to be a consultant.

I lost the tech job that I had, and the job was to go around to different places and help them acquire the technical practices that are part of Agile, right? And invariably, it's kind of like you run into a situation where people have tons and tons of code and they just don't know quite what to do with it, right? It's hard to refactor. And you look at Martin Towers back in that day and they said, OK, and a snippet. It's kind of like, here's all this refactoring stuff, but you

should have tests. And if you don't have tests, you're in a bit of trouble. So I just realized that this was a problem, and I just started collecting techniques for going and breaking dependencies and getting tests into place. And yeah, it's been an interesting ride that way. But it's also been really kind of fascinating for me because I started like a mathematics major in school and I had this interesting idea of kind of like being an introvert.

Of course, I read about this mathematician in Pauli Erdish, and it was like he lived with a suitcase and would go from place to place and sort of work with other mathematicians. And the cool thing was he didn't even have to have a piece of paper or pencil to do this, right? He just had conversations and do these things. I thought, wow, that's really an interesting thing to work on mathematics and just make it purely your life.

But then I kind of realized it's kind of like if you're doing that, you're not really helping people right directly. So I've had much more fun going working with people and realizing that I can make a bit of a difference.

And going back to my book, as much as it's very technical and has a lot of code in it, I'm only realizing now how much it was really about going and helping people keep their morale up and, you know, have a, a positive outlook to what they can do and know what they can do. Within code base. Yeah, I think the book itself, although it has been 20 years, I think it's still pretty relevant because people now, they still work on legacy code.

In fact, there might be more legacy code than last time before, right? But in the 1st place, let's go back to the definition itself about legacy code, because some people might have different perceptions, different definition. Some people think it's like old legacy code. Some people think it's code that they just don't want to touch or they don't understand. In your book, actually, you have one good definition that is probably interesting, like you mentioned something related to

test in the very beginning. So maybe let's go to your definition. What is legacy code? Actually, we've got many definitions, but the one I'm kind of known for is basically the legacy code is code without tests. And it's funny about this because this happened when I was working with the team and I had another consultant with me and I got. Frustrated at 1 moment and. Somebody asked a question. I said legacy code is code without tests. That's just what you need to know, right?

And you know, my friend, the consultant, he basically said, you know, you got to put that out. There, that's a really powerful statement to say. And I knew at the moment that we really was at odds with the traditional definition. You get code from other people and that becomes. Legacy code, right? Or code that you're scared of and don't quite understand.

But I think, you know, with all these definitions, they're pragmatic in a way because they're used to highlight something that you basically want to change. With this one, it was really just like had this. Intuitive sense that. You know, if you have code and has lots of tests and it's relatively easy to change. If you don't have the test, you're really in serious. Trouble. It's a strong. Qualitative difference between those two different types of

code bases. And so it's trying to get that across. But occasionally people will say who are you to make the definition of legacy? It's just one or as many. Pick whichever 1 you want. Pick the one that helps. You. I think it's the best thing to say like that. Yeah. So I think in the context of your definition, you have emphasized a lot about testing, right. I think in the very beginning you mentioned you learned from Kendbeck about test first.

Maybe in the refactoring book also it was mentioned that you refactor also along with the test. Why the test is so important in your opinion? Well, I think the main thing is because this is going to be kind of like getting a philosophical in a way. It's kind of like most of us walk around with an idea in our heads about what the system does. And The thing is, it's kind of like the system has its own idea about what it does. It's not an idea, it's what it

does, right? And I think that that's an interesting thing. We quite often get so caught up with what we think the system is doing and what we think it we want it to do, and we forget to even think about what it currently is doing, right? So to me, that's a very grounding perspective. It's kind of like if you really know what the system does, you have a great base point to go and decide what to do next, right?

And over and over again, I've run into situations where people, once they learn a bit more about what the system actually does, they have different ideas about what's possible. And they're kind of like, oh, you know, it's kind of like people have been asking for this particular feature and now I see it'll be relatively easy to add that. Feature, right? I've always been sort of like saying. It'll take three weeks to do this sort of thing, but now I know it's much. Easier to do.

And without that baseline of knowledge, you just really don't know that. So we talked about tests first a second ago. One of the things I talk about in the book is something I call characterization tests. And quite often people call this like pinning tests now sometimes. And the idea is that basically you write tests that you're used to describe the current behavior

of the system. So you're not writing them first, you're writing them after the code has been written and you're writing them to go and ask a question of the code base. And once you get the answer, you basically take that answer and you put it in as the expectation if the notice. This is called golden master testing. In a way it's considered like a poor practice, but I think when you have existing code without tests, it's just a way of going and actually understanding what you've.

Got. And you can basically put that off to the side and distinguish it from the test that you write 1st to go and actually sort of, you know, figure you towards creating feature understanding when you're done. So yeah, that's the thing. To me, a test is a way of grounding our knowledge of a system, right. When we refer to the tests, are you referring to automated tests or are you referring also for other types of tests?

Like, I don't know, people have manual tests, UI tests, regression tests, so many other tests out there. Right. So are you specifically referring to just automated tests or something else? Yeah, generally automated tests. You know, it's kind of like it seems like I'm finding two or two places that still do much

manual testing and all right. And I think it's you know, especially with like dev OPS and the accelerate book and everything like that, you know, it's the idea is going to get something in place with tests and have that for within an hour if you can, right. So there doesn't really leave much time with that. So generally I am talking about automated tests. Yeah, it's kind of funny.

I think most of the people that are like thought leaders in the non automatic testing space have really kind of moved into calling it exploratory testing and basically going and accenting the fact that as somebody who basically has ideas though the system. Could be doing, you can just sort of verify those and look for really terrible things and make people aware of those, right? So that's an exploratory approach.

So I think talking about testing, right, although it has been around for many, many years, right? I think still the state of the software development practice these days, testing is still kind of like lacking in terms of quality, in terms of quantity. And I know that you have written this book since 20 years ago. Do you think the definition of legacy code still kind of like relevant or is it something changing because with so many other tools, techniques and also

maybe now with AI? So is the definition still kind of like appropriate or do you think something has evolved along the way? Well, if you don't have any tests, I think it's appropriate for you. This is the best way to go and put it, right? But I think, you know, we might end up in a place where legacy just reversed and I think it passed to some degree to basically the thing that we don't understand, right? And I think that's another definition is like legacy code

is code we don't understand. So yeah, you know, there's a lot more that we can do now with in order to go and actually understand. The systems that we have when using AI through this quite often just like taking a lot of code and sort of like pulling it into a session and asking questions about it. And you know, the results have been mixed. They can, kind of. See the advantages to this now? And I'm thinking we're kind of like due. For. Let's see, it's August 2024 right now, right?

We're due for this kind of backlash and people say, oh, you know, we're just making things up. And the second to help me as a. Programmer and stuff like that. But you know, you can pay attention to the social winds of things. But I think that. This technology is only going to get better every time, and it's really important. For every programmer to learn how to use it well and understand what limitations are.

So. Yeah, I think speaking about legacy code, right, I think almost all developers, I believe that they hate working with legacy code, right, No matter what, right? So either that they don't know what the code is doing, either the code is buggy or the code is just so outdated that you can't even change it to using the modern practice and things like that, right? So in your consulting, I'm sure you have seen the worst of legacy code maybe and some which are probably not so bad.

But if you can tell us a little bit, what are the some of the typical challenges that people when they deal with legacy code? Why is it something that is kind of like avoided or hated a lot in the software development? You know, I think the mindset has a lot to do with it. And I think also there's the ambition of creating a new system, right?

And it's kind of like it seems with a lot of modern systems, you can, you know, you may be working with older code, but you get to go and sort of like create this little space where you have, say, new, new service and you can write the code from scratch and doodles. And you get very happy about this because you get to sort of display your creativity. But some people actually enjoy debugging, right? You know, some people who enjoy debugging, right? It's the same kind of thing in a way.

It's this thing of trying to understand something. And I think I might be sort of like more predisposed to this than most people because from being a kid, I've just always been curious about everything. Anything I could read, I would just sort of read, read, read and try things out and that sort of thing. And if you approach it as an adventure, I think that's something which is really kind of good in a way. Reminds me of a story.

And it's not directly about the technical work, but I was working with a team many years ago. And it was interesting because I was there for like 4 or five months on and off. And, you know, at the end of this, the guy who brought me in, he brought me into his office. They showed me these graphs. They showed me how the quality had improved through all the time that I'd been there. We really, you know, made a big difference. And I thought, well, this is weird because I feel like a

failure. Why do I feel like a failure? And what it was, this was like early days, like 2000s, likethe.com. Bus and all this other stuff. Was working at a startup and everybody thought they were going to be a millionaire and then they. Discovered they weren't going to be a millionaire, right? And it's just this interesting thing of kind of like, and I

started seeing the friends. It's like, wow, it's, you know, the thing which really affects whether we feel good today or not is what our expectations were, right? And it's, you know, and I talked to a friend who was like in Eastern religion, he's like, oh, that's his own thing. It's like, OK, but it's like, it's really an interesting thing. It's like our. Expectations set our experience to a strong degree.

And I think if you can actually cultivate the curiosity about what does the system do right, or the desire to help people in that context, it can be very, you know, rewarding work. You may just have to go and put aside your expectations a little bit. Yeah, you touch on just now something that a lot of developers probably like to do, right, which is to create new system or rewrite everything,

right. So since you write the legacy code book, what is your approach towards fixing the legacy code or maybe refactoring the legacy code versus rewrite? Right. So when should we actually contemplate doing rewrite versus fixing the legacy code? Yeah, a lot of it comes down to business reason rather than technical reason, because at the end of the day, the technical things just kind of like we can deal with anything. You know, it's a question whether there's payback for this

particular thing. But the business case needs to be made, needs to be understood that you don't have to rewrite an entire system most of the time, but you can concentrate on the things which basically have growth in the future and also, you know, are presenting difficulty to you in the

meantime. Usually what I'd like to do is I think I'd like to go and actually like try to do some refactoring, try to do some planning for some refactoring, look at perspective features, and then having all that stuff together thinking about whether a read write is justified or. Not right as. I mentioned a little earlier this thing of going and actually doing spot rewrites on particular things and it's really pretty powerful. And quite often for people, it's like an all or nothing.

Proposition. And that's really. A verbal. Position to approach these things from. But yeah, you know, the thing with rewrites is that it's great if you have tests. So if you have tests, you know, really in a golden space. If you don't, then you're kind of like dealing with the situation of like, oh, I need to write this thing and I don't understand what it does. And it's like, OK, well now you

got 2 problems, right? So I think it's really just the best way to kind of approach it. The thing is that's one that's rewrite when you're basically dealing with technical debt directly. But there are these other. Rewrites, which are really all about architecture that really have, you know. A different set of considerations. Leading into them. And these are the architectural ones are usually like, you know, much more expensive speaking about architecture, right?

So some people to the extreme right, like doing micro service. So that one part of the definition of micro service for some people is like, if you can rewrite the whole service within, I don't know, X days, right, then that's the micro service. So with that kind of maybe well designed micro service, you can do that. So what's your take about this as well, right? Like when you refactor the application into a different service, is that also some strategy that you can do for

tackling legacy code? Yeah, definitely. You know, I think that's an interesting thing to actually move things around to different places. And so it's really, at a macro level, the same thing we do as a micro level, at a micro level with classes in many ways. But as far as that thing of like, you should be able to rewrite in a day or so, I think that's a great goal. Hard to see it in practice, though.

It's really a weird thing. I think there's this intrinsic thing about software that basically tends to grow and grow and grow. And quite often it grows to the point where you basically have, you know, it's hard to go and do anything like that. But it snuck up on you, that kind of thing. Remember like reading through some research years ago about like how big does a class need to be? Before you actually go in refracting, right, that kind of thing.

And looking at actually like quality data, it's kind of like where do we have the most bugs in the biggest? Abstraction to the smallest ones. Turns out the answer is really the one so you touch the most often, right? And so it's kind of like we all have a feeling for when things get to be too big, but quite often it's kind of like there's no set point. It's kind of like a. Subjective sense in a way.

But yeah, I think there's a lot of stuff that was a dream for micro services that I think is, you know, it's a shame that we kind of fell away from some of that stuff. The thing of being able to use almost any language, be able to throw things into production almost immediately, be able to go and rewrite them when we need to. And yeah, I don't know, I tend to think there was a lot of these things. It's kind of like we only get the resilient systems we need when we stress.

Them a bit. If there's a reason to start rewriting things, then it's good because we actually gain the skill to do this and don't think we're just being an atypical thing, right? So it's actually good when there's a bit. Of stress in the environment, you know. So speaking about how people tackle this legacy code, right, maybe from your experience or maybe some summary of your book, right?

What are the techniques that people can evaluate or maybe people can try to actually tackle legacy code in a much elegant way, so to speak? In terms of that, I think the main thing is to go and figure out exactly where you need to make changes, right? And then you move outwards from

there. They may be cases where you need to change two or three lines in the method, for instance, or you need to go and actually sort of like you add five or six methods to a class, but maybe you're thinking about creating a new class. And then what you do is. So basically you think about what would be involved in getting tests in place for each one of those places, and you kind of like crawl the tree upward and see if there's a common. Place for those changes.

And you try to pragmatically figure out where you want. To go and have your tests. Now, if you have code that doesn't really have very many tests in place, chances are the code isn't really able to accommodate tests. Yeah, and you have to do quite a bit of dependency breaking work in order to go and actually put the test in place. To go and solve these problems. And that's really what my book is mainly about. Is going and.

Breaking the dependencies and writing the tests going to do these things, but at a micro level that's what you kind of need to do, right? I think in the more macro level, the important thing to go and remember is that essentially this is the kind of stuff where you're never going to go and have complete tests on the code base unless you started that. Way. Right. And that it's OK to live in this limbo. Space, and you probably will for a long period of time.

Where you're going to have some areas of great coverage in other areas, so not so good coverage and that's just normal, right? But at the end of the day, the coolest thing is that the things that you're about to change right now, chances are you'll be changing in the future. So what you do to go and get tests in place for those things, it's really kind of valuable if you need to go and actually start to make changes later.

And chances are you will. So you're going to start to get like very quick returns from doing this sort of thing. Like Joe be thinking, you know, one day that's like, wow, I need to go and get in this area of code and there are many tests or the tests are very good and it's going to be a pain when I do that tomorrow. And then you get there tomorrow and you're. Always like oh damn wow, one.

Of my team mates was in there three weeks ago and they put tests in place and wow, yay, my job is easier than it was before. So I think there's that, but there's also I guess the psychological thing of basically doing that enough to get to the point where you notice the difference about how it feels. We have an area of code that's easier to work in versus one that doesn't.

Quite often I run into people that have, you know, even independent of whether you have tests or not, they're not used to working a good code. Base at all and so. They're in pain, but they're in pain, right? And that's really a tragic situation. To be in. Yeah, speaking about some of the techniques you mentioned, like dependency breaking and being in the limbo situation, you have this one concept called seam, right? So I think that's really a

powerful thing. Maybe if you can, you know, define what is seam and how should people use it within their code base. Sure. It was kind of funny because I thought of this and I actually wrote a chapter on my book. They came very close from going and pulling it out because I thought it was just a peculiar way that I'm seeing software and it wouldn't be beneficial to

anybody. What it comes down to is this, and essentially when you look at a class or a set of classes, there are places where it's easier to go and actually sort of replace things, replace behavior than other places, right? So let's say you have a method and it's basically doing something crazy with IO and you want to get it out of your way so you can write tests for the class without actually doing the IO, right?

If it's a virtual method, right, you can basically go ahead and override it in the subclass and then it's out of your way. So that part of the method is a scene. It's kind of like the seam on your shirt is a natural breaking. Point. We can actually go and replace one thing with another, replace one behavior with another. It's interesting about this because if you start to categorize all the seams, there's just like lots and. Lots of them.

But it's an opportunistic way of looking at software. You go and say, what can I do to actually without changing things drastically, be able to go and get areas where I can get understanding and coverage? Because quite often it's like you're, you know, if you're going to make a change and you don't have all day to go and like refactor everything, you're going to have to go and get that change in in a way which is not going to be disruptive has very high quality things along those

lines. And it just might be a spot change and it's good to know where that's. Possible so. Is this same concept similar to the kind of strategy when people doing micro service, you know, or re architecting certain parts of the API or their service? Not really. I mean, to me, it's like with Strangler, it's kind of like you're how what you're doing is you're kind of like building things in parallel. You're diverting flow to 1 area of the system so you can go

build out another one. And it's like my favorite before it was even sort of like written up as a pattern. It's like I used to live in Miami, FL and there's like this giant bridge, this seven mile bridge that goes from South. Florida to Key West. And it was kind of funny because many years ago what they did is they're kind of like, OK, we've got the old one, we're going to build a new one next to it, and then we're going to go and tear down the old one, right?

And it's just, you know, I looked this up one time. I think it's like parallel replacement is the term that people use in other engineering disciplines, you know, this kind of thing. But generally, that's what strangler fig is. It's just this thing of going actually sort of selectively rewriting areas by going to allow yourself to go and have the old path to fall back on. So in terms of seams, I guess you do have to find seams in order to actually understand where you can make these

diversion points. So I guess that's the commonality, right? Thanks for the clarification. One thing that is always very tightly coupled right with the legacy code is this practice called refactoring or you know, writing tests, maybe TDD as well. So maybe in your view, right, is it very important for us to be able to do refactoring right or refactoring well? Should we also read Martin Fowler's book in order to be able to tackle legacy code better?

Totally. I think it's really, it's a great book and it's kind of funny. My daughter many years ago had a friend who was seen by getting into programming and he's like, oh, what should I do? What should I do when I give him a copy of the book refactoring. And the reason I did this was kind of like there was, I think it was Ralph Johnson who said this many, many years ago when

the book first came out. He said it's kind of interesting that basically if you want to teach good design, basically teach people the things to avoid and everything that's left is good design. And that's really the way the book is organized. It's kind of like OK, here's all these code. Smells. And your job is to go and look at these code smokes and get rid of them. And if you do, you know you're done to be better than it was before.

It's a great way of going and conveying design sense, you know, kind of like what is better than the other thing, right? So I think it's a very valuable thing just in terms of understanding systems. But in general terms of dealing with systems, it's extremely valuable because refactoring is all about clarifying things to the point where basically you can understand them and where

change becomes easier. It's not just refactoring itself, but understanding my predecessors like the code smells I mentioned, but also design principles so you kind of understand. What direction to carry things in. And once you have that, you know, you're going to just be able to go and sort of like make things better for yourself in the future and the people around you. I mean, that's a wonderful

thing. In terms of the structure of automated tests, do you have any suggestion or should we also still refer to the like test pyramid or maybe something around that? Or is there any kind of like suggestion that you would advocate people when dealing with legacy code? Well, I think for the most part, 1 of the things that's kind of funny is that there was like BDD behavior driven development that came out many years ago, right?

And one of the interesting things there is they were concentrating on like high level behaviors and sort of writing tests that would deal with collaborations of classes at. Once and it. Took me a long while to realize that, you know, I'd run into people all the time. They're writing like one test case class per test per class, right? And that you're in this weird

situation with that. But invariably, you know, when I'm working with legacy systems, I'm trying to find some vantage point I can write tests at, which isn't too far from the behavior I'm actually going and covering, but goes and covers, you know, the behaviors that I care about, right? And these clusters are really more than just one class quite often, right? That's just the way things go.

So I think that the conversation we have about whether something is a unit test or an integration test is not terribly productive in a way. I think it's really about testing behaviors. And you know, there's many other people saying this as well as I am. It's just a really valuable thing to go and look at is that you're testing behaviors. So you need to go and find the places where it's best to do that and kind of move forward

with things. So testing pyramid, you've got a unit and you go all the way up to like acceptance. And stuff like that. I guess the thing to say is that you can. Basically, the lower level tests that you have are things that you build. Upon in terms of understanding the system. And there's no way. Generally to go and have tests at an extremely high level and cover everything you care about,

right? So it's kind of like I try to concentrate on the lower levels and then know that's to make the higher levels. Easier when I need to go approach to this. Yep. So what about if you mentioned something very interesting about behavior, change of behavior, right. So I think the business most likely will demand a lot of changes, right? And some program actually are not touched because some business does not demand it to

change, right? What do you think in terms of those kind of code, right, for when it happened that we have to change the code, but there is some limited test. Is this something that is also common in your consulting experience, right? How should people think about code that has been sitting around still producing value, but one day it has to change, right? But it's so difficult to change because maybe people have left.

I, I think generally I'm really, you know, in favor of going, actually just really trying to go and make your changes supported by tents, OK. Because even though today it looks like nobody's going to change this and stuff like that, it's kind of like it's just the safe thing to do. The fact that you have that code around still means enhanced value. So you don't want to be in a situation where you're just making it worse. Right, but. Of course people are going to be

pragmatic about this. It really depends upon how much other work they have in front of them and stuff like this. But you know, I think even going through the exercise of like, trying to write tests for something which doesn't have many tests and it's really, really difficult, gives you an appreciation for, you know, it's like, OK, I'm never going to do this again. And none of my team mates. Are because we know how bad this is, right? So it's really always a valuable exercise.

Try to get the test in place to support the change you're going to make the. Other thing I want to go and mention with this is that this is not an uncommon thing. It's kind of like, you know, people in business all the time are trying to figure out how much to invest in particular things in terms of like investing in the, you know, the current line of business, basically going and creating new lines of. Business and stuff along those lines. And we have the same thing as

technical people. There are no easy answers. To this question, I think it's. Important to know that just going into it, you know? Yeah. So one thing that could help us these days is AI, right? So if people dealing with legacy code, maybe some people will play around and try to explain this part of the code base, right, so that you can actually understand it. So I know that you're also writing this book AI Assisted

Programming, right? So I assume that you have been playing a lot with AI recently, so maybe let's go there. How do you think the role of AI in terms of tackling legacy code? Maybe that's the first question before we talk about anything in general about AI. Well, it's really kind of hard to go and actually sort of see where things are going to go because they're changing all the

time, right? And I think the thing that people are most concerned with right now is the hallucination problem where it's kind of like you ask a question, you get an answer, and you just really don't know whether it's right or not. And I want to take that as a given. It's going to get better over time. But I think the thing that's important is really to go and understand that if you can't trust what's being generated, there still is value there.

And I think a lot of this is really about going exploring alternatives. So it's, you know, if I'm about to do something, quite often I'm like, OK, well, let me go ahead and ask for a different way of doing this. OK, let me ask for three different ways of doing this, OK, And just compare them side by side and understand what's

possible in this space. And quite often good ideas I wouldn't have gotten otherwise for things that we can verify easily, like going and asking a question on a particular. API and gives you the answer in the course. You put in place and you find it very quickly whether it works or not. It's kind of, you know, brilliant for that. But yeah, I do use it to explain

code to me quite often. And I think, God, one thing I love is this thing where you can sort of like, I call it lensing and it's kind of like you drop in a giant area of code and you're kind of like, OK, this giant class that I have here, what responsibilities does it have? Right? And it goes and gives me a list

of them. And usually it's kind of like so, so and you start to interrogate and you ask other questions about it. But I love to do this thing where you're like, OK, you gave me 10 responsibilities, just give me 6. Basically, if you had to look in this frost, it's kind of like, what are the six most important

responsibilities? And by scaling back and forth with this, you start to go and understand, you know, where perception can change of a class in terms of what the responsibilities are depending upon the level that you're looking at, right? And it can give you ideas for a factor. And so I find that very, very useful. In a strategy so. There's a ton of other little things like that. They're kind of, you know, handy.

Yeah. So I think these days a lot of programmers have been playing around with AII personally also have used it. So I think you mentioned about hallucination problem, right? I think it's also one of the risks. Would AI also create more legacy code? Because like some people will just take it as it is, right? And then just plug it in and maybe deploy it without even of course has to verify it. Of course there's something it's the get clear report.

I think one of the things that they were mentioning there is it seems like there's a lot more churn of code. Code's being put in public repos much faster. There's much more churn change after task fund, right? Yeah. I mean, we're just going to go and end up in the space for a period of time and everything. The thing that's tough is that it's kind of like it's shifting the balance. In a way. It's kind of like it's easier to write code and it's a bit hard

to understand. And I think for me, I'm always dealing with this fatigue issue. It's like I'll look for three. Different ways of doing something. And then I'm doing code review for all these things and it's kind of like, at what point is that? Productive. And what point is that

counterproductive for me, right? But it's kind of like we have to review code that other people have written or that we've written a long time ago and have forgotten, and this just goes and increases the burden in. That space and it's kind of tough I. Was just saying an area that I think is really kind of interesting is the entire thing of going and writing tests. Right, because.

It's kind of shocked at the beginning to see her vendors basically go and say, hey, we're going to write all your tests for you. Yeah. You know, as a TDD guy, you're looking at this and you're saying, oh, my God, no, Right. But for characterization testing, it's really kind of powerful because you know if you're not changing the code right, it is a document of what the behavior currently is, and you can go and write have.

Tests written for this. And if they pass, then they are actually showing you, you know, real behavior. And so that's useful. I think the thing we have to get used to with this is the idea that tests can be. Disposable and temporary sometimes and just using the get insight or to facilitate change. So I think that's a very valuable. Thing, right. So you mentioned about generating test cases, right? And also interrogating code, explaining code, right.

What are some of the other use cases that you typically use when using AI in your maybe day-to-day work? Well, all the time. It's just for exploring alternatives. You know, for the most part. I mean, it's like even things that have nothing to do with code. It's kind of like just, you know, it's an interesting thing to admit. I'm just so curious. About things that I have a thought about. You know, something in culture or something and you know, kind of like.

Science and it's like. Damn, it's like, you know, it's like, how long is the manta rays, you know, Fin. In the front, you know, it's like, oh, it's yeah, they're interesting kind of thing. So it's, yeah, it's an interesting thing. I just, I think in general, any domain that you want to dig into, it's easier to do now, you know, the advent of search browsers gave us a lot more ability to go and. Discover things and sort of learn things. And now it's off the charts.

So I think that's just really, you know, incredible so. You're writing this book AI Assisted Programming, so I think it's still in progress, right? Very early in the process, right? So what made you decide to write a book about AI programming? Well, it seems like a very strange thing to do considering the how fast things are moving. But I think what was interesting to me is I felt like it was an interesting way of going and actually talking more about how

we work in a way. And I felt like there are some of the things we confront with AI are things we're confronting with right now, but haven't we talked? About all that. That's right. And you know one of those is that. Fatigue issue that I mentioned a little bit earlier, right? Let's see, another 1 is really the thing that. Sometimes you know it's. But often you're working in an ID and basically gives you code suggestions all the time.

And you're looking at this as kind of like, can I accept this? How much trust can I place in this? And the same thing is true with code that you get from somebody else, right? Where is my trust? How do I focus on this particular thing? And then there's a general thing of ideation. You know, one of the sections I have in the book talks about the lost potential. Basically, you ask the question of the AI and you accept the first answer.

Because quite often you just ask this prompt again, you get a different. Answer and a different answer and a different answer. And I find that so valuable because it's sort of open to the. Possibility space in a way. And gets you thinking about different things that pokes your mind in a different. Direction. Which quite often gives you better ideas. About things and I think that's.

You know, a great thing. The other thing as well is that basically it makes us better question askers, right? We get better at it because we have to go and sort of ask questions to interact with it. So it's really a capability amplifier. So do you think this prom engineering thing is one of the skill set that any developers now need to be able to master? I think so. I think it's and it's going to change. So I think with my book, it's less of that prompt engineering

and more bad approach. But yeah, it's it's interesting. I think 1 section I haven't written yet, but I gave him an online lecture. About like a while. Back it's just having a mental model to have these things work at a behavioral level so they can help you with your prompting, right? And just, I can very briefly say, it's almost like you can imagine you have this giant net, right? And it's kind of like if you ask a question, it pulls some of those things towards you.

And then basically you ask another question, it pulls other things towards you. And quite often the way that you ask questions doesn't lead to in a different path. So it's kind of like this thing of going in, like what are you pulling into active memory when you're going in? Sort of like asking. Questions. I think you know little things like that quite often. Make us better at doing these things.

Yeah. So I think what 1, I mean, one thing that if we always ask question and we got different answers, right? Obviously reading the code is like a big cognitive load, right? We try to understand different ways of doing thing, although it maybe end up the same and also at the end of the day, still the same thing, right? So we gotta write the test for it. So if we don't actually it creates a legacy code as well, right?

I think reading code is something that I feel is much more important these days, right, Rather than actually writing it because the prompt probably could, you know, use a natural language and they give us a code and you read the code instead. So in your view, like how can people master, you know, reading the code much better? Or maybe sometimes like the design is something that is sometimes it's not appropriate with the larger code base,

right. So what's your take about developers taking AI answer and just putting in well, I just, I feel like everybody. Knows this, but I have to say. And so I remember like the story of about like somebody is in like high school and they're taking mathematics course and their teacher goes and says to them, you know, there's one secret for getting an A to this course and everybody's like, oh, what is it? It's like, do your homework, OK,

do the problems, right? And I think the same thing is true for us in software development. The secret for a lot of this stuff is take smaller steps, right? So if you are looking at generating something, generate something small, right? If you're trying to understand something, paste in something that is kind of small and just get its take on things and you're just trying to understand what you're bringing, what's going on with something, look at smaller steps and build up from

the foundations. And yeah. There's a skill to that sort of thing, I think. There's another thing which hasn't been written up all that much that I think it's kind of powerful and it has nothing to do with AI really. And it comes down to basically seeing enough systems that you develop enough impressions of different systems, you start to see what's common and what's different, right? So there's nothing that's a good substitute for going and having very wide experience of many

different domains. And that experience of even if you're not hopping from job to job to job is just, you know, reading. There's books, there's open source code and stuff like this. And you start to see how people approach problems differently in different domains. And then when you see something which is totally atypical to you, you have, they call it sometimes the coat hangers.

It's kind of like you're given all this information and you're looking for the things that are like the basis that you can use to sort of organize your knowledge as you get more knowledge of the thing you're looking at. And yeah, I think that's a valuable skill to develop as well. So, yeah, you mentioned about understanding domain. Yeah, I still think that AI still hasn't reached there yet, right? So maybe like building the whole application end to end, right?

And also maybe building a more distributed complex systems is something that they haven't reached out yet. So in your view, what is the ideal, you know, stage where we should rely on AI more versus something that use human creativity or brain more? I think it's really for the areas which are low risk, you know, and this is kind of funny because there's all different ways of looking at risk. And one of the things I think is great is actually going to

develop blower plate code. So it's like thinking well back about creating like a Chrome extension. And it's kind of like, OK, just ask me to create like a simple Chrome extension. And it's kind of like, I don't need to write all that code. It can. Basically, I can find it very quickly whether it's working or not, right? But right, we want to concentrate on the thing that I want the Chrome extension to do,

for instance. There's that, but there's also things like that that should be like in house. Tools and stuff like that. Where you have some confidence that somebody's going to find a problem before it causes loss of life or money, right? That's a very important thing, you know, so I think it's finding these low risk environments and you know, a place where this actually kind of works very well is if you are creating tools to go and help you do. Things with your code for

instance. And I guess you know, also things like quite often I'm feel like I'm rediscovering shell programming in a way. I've done a lot of shell programming in my in the past, but when you think about it, shell is perfect for AI generation in the sense that you're basically building from these bigger components, the commands. And it's very easy to find out

exactly what a command does. It has wider knowledge of these things than we do. And you can see very quickly whether what it's producing is right or not right. And it's usually. Very brief and you can see with others. So going and doing that for my work. Quite often it's not a very valuable thing. So yeah, here's that. I think one topic associated with AI, with software programming is that a lot of people are worried about their

jobs, right? Or the roles will evolve quite a lot such that you are becoming obsolete or redundant, right? We also see some maybe hype technologies like Devin where they claim they can write code just by itself. So what is your view about, you know, all these worry about developers having to maybe upskill themselves or maybe getting redundant or things like that. So is that something that we have to fear about? Well, I think where people are getting much more realistic now.

I think in the very beginning people start doing and extrapolating and they just get completely. Freaked out by the possibilities, right? But I think many. Developers now have enough experience what they are, they realize it's not going to replace many times soon, right? It's basically at the end of the day, you know, it's kind of like in the legal system, you can't go and say, oh, the algorithm did it. And it's like, no, a person who works at a company did this.

At the end of the day, we are responsible for what we do. Right. And I think that's the thing that's. You know, really important for us to go and recognize that there has to be somebody in the seat of responsibility. You have to understand what you're creating as well. So I think we're going to have a place for a long time and I can't remember the name of the book. I wish I. Could maybe I'll send it to your show notes.

If you do that, but this guy who basically made the case ages ago, it's kind of like we just need to see ourselves as problem solvers and programming is one tool to solve a problem, right? And sometimes we can solve problems without writing code at all. And that's great, you know, but we have to basically do that thing of understanding far beyond the code, you know, everything around it, what's the business and all these other things because all that.

Information makes us much more effective. So I think it's this thing of going and expanding. Out from our roles to that. And I think a lot of people kind of recognize that that's just. Where the future is, and I do too, so. Thanks for, you know, giving your thoughts about this. So one technique that I found in some of your talk or resources that you shared before this conversation is that one thing called pseudo Lang, right? I find it quite interesting, right?

So I think for some people who may not have heard about it. So tell us what is pseudo Lang and how can we use it in our, you know, day-to-day work with AI? Well, it's an interesting thing. This is going to take a minute or two to explain, right? But I remember I think I found it through a web search and Slay wrote a couple of media posts about a thing they called pseudo Lang. So it's SUDO Lang, right? Just as Apana.

You know, what the author was saying was that it'd be great to go and actually create a language that's kind of like a programming language that basically you can feed into an LLM that would go and generate code for you and do translations and all these other things. And so he described the language and had interesting features like constraints and stuff like this and a very familiar syntax. And it wasn't quite like any

other language. It seemed like it was at a bit of a higher level because he could replace greater than with like the words greater than, for instance, and all this stuff, right? But the further you write down in the post, the further you realize what had happened. What he did is he asked ChatGPT. Hey, I want to have a language which makes it easy for me to talk to you about. Programming and get the things that I want. Give me a language that does this and actually, you know,

that's what the system did. He created pseudo like, right? And then it was even interesting and more tricky because he said, you know, I asked for this again. And I asked for it. It's kind of like, can you give me a syntax to work for this sort of work even if I didn't tell you what the speck of pseudo. Language was right. And it's interesting because it's like it goes full circle at that point. So it's really more like pointing in a direction.

I don't think it's really like the language. To learn or anything? And in the book I'm writing right now, I basically talk about something I call pigeon specification, which is really kind of like a pigeon language is a language you know, that people from different languages adopt. They can communicate with each other. It's usually some subset. Of two languages. But I can write like a test case using just a very brief test colon dot dot dot dot, you know

this, assert that, right? I can type that in and basically say, give this to me and J unit and it just gives it to me. And sometimes it's wrong. But I'm dealing with something small enough I can actually see what the results are, right? So I think we're going to see an off lot more of this people developing like private languages in much the same way that you might with people you work with.

I remember hearing about a musical group many years ago and somebody knew joined the band and they had serious trouble because the other musicians in the back could talk to each other, winking a nod. And this guy was new. He had no. Idea what they were where? They were going and what they were doing because these people knew they, they knew things about each other. And I think we're going to go and get into that symbiotic state with the coding assistants that we are using.

So speaking about symbiotic, you know, relationship, right, will AI be appropriate for us to do this TDD cycle where maybe we generate test 1st and maybe AI help to verify and also create the business code or maybe vice versa that kind of stuff like a real pair developer or those virtual, right. So is it something that you have seen it working before? Yeah, I'm done and I basically do and I quite often get frustrated. I've seen people.

Kind of carry a bit further. Loewen Falco is basically some videos ongoing and doing this, but I think it's, it's a powerful approach. You just need to get the bugs out of it to some degree. The thing is that essentially it's like you write tests and then you can go and sort of like how to generate code to satisfy the test.

What I've been finding is that essentially if you give it a whole bunch of tests at once, quite often it's going to do a reasonably good job for you and you can run the test to see whether it has or not, right? But quite often I've done this thing where I basically start to go and say, OK, here's a test, here's another test, here's another test, here's another

test and have it generate code. And I'm asking it to go and always make sure that when it generates code that it's going to satisfy all the tests I've shown so far. And it's kind of like a little bit problematic with that right now. I'm asked to do with I guess context window problems and stuff on your. So I think, you know, it's moving forward in a good way.

I think there's so much you can learn just by going and taking a project and going and deleting all the source code and just giving all the tests to an AI assistant saying write the code for me, right? The things that it's missing are things that you were missing in. Coverage for that kind of thing. It's, yeah, there's a lot of interesting stuff we can do in that space. It's going to get better and I think TDD. Is still going to be around so.

So you mentioned about context window, maybe some people are not familiar with the concept and I know that some of the LLM newer models always mentioned about this context thing which gets larger and larger and larger. Tell us what's the difference with having larger context window? Well, it's like when you look at how an LLM works, it's kind of like it's rather deep and involved many layers of neural networks.

But it seems that at least for a little while ago, when it basically goes and does inference like of your prompt and processing and things, it's doing almost like a quadratic operation. It's just like the more the needs in memory, the longer it's going to go and take.

To go and do things. And so for that reason, it's kind of like you have this thing that happens quite often where you're working in a session, and then after a period of time, you're asking it to do something and then it goes and gives you an answer, which makes it obvious that it doesn't know what you gave it like 10 minutes ago, right? And so it's kind of like, I called this to like performance degradation, right? That just has to do with the physics pretty much. You know, like how

computationally complex. These operations happen to be so it puts limitations on how much we can go and basically do it once. The thing is, I've heard recently that some of the newer models, I think Gemini. Claims that it has like, you know, an infinite context window. And I haven't really kept up in that space to go and see whether those things still have that issue. I know some of the tools I'm using today still have that. Issue.

But I think it's going to be with us regardless because it's very much like, I took a lot of cognitive science in college and it's just like the way humans interact with things. It's kind of like if I divert your attention to over there, it's not going to be immediately top of mind the thing that we were just talking about and vice versa, right? We have attention and it's relatively fixed because nothing can have any attention. It's just it violates physics.

So we're always going to have that thing of kind of like what's in our intent to focus and what is not. And I think that basically understanding that's very useful to being effective with AI right now. So I guess I hope that's, you know, a decent summary. Yep, thanks for explaining that. So we have spoken a lot of things about AI. Any things that we haven't spoken that you figure it out recently that people need to

know about AI programming. It's funny because in writing this, it seems like I've had a lot of topics and it's been like digging down deep in them. So recent isn't really, you know, the best way of going and putting. Here's one. OK. And I just released on LinkedIn a couple of days ago a chapter when it's writing and it's something I call way words. And it's kind of a powerful idea. And what it comes down to is this.

It's kind of like supposing you're asking, you know, the tool to go to retract or something, right? And you write a prompt to go and do this. And then it's kind of like it does send you give it more test cases and you discover you need to change the prompt a bit and change it a little bit more. At that point, you probably want to name this. Thing right? You really want to go and say, OK, you know, this is a, an operation called da, da, da, da da.

And then basically you can just in English, you know, or your language, just go ahead and just sort of like use that as a piece of new nomenclature in terminology. And so it's just like introducing a, a method name or

a variable. One thing you can do sometimes is go and say, OK, please, you know, now that I defined this thing, give me a summary prompt, give me a prompt that I can use to put into another session so that we can go and actually do the same operations doesn't always work, but it's getting better. But I really find a lot of utility in this thing of naming things as you go along when you're. Working with things.

It can just be OK. Well this example I just created call this response ABC and then you can go back and say well when we did. ABC that's it, right? It's going and creating these handles for going and deal with things. And yeah, very useful thing to go and use. So speaking about this nomenclature, right, we just spoken about the context window

in the different sessions. Do you have to sometimes copy and paste the prompts that you had previously in some of the notes and then when you work on a different sessions, maybe some couple of days later that you have to paste it back, look sort of the memory or the cognitive thing to the AI brain and then try again. Is that something that is also commonly done by people who are using AI?

I think for the most part I kind of cheat by going basically making the source code the thing, right? It's kind of large. If I knows I can transport source code from one session to another, that's kind of good. But what I have durable things I'm working on. Yeah, it gets down to copying. Things back and forth between sessions or just sort of re describing something and quite else I can get it back to the point where I feel it's useful. So yeah, it's kind of problematic with.

So I'm looking forward to things getting a bit better in that space. I think there's somebody who's talking about actually doing this and calling them skills that you can actually sort of like make almost like plug insurance for particular things. And there's many different ways to going and tuning LMS to go and sort of like facilitate this, but to the point where we can actually create user defined. Skills to move them across

sessions if it's valuable. The other thing I'll say is that even if we have an Internet context window, sessions by themselves are so valuable because quite often I'll keep one main session and I'll basically just create small ones I dispose of, right? And it's almost like managing tabs in a browser, right? It's kind of like, here's the main thing, I'm working and I've got 567 eights and you have to kind of know when to get rid of them and when.

To keep them. But it's nice to go and have a good separated space. We can, actually. Go and do some working things and experiments. Without actually sort of corrupting or degrading performance. And if you have the. Original session you have. I know it's a fast changing world these days, right, But any tools, favorite tools that you use these days, you know, related to AI encoding or is it

Co piloted? It's going to be so weird just there are so you know, Co piloted is great, but it's one of the things I kind of am drawing the distinction between is that let's see, we're in a financial in the world right now. The market is in this place where every time that you make a general LM better, it's kind of like you're kind of eating into the space where people do specialty things. Right.

So it's kind of like you can try to specialize the tool, but if people can just wait for the next general LM to do things, then what's it do right? But I think it's starting to separate now and you're starting to see decent coding tools to have their own utility. But what I like to do is even if I'm using copilot or I'm using code scene or all these other tools is to have my own window open in something like cloud, for instance, whatever I consider to be the best LM at

the moment. And basically do my more ideation work in that space because they aren't clamped down. And by what I mean by that is sometimes you'll be using a tool and an IDE. And so you'll say, well, give me three other approaches for going and doing this or tell me more about this thing in the domain and they'll say, no, I'm sorry, I'm here to help you with your code and refactoring. And that's that.

And you don't, you know, know what the tools are good for, but always keep your most capable general tool next to you in order to go and actually do the things that you are going to help you have high creative value. So yeah, personally also subscribe to many AI tools, right? So I think sometimes you just, you know, pick the best from whatever AI that you use, right? And sometimes, yeah, one works best for certain contexts and

the other works best for others. So I think that this landscape is changing really, really fast. So I think there will be more exciting stuff happening within this space. But one thing for sure, like what you said, I think probably developers role won't be like gone, right? People are still having to problem solve something, right? And especially also the understanding about domain, right? I think that's still one key. So thank you so much for this exciting talk for Michael.

Unfortunately, we reached the end of our conversation. But before I let you go, I have one last question that I always ask my guest. I call this 3 technical leadership wisdom. You can think of it just like advice that you want to give to us, the listeners here. So maybe you can share your version of the wisdom. Yeah, It's kind of funny because I was looking back through, you know, the other, you know, some of your earlier episodes.

And, you know, there's a lot of things about basically managing organizations and basically dealing with people and stuff like that purely from a technical point of view. The thing I want to go and basically mention is that basically looking for things that aren't there is very valuable. Right. And I think just generally in life, it's kind of like if, if you can detect the absence of something that should be there, right, then you're in a good position.

The legacy code book came about because I realized it's like, this is a tough problem and nobody's going to touch it. Nobody wants to touch this problem. So it's like, OK, might as well do this, right? So developing a sense for the absence. Of things is extremely. Valuable. The other is like, you know #2 I guess would be basically learning as many domains as you can, right?

Really digging into things because it's like the more impressions you get of different things, the more you have to draw upon when you're formulating solutions. Yourself, right? And this is almost like how an Lol works in a way, right? It basically is read almost all the online content in the world. And one thing that makes it very effective is because it has that breadth, right?

So you'll quite often see yourself, I'm reading about this and you'll say, wow, that's very close to this thing over there. What's is there a commonality here? And then you start asking questions and going deep. Right. And I guess the third thing is really just maintain your curiosity more than anything else. You know, everybody who's in software development is in a position to be able to learn

more about many adjacent things. You know, you're able to learn more about business, you're able to learn more about management and the resources available to all of us. It's just a question of actually going there and dealing with those things. So I guess those are the main things and those have served me well through my career. You know, and I, I don't know to what degree people can trick themselves in the curiosity if they're not terribly curious.

But yeah, I hope they can because I, you know, it's, it's fun to me. It's fun. So yeah. I'm sure when people opt for the programmer's job, I think there is a sense of curiosity because otherwise, right, I mean, they they can't be a good programmer anyway. So sure, just some of the most interesting conversations ever had at conferences. They have nothing to do with software, just people are just very into things and. Curious. Sorry, Yeah. No problem.

So thanks again for this conversation. So if people like this conversation or they want to reach out or check out with you certain stuff, is there a place where they can reach out online? Sure. There's my sub stack Michael Chathers at substack.com. There's also on X or Twitters M Chathers. So just either one of those places is perfectly fine to go and reach me. You can also search for the book AI assisted programming on Reenpub and it's early days. I'm about 15% done. But I'm.

Releasing new chapters every week or so. So, all right, thanks. I don't know how far it can be a legacy code book, right, which is very classic, but I think I hope I can see the book in a full form, right, and learn how to use the AI much better. So thanks for writing the book as well. Sure. Thank you.