#230 - Technical Coaching in the Age of AI with Samman (Ensemble) - Emily Bache

[00:01:26] Introduction

Henry Suryawirawan: 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.

Emily Bache: Thank you for having me. I’m pleased to be invited.

[00:02:22] Career Turning Points

Henry Suryawirawan: 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?

Emily Bache: 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.

[00:03:23] Being Part of Modern Engineering YouTube Channel

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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.

[00:04:27] The Role of a Technical Coach

Henry Suryawirawan: 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?

Emily Bache: 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.

[00:05:42] The Impact of AI on Technical Coaching

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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.

[00:08:20] Sofware Engineering is a Learning Process

Henry Suryawirawan: 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.

Emily Bache: 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.

[00:09:55] Optimizing Learning With Samman Method

Henry Suryawirawan: 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.

Emily Bache: 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.

[00:11:40] The Samman Method: Ensemble (Mob Programming)

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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?

[00:14:59] The Main Benefit of Ensemble: Single Piece Flow

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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?

[00:17:26] How to Do Ensemble and Avoid Common Failure Modes

Henry Suryawirawan: 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.

Emily Bache: 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.

Henry Suryawirawan: 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?

Emily Bache: 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.

[00:20:27] The Types of Coding to Ensemble On

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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.

[00:22:12] The Importance of Trust, Communication, and Kindness

Henry Suryawirawan: 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.

Emily Bache: 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.

Henry Suryawirawan: 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.

[00:23:52] Common Things Development Teams Are Struggling With

Henry Suryawirawan: 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?

Emily Bache: 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.

[00:25:37] Prompt Engineering

Henry Suryawirawan: How about prompting? Prompt engineering? So have you, um, introduced more of that?

Emily Bache: 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.

Henry Suryawirawan: 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.

[00:27:16] The Samman Method: Learning Hours

Henry Suryawirawan: 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?

Emily Bache: 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.

[00:29:08] Learning is Part of the Work

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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.

[00:31:32] The Practice of Learning as a Team

Henry Suryawirawan: 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?

Emily Bache: 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.

[00:34:39] The Constraint When Learning from Pull Requests

Henry Suryawirawan: 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.

Emily Bache: 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?

Henry Suryawirawan: 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.

[00:36:30] Putting Aside Time for Learning Hours

Henry Suryawirawan: 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.

Emily Bache: 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.

Henry Suryawirawan: 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.

[00:39:14] Becoming a Technical Coach

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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?

[00:41:23] How to Measure the Effectiveness of Technical Coaching

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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…

Emily Bache: 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.

[00:43:52] The Danger of AI Assisted Coding

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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?

Emily Bache: 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.

[00:46:59] The (Still) Important Skills in the AI Era

Henry Suryawirawan: 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.

Emily Bache: 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.

Henry Suryawirawan: 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.

[00:49:56] Why We Should Not Refactor Through AI

Henry Suryawirawan: 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.

Emily Bache: 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.

Henry Suryawirawan: 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.

[00:52:41] The Samman Method & Technical Coaching Resources

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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?

[00:53:29] 3 Tech Lead Wisdom

Henry Suryawirawan: 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.

Emily Bache: 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.

[00:54:56] Finding Mentors for Career Progression

Henry Suryawirawan: 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?

Emily Bache: 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.

Henry Suryawirawan: 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.

Emily Bache: Thank you so much for having me.

– End –