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.