Emily Bache, founder of the Samman Technical Coaching Society and author of several books about technical agile coaching, talks with SE Radio host Sam Taggart about katas and the importance of practice. They discuss how practicing in a safe environment helps developers to learn new skills and build new habits. They also talk about how Samman coaching combines this sort of deliberate practice with applying the lessons learned in practice to the production code base. They also touch briefly on the advantages of working in an ensemble fashion.
Show Notes
Related links
- YouTube: @EmilyBache-tech-coach
- Github: emilybache
- sammancoaching.org
- leanpub.com/u/emilybache
- Twitter: @emilybache
Related Episodes
- Episode 555: On Freund on Upskilling
- Episode 529: Jeff Perry on Career Management for Software Engineers
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Sam Taggart 00:00:18 This is Sam Taggart for SE Radio. I’m here today with Emily Bache to talk about katas and the importance of practice. Emily is an independent consultant, YouTuber and technical coach. She’s the author of two books related to coaching and teaches courses for Plural Slate and O’Reilly. She founded the Samman Technical Coaching Society in order to promote technical excellence and support coaches. Welcome Emily.
Emily Bache 00:00:41 Thank you. It’s lovely to be with you here today.
Sam Taggart 00:00:44 So to get started, you’re most well-known, or at least I know you best for your collection of katas. So maybe we can start by talking about what is a kata?
Emily Bache 00:00:54 Well it’s a small coding exercise that you can use to practice skills and get better at things like refactoring and test-driven development.
Sam Taggart 00:01:02 So often katas are associated with code retreats or coaching. Are these exercises that I can just go do on my own?
Emily Bache 00:01:09 Well, yes. I mean a lot of software developers will do that. They’ll just find an hour or so that they’ve got time to practice and open the code kata in your favorite IDE or editor and you get to choose from a number of different programming languages for most of them or some of them are just from scratch and you can start with an empty editor, some of them you start with a piece of code that you need to refactor and build on and then you, you can just spend the time writing the best possible code in the best possible way and improving your coding skills.
Sam Taggart 00:01:39 Great. So do you ever have trouble selling this practice idea to management? I assume people are doing this like during their work time sometimes. Do you ever get any pushback from management? Because I can imagine some managers saying, well, you know, you want to learn, but why don’t you just learn on the job? Like why is practicing outside of normal daily work useful?
Emily Bache 00:02:00 Well the thing with a code kata is it’s a lot simpler than your production code. So you can really focus on the skills and the moves of coding well and gain the fluency that you need to be able to do that in your production code later on. So if you spend some time practicing doing a particular refactoring using your shortcuts, you’ll find that when you need those same things in your production code later, they’ll come to you more easily. You’ll be able to code more quickly and get the code into the editor and into your production code more fluently and easily and better and raise the quality of your work. So I think, I mean whether you should do that on work time, I mean some people have argued that you should do this on your free time as a kind of investment in your own skills and your personal developments. I think that’s a little shortsighted for employers to think that developers are going to do that. I think it’s actually in everyone’s interest that there is at least a small amount of work time allocated for personal developments and getting better at your job. Everyone wins from developers improving the whole time. So those are the kind of things that I would say to managers. It doesn’t need to be a lot of time, but sometimes spent practicing and improving will benefit the organization as a whole and could work time.
Sam Taggart 00:03:15 That leads into my next question, which is how often do you recommend that developers do katas? Should this like a daily, weekly, monthly type of thing?
Emily Bache 00:03:26 I mean it depends a lot on your previous skills and knowledge and how much pressure there is in your project. Because you don’t want to be doing this kind of practice if you’re feeling really pressured and there’s a lot going on and you don’t have the head space. Or on the other hand it could be a good way to relax and calm down if you’re in a really stressful situation. But still I think it’s got to be agreed with the team and the individual and their manager. But something like, you know, an hour a sprint should be all right or a couple of hours a sprint. Yeah.
Sam Taggart 00:03:56 Yeah. So can you talk a little bit about your comment earlier, remind me about where katas come from because I used to do like some martial arts and I feel like in martial arts you do the katas and it’s about like building muscle memory. Is that like similar when you’re talking about like shortcuts and things like that?
Emily Bache 00:04:13 Yeah, so this idea of fluency, things that you can do without really having to think a lot about it, it’s an aspect of skill. So knowing how to do a refactoring like so one of the code kata, I want an example here. One of the code kata I like is Parrot. It allows you to practice the moves of converting a switch statement a conditional into polymorphism with class hierarchy. And usually there are a few steps to this conversion and it’s not something that you need to do every day when you’re working in your production code, but when you do, it’s good to know the moves and know how to do it safely and extend your design and make it more extensible for the future. So a bit of time spent practicing on the Parrot code kata means that you’ve just got all those moves kind of, yeah, like you say in your muscle memory and it goes much more smoothly when you need to do that in your production code. There’s a difference between knowing on in theory what the moves are and having practiced them and being able to just bring them out. You’ve got so much more brain capacity left over for the rest of your job basically.
Sam Taggart 00:05:18 Yeah. The other thing I’ve noticed about katas in the comparison to martial arts is like doing martial arts, you do a kata and if you have somebody watching you like an instructor, they’ll come in and they’ll just like tweak one little thing and then you practice again and you, it makes it very easy to focus by doing it over and over again. You can focus on like tiny little details. Have you noticed that?
Emily Bache 00:05:37 Yeah, although I mean it’s not usually somebody else observing me, I’m observing myself and often it’s like I think there should be a better way to do this. And looking like my tools have extensive refactoring capabilities, a lot of which I don’t know as well as I could. So it’s about thinking, is there an easier way to do this? There’s a lot of manual steps in this part of the refactoring. Let’s see if there’s a good way to do this with the tool instead. So reflecting on your own habits and how you’re working is part of doing a kata, yeah. And some people publish like so I publish now demos of me doing code kata, like little videos and that can be a way to go back and think, ah you could do it like that too. Maybe I should try that in my tools.
Sam Taggart 00:06:20 Yeah. I find it interesting every time I do them you can kind of just, you end up at a slightly different place every time.
Emily Bache 00:06:27 Right, right. So that’s a difference with the martial arts. Because I get the feeling with the martial arts you’re supposed to do it the same every time and there’s some kind of ideal that you are heading towards, whereas that’s not the case with a code kata you probably do it differently every time and learn something different every time. And that’s part of the joy of it actually that you’re continually learning and improving. Yeah, it’s not about doing it the same every time.
Sam Taggart 00:06:50 I think in the martial arts it can be used that way. I think often it’s used because people are trying to get promoted to like a new belt or something and so like they have to do it exactly the way the instructor wants them to do it and it’s kind of graded. Whereas like when you’re doing code katas for yourself and coding, for me it’s always like, it’s just an exploration. It’s kind of almost like a fun playful thing of like let’s start here and see where we end up and see you know, what happens if I use this one tool as opposed to another If I try this, you know I did these two refactoring but maybe what if I do them in the opposite order? Does that lead me somewhere else or something like that.
Emily Bache 00:07:24 Yeah, absolutely. Yeah, being playful and creative and learning more about how to code well and there aren’t any wrong answers, you know, there’s no way to do a code kata wrong. Well if you break all the tests and the code doesn’t work at the end, then yeah okay. But you know, within the reasonable definition of success there are a lot of ways to solve a code kata. Yeah.
Sam Taggart 00:07:46 You hit on something too. The other thing I like to practice when I practice them is taking those small steps because I feel like one of the problems in software engineering is we try to take two biggest steps sometimes. So breaking things down into smaller steps I find quite useful.
Emily Bache 00:07:59 Well it’s the classic isn’t it? How do you solve a big problem while you break it into pieces and the scale of being able to take, you know, you’ve got a goal for where you want the design to go and being able to break down the steps to how to get to that design and how to build the pieces and make it work at each stage. There’s a huge benefit in being able to work that way so that the code is working after each of those small steps rather than trying to take one giant leap and the code being broken for a long time in between the kind of the style of coding where you can work in small steps I think is more effective. You are more in control and you also have more opportunities to change direction and end up in a better place than the one you first envisaged.
Sam Taggart 00:08:42 Yeah, I always think about that as taking big steps could get you there faster but it’s always riskier. like by taking those smaller steps you’re guaranteeing that like as you go along you’re not breaking things because if you make that big step and you do it all at once and it works, hey that’s great, you just saved a ton of time. But if it doesn’t work then you spend a bunch of time going back and trying to figure out what’s wrong and it tends to take a lot of extra time.
Emily Bache 00:09:03 A lot of software developers aren’t really aware of that and I think just practicing on code katas gives you that awareness of actually I’ve spent too long on this, I should have had passing tests by now. Maybe I need to rethink and back up and try again. And you can do that in a code kata in a way that you might not in production code.
Sam Taggart 00:09:21 Yeah. So you mentioned there are different types of skills that you can practice with a code kata. What are some of the skills that you can practice and can you give us some examples of how you would practice those?
Emily Bache 00:09:30 I’m quite a fan of refactoring katas. So like Parrot that I mentioned before, practicing a particular transformation of a design. A lot of the refactoring katas though actually you start with code that has a really bad design and very little structure and the challenge of those ones is to practice cleaning it up and imposing a structure and getting to a point where the design is easier to understand and extend. Often a refactoring kata has a new requirement that you need to implement and before that’s going to be feasible you’ve got to get the code into a better state using lots of smaller refactoring. So that’s one aspect, just getting better and more fluent with transforming a design from one place to another. Another thing that people practice of course is just test-driven development starting with just a problem description, some code that you need to write and an empty editor, how do we get there using TDD which is like the first test that you write, what happens when that fails and what design do you come up with and what steps you take after that. So how do you break down that problem into steps and implement them test by test. So that’s a great use of code katas and honestly those are the two main things TDD and refactoring.
Sam Taggart 00:10:43 Okay. So if I understand correctly, like the TDD tests, basically those work in any language very easily because you don’t need any pre-existing code, right? You just sit down with a problem statement, and you just start. Is that basically how it works? Yeah. Okay. And is there a variety in those? Are they all basically just like here’s an exercise go start. Like are there ways to practice different aspects of TDD or different types of TDD?
Emily Bache 00:11:07 Well I mean I’ve been playing with this a bit because TDD as a discipline it’s quite big. There are lots of aspects to TDD and to be successful with it you need a lot of skills. You need, you know, like the skill to design a test case, you need the skill to be able to refactor away duplication that you may have introduced like by triangulation. You need the skill of just taking that problem and breaking it into steps in what order to do them in. There’s a bunch of other things involved and that, if you’re not very experienced with TDD, doing all of that at once in the first place is quite difficult. So I’ve been trying to experiment with, well what if we give people the list of test cases and say, so here’s a description of the problem and here’s a description of the test cases in the order that you should do them in. Or what if we actually give them the test cases, just kind of like comment it out and get them to implement them one by one? Because then you’ve removed some of the challenge of TDD, you’ve removed the part we have to break down the problem or you’ve removed the part
Emily Bache 00:12:05 we have to design the test cases so that people can focus on other aspects like just working in small steps and refactoring after each one. So I’ve got a few katas which I’ve tried to do that withand I’m actively using these in the kind of training and coaching that I do. So there are some which are a bit like that.
Sam Taggart 00:12:23 Yeah, we’ll talk more about the training and coaching in a little bit. So some other questions I have. So for the refactoring katas, what languages do these exist in? Are they available in any language most of them? Are most of them specific to a language or a language feature, right? Where practicing refactor there certain refactoring that only work in certain languages like certain patterns, things like that?
Emily Bache 00:12:44 Well yeah, I mean my most famous refactoring kata is the Gilded Rose and that’s translated in like 50 odd languages, some of them very surprising. It turns out you can write bad procedural style code in pretty much any programming language and I’m constantly surprised they’ve, I’ve got a translation like UML which an XSLT, I mean these are not mainstream kind of things you think of as programming languages. So code katas can be available in a lot of strange languages, but really it’s all volunteer efforts. So when I create a refactoring kata, I obviously do it in one language that occurs to me and then usually I’ll translate it into the two or three languages that I might use when I’m training and coaching people. And then it’s all up there on open source on GitHub and people send me pull requests with translations. So a lot of the katas are available in a lot of languages and it’s not primarily me who’s done all those translations most of the time.
Sam Taggart 00:13:42 You also hit on something else that I’ve found and that is you talk about writing bad code, I find it very hard to write bad code sometimes. When I’m trying to come up with an example of like, oh don’t do this. Like it’s almost, and maybe it’s because I’ve practiced a lot but that like muscle memory it’s like I have to force myself to do it the wrong way. Do you run into that at all?
Emily Bache 00:14:02 Yeah, so a lot of the refactoring katas are inspired by production code that I’ve seen. I’ve thought oh this was really difficult to refactor, I think I need to make an exercise out of this. So that’s inspiration for quite a lot of them. But some of them it is, I’ve thought it through and thought I need an exercise for practicing this particular refactoring. Can I construct an example that needs that? So some of them are more constructed and I don’t always succeed in making something that’s realistic but you know, some of them are better than others.
Sam Taggart 00:14:33 So yeah. You mentioned production code, so how well do skills transfer from, okay, I learned how to do this in the kata. Can you talk about some examples of where you’ve seen teams that were struggling with something and then somehow by doing these katas they learned some skills that they were able to apply?
Emily Bache 00:14:48 Oh yeah. Yeah. So I mean this happens when I’m coaching because it’s, it was one team I was working with recently and we would do the coaching, like I would do a learning hour where we would practice on a code kata and then to work in their production code afterwards altogether. And we were using exactly the same skills in the session afterwards and sometimes it just works really well and you think, yeah, actually this learning hour we’re going to use it straight away in the next coaching session. So that’s kind of one of my goals I think when I’m coaching to try and come up with a learning hour that’s totally relevant to their situation. I can say this particular team, they had some C code that was pretty old and a long function that was really long and complex and that they didn’t fully understand.
Emily Bache 00:15:39 The naming was really poor, it was doing far too much and it needed migrating to C++ to a more object oriented design to a more modern way of doing things. And we first spent a lot of time getting it under test and we used a lot of approval testing and combination approvals and we got it all under test so that we could then refactor with confidence. And then we did a lot of refactoring exercises and learned about extracting methods, moving methods, reducing the scope of variables. Yeah, all sorts of refactoring that I’ve got exercises for practicing.
Sam Taggart 00:16:13 Yeah, that brings up an interesting point. Are there any katas where like you take for example a lot of places are move, trying to move away from object writing code into more functional code. Are there exercises to like take object oriented code and transform it into functional code or vice versa or translate between the two? Is that a thing?
Emily Bache 00:16:29 Oh that’s a good idea. I don’t, just at the moment I can’t think that I’ve got any exercises that are quite like that. If the code is well designed object- oriented code, I don’t think it’s a huge problem to then translate that to a more functional design. She says confidently, oh I don’t know. I’m not an expert with functional programming myself. I’ve done a little bit but it’s not really my focus. The problem that I see much more often is that the code just doesn’t have very good design. It’s pretty procedural like long, tangled, awkward, badly named, and so just getting any kind of structure into that is a bonus that’s much more likely to be my focus than a code that’s already all right and just needs to be more functional.
Sam Taggart 00:17:13 Okay. You wrote a book about coding dojos. Can you talk a little bit about like what a coding dojo is?
Emily Bache 00:17:20 So code katas have been around for a long time. It was Dave Thomas in his blog who proposed the idea after watching his son’s karate practice. So that was in like, I don’t know, 2002, 2003, something like that when I first read about code katas and started practicing on them and I was getting somewhere and enjoying this but I felt that it was difficult to get the people in my team to pay any attention to the idea of tester and development or doing code katas. I did try but it didn’t really seem to stick. And then I went to this conference in 2005 where these two French guys, Laurent Bossavit and Emmanuel Gaillot, were showing their coding dojo that they just set up in Paris and they came to this conference to show us what it was like to come to their coding dojo, and I thought well this is great.
Emily Bache 00:18:08 This is a way of having a group meeting where you get everyone who wants together to do some code katas together and we learn from one another, and we support one another, and we start having a discussion about TDD and how to do that. And this seemed to me to be exactly what I needed to get my colleagues on board with doing TDD. So I went back to my organization, and I brought in Lauren actually he came and gave us some training so that we could get started with this and it kind of just went from there really that I started leading coding dojos and I was doing it with local user groups as a way to start that conversation and get people interested and show what TDD actually is. And it seemed to me to be a good way for a group of peers to kind of learn from one another. So that was what led to me to write that book because I found it worked so well for that.
Sam Taggart 00:19:00 So that leads me to another question about just katas in general. If I am a developer and I find one of these katas, I want to go practice it. Do you recommend doing it by yourself? Do you recommend doing it in an ensemble as a pair? What or all of the above?
Emily Bache 00:19:15 Well yeah, basically , I mean if you’re the only person in your team who’s even vaguely interested, you might want to just try it out by yourself to start with. So you get some practice, and you understand the idea of what you’re supposed to do with a kata. So you can absolutely use it by yourself. If you can get a group together of people who are willing to try it, it can be much more fun. You know, you get that kind of group camaraderie going and you can support one another and talk about when you run into difficulties, and you can do it all together as a group ensemble style or you can split into pairs. It’s a little bit less intimidating actually to do it in pairs and then you join together and discuss what you all found at the end. So both those ways.
Sam Taggart 00:19:56 Do you have any examples of like some of the learnings that take place from like watching other people write code like from that pair ensemble thing?
Emily Bache 00:20:04 Oh right. Well when you’re in an ensemble and, and somebody’s at the keyboard that you haven’t seen code before, they’re bound to be using aspects of their IDE and environment that you haven’t seen before and you’d be like, oh how did you do that? And it’s a great way to just pick up general coding tips. It’s particularly useful for people in the same organization who actually have access to all the same tools and maybe just don’t know what you can do with them to spread knowledge in the team. That’s something I find often that programmers come out of an ensemble like, oh I didn’t know you could do that, that’s so cool. I’m going to do that now.
Sam Taggart 00:20:38 The interesting thing I’ve found is sometimes even the more experienced people learn a lot because like you learn a certain set of shortcuts in an IDE and then they come out with a new version and it has some new add-ons that and maybe you missed the press release or whatever and you didn’t see it and then you see somebody else do something and you’re like, wait, you can do that. I didn’t know you could do that.
Emily Bache 00:20:56 Yeah.
Sam Taggart 00:20:57 Or it happens vice versa that you’re doing something the long way and one of the younger more junior developers is like, why are you doing it that way? There’s a much easier way and you’re like really? And so I find that quite interesting.
Emily Bache 00:21:07 Absolutely matches my experience.
Sam Taggart 00:21:09 Great. So I’m curious, what are the challenges with creating your own katas? Like if I’m a developer, like say I work in a team, is it better to try and create katas that mimic some of the problems that I see on my team or is it better to go use the existing ones? Do you have any advice on that?
Emily Bache 00:21:29 I think creating a code kata is a little bit more difficult than it looks. So it’s a good idea to try out some of the existing ones first if you don’t know which kata to choose, there are lots of experienced coaches out there who will probably be able to advise. I mean I’ve got a community of coaches and quite often people will say, oh what’s the best kata to use for, you know, domain driven design, practicing this aspect or whatever. People just pose questions, my team needs to learn this skill, what’s a good kata for that? And people will be able to give you suggestions. So that’s one thing to do first, but if you’ve got a bit of an experience and you think there’s a gap and there needs to be a new kata for a particular refactoring or whatever it is, absolutely give it a go and share your work. Again, there are technical coaches out there who are generous with their time and will give you some advice and say, oh this is good, have you thought about doing it like this? Or who might translate your kata into other languages? And I donít know, there’s a bunch of people out there who are willing to help.
Sam Taggart 00:22:32 Yeah, the biggest challenge I’ve kind of found in trying to create, not necessarily kata but just like examples for things is it’s hard to find something that’s relevant and yet simple enough to explain the problem without it being like overly simple. And people are like, well okay, yeah that solution’s obvious. So like why would I do you know, have you run into that at all?
Emily Bache 00:22:51 Usually the opposite problem. I mean when I’ve been designing katas, my tendency is to make them too difficult and too complex and have too many steps to complete them. I think there’s a huge value in very small examples that you can complete in half an hour. You know, that’s a good size of problem where you can just come from code that doesn’t kind of look good to code that does look good in a short time and it can explain a principle like what is a fake or how do you use delegation instead of inheritance you know.
Sam Taggart 00:23:25 That brings up another question about kata. So like how long, like does a typical code kata take like an hour or do you like time box them usually and say, I’m just going to work on this for an hour and see where I get or how does that work?
Emily Bache 00:23:37 Yeah, you time box them. I mean if you get overenthusiastic you can just spend hours and hours doing them. So you shouldn’t do that. It’s more effective if you practice short and often I reckon. And I think a good code kata you can get somewhere with it in half an hour and in an hour hopefully when you, perhaps not the first time you do it, but when you’ve done it a few times you can complete it in an hour. That’s probably about right. And less or less, I mean definitely less. Some of the exercises I do, I’ve got demos of them, and I complete them in 10 to 15 minutes, sometimes less.
Sam Taggart 00:24:12 Well one of the things I run into with the refactoring code kata is sometimes like when to stop, right? Like you’ve done the main point of the exercise but you’re like, oh I could polish this, I could change this, I could change that. And at some point, you’re just like, okay, that that’s good enough. Do you run into that at all?
Emily Bache 00:24:27 Well yeah, I mean there’s diminishing returns at some point you’re just kind of tweaking and the design is equally good for adding whatever feature it was you were trying to add. Although I think you can still learn from that if particularly if you are getting more fluent with your shortcuts and the transformations you’re making are still improving the code, then I mean you can spend time just tweaking designs and I don’t think that’s wasted time necessarily.
Sam Taggart 00:24:52 Okay. Yeah, well it’s, it’s learning. So I guess learning is always valuable. I guess you just got to have to balance that against the demands of whatever you’re working on.
Emily Bache 00:25:01 Yeah, and also where your sources of feedback are. It can be quite useful if you’ve worked in it by yourself to show the design, you come up with someone else and see, well do you think it’d be worth doing it like this instead? Or continuing to tweak and they might have some good feedback for you.
Sam Taggart 00:25:16 I think that tweaking though is also somewhat useful in the sense that you learn how long it takes to do certain things and sometimes then you can be like, okay, well I could tweak this but it’s easy to do later so I’ll just put that off until I actually need it. Because I feel like sometimes people try to like pre optimize things and like, oh I might need this in the future so I’m going to, I’ll just refactor it this way. And it’s like I’ve kind learned to just, it works to test pass. I’m fairly happy with it. I just kind of let it sit until I have a need to go back and start tweaking it in order to add some new feature or something.
Emily Bache 00:25:45 When you get fluent with refactoring you can actually make quite big changes quite easily. So yeah, I think it’s good to have that experience of realizing, oh actually when I’m good at my shortcuts and I know what I’m doing, I can day that change when I need it. I don’t need to do it now.
Sam Taggart 00:25:59 Yeah, I don’t know that I’ve ever actually like made that connection between that and practice, but I think that is part of what it is, is having practiced it a bunch and getting fluent with it. And also, I think part of it too is the tooling and the IDE too. Like if you actually have good tooling in your IDE and you actually know, so one of the things that I use katasr actually is building IDE tooling. So like I’ll build some IDE tools to do some refactoring and then I’ll try them out on a kata and see how it flows. And I find that quite useful to give me feedback on like, okay, yeah, this workflow makes sense or doesn’t.
Emily Bache 00:26:29 Oh that sounds really cool. Yeah.
Sam Taggart 00:26:31 So katas and this practice is part of what you do, but you also have this thing called Sammon coaching that kind of encompasses some of the stuff from katas. Can you talk about what does the term Samman mean? What does Samman coaching, how does it relate to katas?
Emily Bache 00:26:46 Well, Samman is a Swedish word. It means together, I chose this as the name for my style of technical coaching just to make it possible to like Google and find other people who know about it. So it’s a style of technical coaching that combines two main elements, one of which is like code katas in the form of a learning hour. And the other part is ensemble. So a technical coach works with developers and development teams to help them to improve the way they work, raise the quality of their code, increase their productivity and happiness when they’re working. And the Samman method then is the particular style that I use with these two main elements. So it relates to code katas in that in order to do learning hours, you need a good supply of exercises to bring in the learning hour. Adds to the code kata though, just as well as being a chance to do a bit of coding practice, the learning hour structures it as a one hour session that you do with a team and making sure that it’s as interactive as possible and that there are opportunities for discussion so that you’re building not only the skills of the participants but starting to build up a culture and a way of talking about coding and learning the words that you use when you’re talking about design and coding techniques.
Emily Bache 00:28:05 So learning hours has got more structure than just a coding dojo or a code kata by itself.
Sam Taggart 00:28:10 You mentioned communication. Do you have any examples of that, like communication, like spreading like to other aspects of the organization or like outside of like the learning hours, have you noticed that improving in other areas?
Emily Bache 00:28:24 The kind of communication I’m talking about is really between developers within the team. So it’s like learning the words for things like we’re trying to move the design towards ports and adapters or we’re trying to increase the code coverage, but we know what that means. We’re trying to increase the support that the unit tests give us for refactoring rather than some number on a graph somewhere. So it’s really about communication between developers. The way I notice these sessions helping is that then in the ensemble session, which is the other part of the coaching where we go into their production code, suddenly the team members are allowed able to explain to one another what they’re trying to do more effectively and they’ll talk about the code design that they’re trying to aim for more fluently and in a way that’s the whole team is on board with. That’s kind of where I notice it.
Sam Taggart 00:29:19 That reminds me of like books, like the design patterns books and some of the refactoring books like the code it smells of just like putting names to things. Does your coaching like go over a lot of that type of stuff as well or?
Emily Bache 00:29:30 Yeah, absolutely. I mean the design patterns book is really old now , but it’s still, you know, relevant to know what a factory is and a single turn and these words should be familiar to all, but they’re not always. It’s the same with the refactoring and code smells. They’re pretty old ideas, but knowing the names of them helps you to communicate more effectively. So you can sit with your team and say, I think we’ve got feature envy here. And then they might hopefully know what you mean by that and they’ll be able to work more effectively afterwards because they’ll see that, they’ll be able to talk about it and say, oh yeah and this is what we do and we have each envy, you know?
Samman Taggart 00:30:11 Yeah. Is there a way that you have to measure like the effectiveness of coaching? Like do you have a way method to like say, okay, we went in and coached and then can you, do you like observe them later in their own quote natural habitat or something to see like, okay, yeah, these ideas stuck or do you have any sense of that?
Emily Bache 00:30:28 So one aspect of the Samman method is that you’re not full-time with a team. You have a more intense period where you’re sitting with them quite often over a period of a few weeks maybe. And then you go away and perhaps you work with a different team or do something else and then you come back and one measure of your success as a coach is when you come back are they still doing the things that you were hoping that they would be doing that you weren’t doing last time you saw them when you were all together. So that’s a big motivator for me. It’s trying to work out well what can we achieve in this coaching block that they’re still going to be able to be doing when I come back for the next one.
Sam Taggart 00:31:09 Do you have a success story of a particular team that really embodies that?
Emily Bache 00:31:14 So one of the things I do is pair coaching and I’ve pair coached with Lulellen and Falco who’s another very experienced technical coach. And this was where I really saw the effectiveness of these techniques were when I was working with one of his teams and I sat in this ensemble and I was just observing, I wasn’t part of it. And one of the people would step up and take the navigator role and start talking to their teammates and saying, oh we need to do a test for this, and it shouldn’t be like this, and we need to set up the data like this and the arrange step. And then the next person would step up, the time would ring and the, and the navigator role would rotate, and the next person would step up and be, had to just carry on. And they were doing test driven developments, and they were producing code with tests that had a good design.
Emily Bache 00:32:03 I was like, wow, they’ve got this, they’ve really got this. And this was like the fifth or sixth time Luellen had been, had a coaching block with this team and he was like, yeah, they’ve got this, they hardly need me anymore. And that was really, really encouraging that technical coaching does work. And I have to say with the teams that I’ve coached, I haven’t been back often enough yet I think to see that kind of effect yet. I tend to have been more spreading myself a bit thinner and seeing a lot more teams and having perhaps a smaller effect. But I think that if long-term technical coaching really can transform the practice of a team.
Sam Taggart 00:32:45 Very good. So you mentioned that someone coaching has two parts. Do you always do them in the same order? Like one session has two parts or the ensemble and the learning hour, do you do them in the same order and how does one drive the other? And can you give some examples of that?
Emily Bache 00:32:59 The order is not fixed. My preference at the moment is to do the learning hour first and then the ensemble just because I’m hoping that we’re going to learn some new skill in the learning hour or some new words or new vocabulary that we can then apply directly in the production code when we come to the ensemble part. And that should be the case at least some of the time. Although not every learning hour is practicing a skill that’s directly relevant for today. Quite sometimes we are just learning speculatively about skills and things that we are going to need in the future. Perhaps not even this coaching block, perhaps next coaching block or the one after that. So it’s not really important that you do the learning hour first, but still the goal is always that the team should be learning new things and opening new horizons and new ways of communicating.
Sam Taggart 00:33:49 Yeah, I feel like it could be like a chicken and the egg problem, right? Because you do the learning hour and you just, you learn a new skill and then you go apply it. But also like sometimes you’re working in the code base and you’re like, oh that skill would be useful and then you go back and do the next one you would do a learning hour, right? Something like that, right?
Emily Bache 00:34:08 Yeah. So if I’ve got the breathing space between these sessions, so each session is like half a day with a learning hour and the ensemble, if I’ve got a half a day or a few days between and before the next one, then sometimes I will be able to prepare a completely new learning hour to address that particular skill that I’ve noticed that they need. And that’s really rewarding when I can get that to work. It doesn’t always happen that way. Sometimes it’s the next coaching block by the time I’ve managed to prepare that session that they need.
Sam Taggart 00:34:36 Do you find that a lot of teams are already doing ensemble programming or do you find that when you start you spend a lot of time teaching them just how to do the ensemble as opposed to like teaching them how to do whatever skill they learned in the learning hour?
Emily Bache 00:34:47 Oh yeah, absolutely. When I’m going into most organizations, ensemble is new, and they haven’t done it before and the developers don’t have those skills. So yeah, the first learning hour or perhaps two will be focused on, well what are the roles, what are you supposed to say? How do you do the rotations? Yeah, absolutely. Teaching ensemble skills is usually the first thing, but you know, they pick that up over the course of the sessions by the end of a coaching block. Most teams have understood what ensemble is, they can basically do it and they have a good idea of when it would be useful to continue doing that with their teams.
Sam Taggart 00:35:22 What is the biggest challenge you face teaching ensemble programming?
Emily Bache 00:35:26 There are lots of challenges with teaching ensemble. The first challenge is getting people to try it at all and be willing that gets easier when I’m framing it as this is part of the coaching and you are going to learn from one another with me mentoring you as a team. That makes it easier to introduce when I’m there. But then once they’ve got over that hurdle and agreed to do ensemble, the next hurdle is helping people to feel confident to step up and take the role of talking or navigating and not be too nervous to say anything. And then to feel confident as well to take the typist role without feeling nervous and worried that you’re going to type the wrong thing. So it’s mostly about creating that safe environment where people know what they’re supposed to do and it’s okay to ask questions, it’s okay to go wrong. And even for senior people it’s hardest for the senior people in the team because they’re so used to knowing everything comparatively to suddenly being some kind of beginner at a skill that can be hard for people. So it’s really important for me as a coach to put them at their ease and reassure them and make it okay to step into that role.
Sam Taggart 00:36:37 Speaking of like being willing to speak up and stuff, do you run into cultural issues? I know you probably deal with teams from different areas of the world. Does that play a role?
Emily Bache 00:36:46 Well yeah, I have worked with teams with people from different countries, the US, Europe, India, and I wouldn’t have said that, I mean there are cultural differences but ensemble, we were a bunch of developers, we understand code. I haven’t found there to be big cultural barriers there. Once you’ve got people to agree to try it, I haven’t found it to be really too hard.
Sam Taggart 00:37:09 Okay. So do most teams, after they do the Samman coaching method, do they continue then to do ensemble programming on their own or do they mostly do that, like when they’re in that learning mode?
Emily Bache 00:37:21 Yeah, so far it’s mostly when I’m there. Very few teams have continued with it when I’m not there, which I think is a shame, I would like it to be different. I think there is a huge benefit to ensemble even without a coach present. I think some of the teams have understood that there have been a couple who have continued with it. And I think when I’ve come back to those teams for the next coaching block, it’s been like, wow, okay. They have carried on with what we were learning last time, and they have improved since I was last here. So I think there are huge benefits to it, but somehow corporate culture, it’s just, there seem to be a bunch of unspoken norms that say no, we work individually, you can’t, you can’t work altogether that the managers wouldn’t let us even without asking the managers. You know, it’s just kind of assumed that no, we can’t work that way in real life. I’m working on that.
Sam Taggart 00:38:12 Yeah. My immediate question is going to be is that a real thing or is that something imagined by, I’m sure it’s probably in some cases a bit of both, right?
Emily Bache 00:38:19 Yeah, I mean of course at first glance it seems really ineffective getting a whole team to sit together and work on a task when that’s not normal. They could get twice as you know, five times as much done if five people sat all separately. I think that’s a, just a misunderstanding of how software development works. I mean if you’ve got a very heavy box that needs to be carried and you ask one person to carry it, they might not be capable of lifting that box. But if you’ve got a team of five, they can easily lift that box and move it much faster. And it’s getting the people to understand that software development can be like that. Sometimes it takes five minds on a problem to really get hold of it and move the solution somewhere. One person on their own just doesn’t have the mental capacity sometimes to solve some of the programming problems that we are facing.
Sam Taggart 00:39:10 Yeah, I don’t know. I’ve been working on this analogy lately of like a basketball team and like if the coach at the beginning of the game said, oh these are all the tasks that we need to do and he assigned them each to an individual player and threw them all on their own court with their own ball, like that might work, but that’s not really a team, right? And like I feel like we use the word team and then we all go work individually. That just strikes me as an odd use of the word team sometimes.
Emily Bache 00:39:33 Right. Can be deeply ingrained in a company culture and reward system that each person is going to work individually and it can be difficult to get people to see that that’s not the only way to do things.
Sam Taggart 00:39:44 Yeah. The incentive structure does not help that very much. Because one of the things I’ve heard people say is like, okay, well if we do this as a team, then who gets the credit? Right? Yeah. Or who gets the reward and it’s like, well you know.
Emily Bache 00:39:56 Yeah, I’m being measured on how many tickets I close each sprint. I don’t get rewarded for helping someone else close their tickets and I’m, yeah. So the thing is, I’m a technical coach and that’s an organizational problem. That’s a kind of process problem. And there are other coaches who are much better at those kinds of things than me, people who would work as a Scrum master or an Agile coach. And I’m very happy to delegate all that side of things to them if I can. I’d like to work together with someone like that and so I can really just focus on the coding and the people writing the code and getting that part to be more effective. And if that’s not the biggest problem that your organization has at the moment, then hire someone who can fix your biggest problem that might not be me.
Sam Taggart 00:40:40 So I have some other just general questions about someone coaching. So like is there an ideal team size? Does it work better for smaller teams, larger teams?
Emily Bache 00:40:49 When you’re working in ensemble, you need to have enough people in the room that have all the skills you need to deliver the task you’re working on. And it’s usually around four to six people is a good size for an ensemble. I’ve no reason to believe that actually if you needed more people than that because the skills were lacking in the room, I think it could still be effective with a lot more people than that in the ensemble. But my experience is mostly with teams of about four to six people and that seems to me a quite a sweet spot for a team size for software development. So that’s what I would normally recommend.
Sam Taggart 00:41:30 Is there an upper bound that you’ve seen like over a certain number of people just gets too many voices?
Emily Bache 00:41:35 It depends on the facilitation and the nature of the problem you’re trying to work on. I found it more difficult and stressful when you’ve got seven or eight people and that’s why I usually advise, let’s, let’s take a smaller group, at least when we’re still learning and this is the first time we’re doing ensemble, it’s probably better to have a smaller group. I wouldn’t want to put a limit on it, particularly with experienced teams with hard problems.
Sam Taggart 00:42:01 Yeah, I imagine there’s some self-control of like not blurting stuff out either, right? If you’re in the audience, you if everybody’s talking at once, that just gets to be too much. So having that, the discipline.
Emily Bache 00:42:12 Yeah. So that’s one of the skills of ensemble is knowing what is my role at the moment and how can I best contribute. And often that’s not by speaking your mind all the time, it’s by picking your moment to speak.
Sam Taggart 00:42:26 So another question I have is how often do teams typically do coaching sessions and is there value in having them spaced out so they have time to practice between or do you try to cram them all together to learn as much as possible in a short period of time?
Emily Bache 00:42:40 I’ve done it a few different ways. You can schedule a block of two weeks with coaching every day and then, you know, a couple of months off and then another two weeks coaching every day. That’s kind of intense. At the other extreme, I’ve done it one coaching session per week for like 10 weeks or so. And that is much more relaxed and the team has much more time between to practice what they learned in the learning hour in the last session. But it takes ages to get anything done and you lose a little bit of context I think between the sessions and then another 10-week block is going to be like a year away. So, and that’s again, I think it’s a bit long. So at the moment I’m generally trying to schedule 10 half days of coaching in a period of three to five weeks as a kind of medium between those.
Sam Taggart 00:43:33 So can you talk about like the biggest success story that you’ve seen from coming coaching? Do you have a team where like they started out one way and then after a bunch of coaching the kind of transformed the way they work?
Emily Bache 00:43:44 I think I already told you that success story. Okay. That was the Wellins team that I worked with. Yeah. Other success stories. I worked with a team that was full of quite relatively junior developers and there was just one person in the team who was a bit more experienced but still they were really struggling quite a bit with the code that they were working on. The design wasn’t very optimal, it was a bit legacy and because they were all so junior, they were really struggling to make progress with it. So through some coaching sessions we learned some skills around refactoring and in particular extract method naming as a process, think just code smells and names of refactoring. And at the end of a coaching block, the person with a bit more experience was like, well I feel so much more confident now talk with the rest of my team and explain to all these junior developers what it is that they should be doing. So he felt a lot more confident and I could see that these junior developers, they were just starting to blossom. They were just starting to get it and feel confident enough to make changes. So I thought that that was a really good story of how coaching just helped that team to go from barely managing what they were being asked to do to actually being able to collaborate and make progress.
Sam Taggart 00:45:06 Yeah, that’s good. So can you talk a little bit about the Samman Coaching Society and what its goals are and why you founded it?
Emily Bache 00:45:15 I’ve been doing this style of coaching for a few years and found it to be really beneficial. And I wanted to share my methods with the world. Because I think there’s such a need out there for technical coaching. There are so many teams struggling with code that is difficult to work with and to maintain and they need to learn refactoring skills. They need to learn test driven development and the resources that are out there that were code katas and coding dojos. But I think technical coaching is what I found to really work and I wanted to spread this. So I wrote the book explaining it as a start and in association with that, I registered the website Samman coaching.org and I started to publish more materials and discover other people doing technical coaching. And some of the, my colleagues at the time were like, well we could set something up that would be bigger than just us in this company.
Emily Bache 00:46:12 So we founded a not-for-profit organization and the reason it’s not-for-profit is so that people from competitors basically could join and we could share our materials and we could help one another. And in a way that wouldn’t be for profit for what any of those particular organizations. You’re not helping your competitor. You are, you’re helping a community. The whole point of this basically is to grow the markets because there’s a huge need for it. And we’re just trying to say, well if we help one another and do a better job and people benefit from the coaching and tell their friends, then that’s going to benefit everybody. So let’s help one another and share our materials.
Sam Taggart 00:46:53 So it’s a big coaching kind of collective collaborative type space.
Emily Bache 00:46:58 Well, yeah, in one sense that’s the mission of the not-for-profit. It’s to support technical coaches everywhere. Although I have put some limits on who can actually become a member of the not-for-profit because I wanted also to be a way to develop someone coaching as a method. I mean, what I wrote down in my book was what I was doing at the time. And I’m totally prepared for that not to be forever. What Samman coaching is, I want the method to develop and be improved and others to contribute their wisdom and knowledge about how the best ways are for doing technical coaching. And I wanted there to be a trusted group who were in control of the future of Samman coaching. So the society owns the brand and the website and we have a board and we have meetings and procedures for how to admit new members who we trust. And we are working on ways to communicate updates to the Samman coaching method so that it can evolve and grow and change and not always just be what I wrote in my book a few years ago.
Sam Taggart 00:48:06 Yeah, I think that’s probably wise a lot of things like test driven development and some of those things like they mean a lot of different things to different people. So having a group to kind of curate that meaning I think is useful, so it doesn’t get too diffused. So you mentioned something there, just wrapping up, you mentioned that many teams struggle dealing with existing code. Why do you think that is?
Emily Bache 00:48:28 It’s about skill and culture. A lot of developers actually didn’t learn how to refactor at university and they’re not learning it on the job. There’s not enough knowledge transfer from more senior to more junior developers. So a lot of developers don’t actually know how to improve design of existing code or at least not how to do it safely. So that’s one of the problems that they don’t know how to do it. The other problem is they don’t given time, like they need to ask for permission to improve the design of the code they’re working with and, and that somehow the managers should decide that. I think that’s the wrong way to look at this. There needs to be a culture in the development team of we improve the design, this is how we work. We support one another. We expect that when a new feature gets built, a certain amount of that time will be spent improving the existing design to make it easier to add that feature that we’re not just going to shoehorn it into the design we had before. And so I think this is why organizations get into trouble because they don’t have the skill and they don’t have the culture. And it’s not enough just to say, okay, developers right now you’ve got a refactoring sprint or a quality week where you can fix these problems. That’s a kind of like a one one-off sheet that doesn’t actually solve the problem. You need it to be a continuing, ongoing way of working and with skilled developers who know how to do this.
Sam Taggart 00:49:54 So my last question that just kind of popped into my head was, do you think there’s a role for katas in education? Because I feel like a lot of computer science type education is starting from a greenfield, right, here’s this problem, go solve it. And a lot of what we do in industry and in production is you come in and they, there’s already this code base and it’s like, hey, add this feature. But the code base doesn’t really lend itself to adding that new feature yet.
Emily Bache 00:50:24 Yeah, I think there’s a lot that could be improved about educating new developers. It’s not really my area though, honestly, I’ve always worked with people who are already professional developers and that’s where I’ve applied all these techniques. So I think if I’m going to talk about computer science education and so on, I’m just speculating. But if there are educators who are interested and want to use my code katas, I would absolutely support them. I know my code katas are being used a lot for job interviews, so students already practice on them to prepare for job interviews. So there’s already knowledge about them in that community, but yeah, probably there could be more.
Sam Taggart 00:51:05 Okay. Great. Thanks for coming and sitting down and talking to me for SE Radio. This is Sam Taggart. Thank you for joining us.
Emily Bache 00:51:11 Thank you for having me.
[End of Audio]
