#65 Woody Zuill brings people together who should be working together
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Woody Zuill 0:00
I'm not a teacher, really, I don't have a degree. I don't have any formal training. And he said, Boy, after hearing you talk today, I think you're perfect for this job. So that one little thing that somebody else recognized it and told it to me that way, made me feel like, you know that that really helped me get over this that that, you know, I don't know what I'm doing. I don't want anyone else to find out. I don't know what I'm doing. I still don't know what I'm doing. There's too much to know.
Tim Bourguignon 0:34
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 Rudy Zhu. Woody is an independent, agile and lean guide, and has been programming computers for more than 35 years. He's an originator and pioneer of the mob programming approach to teamwork in software development. And he's also considered one of the founders of the no estimate hashtag discussion on Twitter. He's passionate is to work with teams to create an environment where every one of us can excell in our work and life. Woody, a warm welcome to the afternoon.
Woody Zuill 1:18
Thank you, Tim. I'm really glad to be here.
Tim Bourguignon 1:20
Let's start let's start with nasty question. He not that I want to desperate you as a as an old or anything. But as you just said, in your bio, you've been programming computers, as long as I've been alive. So could you please take us to the IT industry? When you started? How was it?
Woody Zuill 1:39
Sure, I think that's a great. That's a great question. So I started programming, I was already 30 years old. So it's not like I started as a teenager in high school or in some sort of a college courses, that a lot of that stuff wasn't even available. At that time, if you were going to learn to program, particularly in the late 70s. Any time before that you probably, you know, needed to have access to a computer, which was hard to get, which meant you had to be in a school, or else someplace where you're working, where you had access. But in the very late 70s, in the early 80s, it started becoming possible for us to get our hands on a personal computer at some time. So I realized the industry that I was working in at the time, I owned a business. And I realized that that business was you know, computers were quickly encroaching in that business, it was going to change the nature of that business. So I thought, well, maybe I need to get my hands on a computer and learn something about using a computer. And very shortly after I got my first computer, I it was good for some things I actually bought, very early on bought two computers. I've realized that while the computers were good for some things, a lot of the software was terrible. It didn't work well, it was buggy, things crashed all the time, you couldn't depend on it. And I thought, well, the such a low barrier to entry to, to writing programs, maybe I could learn to write some programs. And in, in a sense, that's what drove me to learn to be a software developer. At first, I just used language that came on the computer, which was basic, I'm not sure which version of basic but it was a CPM operating system. And whatever came on that that's what I had, I started writing software. And within maybe two or three weeks, I was writing stuff that was useful to myself. So that's, you know, my Inception story or the beginning of me learning to program computers. It took me maybe five or 10 years of writing software for myself that I started realizing that, that I was more interested in that than in the business that I owned. And maybe I should start thinking about, you know, making a career as a software developer.
Tim Bourguignon 4:05
I was it to switch careers after so long.
Woody Zuill 4:09
Oh, that's a good point. Because, or a good question to ask. Because at first, you couldn't make enough money as a computer programmer to replace what I was doing. But as the rates for programmers went up, and that, you know, the ability to find work as a programmer got easier and easier. I started really seriously considering it. And I was a little afraid at first, in the late 90s I started taking on work for my friends actually, I would just say, you know, people come into my shop, and they you know, Hey, what's up, do you kind of thing? And I say, Well, you know, I've been learning to program. computers. Let me show you some stuff and I you know, show my friends or whoever came in a few things I was doing. And they say, Oh, you know, I need to get this done whatever it was, and I'd say sure, and like they've got some camera that can be controlled. By some API or interface that it has, you know, they and they wanted to do that. So I just start taking on these little, what I would consider side gigs to help people. And then somewhere around 1998 or so I was good enough of a programmer to start taking on really big or full time things. So but I was afraid of making the change from the business I was in where I was making a living, to something that I really wasn't yet making a living. And I had a lot of this. So you know, what they talk about nowadays, you know, kind of imposter syndrome. Am I really a developer, I didn't take any college classes. And in fact, I decided not to take any college classes. Because I went to the nearby college, which happened to be UCSD University of California, San Diego, they're very famous, and were particularly back then for their computer program, or their computer, you know, study. And I went look through their materials. And what I found was, it would cost me a huge amount of money and a lot of time, to, to, to learn to, or to get a degree of some sort in computer programming. And I had already been programming for 15 years. So I just went to the bookstore, bought the books from their classes, and took them home and studied them. And I pretty soon realized I actually knew much of this stuff already. And they were kind of behind the times in what was in their, in their study system and what was in their books. So I thought, yeah, maybe I can just do this. Now, this was a time 1999. If you could spell ASP, or you could fail spell VB, you could get a job as a programmer, they were so desperate for people who could program you didn't need to know anything. So I just started applying. And I got my first job at it in a full time job. And very early 1999, probably January, like January 2 1999. And it was a three month contract. And it was amazing. The place was doing extreme programming or something close to what Extreme Programming is sort of a pro agile approach to software development, I loved it. And I told myself, I can remember saying these very words to myself, I'm so glad to be in this industry where there are so many brilliant people, and they're doing things so well. And that was a trick, I think that got played on me, because that first place was excellent. And then when that contract was over, we finished the work that needed to do, I went on to my next contract, and it was terrible. So I was really afraid that it would be seen that I was not capable. And now it was revealed to me that actually, this place was a mess. And I didn't need to be afraid that I was just more or less in a way novice or beginner. So there you go. That's sort of the story. That second contract, though, was meant to be a three month contract, it extended out to a six month contract. And then sadly, I didn't renew again, because it had gone the project itself was so terrible, there was so much pressure, and the people there were, I would consider I would say they were under pressure, but to pressed as well. And so by this terrible project Iran, but that began the journey of me looking for ways to make our workplaces better ways to make our workplaces more. I would say kinder, and more Kinder is probably not the right words to use, but to make our our workplaces kinder, more respectful to the people working there. And and that started me down the path that's brought me to where I am today.
Tim Bourguignon 8:50
When the nice story, if I can backtrack a little bit, you started from the get go was a contractor.
Woody Zuill 8:56
Did I get that? Right? Yes, that's correct. So I would say Well, at first I just took on projects for friends. And then in those days, it was very easy to get a contract, you would just go to a company that needed somebody and and sign up for a specific amount of time rather than as an employee. So first of all, maybe I was independently taking on work. And then I went in as a contractor. I didn't take a what I would consider a full on job as a programmer where I was working as an employee of a company until something like late 2001, something like that. And I said, and
Tim Bourguignon 9:36
you talked about imposter syndrome. Did this first gig, a wizards gig enough to help you overcome this imposter syndrome? Or did you have to do some things fix it?
Woody Zuill 9:49
Yeah. Well, yeah, that's a great question. I did a few other things as well. So in 1999, as I kind of explained I was going to you know, that's why When I started, I was attending a local user group, Visual Basic, that was the language that I was mostly working in at that time, Visual Basic user group, I had already messed around with some other languages like C, and c++. But a lot of work was available for Visual Basic programmers and also ASP, which is, you know, use Visual Basic scripting language as its, its its core language. So I was attending these user groups probably going back as far as 1996. And by 1999, I realized that if I really want to have a career at this, rather than just be one person, with a resume and a stack of other resumes that the company was reviewing, to see who they'd hire, I probably need to be in front of people so that I could be talking about the things I was interested in. And that would hopefully attract people, to me to hire me. In other words, they would say, Oh, we heard this guy talking about, you know, whatever it was at this user group. And that's just what we need. So he's an expert, clearly, so why don't we hire him. So speaking at the user groups also helped me get over this imposter syndrome. Two or three things that are important about that one was the developers who come to the user groups, at least in those days, they were interested in learning things, and they weren't too picky about your overall skills, as long as you could, you know, teach them something they wanted to learn. So I started realizing it's not that you know, everything about software development, but you have some things that you're becoming an expert at, and you can share that with other people. Another thing that helped me was that these are, this is a very forgiving audience. So if you make mistakes, they don't care, as long as you can get your material across. And I actually was learning, I'm much better at coding in front of people than I am in explaining it in front of people back in those days. So I would generally just take something I was, had been studying for myself that I wanted to use in my job. And I'd put together like a scenario that we want to, you know, do and then I would write the code in front of the audience. And I found that really helped me gain confidence, because I would practice and practice and practice so that I could do it without mistake in front of somebody else, I would practice something 50 times before I'd give a talk on it. So that helped me a great deal. And that's that's one thing that drives you towards becoming better. And that is the the help you share it with someone else that then you know, you need to get good enough at it, to be able to show it to them without
getting stuck in the middle of it because you forgot how to do it or, or keep making mistakes, and so on. So that was useful to me is getting in front of an audience. That was a forgiving audience, that presenting something I really knew well, that helped me get over it. Now another thing happened, I don't know, you can break in in any time, and interrupt me if you want. But in those earlier years, let's say right about the beginning of 2000, I was giving a presentation at a user group. And I think it was on doing graphics or something like that, manipulating your screen, BIT bit by bit, and so on. And, and they came up this recruiter came up to me and said afterwards, I want to submit you for a contract that I have. It's for some night work teaching a class. And I said, Boy, I I'm not a teacher, really. I don't have a degree. I don't have any formal training. And he said, Boy, after hearing you talk today, I think you're perfect for this job. So that one little thing that somebody else recognized it and told it to me that way made me feel like, you know that that really helped me get over this that that, you know, I don't know what I'm doing. I don't want anyone else to find out. I don't know what i doing. I still don't know what I'm doing. There's too much to know. You know, it's way too much to know. And so all we can know is is sufficient amount to to meet today's challenge. And that actually that turned that one little request from that recruiter. I did go ahead he submitted me for the job. It was supposed to be a few hours a week at night. And almost immediately when during that first week I was doing it one of their daytime instructors quit and they came to me in a panic and said could you take over his class till we can find a permanent instructor and I took over his class and I never did find a permanent instructor. That became my full time job for a year teaching a what in nowadays we would call a boot camp. I taught a boot camp for what you might consider power users to be able to program a client server applications using Oracle and Visual Basic and that's a lot to teach in a boot camp. It was an eight week course. And that so you can see from 1999 when I started full time Till the end of 2000, I went from being a novice what I would consider programmer to being an accomplished instructor in programming. And all because I was opening myself up to these chances. by speaking at a user group, it's a funny thing. The user groups, that very first job I got, came to me through an acquaintance that I knew previous to all this, but the second contract and on from there came to me through context I'd made through participating in a user group. If I'm going to give anybody some advice, it'd be you know, at least try that out. See if that helps. boost your career a little bit, get to know the people at your local user groups. Those are great folks who want to help you, they want your help to, and Gosh, that's a that's a good thing to do.
Tim Bourguignon 15:51
Fantastic. I would like to unpack a sentence you say before, you see you said, Oh, no. Okay. You said you said you knew you were better at coding in front of an audience, then telling something in front of an audience?
Woody Zuill 16:09
Yes, if I asked
Tim Bourguignon 16:10
all the developers around me, I am willing to take the bet that 80% of them, at least the newcomers in our industry, have never coded in front of an audience. At most they have done maybe some kind of fake pair programming where the driver is driving the whole the whole programming session and sometimes telling the navigator where they want to go. But so not not pair programming, but theater programming, maybe, but nobody colds in front of an audience. How did you realize this? So early on, okay, yeah.
Woody Zuill 16:48
So the, it's kind of the reverse is that I had a lot of trouble speaking in front of an audience. So I thought, if I could just, if I could just demonstrate the stuff I want to share. That will be that gives me Well, let's take this back one step, when I was quite a bit younger, I played music, in a band. And when I get on stage with a band, as long as you have really good music, that gives you a super duper, crutch, a super, I would say, an ability to hide behind the music itself, to be on stage. So although I was afraid, and I was I was, you know, stage fright. The music itself gave me an especially playing in a band gave me the confidence to be onstage, all you have to do is get started. As a matter of fact, you know, what's the song starts and then you just, you know, you're in the music. So, but when I had to get as a solo, speaker in front of people, I really had trouble speaking in front of people. So I, I tried combining that with showing code. And rather than showing it, actually writing it, and almost immediately, I could see for myself, Well, that's a lot easier for me. So that's I knew I had a chance that that would be easier. And as soon as I tried it, I could see, I wasn't stumbling so much, you know, I could just type the code in. And if I made a mistake, I could fix it. But it didn't come across as as I would say, odd as making a speaking a mistake. So like I when I would speak, I would start stuttering. Or I would, if I got to a point where I forgot what I was going to say, I didn't have a way to start myself back up again. And so there'll be a long pause, or long silence, I was very awkward for me to speak in front of people. I do not any longer have that, because I started practicing speaking in front of people. And but the the coding is what helps me get started doing that. You're making it easy for me to get in front of an audience.
Tim Bourguignon 18:59
Could I put it this way as letting the code speak for itself?
Woody Zuill 19:03
Yeah, I think that's a nice way to say it. So it's really easy if you take a line of code that you type in front of somebody, and all of a sudden, you can see let's just see a gradient on the screen. You see now if we change this variable and calling this method, we can change the gradient to being less drastic. And then we just change that little thing. And there it is. And so as you write the code, you can narrate what it's doing. And that became my way of learning to, to at least more or less comfortably speak in front of people.
Tim Bourguignon 19:33
That's it. That's very interesting. And I would like to segue into into pair programming and then further on mob programming. How did this experience I'm working on the code with people influence your your further developments toward pair programming and mob programming.
Woody Zuill 19:52
Well, so because I worked alone, the first 15 years of me coding, you know, from 1982 or three until At the end of the 90s, I always worked alone, there was no one else to work with. I'd never heard of pair programming, but then it really didn't come about until the late 90s. Nobody was writing about it or talking about it. So once I heard of pair programming, and I'm going to make this pretty blatant here, I used to say when I'd hear something like pair programming, or you know, some other things similar to that, I would think, well, that can't possibly work. But by the time pair programming came along, I had learned that every time I said that can't possibly work, it would turn out I was wrong. So I started changing my attitude. I don't want to be wrong so much, you know. And so I started instead of saying, well, that can't possibly work, I started saying, I'd like to try that, and see how that works. So by the time pair programming came along, I actually I heard about it, I said, I'd like to try that and see how it works. Now you don't get good at something like pair programming, the first time you sit down and do it, it took me a couple years to get good enough at it to feel comfortable working that way. And a few more years, let's say by 2003. So 434 years into doing it. Five years, maybe I start realizing I prefer to work this way, because I get fewer problems. I don't. pair programming itself gave me a way of getting the higher quality into my code, because there's two sets of eyes on the code all the time. When I work alone, my all of the best of me, and the worst of me, gets into everything I do. And when I worked with a pair, the best of both of us gone to everything we do. And the worst of neither of us got into anything we did, because we were always discussing how to get through those problem spots. And so the pair programming became my preferred way to work. And I would say after a year or so, of almost refusing to work without a pair, it became clear to me that I want to always find a pair, I was not always given that opportunity. But that changed the way I thought about coding, I learned a lot more by working with other people than when working alone, I found my ideas. As you share your ideas with someone else, they build up quicker, rather than if you just keep them to yourself. So that was a bonus from that. And at the same time, during that same period I was had been exposed to test driven development. And I found test driven development to be the same kind of a boost to my capabilities, a higher quality, faster output, so to speak, or I would say you know, more rapid turnaround on the things I was doing. So you combine those two things together. And I really prefer to work that way. That was a big boost to me. Now that still was in the early 2000, we're talking 15 years ago still or by 2005 or so it really became clear to me that working with people directly in a Paris situation is really a benefit. And I started experimenting with other kinds of groupings, not just two programmers working together, but also a programmer and a tester working together, or a programmer and a business analyst working together at the same computer. So I would say that, you know, it was a slow thing. But I started realizing there were lots of ways to collaborate. And then a really powerful thing happened to me in 2006, I think I was given the opportunity to more or less take over the management of a project that was failing. And they was in production it had been is making a lot of money for the company that had it. But they were it had countless open bugs, something on the order of 500 open bugs. And they were asking though, what they were hoping to do was to move most of the developers to a new project that will replace the old project. In other words, they would do a rewrite
in a new, you know, a more modern language than it had been written it in. And they wanted somebody to take over managing this thing and to be a developer on the project, to keep it in production and used by our customers until the new project to replace it. They project it that would take maybe two years. So I volunteered to do that. And at the same time, I said as long as I get to do it my own way that I can manage my own way. Because in this particular company, we really weren't allowed or was frowned upon to do pair programming. And it was frowned upon to do test driven development. So I went I took this over with a skeleton crew of people. We start working collaborating very closely together. And many times, we would have just a developer and a tester or developer and a business analyst working together on the same bug at the same time. In three months period of time. We went from having 500 open bugs to having 17 open bugs This was a huge success, in my opinion, maybe you know, not to other people, they would see getting rid of a bunch of bugs as being a success. But these 500, open bugs had been accumulating and gathering over a three year period. And they had, I don't know how many people 15 2030 people working on this project, and they couldn't get rid of the bugs. And here with a very small skeleton crew, we, we got rid of a lot of bugs. And I think a big part of it was by working very closely together. So that influenced me a great deal. And the the success from that gave me a little bit more freedom. And the company wanted to try doing more agile things across the company. And part of what we did during that time, was a sessions where we gather five or six people very similar to what we would now call mob programming. This was still a few years before mob programming became a thing. And we would do refactoring sessions, where we would take some code, and this was in the new version of the project now, because you know this often the problem is that the bugs that we want to get rid of by throwing away the old code, we just find a way to create them and the new code, you know, what are we going to do about that. And so we were having these refactoring sessions, where it'd be five or six people, at least three or four, sitting in a room with one person at the keyboard, and everyone else, collaborating to figure out how to refactor this code to make it better doing something very similar to the modern concept of read by refactoring that our little bell she talks about, where you would just, you're not trying to change the, the, the, let me see what the right words are, we weren't trying to change the behavior of the code, we're trying to make it easier to understand and easier to work on. And so that was some of my first attempts at doing sort of what you might consider a group programming. So that then, you know, after a few years, of, of having those experiences is when my programming surfaced, when we originate that idea, where we would work this way all day, every day, where there'd be five or six people at one computer, or more. And we'd focus on the problems and solutions together and collaborate real time, rather than having meetings to talk about what we would do, we're going to talk about, we're going to work on this code, as a group of people with all the skills and all the knowledge of database expert, a programming expert, a front end expert, a tester, and so on. So that we have like a super brain working on the project, instead of instead of, you know, our own human limited brain, we now have the brain of five or six people combined. And that's a very, very powerful thing.
Tim Bourguignon 27:41
Nowadays, it's still very, very hard to sell the idea of 34567 persons in front of the same computer working on the same thing at the same time. Because we are wired to think that parallelizing right, is going to be more efficient. How was it back then trying to sell this?
Woody Zuill 28:04
Well, I would never actually try to sell this to, you know, managers who think, or even other developers who think that this would be wasteful, we have to understand that there are many different perspectives. Now my perspective is always been our it should say for a long time now has been, if we try things, and we see some good in it, we can try and accentuate that good. Let's learn more about it just tries to do things can be very powerful and useful thing. A lot of manage people who manage software development, they believe differently, that, for example, they kind of believe that, that having, we want to have five or six things getting done. So let's have our people working on five or six different things, each individual doing a different thing or a different part of something that's sort of a belief that, that we can get more done, if we break this work up into, you know, different chunks. And that, though, has some hidden costs. So there's two different very different perspectives. My perspective is that if we separate the people who should be working together, we're going to pay a very high price for coordinating and collaborating or really coordinate work and limiting the amount of collaboration the team is doing. Whereas when we're doing mob programming, we're, we're enhancing that communication, we no longer need to coordinate it. And we are enhancing the collaboration. So is one better than the other? It's very hard to make that judgment. So I don't really believe I can convince anybody of anything. You know, as a kid, we lived on a little kind of a little farm, and we had dogs and stuff and my brother would pick up a stick, you know, he could throw the stick and he'd go fetch and the dog would run to get the stick, and I'd pick up the stick and throw the stick and go fetch and the dog would just sit there. So I don't think I can convince you than a dog to go get a stick, let alone a manager to let programmers work as a group. Now, when I was first learning to do pair programming, it was often hard to convince a manager to let us do pair programming. And I actually worked in places where we were prohibited from doing pair programming. So I take a kind of an opposite point of view, I look for the manager who is already willing to do it. And that's where I like to work. I don't think I can make the change easily in a place where they're already set against it. But I do, I think I want to make this point, you know, there's a quote from Peter Drucker, I'm not sure I can quote it exactly. But it's something like this much of what we do or consider, management actually makes it hard for people to work. And my point of view about this is that managers are trying to make it easy for them to manage. And in so doing, they make it hard for us to do the work. So as a manager, and I've done a lot of management, my career, I've owned a lot of businesses, and I've, I've had management roles and companies, my goal is always to find it, let's find it easy. As a manager, let's find it easy for the people that need to do the work, that's fine, how to make it easy for them to do that work, rather than easy for me to manage that work. When we make it easy for someone to do the work, it usually becomes easier to manage it. Now, to me, a big part of that is making it easy for teams to self organize and self manage. So that it's not like we're delegating those tasks to them. We're just making it possible for them to find the better ways to do this work. And that's a difficult thing. And I think management in general would benefit from from taking that point of view. I hope that kind of answered your question.
Tim Bourguignon 31:45
Yes, it does. Yes, it does. But it's a very hard mental shift. For managers. We've been doing things the same way for years. And now try to to like,
Woody Zuill 31:56
Oh, sure. Well, so. So this is something that a manager has to. And a manager who really wants to do well in their job should be open to hearing many different points of view about how to go about doing this, what we learn in, in management courses in a university might not suit the modern day, universities try to stay up to date, but they what you learn may have been constructed, you know, in a few years back, and it doesn't necessarily apply. You know, in this modern times, there is a famous quote, you know, Max Planck, he was a physicist. He had a saying, and I'm going to paraphrase it quite drastically here. But it was something to this effect. Science Advances one dead scientist at a time. So this is a, this is a now that's not the words he used. But you get the idea. It's, it's that we get stuck in our thinking. And it stays with us to the end of our life. And the newer people coming up are open to the new ideas, until they become too settled in their ideas, we have to be careful to not let that happen to us. We can get the changes. But boy, we will resist the changes. That's just human nature. We got to figure this out.
Tim Bourguignon 33:18
I would like to come back to one comment you made the very beginning of I don't want to go this way. So soon. But now Now is the time. You said after your second contract, where you realize that the first contract he had was actually very ideal conditions or way better conditions? And the second one, yes, that's you then became interested in looking for new ways to make people work together and how people work together? How do you manage this point of view? And the kind of meta level above the the act of doing software for producing software and the producing software itself? I mean, this pendulum going, like the like the manifest says, doing it and helping all those debates. How did you manage to to go back and forth with this? Yes.
Woody Zuill 34:10
Well, so first of all, when I was exposed to those things on that very first contract, I really didn't understand a lot about it, but I it, I was already reading about extreme programming and other things similar. And so I understood where it was coming from. And I started studying it and taking a lot of notes everywhere I went, and trying to convince people to be constantly looking for ways to improve things that's hard to find perfect. And most organizations, they don't spend any time you know, at all, paying attention to how can we improve things. And there's a great paper written by a couple professors at MIT streaming and repenting. The paper is called and I might get it slightly wrong, but it's called. Nobody ever gets credit for solving problems that never happened. This is a brilliant paper with a brilliant concept that the problem is that we often
Well, let me make it a little clearer.
If we prevent problems, that's a really great thing. But we're almost always incentivized to solve problems. So that's where the focus goes. So this paper is really about the idea that if we spend a lot of time improving our capability, so that we can better do our work, we can spend a lot less time doing our work. Most companies or most managers don't catch on to that. And they are proposing, at least as far as I can tell from their paper, and you can get the paper or download it for free. they're proposing that we spend more time improving our capabilities than we do on doing the work. And I kind of buy into that. So yeah, I think I've gotten off track from the original question.
Woody Zuill 35:55
Remember,
Tim Bourguignon 35:58
I was getting to the the pendulum between the doing the work and the observing the work and improving your work?
Woody Zuill 36:05
Yes. Okay. So we're talking about systems now. Right. So the work itself, is being done in some sort of a system, whether we recognize that or not, let's use the example of making a sandwich. If I you know, sound, most people around the world have something like a sandwich, every, every culture has something where you have some kind of a bread thing that holds the food you're going to eat. So in the US, you know, we have sandwiches, you, you got some bread, and usually you buy your bread sliced there. So you take the bread out, then you put the, you know, spread that you're gonna put on there, maybe some anaise or mustard, and you put some lettuce and you put some cheese, you put some meat, and then you put that thing together, you cut it in half, and you eat it. So that's the work is making the sandwich. But there's a hidden system of work. That was the checklist of things I just listed off. But we don't, we don't think of that when we're just making ourselves a sandwich. Because we it's kind of an internalized. But if we were going to make a business of making sandwiches, we would make that checklist so that every time we make a sandwich for a customer, we're consistent about it. So when they come in and ask for the kind of sandwich they like, they get a consistent experience. So we don't work on changing the system of work. While we're doing the work or in the work, we take a step out from that. So an example here the system of work and making that sandwich, including me taking a knife, taking some spread like mayonnaise out of a jar, putting it on the sandwich, spreading it on the bread, then then using the you know, taking the knife back to the jar and kind of scraping it on the edge of the jar to get the excess Manny's back in a jar. And so there's the steps of it. Now we might say, Okay, let's work on this system. And let's replace the jar of mayonnaise and the knife process in the spreading process with a squirt bottle of mayonnaise. So this is now we're working on the system of work. So that has to be done outside of the work itself, because the work is just making the sandwich. Now we're in the system of the work, we have to move out a step further, we have a system of managing the work, that system of managing the work is Who are we going to have here at the right time? And and what system of work? Are they going to be following to make the sandwiches? And how do we replace somebody who is not doing good job, good job. And we so we have to work within the system, the right level of system to make the improvements we want to work. And it's very rare that I see in any organization, that they're working on their problems in the right level. So we not only need to know the level, we also need to know, you know, maybe from the connection point of view, sort of the domain that this that this problem that we're trying to solve exists in. That's another tricky spot. So you know where you can the making a sandwich maybe comes under the simple or obvious domain, where Yes, just a checklist, you know, you learn the right amounts to put on you follow the rules, it's pretty easy to do, the software development falls under the what they called a complex domain. And you don't get to just follow a checklist. As a matter of fact, if you input x in the making of a sandwich, you'll always get why the same sandwich out of it. But when you do this with software development every time, you're going to get a different result. So we need to start understanding the domain that we're in, we need to know the system, the level of the system we need to work within. And we need to know the domain that we're working on. There's other things we need to know as well. We need to understand our beliefs. This is really a tricky one. our beliefs are based on a very tiny bit of information. And so, you know, all of all the knowledge of the universe is way more than any human can know is the unknowable. But we get exposed to some things and that's the experiences we have in life and in our work. And but we're exposed those things, but we only internalize our can bring into ourselves a very tiny bit of that, that's very sliver of all the knowledge and even if all of our experience and we base end up basing our beliefs on this stuff we need so in other words, what, what our beliefs give us is the ability to say, well, that's obvious. That's common sense. Well, nothing's really obvious. And nothing's really common sense across all people. Each, each person looks at things in a different way. Each culture looks at things in a different way, each company looks at things in a different way. Boy, we're in trouble. And now I've gotten off track again. So
Tim Bourguignon 40:32
bring me back. This is very fine that this really just see what you're all saying. I would like to give one example. At a conference Recently, there was a there was a video game, we're playing a Xbox game, I think was called overcooked, it was a basically a caveman simulation of a kitchen with four cooks. Cooking at the same time, so getting tomatoes out of out of Kray creed, and then bring it to me to to, to the cutting pan, and cutting the coming tomatoes, bringing them in the in the in the overnight etc. And what we realized after one round of 10 minutes of going absolutely terrible, and not being able to prepare one dish is that we were not able to work in the system and on the system at the same time and understand how to do the cooking and observe the workflow at the same time. And this has been, for me personally, a very hard battle to fight between being in the team and working with a team and improving technical practices. And at the same time stepping away and observing how the meta level is working, how the system is behaving, and helping improve the system at the same time. It does make sense.
Woody Zuill 41:48
Yes, yes, very much so. So I can address this a little bit. So I need to put a disclaimer in here. Almost everything I share is from my own biased and limited point of view. So I never claimed that what I'm talking about is the truth or the right way. It's just my limited way of you know, from my own beliefs and experiences and biases. So everybody out there who's listening to this, please take that into account. Here's the thing. You know, when I was in high school, I was on the track team track, you know, and in the US, you know, you're running, you're jumping, different events like that. So you can have in those days, a two mile you'll have a one mile you have a half mile 100 yard dash you have some relays, a long jump and so on. So I happen to be my my main event was the two mile you run for two miles. And a really great two miler runs two miles in about eight minutes. In high school level, in those days, maybe nine or a few more minutes. That world class high schoolers were better than that. But then here was me, I could run two miles, maybe in about 11 minutes, which so I wasn't particularly fast guy on the team, I usually ran what they consider the B team, there's a team, that's the top people in the B team is, is the less capable people. And so I was out running a race one day. And I came around to win it. And I had my my logic in trying to run the race was if I don't ever let anybody past me if I can get ahead right at the beginning, and never let anybody past me, I can win the race. And of course, that makes a lot of sense. And that's what I did. Every time somebody tried to pass me I'd run a little faster, you know, fight them off, so to speak. And I won the race. And I was expecting my coach to come over afterwards say great you were in you won the race. But he didn't. What he did is he came over and said, You know, I said hey, I won. He said, Yeah, you did. But your time was terrible. And I said, well, but I won the race. He said, Yeah. But what's important in your records is, is is how fast you are. Not that you won this race, you won that race. And this is what he told me the last eighth of a mile the last half lap that you ran, you ran really fast. Nobody they could you were dropping them back. They couldn't even keep up with you. You were getting out you were they were they were basically standing still, as you ran that last little bit. He said that's a problem. And I immediately understood, I didn't pace myself through the race. I just merely was fighting off competitors that weren't particularly even as good as I was. And maybe they gave up heart too soon. This to me, this taught me a lesson I was maybe 16. This taught me the lesson of what a coach is for. The coach can see things that you can't see or understand yourself. They're outside of the race, and they're paying attention to what's going on. Their observations can be very useful to you. When he came up to me and he told me that I realized immediately I need to learn how to pace myself. Now he could give me guidance on that. But that observation was very valuable. And I think that's the thing. If we're going to help our teams get better as a coach or as a technical LEED or whatever, we have to be standing outside and watching. Now if we're in the middle of the work, we still need to back back out of it sometimes. Because otherwise, we don't have enough, you know, bandwidth in our brains to take in and watch everything else that's going on. We need to have that that's a, that's a thing for a coach to understand or the thing for a tech leader or agile guide, to understand, we need to be really observant, we need to be paying attention. And we need to learn about what to pay attention to. My coach knew pacing is important. And he watched me as I ran that last, the too fast of an eighth of a mile. He knew I did, I was using the energy I should have used through the rest of the race. This is an important thing. So how do we do it? Well, I can't say this doesn't apply to every situation. But boy, we need to be aware, we need to pay attention. My dad used to say something like that to me, Oh, good things happen to people who pay attention. That's a valuable little snippet to understand. I would say for myself that's paid off.
Tim Bourguignon 46:04
I think he has as well. Yeah, that's true. That's true. Unfortunately, the time book is closing on us. I would like to have to ask you one last question. What should a candidate have to be welcomed on? When if your team's
Woody Zuill 46:24
Oh, you know, this is a, this is a wonderful thing I've been watching for a long time. I'm, I think we're very bad at judging somebody up front to figure out if they're going to work well on our team. And then later, we got to live with the results. When you hire somebody, you're going to get the best of them. And you're going to get the worst of them. And you can't know all that just from a simple interviews and a few meetings with them. But what I'm looking for is the ability to, to say I don't know, the ability to ask questions, the ability to listen to the answers. So in the interview processes that I've had, when I'm hiring people, those are some of the scenarios that I'm putting forward, I'm giving them opportunities to ask those questions. I even used to have exercises that they couldn't solve the exercise with the information given, they, as soon as they realized, Oh, I don't have all the information I need. I want them to ask me about that. And so you know, this is I would make these, you know, exercises that actually to specifically see if they, they were willing to admit during an interview, I don't really know about that thing. And stuff like that. So I think being able to work well with others is important. That is a skill we can learn. Being willing to listen, that's a skill we can learn or being able to listen. But being willing to is something we can bring to it. Teamwork is not something we get from a team, you know, it's something that you bring to the team, your ability to work with them as a team, that that's those are things I'm looking for.
Tim Bourguignon 48:04
Fantastic. Thank you very much. Very great advice.
Woody Zuill 48:07
Well, please don't take it as advice. That's just that's just an opinion.
Tim Bourguignon 48:11
Okay, so thank you for your opinion. Um, there you go. What is on your plate right now? What do you have coming up soon in the next weeks or months?
Woody Zuill 48:22
Well, so off the top of my head, I'm pretty sure I'm going to be doing a workshop in. in Bordeaux, France. I think October 7, I'm going to be at a conference in Lisbon, agile, Portugal, I think it's called. Boy, I wish I had these things written down in front of me. That's September 30. October 1. I have a few other things coming up. I don't know if this will come out soon enough. I'll be at agile Brazil, in early in September. And then, yeah, I got a couple other workshops. I'll be at the go to Berlin. And I'll be doing a workshop, a mob programming workshop there. I'm always looking for opportunities as well. As I travel. I try to group as many internal workshops for companies. So if there's anybody across Europe during that time, I'll be in Sweden, France, Portugal, I think I'll be in Germany, and maybe Copenhagen. So I'm always looking for opportunities. That'd be great. Not to sell too much here. This is just a pod.
Tim Bourguignon 49:32
Don't worry, that's fine, that's fine. And where would be the right place to get in contact with you either to to cut you the discussion or to take you up on the offer of doing something?
Woody Zuill 49:44
Well, the easiest thing you can send me an email and I'm woody at Woody's old.com you can also just send me a note on Twitter or LinkedIn. And usually I'm paying attention to those things. There's too much social media out there nowadays. So So I try to at least pay attention to a couple of them. And yeah, and I would love to hear from anybody if there's any way I can help. My main focus is mob programming. That's the space, I really feel I bring value. I have some other things that I do, but and coaching and so on, but I'd love to help your teams learn about mob programming if they want to try it.
Tim Bourguignon 50:21
Fantastic. Woody, thank you very much. I want to be respectful of your time box since you are at a conference right now. And you took an hour to to speak to us. in in in the middle of your hallway track and networking. So thank you very much for all those opinions and and your fantastic story. And I hope we can we can continue this someday. Yeah, that would be fun.
Woody Zuill 50:43
Well, I I'll be happy to come back anytime. And there's sure that I can. I will forget everything we talked about, and I'll be able to repeat everything.
Tim Bourguignon 50:52
Sounds like a plan. Woody, thank you very much. And this has been developer's journey. We'll see each other next week. Bye 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 www dot 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