AI tools are very bad at refactoring.
They make mistakes. They introduce bugs.
And they forget things or they introduce dead code.
I advise against just producing huge amounts of code that you
don't really understand. That doesn't seem like a recipe
for success. Emily Bache, a technical coach
and a member of Dave Farley's Modern Software Engineering
channel, reveals how to level up your engineering teams in the
age of AI. The more skilled you are with
modern software engineering practices like working in small
increments and writing tests. All of those skills are just
amplified when you've got AI tools.
How do you define the role of a technical coach?
My job is not to deliver code myself.
It's to deliver a team with a better capability to deliver
better code. The two main activities I do are
learning hours and ensemble. Everyone struggles with code
quality. Everyone has a certain amount of
technical debt. Everyone I've seen could learn
to use the tools they have better.
You don't learn how to produce beautiful code only by looking
at a good design and analyzing it.
Junior developers need mentoring to turn into senior developers.
And mentoring is more than just writing comments and pull
requests. Ensemble is another word for mob
programming. You get a group of software
developers together to collaborate and produce code.
It's a great forum for learning because you see each other not
only producing a code at the end.
You get to see how people produce the code.
There are two main failure modes for an ensemble.
One is that you've got a group of five or six people and you've
got one person with a keyboard and they're doing all the work,
and everyone else is just zoning out.
The other failure mode is. Hello, everyone.
Welcome back to another new episode of the Tech Lead Journal
podcast. Today, I have with me Emily
Bache. Uh, she's actually a technical
coach. Maybe some of you know technical
coach, in your experience, in your career.
But rarely actually I hear about technical coach, at least
within, you know, my region, Southeast Asia.
Especially Emily is specializing in this method called Samman
method. Actually I have never heard
about Samman method before until I did my research.
So yeah, hopefully we can learn a thing or two about Samman
method, why it is something that she's advocating, and we'll also
learn about what a technical coach role is.
So Emily, welcome to the show. Thank you for having me.
I'm pleased to be invited. Right.
Emily, I always love to invite my guests to probably share a
little bit more from your career.
Any turning points that you think we can learn from you?
Yeah, so I've been in this business for like 25 years since
I graduated with a degree in software engineering.
And I, uh, we lived in the UK. And then I worked in the UK as a
software developer for a bit. And then my husband and I moved
to Sweden, and we've been here ever since.
I was also very privileged to be an early adopter of extreme
programming. I started doing that on a
project in like the year 2000, and it was a huge influence on
me. I've been doing like test-driven
development and all that stuff for a long time now.
Over the years, I've been trying to help others to learn these
skills in various ways. I had a stint as an architect,
test architect in a company. But these days I'm an
independent consultant. And I technical coach and I go
around different companies helping teams to learn better
coding skills, basically. Yeah.
And I saw you're actually also part of the Modern Engineering,
so the, I dunno, the YouTube channel or the group set up by
Dave Farley. So tell us a little bit more
about that. Like what's your experience so
far? Yeah.
Oh, that's, that was, uh, I was so pleased when Dave Farley came
to me and invited me to be one of the presenters on this, this
channel. Um, it's really, it's really
cool to get. Cause I, you know, I have ideas
and stuff I wanna share and talk about, and Dave has built up
this huge following on YouTube. So it's great to be able to talk
about that stuff for that audience.
But also that when I'm preparing what I'm gonna say, of course,
Dave Farley gives me advice, you know, feedback on, on what I'm
planning to say. And we have a chat amongst the
presenters about what we wanna talk about.
And it's really nice group to be involved with.
So I hope people like to see the things that we produce as well.
Yeah, personally, I've been seeing a couple of more, you
know, contents either through email or videos, right, on
YouTube. So hopefully we can see a lot of
cool stuff happening from that Modern Engineering channel.
So today we are going to talk about technical coaching with
Samman methods. So maybe let's start with the
role itself. Like I mentioned in the
beginning, for some of us here within this region, it is
actually very rare to hear about a team having technical coach.
Maybe it's more prominent to have Agile coaches or other type
of coaches like leadership coach and things like that.
So maybe first thing, how do you define the role of a technical
coach? So Agile coaches are more
concerned with kind of teams and process and introducing Agile
ceremonies and ways of working. But technical coach, my concern
is much more around the code, the people writing the code, how
the code is being written and whether we can raise the quality
of the code and raise the skills of the people writing it.
It's much more focused around that part of what's going on.
And my background, as I said, is a software developer.
So you need very good technical skills to be a technical coach.
Uh, you need a background in software development.
And not all Agile coaches have that.
So it's, I see it as a complimentary role.
I mean, I'd love to work with an Agile coach with a team.
So I would get to focus more on the technical side of things and
the Agile coach more on the process and the organization
side of things. Yeah, probably if I can map it
to like a common engineering team set up, right?
So there's an engineering manager who is more on the
process, you know, delivery and stuff while the technical lead
probably is playing that role, you know.
Like making sure that the code is written well, the process,
engineering process. And you mentioned a couple of
key things that I think are interesting, right?
So you focus more on the code, uh, writing the code, you know,
the skills to write a good code, I suppose.
And the quality. So obviously these days there
are a lot of changes in terms of trends and technology
advancement and AI come into the picture, right?
So what do you think? Is AI a disruptor to your role?
Is AI an amplifier to your role? What has been your experience so
far? Yeah, I mean the AI tools that
are coming in are more and more impressive, and more and more
people are are using them. So of course, my role is to help
software developers to write better code.
And the software developers that I work with all have these
tools. They all have AI tools that
they're starting to use. So I don't think it really
changes my role so much as I also need to understand how to
use these tools well so that I can help others with that.
Because I think it's, I dunno if it's kind of this feeling that
these AI tools are so easy to use that it doesn't need any
training, that you just give them to all the developers and
everyone will just work it out. But I think a lot of software
developers actually benefit from getting some advice about how to
best use these tools. And a lot of the advice that I'm
giving at the moment is that, you know, it's that the more
skilled you are with modern software engineering practices,
like working in small increments and writing tests and being able
to explain what the user benefit of the software is in tests.
You know, all of those skills that, you know, I've been
teaching for a long time are just amplified when you've got
AI tools. And the AI tools work much
better if you can do all those things.
So I'm not sure that it's disrupted my role so much as I
have to be able to incorporate advice about using these tools
into the training and coaching I do.
Yeah, personally, I fully agree with what you said, right?
So given like a good understanding about the
fundamentals, the practices, the important practices, like you
mentioned, you know. The XP practices, for example,
like test-driven development, having automated tests, the
CI/CD integration, and things like that.
Definitely using AI is going to amplify all those important
stuff and you probably will get more things done in a higher
quality. So that will be the wish of
almost everybody in software engineering.
But yeah, we'll see. I mean, whether AI can actually
help people in terms of improving the quality.
But one thing for sure about software engineering that I
picked from reading the book, right, so it is mentioned that
software engineering is actually more like a learning process
rather than so-called, you know, doing the production process or,
you know, just writing the code in order to build something,
right? So tell us the important thing
about this learning process. Yeah, I totally agree.
I mean, I think this is what Dave Farley says in his book,
Modern Software Engineering, that there's two big problems
that you need to solve. And one is to manage the
complexity in the software, in the world, in, you know,
actually solving the problem, which this problem the software
is solving is really complex. But the other half of it is
optimizing for learning, because the world's changing and you
need to be able to keep up. So these are the primary drivers
of most of what we do in, when we're building software, we're
trying to make sure that we are learning about what we need to
build and we're trying to manage that complexity with good design
and so on in the code. So yeah, I'm absolutely, uh,
trying to help teams with that. Just to go back to, you said
earlier about, you know, that it's similar, what I do is
similar to a tech lead. So a tech lead would be on a
team and they would be responsible for helping everyone
around them to produce good code.
And that is of course what I'm doing.
But my job is not to deliver code myself.
It's to deliver a team with a better capability to deliver
better code. I'm a coach.
I'm not delivering myself. I'm delivering, uh, improvements
to other people. So it's a little bit meta in
that sense. But of course I need to help
them to optimize for learning and manage the complexity they
have. Yeah.
When you say optimize for learning for software engineers,
what will be the typical things that you do?
Or maybe this is also a good segue to what you are, you know,
the Samman method that you are conducting as well.
Yeah, so let's just outline the Samman method and how it can
help with these aspects of software engineering.
So, when I come in with a team, of course, I need to get to know
that situation a little bit and talk to them and establish
whether it's a good fit. But after that, the two main
activities I do are learning hours and ensemble.
The learning hours are where we kind of focus on building
skills, doing exercises, practicing techniques that are
gonna be useful in the production code.
And then in the, uh, the main ensemble, that's where we go
into their production code. I sit with the team and we try
and, you know, build a feature or add some unit tests or do
something realistic in their code and I'll coach them through
it. And all the time I'm, so for
things like optimize for learning, I mean, that's, you're
trying to learn about the problem your software is trying
to solve and... But also you need to be learning
skills and improving and leveling up your ability to
deliver. So I guess that's the aspect of
optimizing for learning that I'm mostly focused on.
And then the managing complexity, that's all about
having design skills, basically, about being able to divide up
the problem and decompose it into modules or classes.
And also that the skills to evolve that design, to manage as
the complexity increases, new features come in that you can
evolve the design. And that's something that comes
up in, uh, the skills that we learn in the learning hours, and
of course the hands-on in the teams code.
Yeah, learning hours and ensemble seems to be like the
two core parts of the Samman method, right?
So I guess, let's probably dive into the ensemble first, because
I think this might be more interesting as well to discuss,
right? So the way I read it, ensemble,
right? Some people associate that with
like mob programming, like programming together in a group.
First of all, like how big should ensemble be?
Because pair programming, is it considered ensemble?
And like also, I'm sure many people haven't really tried mob
programming or ensemble. And what will be your, you know,
maybe elevator pitch for us to actually give it a try?
Well, that was a lot of things. So, just to clarify, ensemble is
another word for mob programming.
It's exactly the same thing. And, uh, software teaming again,
is just different words. Different people talk about the
same activity. But the basic idea is that you
get a group of software developers together to
collaborate and produce code. And so it can be anything from
three people upwards, basically. Normally, when I'm working with
a team, it's a, it's the normal, normal Scrum team kind of size.
So it's about 4, 5, 6 people. Those people are usually
software developers. Quite often actually, we get
joined by a tester. Not always.
They don't always like to join us, but we are all the people in
the team who are gonna write code together.
Then you wanted also an elevator pitch, why would you do this,
you know? 'Cause the, the normal way is of
course, for each person to have their own computer and to work
individually. But they, there are a number of
advantages to collaborating like this.
And one of them is that it's a great forum for learning,
because you see each other not only producing a code at the
end. You get to see how people
produce the code. So just at, in the first
instance, people can say, oh, your IDE does that.
I didn't know you could do that. And people learn, just pick up
like keyboard shortcuts and stuff.
And then later, you know, just this whole thing of if you do a
code review, you just see the end result.
If you collaborate with someone, you see how they do it.
And junior developers in particular will find that a good
way for them to learn and level up.
So it's a good forum for leveling up a team.
It's also a good forum for, you know, as with pair programming,
reducing the lottery ticket number.
You know, if one person wins the lottery and suddenly disappears,
how would you manage, you know, have they got so much knowledge
that they've taken with them that the whole thing falls
apart? So by doing this, we're sharing
our knowledge and our context so that we are less reliant on
individuals. So I think those are two of the
main benefits of this style of working.
But also, you know, once you get into it, I think it's quite a
fun way to work actually. This kind of direct
collaboration, where you're supporting one another in real
time. Yeah.
So unfortunately for me, my experience so far have been only
maybe pair programming more, right?
I haven't really developed in a, like a bigger group, right?
And in fact if I, I understand correctly from Woody, right, the
one who created the mob programming, he actually
advocate technical people, non-technical people, including
like business sometimes to just sit together and talk through
the problems and actually come up with a solution, right?
And also funnily enough in my career, I've experienced before
like having to, you know, face a manager that doesn't like this
kind of working. And I'm sure in many companies
they also might feel that, you know, like a few people working
together on, uh, on the same problem might be deemed as a
waste of time, effort, or man hours, whatever that is you
wanna call it, right? So how do you, first of all, you
know, stand by your argument that this is beneficial?
And how do you actually quantify that for those kind of managers
who still don't see it as a valuable thing?
Yeah, I don't know. I'm interested in kind of
browbeating any managers. But I think you, at some level,
need to trust the team that they know what they're doing.
And if they wanna work that way, then let them.
And see how it goes. But I just to come back to this
thing about, you know, the normal way is to divide up the
work and to have handovers. And every time you have a
handover of a piece of work from one role to another, there's a
potential for something to get lost and for time to get wasted
and context to be lost. And then, so the thing with
getting everyone in the same room in, like as Woody says
including business people and testers, you get this
possibility to have single piece flow where you take one task,
you've got all the people in the room who are capable of taking
this task from start to finish and out into production.
And without any kind of handovers in a way because
everyone is present for all of the tasks.
You eliminate these opportunities for
misunderstandings and context to get dropped.
The result that I observe is that the overall quality of the
thing you produce is higher. And actually you get it sooner
because you didn't have to wait for any of those handovers.
So I suggest to the manager that instead of trying to look at
person utilization, they start to look at flow and the flow of
features. It's a very lean concept, you
know. I think that's the way to look
at it. It's a way to get single piece
flow in your development. I like that you mentioned about
flow, right? Single piece flow.
I think that's very crucial in the lean methodology, right?
And yeah, these days in many software engineering team, I
would say that there are specialization, there are roles,
right? Maybe these days is getting much
more blended because of the AI introduction, right?
So like a developer now can do maybe maybe other different
roles altogether as well. But yeah, that single piece of
flow is something that probably as a manager, right, you should
try to optimize much more, right?
So maybe if we go to the mechanics first, right?
Because maybe people are interested in giving a try.
I mean it should not be just, you know, a group of people just
gather on one, I dunno, monitor or one laptop and just talk.
What are some of the mechanics that you think people can have a
guide? Maybe it doesn't have to be so
deep, but at least they have a good sense how to give it a try.
Yeah, yeah. So if you wanna give it a try,
then I would advise trying to get help from somebody who's
done it before, because it's quite easy to fall into one of
the failure modes with this. There are two main failure modes
for an ensemble. One is that everyone, you've got
a group of what, five or six people and you've got one person
with a keyboard, and they're doing all the work and everyone
else is just zoning out. And they're, you know, just
checking their phone or looking out the window or whatever.
So that's the first failure mode that, you know, there's only one
person doing any work. That's not what we're after.
The other failure mode is kind of similar but different.
It's whether the person with a keyboard is sitting there and
everyone else is shouting different things at them to do.
They don't get anything done either because they basically
have to ignore everyone and do what they wanted because
everyone is giving conflicting advice.
Those are the basic two failure modes.
What you want is a collaboration where everyone is contributing
to the software that's getting produced.
And the how you achieve that is it takes some practice.
It's a skill that you need to learn.
And the way I normally teach it is we start with basically
nominating somebody for the talking role and making sure
that that role rotates through all the people who are present
on a timer so that everyone gets a turn to say their thing.
And you don't need to all shout at once 'cause you're gonna get
your turn in a minute. And you don't zone out 'cause
you know it's gonna be your turn in a minute, you know?
So it's, that's the kind of one of the mechanisms.
So separate the talking and the typing roles and rotate at least
the talking roll on a scale of maybe five minutes per turn.
Something like that. So sometimes I see also,
especially in pair, right, they can come up with multiple
keyboards together, you know, uh, I dunno, maybe you can even
type different things on different keyboards, right?
Is this something that should be avoided or is this something
that can also help in terms of the ensemble?
I think the normal, the normal flow of work is that everyone's
attention is directed to the same screen.
And having additional keyboards doesn't really help.
'Cause you want everyone to be in the same task of paying
attention to the same things. And the danger if you have
several people typing like in different files, is that you
basically just you are doing two tasks in the same code base
instead of cooperating on one task.
But of course everyone, when we're doing this online,
everyone's got their own computer and it doesn't take
long to just go and Google a thing and come back to the group
and say, oh, I found this thing that's useful or I found the
name of that method you're trying to call.
Or you know, so you, people can do bits of research and bring
that back to the group. But the, when you're working in
ensemble, generally everyone is focused on the same activity.
Yeah. And for that particular
activity, maybe if you can give guidance typically, uh, is it
something like you pick up a, I dunno, a ticket, uh, and then
you finish it end to end. Like from the development,
design, development, testing, deployment and all that?
Or is there like a typical, I dunno, activity that you
normally do? Is it like code kata or just
introducing tests or something like that?
Well, I think the ideal is that if you can get a task all the
way from start to finish. But of course, you might not
decide to do every aspect of it. I think you learn that from
experience. What kinds of tasks work well
and for what kinds of tasks the people you've got gathered
aren't the right people. And you need to do something
else. When you're first learning, I
think code katas are useful to practice on, cause of obviously
the, the amount of code that you need to understand is much
smaller and you can focus more on how the interactions are
happening and how you're communicating.
So it's a good thing to do if you're just starting out to
start with some code katas. I think if you read up on how
Woody Zuill originally got his team doing this, it was, they
did a lot of code katas before they tackled production code.
So I think just getting the, uh, the communication patterns down
when, in a situation where the stakes are low with the code,
that can be a good thing. But it is a technique that is,
you'll only get the real benefit of it if you're doing it in
production code, I guess. Yeah, you have emphasized a
couple of times about working on the production code.
I guess working on code kata can be fun.
And you can learn something, right?
But there's nothing that can beat, you know, understanding
production code, especially the complex one.
You know, where everybody has probably different parts of
knowledge within the code base, right?
And you can get to learn from each other, the techniques, the
design, and the issues that typically happen for some parts
of the code base. So another important aspect in
ensemble that I also read from the book is the importance of
like, trust, communication skills, and also kindness,
right? Because I'm sure everybody would
have seen bad code in, you know, anybody's code base, right?
So, and especially when working together, you can see different
people's code, being written as the result of, I don't know,
maybe sometime ago or maybe just recent, right?
So any important points that you wanna convey about this aspect,
like trust, communication, and kindness part.
It's all about teamwork and it's about the communication that is
gonna be respectful and helpful and, you know, get this
collaboration going. And the person who wrote the
code might be in the room, or they might not.
But in either case, you need to talk about the code, as you say,
in a respectful way. You don't know what they were
suffering when they wrote it. It might look completely wrong
and off the wall and badly written to you.
But there's probably a reason for it to be like that.
And you do need to be fine and respectful in the way you
interact with one another and with, and talk about the code.
So that's part of it as well, it's all about teamwork.
And this is what you need in a team anyway.
You've gotta trust your colleagues, you've gotta respect
them. And that's what it's all about.
A good ensemble just looks like a really, really gelled and good
team. Yeah, and I like the quote that
Woody mentioned about this, uh, ensemble thing, right?
Like "honor the code and the coder", right?
So of course you don't know what constraints they were dealing
with when they wrote the code. This is also probably like in
the agile retrospective, normally we call this prime
directive or something like that, right?
So no matter what happened, right?
Maybe that was the best thing that happened at that particular
point in time with the right person.
So maybe from your experience, you have been technical coach
for quite some time now and doing this ensemble.
What are some of the cool things that you have, I dunno, observed
or maybe you have achieved by doing this ensemble?
Right. So, well, I have this privilege,
I guess, that I get to go into a lot of different organizations
and teams to coach. There are coaches who have a
much more long-term relationship with like one organization and
several teams in that organization.
And I think that if the benefit of having this long-term
relationship is you really get to see teams develop and improve
over time. And I've seen a little bit of
that happening with other coaches that I've worked with.
But for me, I, I'm a bit of a, I hop from different organization
to different organization and just get a short amount of
coaching with lots of different teams and different places.
I'm not quite sure how, why it's like that, but that seems to be
the style of engagement that I have.
And it means I get to see a huge variety of teams and
organizations. And I guess I get to see that
everyone struggles with code quality.
Everyone has a certain amount of technical debt.
And everyone, basically, everyone I've seen could learn
to use the tools they have better.
I mean, everyone's got these amazing refactoring tools and AI
tools and all of that. And most developers are not
using even a fraction of what it's capable of.
So I get to have that reinforced every time I visit the team.
Let me show you. There's all these things that
you could be doing. I like to, uh, get people using
more shortcuts and more, you know.
I mean, most people have got rename these days, but no,
introduce variable, introduce parameter, move method.
These are refactorings that a lot of people have never tried.
And so I'm doing a lot of just getting people to use their
tools better. How about prompting?
Prompt engineering? So have you, um, introduced more
of that? Well, this is obviously quite a
new thing for most teams to have these AI tools.
So I have to say I haven't got a, a lot of hours under my belt
yet working with them. It's, of course, the skills, as
I said, are similar to the skills I know about, you know,
working in small chunks. Giving the prompt for quite a
well-defined task and making sure you know how to verify that
the thing has done the right thing.
So having tests and knowing how to write those tests and
checking the diff for what it's actually done.
All of these skills are things that maybe not completely
obvious to everyone. And more and more with the teams
I'm working with, we have to bring those in.
And we start in the ensemble to the person talking is
explaining. I think we need to prompt it
like this and this is what I'm gonna intend to verify when it's
done its thing. So there's a lot more of that
coming in, but it's early days for me at the moment with all
those AI tools, actually. As it is for many people, I
think. Yeah, I'm sure many people will
also feel it's early days for them, right?
Picking up new tools. Not to mention there are new
models coming in, new tools or new IDEs coming in, new agents
being invented. So obviously, there's always new
things to learn these days. And I like that the points that
you mentioned about your experience, right, observing
multiple teams, right? They're always code quality
issue. They are always tech debt.
And they're always underutilized tool.
So I think, many software engineers, I believe could
relate. So no matter where you go in any
company, right, you will see these themes over and over
again. So thanks for highlighting that.
I think that is quite insightful.
So the other aspect of Samman method that you mentioned is
about learning hours. I think learning is kind of like
given. Everybody knows that we have to
learn. But what specific things about
learning hours that is different?
Well, I've been a, I was a very early adopter of the Coding Dojo
back in the day, which is a forum where a bunch of
developers get together to do code katas and increase skills.
And I found that that was a really helpful thing to do.
But over the years, I realized that you could make it even
better by using some techniques from instructional design.
And in particular, I was very inspired by Sharon Bowman, who
is, uh, written this book Training from the Back of the
Room. And she's nothing to do with
software, but she knows a lot about instructional design and
how to make learning experience is more sticky so that you
remember more of the stuff and it has more of an impact in what
you do afterwards. I've been very inspired to take
a coding dojo, make it shorter, just an hour, you know, maybe a
little bit longer than an hour, but still pretty short for a
training. And trying to make sure that
it's structured to take full advantage of how, what's gonna
keep your attention? I use the 4C model, which comes
from the book. Uh, we open with a connect, get
everyone saying something about what they already know.
We do a new concept, why I present what it is we're gonna
learn, the new skill or the technique.
Then we have some concrete practice where everyone does
some coding. Usually coding exercise or some
form of exercise. And then the conclusions at the
end where we just try and make sure that everyone is, summarize
in their own words what we've learned so that they can
remember it better. So that's the structure that the
learning hour has that I, so I designed these as a, you know,
learning experiences for a team of software developers or to
learn coding skills. So thanks for sharing about this
Coding Dojo. I know that you have written a
book about it as well, so I think in the past I, I learned a
lot about this coding kata, Coding Dojo, right?
People are doing, I think I haven't heard about it lately.
I dunno why. Maybe people are dealing more
with the AI stuff by themselves solo.
But I think having this experience, learning in a dojo,
like with the targeted focus of problem, right?
So I think, with the right coach, which is also important,
right, can give a lot of benefits, right?
And you mentioned about specifically reducing it to an
hour, is there any particular thing about that hour?
Should we find an hour within our working days to actually do
this? Or should we do it outside
working hours? The Coding Dojo concept was a
little bit based on the idea that you would spend your
evenings, possibly your weekends, doing this kind of
training. And I did, I put in evenings of
weekends back in the day. And I found that, for me, that
was possible. And I thrived on that.
But for most developers, asking them to code in evenings and
weekends, it's just not gonna happen.
And they're just not gonna do it.
And for the organization, that's a bit of a failure because you
want people to upskill, learn stuff.
And I think the best way to ensure that they put the time in
is to give them time in the working week.
And that's where another reason for making it shorter, because
it's much less difficult to get a manager to agree to a one hour
training session than to get them to agree to a half a day,
you know? And you might be able to do it a
bit more often and with practical skills like coding,
the little and often is actually more effective than doing it
occasionally for longer. Obviously, when I come in and do
the coaching, the team will be doing learning hours with me for
all the days that I'm there. But even when I'm not there, my
hope is that they will perhaps be able to find an hour each,
each iteration or sprint maybe to do one of these and or even
more frequently if the boss will agree to it.
But that it should be part of the normal work.
Learning is part of your work, so let's put it into the
schedule and make sure that it happens on a regular basis.
That's the philosophy I think here.
Yeah, so learning is part of the work.
So I think this is very important, especially for
knowledge worker. I think software engineers are
knowledge worker, right? So we have to learn.
In the beginning, we also mentioned that software
engineering is a learning process, right?
Tackling complexity. Making sure that we can learn
the problem better. And I think you mentioned as
well about learning, right? That we have to spend the time
to actually learn. I don't know, like how people,
uh, learn these days, right? I'm sure there are many
channels, right? But learning as a team is
probably a more powerful thing to do as well like the ensemble
thing that you mentioned, right? So maybe these days people have
instilled in their mind agile practices.
Things like, I dunno, daily standup retrospective, demo, and
things like that. What will be some typical, I
dunno, ceremonies for learning that you advocate for your
teams? Yeah, so I guess I was trying to
hint there that if you can get a learning hour in each sprint,
then that's a cadence that I think you should be able to
sustain. If you can get more than that,
then that's a bonus. What I see when I go into most
teams is that the only learning activity they have is code
reviews as part of the pull request process.
And that is just universal. It seems to me everyone is doing
these pull requests. And I'm, it's fine.
Code review is a good thing to do, but it's happening after the
code is written. It's happening asynchronously.
It's written. And these are not great for
actually training up junior developers.
You want something a lot more kind of face-to-face interactive
happening while the work is going on and to actually help
them to upskill and to turn into those senior developers that you
want. I think something like pair
programming or ensemble is, that's the forum where you
actually turn juniors into seniors.
And you can do that obviously on the production code, so that you
get work done at the same time as you are upskilling people.
The great benefit of a learning hour, of course, is you can take
a skill that you need for your production code and you can
practice it on a simpler environment where you can repeat
it and really start to get that fluency with it.
And to make sure you remember all the steps so that when you
meet that same situation in your production code, that it comes
naturally to you. So I think for a healthy team,
they'll have some learning hours, but they'll also have
some collaborative coding, some pairing and ensemble in order to
level up the more junior team members.
And also the senior members, I mean, they benefit from this
too. So if you are sitting with a
junior and they're not getting something, you have to explain
it to them. You have to learn to put into
words what it is you do and to explain why you do that.
And just that kind of being forced to explain helps you to
understand it better yourself. So I think it really benefits
the senior team members to also level up their skills by having
those juniors that they need to explain stuff to.
So I think this is one of the sort of the great strengths of
the way we organize software developers today is into teams
with a mix of, you know, years of experience that you've got
juniors and seniors who have this vested interest in, well,
we're gonna work together, we're a team.
If that other person upskills, then it makes my life easier.
So I have an interest in coaching them and mentoring
them. And yeah, so that's the way a
healthy team should be from my perspective.
Yeah, so I like that you mentioned about pull requests,
right? I think maybe in many software
engineering team, this is like the workflow that they adopt,
right? So like a pull request being
raised and somebody review. Good thing if the pull request
is small. But if it's large, I guess it's
very difficult to actually understand, even.
And sometimes like the challenge is like what you mentioned is an
after effect thing, right? So the code has already been
written, the thought process is missing, the context probably is
missing. And you, yourself has your own
thing that you work on that maybe still lingering in your
mind and you just couldn't forget, right?
And yeah, it's very difficult to actually learn from such
situation. And I guess the pull request
thing can be detrimental to the learning that people can have,
right, so compared to like pair programming.
Yeah, I wouldn't say it was detrimental.
I mean, I think there's a lot of evidence that code review is a
useful practice, so I don't wanna tell people not to do code
review. But I just think you can't pin
all your hopes on it, that this is gonna do all of the
mentoring, you know. This is not something the,
shouldn't be the primary mechanism to give advice to
junior developers. So I'm not sure that it, yeah,
I'm not trying to say don't do it.
Although I happen to be a big fan of trunk-based development.
I think that's not a battle I really wanna fight.
The thing I'm most interested in is making sure that senior
developers actually collaborate with the rest of the team
members, and don't just think that it's enough to write a pull
request comment from time to time.
That's not being a senior developer, you know?
Yeah, I was about to mention about comments as well, right?
Because in a pull request, typically.
If you put a lot of comments, the longer it will take, because
it's async as well, and people kind of like multitasking,
right? So obviously maybe trunk based
development is something that people should aspire to.
But yeah, definitely different team has different contexts and
the practice that works best for them.
So one thing about learning, right?
So I think it's ideal, every team should have this learning
hours probably. But you know, these days there's
so many software engineering team that are just, you know,
bogged down with so many different tasks, right?
Uh, and so many different things that they have to do with such a
small team, right? So again, like how do you
actually do the elevator pitch, like as a team, right?
So maybe once a sprint you can spend, I don't know, quality
time to actually do some learning.
Because some people are really struggling to find the time to
actually do this kind of thing. Yeah, I know it's, that's one of
the great benefits of being a technical coach is that I'm not
responsible for delivering any of those tickets, so I can
really, uh, have that time to prepare training materials.
And when I come into a team, I can help them without needing to
get involved with the deadlines that they're facing.
So that's a great, you know, privilege I have.
But yes, if you are a tech lead and a team with delivery
responsibility, it's hard to think, oh, I've gotta organize a
learning hour as well. And that's one of the things
that I'm, I think for it to really, you know, for this to
happen, people to be upskilled, that it's not enough that
there's a bunch of people like me running around being
technical coaches. We need to make it possible also
for normal team leads to do learning hours.
So one of the things I've done is found a society, a
not-for-profit organization, the Samman Society.
And we try and provide resources for all technical coaches and
all software developers to make it easier to learn these things.
So we've got a website and we have online meetings where you
can meet other coaches. But published on the website, we
publish code katas. We publish also descriptions of
learning hours. So you can go on there and, you
know, pick a topic that you, you'd like your team to upskill
in. There you find hopefully some
materials, some suggestions for how to structure a session.
Some code katas to work on. Hopefully that's gonna make it
easier for normal developers to do this.
And then of course, I've also got the whole, uh, YouTube
channel thing. Written descriptions of a
learning hour is great, but I find video is a great medium for
showing coding techniques. So a lot of the videos that I
produce are little demos of refactoring techniques and
little code katas and stuff that you could try out as well.
So I'm doing more of that as well these days.
Wow! That I think is really helpful,
right? So for people, again, many
people might be new to these kind of techniques, right?
Having resources definitely is gonna help them.
And I think I've seen a couple of your videos on YouTube.
They're really interactive and you know, you can see exactly,
you know, how you do stuff. I think that's definitely a
thing that people should, you know, maybe learn something from
your resources. And for people who aspire to be
technical coach, right? Because, I don't know, some
people are just born into this, you know, engineering practices,
TDD. They wanna upskill people doing
quality stuff with their code. Is there a thing that you want
to convey to them? How can they become a better
technical coach? Yeah, so I think the world needs
more technical coaches and technical coaching.
And I think that it, as I said, if you, if you're a developer or
a tech lead on a team and you start doing a few learning
hours, then basically you are doing some technical coaching
part-time. And if you are in an
understanding organization who realizes the value of that,
maybe they'll let you grow that role from being just a thing you
do with your team from time to time that maybe you can lead
learning hours with other teams. And maybe you could start doing
some ensemble and, you know, start to build it up as a bigger
part of your role. And maybe even then transfer
into a, like a staff engineer role in your organization where
you've got responsibilities for more than one team.
And part of your role could be doing these kind of technical
coaching activities alongside, I mean, staff engineers do loads
of variety of important technical leadership things.
And I think you can combine it with some technical coaching.
And then, uh, maybe if you really like this side of the
work, you could go full-time like I have and be an
independent coach. But I kind of see the, the path
into this through basically a part-time role alongside tech
lead and growing that in your organization.
Although, I mean there are organizations that are hiring
technical coaches and maybe be lucky enough to, to get a
full-time role straight away, but I think it's more likely it
would be alongside a staff engineer role.
Yeah. So I think, I mean definitely
there are people who are interested in doing this, right,
within the team. I think the message here is just
keep continue doing that, right? And that's also improving your
skills, right? Maybe your soft skills, maybe
your teaching skills, right? And also learning new things,
right? Because I'm sure you want to
learn new things together with others as well and making sure
that people also learn benefit from the learning, right?
So I think you mentioned about being technical coach.
How do you actually get measured?
This is something that I'm quite curious because is it more like
an engagement, uh, with a set of, I don't know, teachable
skills? Or is there something else that
you measure quantifiable? Yeah, this is one of the hardest
parts of my job 'cause it really just does not interest me at
all. This whole thing of metrics and
performance and, yeah, that's managers obviously do a lot more
of that. And I'm, I've made a deliberate
choice in my career not to be a manager.
All of this kind of like, how do we measure if the technical
coach is effective? My usual answer is, well, ask
the team. What did they think this has
given them? And try and perhaps do a survey
before and after the coaching about their attitudes towards
teamwork and, and ensemble and ask about their attitudes to TDD
and code quality, and see if there's a shift through the
coaching. And then also, while the
coaching is going on, I like to write little summaries that I
send to the managers about what happens during that coaching
session. And really just like a
paragraph. No more than two or three
sentences really just to describe the what happened and
the impact that I think it should be having on the team and
the organization. So the manager gets then, at the
end of the coaching, summary of all of those little summaries,
it's a bit meta. They get a kind of an idea
about, well, this is what I, as the coach, think that the team
has got outta this coaching. And then they can go and
basically follow up. Do they observe that continuing
after the coach left? That's the way I usually try and
help people to understand what is the value of this.
Yeah, it's always difficult to kind of like quantify coaching,
right? Because sometimes it's like more
abstract, right? There's not immediate impact as
well, right? It's not like suddenly you can
do code faster, for example, produce more lines of code.
Um, but I think... Yeah, you hope, you hope that
people will be more productive and better coders afterwards,
but those things are really hard to measure and they...
It might take a while before you see, you know, an increase in
productivity, if the code quality is very low.
It could take a while to raise it, you know, so I think there
are people much more interested in those questions than I am,
who would be able to tell you more about how to measure
developer productivity and the impact of some coaching.
So I just gonna dodge the question, basically.
So, let's go back maybe to the AI case, right?
So I'm sure with the advancement of AI these days, like
especially the agentic thing that could happen, you know,
asynchronously. And there's a danger that people
probably do a lot of multitasking, accepting AI
suggestions or even just merging the code straight away, right,
to production. As a technical coach, maybe you
have something to say about this.
What do you think? Like your prediction, like what
could happen if this trend continues?
Yeah. So I've definitely heard that,
that people are, you know, vibe coding and that can mean not
looking at the code the thing produces at all.
Just kind of accepting, oh, it looks, it looks good to me,
let's just ship it. And of course, I see a danger in
the code quality there, not being quite what you'd like it
to be. And I kind of have this notion
that as a software developer, I'm responsible for the quality
of the work that I deliver. And if I haven't even looked at
the code, I mean, how do I know that it's gonna be even vaguely
something I could stand up for? I mean, okay.
Okay. I'm, I want to use these tools
to augment my abilities and to write even better code than I'd
be capable of without the tool. So, uh, I want to look at the
code that it produces before I ship it.
I think that's actually quite fundamental, that a software
developer should be responsible for the code they produce.
Yeah. But one challenge with these
tools is like kind of seductive, right?
Like it can churn out code really, really fast
automatically. And I've experienced myself
using some newer models, they're like hungry to give you like a
lot of output, right? You know, like maybe I could do
this, I could do that and keep on doing stuff that sometimes
yeah, you wanna see how far it goes, right?
But after they have done it, right?
It's like so many things. I think it's really hard to
review. Maybe I don't know whether you
have this special case that you have seen before?
Maybe I need to qualify this with, if you're writing a
prototype or proof of concept to show that you could write
software to solve this problem or... and, uh, it's not gonna go
into production and... then that's a very good use case for
just doing, as you say, just get it to produce a huge amount of
code that just demonstrate what could happen.
But I think if most of the teams I'm working with are not in that
situation, they're, they've got a large existing code base,
which is pretty complex and valuable and is producing a lot
of money for the company. And if you are using the AI to
produce a load of code that is gonna be unmaintainable and
integrate with this existing code base, it's a bit of a
recipe for disaster. I think it's gonna come back and
bite you pretty soon. So most of the developers I'm
working with, I'm saying, look, yeah, use the AI tool to get
ideas and suggestions, but you've gotta check it and you've
gotta be making sure that the changes that it's making are in
line with the rest of the system that's already there and that
you're gonna be able to maintain it.
So I think, yeah, I advise against just producing huge
amounts of code that you don't really understand.
That, that doesn't seem like a recipe for success.
Right. And this gives a much more
importance for, I dunno, reading code, rationalizing the design
that is, you know, generated, right?
So do you think, uh, there are like more prominent new skills
that, I don't know, like technical people or maybe
technical coach needs to be aware of?
That something, you know, because of AI, right?
We have to be more careful about this.
Or maybe some skills, I dunno, like reading code, making sure
the code is well written in terms of variable naming, design
and all that. Maybe some things that you can
advise us as well. Yeah, I'm not, I think the
fundamentals are still the same. The modern software engineering
skills of being able to look at a problem and break down the
complexity of it into a modular design.
And being able to work out how to build that design in small
steps and react. As you get more code, you
realize that the design you initially had in your head maybe
wasn't the best. And you can adapt and move the
design in a different direction. So it's about being able to
explain to the AI tool this is the problem I want you to solve
now concisely and then to verify that the code it produces does
that. So as you say, code reading
skills. And then refactoring skills to
say, actually I wanna move this in a different direction.
At the time I'm speaking now, the AI tools aren't that good at
refactoring. Um, they tend to introduce
errors and do unexpected things. I still think it's a really
useful to learn refactoring tools, deterministic refactoring
tools, because they do it in a reliable way that is
predictable. I think that, uh, the
refactoring skills are still valuable.
But the skill I, you know, describing this is the piece of
the problem I wanna solve now, that's test-driven development.
That's being able to break down a problem and describe what the
next bit should do. The abstraction level has gone
up a little, and I can describe it more in words than in a test
case. But still, I think it's
fundamentally the same skills that you need to be a good
engineer today as it were before AI was invented, actually.
Yeah, I like that you mentioned about refactoring, right?
I, from my experience as well, using these AI tools, I feel
that refactoring is very, very crucial.
And if we think about the TDD loop, right?
You know, red, green, refactor, right?
I think these days like prompt, I dunno, uh, red, green, the
refactoring part is actually still very important.
Because I can see AI generating code that is still kind of like
procedural, long lines of code. And even they just put comments
on top of some sections of the code rather than creating, you
know, methods. So I think, um, not, not, uh,
doing refactoring is I think a big mistake, uh, especially if
the software needs to be maintainable in the future,
right? 'Cause you could end up like
with so many lines of code in just one particular class or
function, right? And it gets so difficult to
understand over the time. So I think thanks for mentioning
about refactoring. I think for people who are still
not familiar with the refactoring technique, please do
learn about that. And what I'm seeing quite
interesting as well, people actually do the refactoring by
prompting the AI to do the refactoring.
Uh. Although it's not deterministic,
right? There's no like compiler thing
and the structure of the code, static code analysis that is
being used. Sometimes it gets to produce a
decent result. But what do you think about this
refactoring through AI? Because it's, again, like I
said, right, it's quite seductive.
You could just instruct something to do something for
you rather than, you know, the mechanics of, you know, doing
all this refactoring by yourself.
I think there's studies to show this, that it actually, AI tools
are very bad at refactoring. They make mistakes, they
introduce bugs and they forget things or they introduce dead
code or, you know, they do random stuff.
And I think the tools are bound to get better.
They seem to be getting better all the time.
But at the moment, I don't think you should trust it to do
refactoring, particularly, if you've got a significant amount
of code in your project. It won't find all the places to
update. It will do random things.
But we do have, for many years now, reliable deterministic
refactoring tools. Use them, for goodness sake!
I think it's much better to use a reliable tool that you know
what it's gonna do, and it's gonna find all the right spots
to update than to ask the AI to do it.
And the cost, of course, is that you need to learn how to use the
refactoring tool and learn what the thing is called and where,
how to prompt, you know, where to put the cursor.
One thing I really realize now, I've been teaching refactoring
tools to so many developers, how un-user friendly these tools
really are. I mean, you have to get the
cursor in exactly the right spots for the menu item to even
appear. And then the name of the menu
item is something that isn't perhaps anything you recognize.
It's called transform parameter or introduce parameter object.
And when I first read those, I was like, well, I dunno what
that is. I'm a bit scared to click on
that. I don't know what it's gonna do.
Um, and then you... but so you, that is the thing that, you
know, that the usability isn't there, whereas the AI tool, you
can say, okay, I need to change the class of that parameter and,
uh, introduce an adapter pattern and it might understand you.
So I think that the, uh, refactoring, deterministic
refactoring tools have got a usability problem.
But I think the solution is not to just tell people to use AI
instead. Right.
So you mentioned a very valid point, right?
So I think the vocabulary, right, the techniques.
I think Martin Fowler has a book about refactoring.
I think some other people, maybe like Michael Feathers' Working
with Legacy Code has some techniques for doing this
refactoring kind of thing. Definitely, knowing the
vocabulary helps, right? But getting to master the tools
in order to do that deterministically, I think it's
also still crucial for software developers as well.
So I think it's been a great thing to learn from you, Emily.
So I dunno whether there are a thing or two about ensemble or
Samman method that you still wanna convey to us.
Maybe is there a thing that you wanna plug in?
I would encourage anyone interested in technical coaching
or the Samman method to come and look at our website,
sammancoaching.org. Uh, we have a newsletter that
you can sign up for and then you'll hear about updates to the
website and new materials that we publish.
And of course, we have these in-person shorts, online
meetings every month. If you're on a suitable time
zone to come along. You can come and meet me and
other coaches at those. So that's something to try if
you're interested. Yeah, sounds like it's gonna be
fun, right? So having technical coaches
together and exchanging, you know, good practices.
I think definitely it'll amplify a lot of the skills, right?
So Emily, I only have one last question before, uh, we wrap up
this conversation. I normally, call this the three
technical leadership wisdom. I always ask this to my guests.
If you can think of it just like advice that you want to give to
the listeners. Maybe you can share your version
today, that would be great. Okay, okay.
So I've, I, you've told me this in advance, so I've prepared,
uh, three things. So the first technical
leadership wisdom is that junior developers need mentoring to
turn into senior developers. And mentoring is more than just
writing comments and pull requests.
Find a way to make sure you're actually mentoring your juniors.
The other thing is that about technical leadership is you
don't learn how to produce beautiful code only by looking
at a good design and analyzing it.
You learn to produce a good design by watching good
designers coming up with that design.
So you need to involve juniors in the design process and show
them not just the end result. Then the other thing I wanted to
say is that, in terms of technical leadership, that
sometimes it helps to have someone from outside like a
technical coach come in and help your team.
Our priority as a technical coach is to level up the team,
not to deliver features. And that could give you some
time and breathing space to actually focus on that and not
only delivering. So, uh, perhaps think about
getting in a technical coach for a short period or to level up if
you need that. Right, I think that's really
beautiful, right? So you emphasize a lot about
bringing people along into the journey, right?
The juniors or maybe the one who doesn't understand about good
design, right? Bringing them along to the
journey and making sure they learn from, you know, the
evolution, right? From like the bad to the good,
for example. But maybe for some people who
find it hard to find mentors, any last piece for them?
Like how do you actually find mentors that could actually
upskill you, bringing them along with the journey?
I spent a lot of my career looking for mentors.
I think it's really important to just, if you are in a team and
you're not getting that, then perhaps you need to look around
and see, is it, could you transfer to a team that has
somebody who will mentor you? And if not, then maybe I don't,
I hesitate to ask you to put your free time in.
But that is also an option. Go along to open ensembles and,
uh, events by the Samman Society and so on and see if you can get
people who will help you. I think everyone needs that to
progress in your career. You need mentors.
Yeah, so definitely go to the community, go to the forum,
maybe online, offline, right? Talk to people, I think that's
always still the best way to find good mentors, right?
Sometimes you are lucky you can find good mentors at work,
right? Working side by side with you.
I think that will be great definitely.
But for many people, sometimes this is not a thing that they
have, not fortunate enough to have that.
So definitely talk to people. Be active, talk around, uh, and
maybe join, uh, one of these sessions that Emily has.
I think that will be great things to find good mentors as
well. So thank you so much for
teaching us about Samman method, ensemble and importance of
learning hours. So I hope that people can do
practice of some of this. And also remember about the
danger using AI without actually caring about the quality or the
output that they produce. So thanks again, Emily.
Thank you so much for having me.