 I think we should start. Hi everyone, I am here to give a talk about technical mentoring, what works out and not. I'm Stanley, I'm from Singapore, I grew up in Singapore. This is my second time in India. I'm glad to be here. The first time I was in Chennai, and there was a very short trip. So this is a longer period of time here. I've now mainly focused on work on. I'm a software development coach. I used to call myself an agile coach. I turned that to a more general term because I realized that the term agile coach tends to have different meanings to it from different people. So I make it more general. I'm a software development coach. I help companies to management and also teams on technical practices and also how they organize their ways of working. And then I'm currently in a small company called OTHE, where Buzz Voter, who gave one of the talks, the creator of LAS, is. So more than six years ago, I'm a full-time software developer. I work on Java.net applications. I work in financial institutions. And since I joined OTHE, I began to shift my focus on getting into the area of helping others to improve the development skills better and also software practices better. That is quite a drastic change for me because all the while in my life, I've been communicating with computers. I never thought of myself to communicate with people much. But I realized there is this problem that is yet, it's like a mystery. It's like when I try to, in the past I show my colleagues, you know, this code on clean code, this book on clean code, so great. And then I say, what? No, I don't read. I don't need to read. No, no. Just don't bother me. And I show them, wow, domain-driven design book by Ari Ivans, so great. So much good ideas inside. We can try. You say, no, I don't read that. That made me realize there was the first time that I even could tell the management. I had the opportunity to go up below the sea level. And I was kind of naive at that time. I told them that, you know, our system sucks actually. He asked me to get out of the room. So I did. So that was the first time I tried to challenge. And I know from many experiments what works and what didn't work. So apart from that, in Singapore, I work in small companies, local companies, and also international companies. I realized many of these companies are like living in caves. They are developing software based on what they know within a company, within a culture. And there are so much great things out there that can reuse or use it, but they don't know. So I intended, when I first joined ODE, intended to know, let's do something. Let's build up the awareness. So I started the agile community in 2010. And 2013, we started, I organized 2013 conference, 14, and also last year, where we have, in our conferences, one of the main things is that, because Singapore is far away from many of the great ideas in Europe and US, so we try to bring speakers to Singapore, just like agile India, just like agile conference in the US as well. So I spent a lot of time on that community work, but I also spent a great deal of time working with clients. I like to see their context, understand their context, and then work with them together to support them in solving the problems. My main purpose goal is that to help them become the problem solvers, so that they can sustain solving problems by themselves without me. I'm trying to get myself out of the job. And recently, well, the topic I wanted to talk today is about technical mentoring. And this has been something that I've been working on for the past five years. And I'd like to share a couple of stories that I, that motivates me to pursue this forward. So imagine that you have a task, a developer, you have a task. This task is pretty simple. You want to add a criteria, additional criteria, to some queries that, that displays information out on the web page. You, you know where the code is to change. We bring up the code and then you show it to me. And we saw that, wow, it's a 500 methods line, 500 lines long method. And inside this 500 lines, there are seven loops. Some of the four loops are nested. And there are about 16, if else, conditions inside. And many Boolean flags sprinkle everywhere. So we spent a great deal of time about an hour plus to understand what this code is trying to do. And my pair, and you, who I'm pairing, pairing with, have no idea what this is. So, so as we're going through, we're stepping through by, we kind of understand where the change, where we can add this additional criteria. So, no, we can, there are two options. One, add the, one more if condition there, and then done. Right? But we didn't choose that, of course. Well, I was there, I was, I was saying that, so how about let's, let's do it the right way. No, I don't think someone would create all this complicated code, a mass of what earlier in the talk, Michael mentioned, Michael mentioned about mass and crop, crop. And we, let's stop that and let's try to make it right. So, okay, he don't, you are not, you don't have much ideas of how to approach it. So I said, oh, let's, let's try to, let's try to smell the code. Let's smell what smells it has and then try small steps to refactor it so that it becomes better. So as we are going through, we spent another, another good amount of hours, probably about another one and a half hours. And then what was 500 lines long became four lines long. And it says that we have a couple of dictionaries retrieved from some, somewhere. And then we are going to do some, these two dictionaries, we wanted, in one of the, the collections, we want to do an intersection. What we really want is this intersection. And then with this intersection, do some sorting and display it out. That is what the code is trying to do. Well, in dot net, so we use, we make use of link queue and that, that works well. Now, of course, once you know this, you can probably put, if it comes from a database, you can do it from a view. And this code wouldn't exist anymore. So we have that in the intention of the code becomes clear. We spent five minutes at a new test to, to make the new criteria happen. We call it and done. So, no, we felt lucky. It is like working in a my field. You don't know, you don't know that this my field is pretty, pretty clear. You know where the mice are. You try to avoid it. You try, you know, the mice, the mice, when you try to clear the mice, when you refactor, you try to clear the mice, it's pretty safe. However, most of the time, we weren't that lucky. Sometimes we spend days in my fields and large my fields. Some mice aren't visible at all and you may step accidentally. Well, then, then the mice friends will know you where, where his friends are in the neighborhood. Sometimes when you try, you have good intention. You want to remove the mice and you got hurt by yourself. So this is what I noticed that most developers, I've, I've been to companies in Malaysia, Thailand, Singapore. Around this region, I work with them. I saw their code bases. I noticed that they spent more time reading the code during writing code. And the customers are actually paying for it. They don't know that they are doing that. So I, I, I wanted, I'm very interested in solving this problem. And of course it is not a, is it problem to solve? I don't, I don't think that I know all the answers. So I tend to do a lot of experimentation. I try something and see if it works well, what I learned and I try to refine it. This talk is about the journey of mentoring, technical mentoring from the beginning, probably about five years ago in how, how to help developers getting better at skills. So no, um, that is a problem. And I did technical practices. There are lots of practices. Why do I pick first? I decided to pick the code smells and refactoring. I think having these skills can help to improve, can help. It's one of the essential skills in software development. So I decided to pick this and to give a quick run through of what is refactoring a visualized form. If your original program looks like this, it looks good. Greenfield project. And we will make changes. You patch it. And if we don't do anything to that, the patch grows bigger and becomes a mess. Um, what I realized after attending Michael's talk on technical debt, uh, most developers are mad or in the context of those companies, though they don't even know that's a mess. I got to realize that up when, when coming, coming across one of the experiments I did, which I'll share later. So we've refactoring, uh, you, you make a patch, but because you have tests, uh, protecting it, you can refactor, improve the existing design of, uh, at the internal design of the code and protecting the behavior. It becomes well again. So this is the, the motivation for refactoring so that it is easier to change the next time. So to clarify a bit about the term mentoring, mentoring is, um, from David Clutterback and, and parcel, um, mentoring is a lot about experience gap. You usually have a mentor who has more experience than the mentee. And you have this relationship is not because you are a senior or because you have higher authority. That is not the, the points. Um, and the other thing to met, to highlight here is that as a mentor, you need to, um, help, you need to recognize what is the mentee's potential, help them to realize their potential and, um, so that they can move forward themselves. So that's the kind of brief description of mentoring. I don't have a lot of structural mentoring. I, I, what's next I will probably go into is to go into formal mentoring, um, professional mentoring courses and to learn more about that. But, um, I started five years ago, I started with something simpler. So I started with, uh, giving a TDD workshop, all right. And then followed by pairing with the team members for, for two weeks. So in that, I quite try to combine theory and practice. I know that theory itself is not sufficient in the training I gave about 70% of the lectures, some 30% exercises. Most of the code exercises are from a public, like code cartas. You have a string calculated exercise and so on. Um, pairing with them after the workshop happens quite randomly. So, uh, what, what is random? Random is like, uh, whenever I, I see that's, Hey, um, they could be, they could be, the, this team member seems to be working on something. I just joined them and then, uh, sit beside him or her and ask her, ask them what, what are you working on? And then we, we try to work something out. The, the problem that I learned, the challenge that I learned is that, um, when they were in DR iteration on their sprints as they're working, not every time they touch on code. In fact, the times I was with them, they were working on something about reports. So quite a few of them are doing SQL queries. I mean, the SQL queries, uh, it's not a function. It's nothing much to, to work on, on code smells and refactoring. And other times, uh, it's even like, kind of like, uh, screaming out to me is that even if they're working on codes, they have difficulty trying to test it locally. Most of them don't have automated tests at the beginning. So, uh, they have trouble testing it locally because they can't get the, uh, application to run locally. And that was like, wow. Okay. How could that be? So I, in, in, from that's what I learned is that before I work with the team, I probably want to check if they have a, if they're able to run the application locally, if they have automated builds at least, uh, so that they can get somewhere they can also add some unit test later on. If they don't, I should focus my effort there first. So, um, and of course, uh, when I was, uh, started, I, I'm not very, very good at, um, people soft skills yet. Often I, when I sit, mention about their codes, I would say, no, your code is, and, and, uh, they don't really like it. So I learned by heart that, uh, well, if people would become defensive, then learning drops, that's not what I want. So I changed myself to remove the person out from my statements or say, uh, what this code seems to do is, this code, um, this code, uh, is lacking of intention. What is it trying to say? And I'll hear what they say and say, Oh, hey, you use these terms called, um, uh, placing, placing orders. This word doesn't seem to be in the code. How can we bring that up? Hmm. They haven't thought about that. So, so using this, um, to, to, to work with them, then the next experiments, I've done a lot of experiments that comes in, uh, uh, randomly or in different, different ways. Um, and also all of these experiments, I will consider them informal experiments. I don't have as, as a result, I want to achieve. Sometimes I do the experiment. I want to see what happens. So the next one is a community in a code, mini code retreats, uh, code retreats, retreats is where you spend a whole day, uh, working on an code cutter, uh, pairing with people for 45 minutes and then you switch pairs after every 45 minutes. You do that for multiple rounds. We, I was, um, organizing the community events at that time. So we'll, we usually do it in the evenings and we don't have the whole day when you have two hours. So our code retreat is 25 minutes followed by five minutes break, uh, debrief, 25 minutes, uh, five minutes debrief and 25, three rounds. They were on TDD exercise, uh, string calculator exercise. 20 people came from different companies. And, uh, what I learned is that, I discovered that most people have trouble writing, uh, test first. Uh, most people don't know what is a automated unit test. So this was, this is about 2011. Um, and then, and even, even if they, uh, know how to write unit tests, uh, they tend to have lots of implementation. Yeah. So many of them ask, they appreciate, uh, they come because they want to learn what is TDD. And they also have this, this question, how do I apply it in my assisting systems? And so I was looking at how they, how they work on, through these problems. I realized that, are we giving, uh, too, too much of a big step for them? I mean, if you, if you don't even know how to write unit tests, then how, how could you even, even, even proceed with refactoring? Um, so that spawns an, an idea for another experiment. How about we forget about, um, writing unit tests, let's just focus on refactoring. In this refactoring, I created from a, uh, a code exercise. I added unit tests through it. The code is, the code is, um, smelly, like this. It's very smelly like this. And we have unit tests that pass. Their task is to remove the code smells. I'll make it cleaner, improve the design by, by, uh, gradually, by, keep running the tests. At that time, we are using Eclipse, so control F12 quite a lot. Sometimes you make a change and it fails. You keep doing this, keep doing this, keep doing this. You have this test that runs in milliseconds. So what's the, so this is one of the early, um, code exercises. Interestingly, one of the, when I ask, uh, one of, one of the participants before the exercise starts, what do they think about this code? A couple says that what, what, what's the problem with this code? So it's like, okay, looks like there's a smaller thing we can do to help them to realize that, uh, which is learning about code smells. So that incorporate later part of my experiments. Anyway, the outcome is that they felt confident in changing code. I did this for my clients as well. They felt confident when it's like, wow, we can change code with confidence. It inspired them to add tests to their work. They learned, uh, test automation. They were using N units and also spec flow. They were inspired, they added depth and it became unmaintainable for some, after some time. You can see lots of, uh, smells in the, in the, in the test. And, um, yeah, that, that's the states and of course, uh, that is not surprised to me because, uh, the, the level of skills of refactoring is yet to be, we haven't really touched on that. We haven't really worked on that. So apart from, from this, I also did, um, no, jump into the context. One-on-one mentoring. I did for more than 20, 20 people one-on-one. Um, usually last for a few hours. Um, I'll ask them, I, I begin to have a bit more structure. It's not just paring. It is a bit more map, formative, uh, mentoring. I asked them to prepare a few topics, topics that, you know, a code that they have been working on, they have refactored, uh, recently and they want to find out a different opinion. I'll find out my thoughts about it. Um, it could be topics like they come to this code and they don't know how to refactor, they wanted to do it together. So, at the end of the session, I will ask questions like, um, so can you share with me what you learned? Uh, what is your reflection about how we have been working on so far? So, questions like this in order to reinforce their, their learning. One of the, the things that highlight to me at a, at an early on is that one of the members tell me, told me, bring out this code, Stanley. They've been giving us, showing us demos and workshops and trainings on refactoring but when I open up this code, I need to change this code and it has a long method. I don't know where to start. It's an immediate feedback to me, you know. It, it is an information of, um, probably there's a smaller step that we can, we can make. And because of that, I, I spent a lot of time, um, trying to, I even record now, what are the kinds of things as we're going through refactoring, removing the code smells in the code. What are the common topics that came up? I want to see if there's any pattern to it. If there's pattern, we can do a deliberate practice to that. So one of the common um, pattern is, um, well, well, one of the useful things is to draw the classes, you know, UML diagrams, class diagrams or sequence diagrams to see the interactions, which is something new to them. You know, most of the developers I've been working with have probably a few years experience. They are pretty young and new to the software development industry. And many of the companies don't have seniors who are really good at development, who are, who can deal with technical depth or deal with the mass in code. So a lot of these developers, they couldn't see abstractions, they couldn't see how, how classes relate to each other. We do, we, we draw, we model the classes. It helps on them to understand the, and also helps to communicate. Some of the common patterns that came up on the skills, uh, hotkeys is, is our favorite. Almost every time they will say, hey, I learned new hotkeys. I know I can do this much easier. You know, it's something very tangible for them, it value for them as well. Uh, that's the most quickest improvement I ever seen. Of all the 20, uh, mentors, uh, male mentoring sessions, um, I see the drastic improvement or quickest improvement within one month. You see that they were much more fluent. Understanding single responsibility, we talk a lot about that because long methods has more than one responsibility. Um, returning now versus empty list, no, I see many codes where you return a, a collection, but if there's no collection, they return now, which brings up to the caller to, to check for now. And that's, that's, that's nasty. We talk about, a lot about that, um, in C sharp you can do a out parameter. To return more than one thing, uh, we have a lot of discussions about that, how, how that would surprise you many times. Um, also many times you have smells like lazy data class. A class that already has data and wears all its behaviors everywhere, everywhere that uses the data class. So how to bring close to them? It becomes a domain object. Um, they work with third-party services. So some third-party services are good. They have good documentation. They provide SDK for you even, but most doesn't. Some don't even have the documentation. So how do we, how do we, um, create an abstraction layer so that it doesn't, it doesn't leak the language of the third party application doesn't leak to our code. And also naming, uh, which is one of the most common thing. I can, I still remember one of the, the session we had, uh, we we were refracting along methods or across different classes into something simpler with a 10 lines long. We put, I kept mentioning about, I kept asking him, no, what does the product owner says about this feature? What, what do they name it? I drilled out a lot, a probe a lot. And then I say that so how can we make the code tells its story? What is its story? And at the end he was saying that Stanley, I didn't know that, uh, we can make our code tells, like, read like a story. This is one of the things that, uh, that is very new to them. So I think, I didn't stop there. I even continue to, continue, uh, working with mentoring with, with, um, senior developers. I want to dive deep, not only within a few classes, but into spending multiple classes, while working on a large mind field. With senior developers, we remove minds, uh, spend 10 days or that. Um, I don't give, I don't give a lot of guidance. I, I give some guidance at the beginning. I see where they are. I notice that, uh, we have together remove a code smell of primitive obsession. The next time I, we met again, I ask him, how would you remove this? And I say, how do it? That will indicate, uh, how far he has gone. Through, through an intentional, um, way, we landed with, so in this context, this company is using csharp.net, uh, Microsoft platform, all the way. They, they are, they are not, uh, they don't, they don't know much about open source, uh, what is the modern technologies, like a Ruby and, and Ruby and Go language and so on. So we, we spent one day on a Ruby and Rails project using some of the services online to develop some simple application. So some of this senior, uh, senior developers, they were excited. Wow, you can do so, so much, so little. And some of this, um, gained their interest in continuous delivery. Um, later on, I go to, I, I heard that, uh, this, uh, influenced, partly influenced them to, you know, cut down their production release into, into less than half an hour. It was, it used to be a day, uh, or more. And quite a few are inspired by, by that special project. Which gave me an idea. You know, we probably can have a some, some special, uh, practice on trying different technologies so that, so that they can provide some, uh, new ideas. One of the, one of the developer even, um, like the, what is that, active record in Rails so much that he says, is there some, something like this in .NET? And he found that, uh, there is, but it doesn't fulfill their, their needs. I think it's called, what is it called? Active record. Active record for, for .NET. And, and he focused on the project and tried to modify it. This didn't happen at all in the past. They were living in the caves and I realized that's what, what I did there. In fact, uh, it's like bridging, making a connection out from the company to outside world so that they actually see what is happening outside. So, a bunch of this, uh, much of this, uh, a lot of bits and pieces. Most recent in the past, uh, since last year, I began to find a lot of patterns in this and try to create some more structure and, and more structure and to make it more organized in, in approaching mentoring. I attended last year, I attended a co-active coaching for, for those who know, this is one of the professional coaching courses, program. And one of the ideas I took from there is four stages of competence. What this means is that, um, you, we started out of skills, how do we gain skills of getting skills? We started out with unconscious incompetence, just like when I first, um, shared a thing about refactoring with companies and, and then my, my friend would say, no, we don't need that. Why do we need that? They don't know. After some training or some introduction, they may be aware about what they don't know. That's conscious incompetence. And once they gain motivation to try it more, and that is conscious, uh, competence, it still requires a lot of thinking in doing that. And when they practice a lot, till become mastery, becomes unconscious competence. You know that when someone says to you, hey, how do you do that? And you may say, I don't know. It's just like this. You're unconscious about your competence. That could be a dangerous sign because, um, it may, when you teach people, when you are unconscious competence and you teach people, uh, you may be telling abstractions that it's hard for people to relate. So, uh, to be a good mentor or trainer, I need to know what I am unconscious about and break it down. So we started with this, uh, technical training program. In short, it is, it is a series of one-day workshops. Okay? Each workshops are progressive. The later ones are harder than the earlier ones. And one of the main features of this workshop is that all the code exercises are from your code base. I go into your code base and look for code smells and try to derive exercises from it. And yes, we did. We spent about five full days, uh, working on that. We are thinking that, uh, this is an experiment, a big experiment. We don't know how this will, you know, turn out. Our hypothesis is that if we go run through these workshops with people, we should see less code smells in their commits eventually. That's our hypothesis. We are so aware that, uh, there could be other influence, uh, influence, uh, factors that will influence that. So we, we try to, you know, just try and see what happens. So me, um, I was in this company, coaching this company, and, um, I decided to ask the, the most senior people, uh, in technical and collaborate with them and ask if they want to create together this program. It's one of the ways to also, um, create mentors. Um, so this is what we did. And, you know, I have an ominized, uh, this, uh, this wiki page. This is from a page in, in GitLab. We just go to, we went to their production code base, try to derive code exercises. We cloned the code base into their GitLab. And a wiki page, we have this, um, code smells. So, magic number, duplication, primitive obsession, feature envy, and they are more below. Uh, we didn't really know what to come up with at the beginning. We just go into code base and see what makes sense. And the target is that we have methods. We restrict, in order to make the exercise, uh, easier or simple, we restrict the context to within a method itself. So, you don't, as a, as a participant, you don't have to look at who caused this and think about the design in broader sense. So, it's just mainly removing code smells. And, uh, another feature we add to it is repetition. We have code smells that are duplicated code, but the next exercise is the same plus a little bit difference. That little bit different I often ask, uh, after they, they try it. Okay, what's special about this exercise? And then you'll say, yeah, that part, that part is a bit challenging. So, there's always some challenge. There is a lot of, uh, practice. I also make it a point where, um, we, we as a colleague, as a leader of the, the workshop, you have, we have eight participants, they were working on the exercises and we will go around and see their code. I say that, no, we will come around and see what you do. And if we find that, uh, you can actually make a smaller step. We may come to you and say, oh, there is a smaller step to this. Could you try that? Challenge them. So, this is what we do, uh, a lot. In one workshop, one full day, from 10.30 to five o'clock, they did more than 10 exercises. Um, at the end, we will have a grand finale, a finale exercise where it incorporates the smells that they have seen before, only in the day, so that they can feel more confident in, in removing that. Um, at the end, no, as we go through the, um, the exercises, we will unlock refactoring and code smells. When they identify a magic number, we would go there and write, yeah, magic number. When they found duplicator code, we write it there. When they did extract methods, we write it here. When we did inline method, we write it here. So at the end of the day, you have a, you have a board full of smells and refactoring that they have unlocked. And at the end, we ask them to please dot, please vote for those, uh, smells and refactoring steps you are most familiar with. You, you get, you are pretty confident of removing it or doing it. And the dots that you see over there are their votes. So these are just some sort of feedback to see how they are learning. We also ask them feedback after the, the, the refactoring, um, in what aspects that helps them to learn a lot using rich sharper hotkeys. Uh, they appreciate a lot using production code to practice. So they were also very, very, uh, interested in how we approach towards a problem, um, especially in dealing with those code smells in, in the production code. So what improvements are there? So these feedbacks from them, um, they want to see more examples on how to identify the smells. Uh, sometimes they are lost because we make a two big step and that, that is a feedback for us to, to refine it further. Uh, some of them, quite a few of them says we wanted more sessions. So we didn't, we didn't stop there. Um, we went on to, recently we created workshop number two and it took more than one week of preparation. Uh, it should be more difficult than workshop number one. So this time we, in terms of code smells, the contacts, we open up to the callers and callies. Uh, we have new code smells. We also tend to give exercises about how to draw, how to model, so that they can go back and practice that. So one of the picture, um, recent picture that, uh, that's how they draw, they did the exercise. Um, and so on, new library, they, they appreciate that. Well, they were kind of surprised. They've been using JSON convert library without knowing that there's, there's attributes they can use to, to rename, to name a property name differently and even to ignore. They were doing it manually before, before hand. They were also, um, like the speculative, uh, generality where it talks, we have this exercise where there is about eight classes that's doing very simple thing. And after they try to remove the code smells and like lazy classes, data classes, it shrunk to just only three classes. We were on a boat and they would, they drew that class diagram and after they, they, they done the reflect, they removed the smells. I went there and asked them, um, which class have you removed? They say, this class, I cross it out, cross it out, cross it out, cross it out. And what they realized is, is actually can be very simple. Uh, they even question themselves, how come we did this? So what improvements, uh, they look for more, more workshops like this, more practice, um, some of the starters, no, some people who are less experienced, they, it, it's hard for them to follow up. So that becomes one of our challenge. How do we, do we have a workshop where people are about at a, at a similar level that we give them at the workshop? Or do we have a mixture and do some changes in how we, uh, gave the workshop? The bleeding age experiment I've been trying. So after this, um, agile India, uh, this conference I'll be going to Taiwan next week to visit the Taiwan teams, um, in Taipei. In workshop number two, one of the prerequisites in Singapore that we have is that we will have a, in order to attend workshop number two, you have to have at least three hours of one-on-one mentoring with me. So that I see where you are and help you to apply and then attend number two. But for the people in Taipei, I can't, I can't do that. I can't, I can't, there are so many people I can't fly over. So what I did is I gave them an assignment. This assignment has two parts. First part, um, please share with me a quote you have recently refactored. Tell me what smells you have identified, you have removed, what refactoring have you applied, what is your design decisions in driving the refactoring? So I tried that and part two, I gave them a public, uh, refactoring kata and asked them to refactor. I said that I will respond your email with my thoughts. And, and then, uh, when you have done all this, you are eligible for refactoring workshop number two. So, uh, what is the learning or the outcome is an excellent way to even slow down to find out where they are because it's already written and, uh, it's an opportunity to, opportunity to hear their thoughts. So just a few days ago, I received this email from them, response from them, after I shared with them my thoughts, um, they said that actually I knew this code smell in my code but I don't know any good way to remove this smell. So this is very important because it keeps me in sync to where they are. And I think I'm, I'm kind of out of, um, probably I'm going to be a shot of time now, but I'm out of, I believe there is something that I can do to, to track, um, to monitor each of the, the, the mantis and help them to improve. Um, yeah, we have been here in workshop number two. Nick's mind we are going to create workshop number three. Uh, one question lingers to me is that how many workshops does it take to remove, to reduce the smell in the comm, in the, in their commits? I don't have to answer. I don't know if we'll ever get there, uh, but as long as we keep trying, I believe there will be improvements. So, wrap up, what works? Um, if you're into the journey of this mentoring, facilitative mentoring works. It's not about just telling people what to do, but to see where they are, uh, assess, have the skills to assess where, where they are, giving them appropriate challenge that is not too big, not too simple, but just nice. Um, create a structure to facilitate follow-up. So this training program, I think it's a, kind of a good structure. It's a long-term thing. It also provides, uh, following up to track where they are. Of course, please use existing code bases. It will, no, I think I lose a lot of hair trying to, trying to see the code base, but I think that helps, uh, for, for the greater. Um, it is also an excellent chance to engage and grow internal mentors, because as you work with them, they learn from you as well. Workshop training alone is insufficient, um, and also communication style. I've changed a lot in how I communicate in order to open up, uh, others in speaking their opinions in countries in, like, in, in Singapore, in Taiwan, um, in countries surrounding Asia, not all Asia, not all countries in Asia, people tend to be, uh, quite reserved and doesn't really speak up much. How do we, uh, hear their voice? That is all I have. Thank you. So I, do I have, how many minutes do we have? You have three, two more minutes. Two more minutes. So no, I don't claim that I know the, all answers to, to mentoring. I've been learning and if you have any ideas or questions about how I can improve better or do differently, please let me know. Um, yeah, any questions from, from you guys? Uh, you tell that, uh, the participants will be sending the code first to you to see how bad their code is first. But I think the, if they're working on a financial institutions, they're not supposed to send their code to you, right? That's what happened to them. So in those circumstances, what they do, if they're not supposed to send their company's code, because the code, what they want to send it to you, that will be a company's asset. So they want, but they, on a day-to-day job, they'll be the victims of that, actually. So on those kind of candidates, what, how do you handle them? Well, that's pretty simple. Well, for my context, I've signed an NDA with the company, the non-disclosure agreement with the company, so I can access their code base. Okay. And within their company, they are okay to send, send me the decode. Oh, it is you contact the company, not the individual out there and they want to talk to you, not you talk to the company. Yes. So in the context is that I, as an external consultant, I have an agreement with the company, I work in the company. I thought the individuals are a bit worried and they contact you. That's how, not like that, you go to the company. Oh, perhaps sometime we'll get there. Any more questions? How do, how do we measure the code smells? Do you mean, how do you identify code? You know, it impacts our deliverables and all those things. How slow can we measure at all? Have you come across such a case? Well, usually you have the common matrix, like in the technical depth talk, you talk about cyclomatic complexity, duplication. Those are the, and also the coupling as well. Those are usually the matrix that you can determine whether what is the, what is the, how difficult it is to change. And for me, I, I, I tend to ask, I go to teams and ask them which is the most difficult codes that you often change and it's, it's difficult to change, they'll tell you. And you look at it, you see the code smells, you kind of know the impact they will have. Yeah. My question was more, how do you convert, convey to people who do not understand code? That is where I'm going to, because at a, so in any product company or in any financial institution, the decisions are not done by developers at the end of the day. The decisions are done by somebody who may not have any idea about code too. So can we convert this matrix into something which is comprehendable, have you done it, is where I'm pointing to? Maybe I can take it. Okay. Okay, sure. But I think the answer to that may not be so simple. Yeah, yeah, yeah. Yeah, I think so. So come, come to me directly to, for the answer. Yeah. Thank you. Thank you.