#62 Llewellyn Falco brought the joy of programming back in his life via mob programming
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:06
Hello, and welcome to developer's journey. The podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today I received well in Falco, welling is an independent adjuster coach who spends most of his time programming in Java and C sharp, specializing in improving legacy code. He is the creator of the open source testing tool called AP approval tests. He discovered strong style pair programming, and he is the co founder of teaching kids programming.org. And finally, and that's how I first heard about him. He is the co author of the mob programming guidebook. Welcome. Welcome, Steph journey. Oh, it's great to be here. Let's get right in where do your developer's journey start? Hmm.
Llewellyn Falco 1:01
So my mother was a programmer, which is not that normal, I didn't have a very normal family. She's also the developer of a game called set, which is sort of it's a card game with shapes on it, we do pattern matching. So we grew up with a lot of like, math is fun kind of things. I mean, there's set is a very mathematical game. But we also did lots of like math puzzles and stuff growing up. And we actually had a PDP 11 mainframe in our house, when I was in, like, fourth grade. And so you know, when other kids would sort of get like to get their money, their their allowances, they would have to like clean the kitchen and stuff. My dad would give me these little Fortran programs that you had to write. And, you know, it's very, it was like, here's the equation, program it up, it wasn't very complicated stuff, I didn't really have to understand much of it. Um, but it started that journey with computers very early. And then we had a remnant that the PDP 11 had, like, I remember, we had a 100 megabyte disk, which was just insanely big, both in terms of virtual space on it, but also, like, physically, it was, it was like a platter that we would, you know, there was an entire drawer of the mainframe would open up and you would set this thing into it. And, and so we went from that to like, IBM compatible computers growing up. And my mom actually came into our middle school in sixth grade, and, and taught us how to program in basic, you know, so that wasn't just me. But I was one of the few kids that I was selected for the, for the programming conference, or conference is not the right word, I guess, programming class. We did. We did a version of tic tac toe, which there are these wonderful books that we had growing up called, like, Aha. And they were, they're like these puzzle books, all these little mathematical puzzles. And inside of them, there was this one puzzle about this guy at a carnival, who had this game, where it was like all the numbers from one to nine. And if you want to play the game at the carnival, you would come up, and he would put, like 50 cent pieces down on the letters when he took his turn, and you would put down nickels. And when whoever won, whoever got three numbers, that added up to 15. First, they would get all the coins. So this is the way the carnival game was set up in the book. And of course, the guy was always winning. And so the question was sort of, like, how is he doing it? And the answer was that you it was a magic square, right? So it was a three by three square of the letters one to nine, where all the rows, columns and diagonals added up to 15. And once you do that, he's playing tic tac toe. And you are doing math. And so, so our programming exercise when I was like sixth grade, was to program up that game. So we programmed up the, you know, we had the board with the numbers one through nine, and you would select and then the computer would select, and it was basically it was Tic Tac Toe which is still a kata that you know, a lot of times when we are doing programming exercises for fun, tic tac toe is one of the ones that we will do. Um, but my very first example of this was because my mother took time to volunteer and come to our school, I think mainly as a ruse as a as like a small deception to teach me to program but to do it with, you know, sort of friends around, where it wasn't just like one on one her teaching me, but it was like, you know, we got to program with our friends,
Tim Bourguignon 5:09
what attracted you to programming in as it's such an early age?
Llewellyn Falco 5:13
Well, I mean, I was attracted to computers, period at an early age, part of it was games. I'm part of it, we This was before the internet, because I'm old now. But we used to have bulletin board systems. And so like part of it was that I'm one of the things is computers have a couple a couple advantages, I think over normal life. One is, um, they're they're much less random, right? Like there's a, there's a system and an order to them. Whereas normal life can be a bit arbitrary. Um, so I like that aspect of them. And I think I was attracted to that really early on that there was like some sense making involved. The other is, like, I remember once I was programming with an ex girlfriend many years ago, but we're programming and she was a programmer as well. We were pairing and she just, she got really angry at one point. And we were downstairs programming and so she went upstairs to our bedroom. And she came down with like a bunch of like my dirty clothes and underwear, and she throws them on the ground. And she was like, your underwear can be all over our room. But I can't have a single semi colon out of place. And there's just this element of like, on the computer, you can make things orderly and they stay that way. And then life. They don't and and it's so like discouraging to me that like I just I started give up early and like well, it's just gonna be messy in life. But but on the computer like you can have that order you can have that power in so I really early I like that I like the the sense making that came in the world. And then I also liked
Llewellyn Falco 7:18
you know.
Llewellyn Falco 7:20
So I didn't, I didn't go to college for computers. I went to college, actually for physics, which has a lot of this aspects of it as well, right. It's also sense making, it's also mathematical. The thing about physics is to do physics, it's very expensive, right? Like, you need someone to pay you to research things for a long time, give you the you know, equipment and a team and, and basically all this comes down to other people's permission, like you need other people's permission to do things. And in the thing that I loved about the computer is I didn't need other people's permission. If I wanted to do something I could, all I needed was a computer. Right? And, and so you just didn't need other people's permission. And I wasn't all that good at getting other people's permission anyways. So it was really nice not to need it. And I really loved that aspect of it. I love that you can just say I have this idea. Let's do it. And you don't need someone else to say I grant you permission to do that. You can just do it. I really like that. I mean, I remember even early in my career, I used to do a lot of swing dancing. And I met this electrical engineer through swing dancing. And, and she was complaining about making a remote. Alright, so so for her job, she was making remote control TVs, and they wanted to put a backlight on it. So that the the buttons would glow at night, make it easy to push. And she's like that that component costs 20 cents. And so my boss just won't approve it. For the remote, it's like it's too expensive. We're not doing it. And I was thinking I have never ever had that conversation. Right where it's like, Hey, I built this feature and someone's like, well that's too expensive. We're not adding it to the project. Like they might not like it we've had that conversation. right but we've never had the well this is going to make the process too expensive. Right. And and that's a wonderful thing about software is you know, it scales so nicely in terms of, of shipping, that you can build the thing that you want to build Not the thing that someone else has given you permission to build.
I still love that about software.
Tim Bourguignon 10:07
I agree with everything you said yet, I think we are having this discussion. And this is exactly the discussion we are having. When we discuss, should we build this fetches this feature? Is this the right feature? It is really bringing value to the software right now? Or is it something that sounds like a good idea, but actually isn't? What you think?
Llewellyn Falco 10:29
So, yes, I agree with that, um, I have created lots of techniques to avoid those conversations. So, so maybe I agree with that too much. You mentioned that the mob programming is one of those things that you had discovered me for. And in mob programming. A lot of people when they hear about my programming, you're gonna have five people at one computer working together. Like, that just sounds crazy. And, and there's a couple really big misconceptions that come right off the bat. Some of them are just implementation details, right? So a lot of times people are like, well, we're gonna be watching one person work. And that's horrible and boring. But that's not at all what this is like. And the main reason it isn't, is we don't let the person at the keyboard do any thinking. Right, so we we actively make the person at the keyboard, sort of just a typist, where they are typing with the rest of the group is telling them and that that prevents the watching one person work occur. But another big one is people are worried that maybe they're quieter, or shy or more introverted than other people, and that they won't get to be able to do their ideas. Maybe they're not sure how to convince other people, or the other team won't listen to them when they do their ideas. And one of the reasons that doesn't occur, is we have a very strong rule of if there are multiple ideas, rather than trying to figure out which one we should do. We're just going to do them all. And then we're going to vote on which one we like best. And so that changes the dynamic a lot. Right? First of all, you're no longer getting someone's permission to do it, you're still getting permission, you're getting permission from the team, but you're getting permission to keep it, which is a very, very different than to do something. And the other is you're now you're getting more of an opinion, retroactively. So there's a lot of things that when you hear about them, they sound weird. And then after you do them, you're like, Oh, that's actually quite nice. Um, and you, there's, I don't know, a way to get from point A to point B, without actually doing it. Like, if you want to know, if you like a food, really, you've got to taste the food. Like there isn't a substitute for that. Right. And there's a lot of foods that I really thought I would dislike, until I tasted. And I was like, Oh, that's actually quite pleasant. I'll have more of that, please. And, and so, I mean, sushi was a big one like that. For me. I was like, I don't know about this. But turns out, I love sushi. I really love sushi. And so so you sometimes you just you really need to taste it and and we do that a lot in the mob and and we have a saying like we are willing to waste two entire days trying out things that we throw away. And, and that seems like it might be wasteful. The truth is we've never come anywhere close to that. But I like that the budget is so much bigger than than what we've spent, because I like that we've never had to worry about oh, maybe we're going too far. Um, and so it just gives us that sort of permission and that, that space to play with stuff.
Llewellyn Falco 14:14
And then
Llewellyn Falco 14:16
you know, very often
once you you see something, like once the team sees it, there will be agreement and there is difference. You know, permission usually is coming from a single source. Right? Like, you're trying to convince your boss or you're trying to convince a manager or you know, someone above you, but here we're the team does it and then the team votes. It's a very different kind of, of selection. And that's not to say that the team is always right. Um, I've seen places where we've done stuff that I thought was clearly better The team was like, No, we'd like this other answer. And so we went with the what I thought is the worst answer. Um, the thing is, usually one of two things happens, or, which is, we never revisit it. So it really doesn't matter which answer we took. Right? Or we do revisit it. And in the future, if it is the worst answer, they will change their minds. Right, but now, like the team is able to accept the new way, like maybe they just had a longer path to get to the right answer. So it, yeah, so I've learned to be more patient and realize, like, Hey, we're gonna get to what's right, in the end. And, you know, maybe we go through some wrong, some wrong paths. It's, once you start seeing that in others, and feeling comfortable with it, you can start to recognize that, like, I do that all the time with myself, I just tend to forget about my past. Like, there's tons of things that I did last year, or five years ago, or 10 years ago, God, if I look at my code from 10 years ago, it's embarrassing, right? Like, I've learned things, and it's, I think it's sort of human nature to block out the things that are inconsistent with who you are at the present. And so when I look at those things, it's easy to think, Oh, well, you know, either I didn't know better than or that's not really who I was, or, you know, stuff like that. But But we, we very often don't make a straight line,
Tim Bourguignon 16:36
would you mind quickly, briefly defining my programming and and then telling you the ins how, how it came to be in your life? How do you came to, to, to discover it and be one of the of the leading minds in establishing it.
Llewellyn Falco 16:50
So this Okay, 2009, I was at the Agile conference in Chicago, agile 2009. This is my first really big conference that I was speaking at Absolutely. My first big conference, I was speaking out, and one of the first big conferences that I even attended. And I was there for approval tests, which I really wanted to do, it actually worked with, with someone for a couple months to craft my proposal and
Llewellyn Falco 17:22
to get accepted.
Llewellyn Falco 17:25
No, but I was very excited to go. And it's also very, I was like, oh, finally, I'll be it with a bunch of people that I fit with. I am, like, I'm one of the tractors of the Agile 2019 conference this year. And and very much for me, that conference is like going home. It was not like that in 2009. When I showed up, I was like, why is nobody here? I don't fit at all. Um, but so I go to this conference. And it was a it was a hard conference. For me it was it was very intensive. I had signed up for this thing called coding with the stars with a partner view with was sort of luminaries in the field. And you did these little 30 minute presentations every day, which took like all day to prep the day before. And you wouldn't know if you had to do Tuesdays unless you one Mondays. And so Monday was spent sort of prepping for Tuesday, and Tuesday was spent prepping for Wednesday and Wednesday is spent prepping for Thursday. And anyhow, it's very a lot of work. Um, and,
and one of the talks that I went to,
I there was this thing called a coding dojo. And it was a it was Laurent, who's is from Paris. And in Paris, they actually have a user group. Or the very least they had a user group, I'm not sure if it's still running today, called coding dojo, where they would get together I think it was like every other week, and just program together in in this style that definitely if you squint sort of looks like mobbing. But one of the really big differences is the way that they pair was very, very different than the way that I paired. And so just to give like a little bit of background there, I started pairing, I had a company of my own, it was really for a long time, it's just me and one other employee. And so we paired all the time, cuz I had already been introduced to pairing and it found so many benefits from it. But I didn't realize that my style of pairing wasn't what anyone else was doing. And so what everyone else was doing is when you're pairing and you have an idea, you would take the keyboard and you would type that idea in and the other person would sort of look over your shoulder and, and sort of comment and keep you on track and stuff like that, which is not at all what I was doing. What I was doing was if you had the idea, you gave the key To the other person, and you sort of would tell them what to do. And, and they would do it. And, and this, this works out really nicely. And in a whole bunch of different ways. But the biggest way is, the worst part about pair programming is one person working and one person watching. And if you uphold this rule that for an idea to go from your head to the keyboard, it goes through the other person's hands, that that goes away. And so here I am, and I am at this session, and they were doing the other way. So the person who is typing was was thinking, and then they would rotate, and they were rotating fairly quickly. And I don't remember exactly what the timing was, but it was something like every five minutes, somewhere in that neighborhood. And the problem was, was really hard to figure out what the person typing was doing. And so when we rotated, the person who took over was sort of like, I don't know what to do, but now they have like, eight people watching them. And they're like, well, I gotta do something. And so very often, what they would do is sort of undo what the person in front of them just did, and start doing the way that they saw to do it. And, and so this, sort of made this, we couldn't go forward, right, we took sort of like two lines, and then we delete two lines, and then do another two lines. It was very frustrating to me. And I was like, well, the easiest way to fix this, is if we pair in my style, and I didn't have a word for that at the time, um, because I was just discovering that what I thought was pairing wasn't, wasn't universally understood. Like that, in fact, not only not universally understood, nobody understood it like that. And so, um, but but I was like, I think like, this was very interesting. I think if we just applied my style of pairing to it, it'd be a lot better. Now, at this point, I'd already had a very interesting relationship with local conferences. And there's these things in Southern California. So I was living in San Diego at the time. There's these things called code camps, and love code camps. I still love code camps. And I like conferences in general, for a lot of different reasons. But I like a lot of things like the Code Camp conferences, which are much smaller local conferences, because you can experiment in them in a way that you can't, at a big international conference, like at a big international conference, people have paid a ton of money they've traveled like you need to sort of deliver something that is going to work. But but at these code camps, you can do something that sounds kind of insane and might not work. And and you can test stuff out. And I love that element of experimentation. And so one of the things that Carl Monastir has a friend in San Diego had sort of said was all these talks we go to, they're all they're all pre planned. But the entire idea of extreme programming and agile is that we can respond to unplanned things. So there's like a fundamental lie in all of these talks. And he's like we should do, we should do a session where we just take a suggestion of something to program from the audience, and we build it in front of them. And I was like, That is insane. Like, I am not willing to be that embarrassed.
But I'm, like I said, Carl, Carl was a good friend. And we started doing these things called Monday night code, which, which was just on Monday night, Carl would come over. And we'd spend like two hours or so playing with code. And these were great sessions. And they, they brought the joy of programming back into my life.
It sort of stuck since then. But
when I was young programming was always fun, because it was always that's the only reason you would do it. Right? when you're a kid in your programming, you're not getting paid. Like oh, I mean, when my dad was giving me allowances, but that stopped. And then then I was doing it because it was fun. I wanted the thing I was creating. It's like coloring, right? Like you don't color in a book because for any other reason, then it's enjoyable to color in the book. And, and then when I started working, you know, it became less fun, became more became more work. And when Carl would come over, and we would do programming for fun, it reminded me how much I enjoyed doing this thing. And usually, that would sort of last so this would be on Monday, and then you know that would last Tuesday and Wednesday and Thursday would sort of die down a little bit and Friday would sort of teeter off, and then on Monday would sort of be gone again. But then Monday, we'd have Monday night code again, and it would sort of come back. And so it reminded me how much fun it was. And at one point, me and Carl, were working well enough together, that I was like, Carl, I still think your ideas insane. But there will never be a time in our lives, that we are going to be better prepared to do this. So let's try it like, you know, if it has a chance of working at all, now is the time that it will work. And so we did that. And it was it was wonderful. It was fun. And I met woody around that time. And he was like, this is a great idea. You know, so often we go to programming conferences, and we talk about programming. But we don't, we don't program together. What he used to be a musician, he used to be a banjo player. I'm part of the Zulu brothers. And he traveled the country for like, 10 years playing bluegrass. And he said, at the festivals, you know, late at night, people would gather around the campfires, and they would play music together. And he missed that element of, of, of that playing together in programming. And so when I found this coding dojo thing, I was like, we could do that. At, at the, at the local code, conferences, and it would be fun, and now other people get to play with us. And so we started doing coding dojos, at the code camps. And, you know, we would often either ask the group for a problem, just like a variation of what me and Carl were doing, or we bring our own sometimes. But most of the time, in the beginning, we just, we had people suggest, let's build a, b, and c, and then, you know, vote, and the one that was voted, so like, one person was like, let's, let's make a dress chooser. And we're like, Okay, and then we voted, and that one's the one that got there. And so we're like, well, you're the product owner, it was your idea. You're the product owner. And they're like, Okay, and so they just kept giving us an example, and we program it up. And then they give us another example and program it up. And it was super fun. And, and this is the beginning of mob programming, it was just the coding dojo, but with strong style. So instead of one person programming in the group watching, it was the group programming and one person typing what the group was thinking. And that allows you to actually rotate much faster. Because let's say you have, you have eight people in your group. Well, one of them is type. In the other seven people are thinking, and when you rotate, you have another seven people, but six of those people are the same people. So it's much less disruptive, on what's happening. And of course, when you tell the typist what you want, you're also telling the rest of the group what you want. And so, so that, that the shared mindset is really high. And, and this was wonderful. And I was doing teaching at the time. So both corporate teaching through a company called development are where we come in for like, four to five days at a time and do like test driven development in a classroom setting. But also teaching kids programming, where we would go and do like usually one day events or like, you know, morning events, with kids, usually, you know, 10 to 15 year olds, with a heavy focus on girls. And so when we are doing this, my co founder for that Lin Lang it. She She worked at Microsoft that time. So we were doing a session at the Microsoft offices, and it actually took us It took us all day to set up those computers.
And, and we had come in the day before, and we set up all the computers and we started. And about halfway through the first hour, an entire busload of girls arrived late. And they're like, Oh, well, we'll just set up this session. And we'll join the next session. And I was like, that doesn't work, because the next session builds on the first session. You just you can't just skip it. And I knew I couldn't just set up new computers, because that took me all day yesterday. So I was like, Oh, well, we'll just do a coding dojo. And so I set up my computer, and I put them in a circle and I did it the same way we do coding dojo at the code camps, and it worked really well. And in fact, it worked well enough that I started teaching this way. In general, like very often when I was teaching, I would put people in, in a coding dojo with strong style. Well, we know I'll call my programming but we didn't at the time. And, and because me and Woody were doing this at the code camps, and he was also teaching at his work, he was also doing this a lot. And then this thing occurred. Now, there's the saying that I love, which is a swimming pool is not just a bigger bathtub. And, and what he means by that is, even though you know, a bathtub is just like a container with water. And a swimming pool is a bigger container with water, what you do inside of a swimming pool has no resemblance to what you do inside of a bathtub. Right, there's just, you don't have lifeguards, you don't have diving boards, you don't have, you know, pool pumps, like all these things just don't exist at the smaller scale. So just the changing of the scale changes everything about it. And what happened at Woody's work, is the scale changed. Because all these things that we were doing just for learning, people get together, you know, for an hour or a day or five days, and then that was it, they were gone. But at work, when what he started realizing that this style of working, actually works for production. Now they're together 40 hours a week, for years. And in that those hundreds and thousands of hours of of time together become hundreds and thousands of hours of better communication, of trust, have empathy. And it's huge changes things fundamentally. And, and so, you know, I sort of helped assemble the ingredients, with no idea of what what it was going to create. What was possible with it until woody sort of unlock that. But it has been one of the best things that I've discovered, and it allows for so much of my life to be possible. And one of that pieces is like I'm a technical coach, which means I go to companies and I sit with their programmers and I program together. And that's how I introduce new skills to them. And it's how I introduce new behaviors, which is different, like it's different, knowing what you should do and actually doing it. And in my programming sort of allows this and I was at a conference in in Serbia, where it was my first time in Serbia. And I didn't I didn't know anybody there. Nobody knew who I was. And and so meeting all these people and one question that kept reoccurring is Do you still program? And that was a very weird question, because, and anyone who's seen almost any of my talks, I'm usually doing live programming on screen. That's not a question I ever get. So I was like, Yeah, Yeah, I do. But then after a while, it's like, why are people asking me this question? And so I asked somebody one point, I'm like, You're not the only one who's asked me this question. Why are people asking me this question? And, and they're like, Well, usually, once you become a consultant, you stop getting the program. And I was like, Oh, yeah, that makes sense. Like, a lot of consultants do. They, they start teaching and they start talking, but they, they don't actually get to program anymore. And I was very fortunate and lucky that, you know, I got to program like, this was still something every day, I got my hands in code. And, and I was like, I didn't realize like, I didn't realize how lucky I was that I still got to do the thing that I loved.
And, and my programming has really made that possible for me. And it's allowed me to, to go to so many different areas and places. Because in a mob. What you don't know, doesn't matter. So I'm working in a domain, I don't know, that doesn't matter. Somebody in the mob knows that. So that that's covered. Right? Or I'm working in a language. I don't know. That's okay, too. Like, they know how they know the language. So, so what I don't know, doesn't matter. And that allows me to be useful and valuable in a lot of places where I just wouldn't be if I was by myself. And I love learning, I love getting to work with people and I like I love all these things. And I mean, all of this came from, you know, or started came as a strong word. But But, but it started it was seated from this one talk at a conference that I just sort of lucked into. And so much of my life has been me being lucky by discovering things that I had no idea That I didn't know. So there's no way I could have actively searched for him. And I just happen to get to enough random places that I get to discover these things that I didn't know I was missing in my life. And that's, that's a huge thing.
Tim Bourguignon 35:20
I've co moderated a mob session with with fire. And in London, I think 18 months back, and it was exactly that, like you did describe the, um, it was in C, which has I haven't program with for at least 15 years. And on on email server that he co authored, which I didn't know anything about. And the audience or the participants of the talk, didn't know anything about either. And it went fantastic. Yeah, definitely, as you say, um, there was always one person that knew enough to make the next step. And that was enough to get going. And this was kind of sick to see,
Llewellyn Falco 36:05
yeah, it doesn't have to be the same person, they just need someone who has the insight at the moment. I mean, Amata is actually great. I don't know if you know the story about how we got to work together. So um, so I was working at a client out in DC. And I got, I got a very special privilege, which is they, they wanted more work than I could give. And, and I said, I would like to do a visiting coach program, I'd like to collaborate with other consultants, who I never get to collaborate with, but I get to see at conferences. And so I would like to bring my competition to you. And basically, the way it would work is, you know, I work in two week increments, they would come halfway through my session, so they would come on the second Monday, I'm there, we would pair together for a week, coaching the teams, and then I would leave, and they would coach for one more week solo. And, like, they were like, yeah, we will do that, which I mean, this is a this was a wonderful program. But absolutely, you know, it's expensive, I can't tell him exactly what great things will happen, just that I believe great things will happen. And so you really need some someone who has a lot of trust in you that's willing to extend that. But but they were willing to, and, and so I set up my coaches, and I approached omma ty and said, I would like you to be one of the visiting coaches. And he actually said, No, I'm having the kid. And that that is a very reasonable response. As, as kids take a lot of energy and effort. Um, but but afterwards, I was about to bring bill Odom out who is another great programmer, and bill called me and said, You know, I have a client, and they're having some problems right now. And I just cannot abandon them. Like, I need to cancel on you. And I was like, oh, man, it was like, you know, on the one hand, you know, like you're coming out in two weeks, man. But on the other hand, like, one of the reasons that I wanted bill in the first place, is because He cares about his, you know, he cares about his people so much. Right? Like, that's an excellent quality to have in a coach. So I'm like, you know, it's the very quality that you're exhibiting right now is the reason that I want you to come and is also the reason that you're, you're not coming right now. So I was like, oh, what am I going to do? And literally at this, like, the same day, I'm typing me and he's like, you know, my kid is, you know, doing pretty good. Now, I think I'm about ready to come back to work. So if, if you're open to it, I'd like to change my mind on the visiting coach. And I wrote him back and I'm like, how does how does like two weeks sound to me? It's like, Oh, yeah, it's a little quick. But yeah, we can do that. And so I got to bring on the tie in. And I'm gonna tie was a great coach. And I mean, all my visiting coaches, I was so happy to work with. And all of them, I got to learn different things from one of the things that happened with ATI, which is really interesting, um, is one of the days that he was there. He did something that I kind of didn't like, right, there's just something was going on at home. And, and that's okay. But while we were coaching, he was on his phone just just too much. And one of the things is when you're coaching, you really need to put your attention on the thing, and it's not like a huge deal, but I did talk to him afterwards. And I said, you know, hey, and he's like, Yeah, I was, I'm sorry about that, too. I even when I was doing it, I realized I shouldn't be doing I just sort of sort of wanted to take care of some stuff. And I said, That's okay. He's like, I was like, but I'm having a problem with this particular team, where they also are on their phones too much. So do you mind if I publicly schooled you in front of the team? So that they, like, I can make an example out of you? And oftentimes, like, yeah, that that's not a bad idea. He's like, actually, you know, what might be a better idea is if I just probe proactively do it myself. And so he went to the team at the start, and I purposely, like, came a little late that day. And he sort of he went to them and said, Hey, you know, yesterday, I was on my phone a lot. I wasn't giving you my full attention. And I wanted to apologize for that, because that's not right. And, and they were like, Oh, no, that's okay. And they forgive him. And now, they are sort of in this, um,
like this high ground. And so now that they're there, their behavior started getting a lot better, because now having forgiven I'm gonna tie, they didn't want to model the same behavior that they had just done, and it actually worked out so well. Then afterwards, we're like, maybe sometimes we should model the behavior we don't like, just so we can ask to be forgiven for it. It's just like a neat little hack to change the team's behavior,
Tim Bourguignon 41:27
as long as it's not known by the by the coaches, then I guess it's fine. Yes.
Llewellyn Falco 41:33
Yeah, I think
Tim Bourguignon 41:34
that might be the trick. And the the time box is running away. And I have so much, so many questions. It's, I guess we could talk for hours. And maybe what when, when interesting question, Where does the the idea for the for the name mob programming comes from? You know,
Llewellyn Falco 41:52
that is an excellent question. And I'm not entirely sure that anybody knows the answer to that, um, there are a lot of the, there's a lot of weird parts about naming things, period. One is you the think that the people who are associated with the name have control over the name, which is just not true. It, I think the name actually existed before we came up with my programming, I think someone had a had associated that term, with just the concept of a group of people working together. And so that name sort of was there, in the very beginning, and I don't think it was really from a specific person. And then, and then it just stuck. And, and sort of So, you know, it wasn't like assigned by any particular person. It just sort of just sort of got labeled, and now it's there. Sometimes people want to change it. I know, in Swedish, it's a it's not a good word. And so people want to change it for that. But again, this is just it's, there's not like a committee to go to, it's just sort of something that's in the public lexicon, and it feels like it was there before even even the thing that it's been associated with, it feel like it predated that by actually quite a bit and just sort of got attached like maybe a floating concept that was waiting for a home. Yeah, I know, that's not a very satisfactory answer. But sometimes
Tim Bourguignon 43:31
I would have to smile because I find that the term actually, actually fantastic. So it's really it's really a he's to me for the for the wisdom of the crowd, and saying, well, we are a group and as a group we are we are stronger. But when I when I present this to my to my clients and try to coach teams in this direction and start there's always the not the mob programming term is coming out, but the word mobbing and it always bring out some really hard discussions. We don't want to bore anyone.
Llewellyn Falco 44:04
Oh, that's interesting. I
Tim Bourguignon 44:05
always have to smile.
Llewellyn Falco 44:06
So I actually usually don't use the term when I'm working with a client in the beginning. Because I found it not to be helpful. I actually will just say, we're going to program in this weird style for the purpose of learning. So one of the things remember, I was saying like a lot of times, we'll try the ideas and then we'll make opinions about them. So an interesting thing is when you give something a name, it's sort of like taking a step forward. But I don't mean that in like your advancing I mean, it's very hard to undo that step. And so the moment you give something a label, people all of a sudden get opinions and ideas about it. And it's it's nicer if you can experience it before getting the name. Right. Like, if someone gives you a piece of food, sometimes you'll be like, Well what's in it. That's usually not helpful. Try that. Food first, see, if you like it, then ask What's in it? And find out if you actually do like oysters or not. You know? It's, it's because because that label carries much more power and much more weight than you would you would expect. And so, so yeah, I just found that when I'm working with my teams, I'll just sort of say, Hey, we're gonna, we're working together to learn. And so I'm going to work in this weird style. And then after we learn, then we can talk about the word mobbing because then they've already made their opinions, right, because they've made it based on experience.
Tim Bourguignon 45:41
If If you were to, to, to have a bunch of newcomers really fresh from university, or apprenticeship program, or, or whichever whichever studies they went through in front of you, what would be the one advice that you would like to give them.
Llewellyn Falco 46:02
So like, if you are going to go with one piece of advice, the thing that came to me early on was pair programming. And the thing that is so valuable about that is both parent and mommy and at the time, it didn't know about mommy and mommy didn't exist, but
both of them really increased learning.
And we are in an industry where increasing learning is how you how you do better at everything. Right? It's how you are more productive, it's how you're more innovative, it's, you really want to increase learning. And so I'll be my one piece of advice is pair and mob absolutely as much as you can with as many different people as you can. So So I mentioned that I used to do swing dancing. And one of the things that was really helpful for me, I was not a naturally gifted dancer in any sense, right? My coordination was wasn't great, my rhythm was non existent. Any idea of elegance was not in there. Um, but one thing that was super helpful for me is when I started dancing, um, I was I was both singing single. And also, I had no other friends who danced. And in fact, when I started dancing, I was in California, I grew up growing up in Michigan, and in Michigan, the rules were different revolving, involving liquor. So in Michigan, you could go to any bar, you wanted to, if you're over 18, you just couldn't drink until you're 21. But in California, you couldn't go to a bar until you were 21. There was no inter bar and don't drink that just wasn't allowed by law. And so my friend who was the one who was like, hey, let's, let's go take a swing dancing lesson. She was she was under 21. And so the first bar we went to, they literally went, let her in. And I'm like, I don't understand what's going on. And she's like, I'm like, we're not drinking. And they're like, it doesn't matter. She's not allowed to enter. And so I was I was at all these places where we were doing swing dancing, but I didn't have anybody to dance with. And so out of utter necessity, I just had to keep asking random people to dance. And the thing about that is you would you would learn a move in class, and then you would go out dancing, and you would do the move with some women, and it would be great. They would they would follow they understood exactly. I was like, Oh, I really understand this move. And then your dance with someone else. And no, wait, I, I obviously don't understand this move. Like they're not doing it all what I'm trying to tell them to do. And, and just all these different people, each one would show different aspects that you could learn from the one of the things I noticed is people who did have a partner that they always danced with, they would dance really, really well with that partner. But as soon as they started dancing with anyone else, it would go really badly, because the things that their partner knew what to expect, they weren't actually doing the moves very well. It's just the other person was able to anticipate them really well. And so there's this huge gift in getting to dance with as many people as you want it is you possibly could in terms of becoming a better dancer. And I think the same thing is true with programming. Like so if you only get to pair with one person, you'll learn a lot from that one person. But there's still so much new things and so the more people you get to pair with the More people you get to mob with every single person has something to teach you. Every single person. I've never met somebody so dumb that they didn't have something to teach me. And so if if you start and you just never work alone, always pair always mob and always figure out what this person has to teach you. And you will turn around and you will have learned so much so fast.
There's nothing that compares to that.
Tim Bourguignon 50:35
Amen. Thank you very much for the wonderful advice. If the listeners wanted to continue discussion with you, where would the ideal place to contact you.
Llewellyn Falco 50:46
So there's two places that I am easy to contact one is on Twitter. So, Llewellyn Falco is a very global name is internet unique. So that's helpful, it is two L's in both places. And the other is just at a conference, like I am the person who has my laptop open, sitting at a table at a conference, doing some random thing with some random person. Like that is that is completely what I love to do. So like if you ever see me, like calm ask, I am happy to pair I do a lot of remote pairing, and buy a lot. I mean, usually 10 to 15 sessions a week with people, you know, sort of around the world. unfortunate that I've now I've been to enough conferences, and I have enough presence that like I can make these connections. Um, but yeah, like you are my third comp. Here. My third person I'm talking to remotely today and I have one right after you. So like, like, I love working with other people. I love collaborating. So like, don't be shy. Yeah, uh, speaking of conferences, I'm going to be in Lisbon and Prague later this year in the fall, that's gonna be like, late September, early October. Yeah, I'll be out in DC early August. So I think this will probably come out right around that time.
Llewellyn Falco 52:17
Um,
Llewellyn Falco 52:20
my blog, Llewellyn falco.blogspot.com has a lot of the things that I'm interested in. If you're interested in the mob programming guidebook. It's my program guide, book.com. It's free. My learn with Lu GitHub also has tons of educational exercises on it that you can check out or my approvals on GitHub. So GitHub slash approvals has approval test in almost every language. And if it's not in your language, well, that'd be a great thing to pair on. So that's how we got to all the other languages. Well,
Tim Bourguignon 53:00
thank you very much. There was a fantastic story fantastic. Brushing over the history of strong style pair programming and the birth of mob programming. I'm really thrilled to to have heard this firsthand. That's, that's absolutely fantastic. Thank you very much. That's been fun.
Llewellyn Falco 53:17
Thank you.
Tim Bourguignon 53:19
And this has been another episode of developer's journey, and we'll see each other next week. Bye.
Dear listener, if you haven't subscribed yet, you can find this podcast in iTunes, Google music, Stitcher, Spotify, and much more. Head over to WWE WWF journey dot info. To read the show notes, find all the links mentioned during the episode. And of course, links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice right now. And if you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and do fantastic journeys. Thank you