#232 Kevin Trethewey on his extreme programming journey

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Kevin Trethewey 0:00
I think that the number one superpower for a developer is introspection. And I think it's something that can be worked on explicitly as well. It's kind of a meta skill, but it's definitely something that is one of the things that is a big distinction for me on really good software engineers and developers, and ones that aren't so good is an ability to introspect. And there's levels to that right there is I just write wrote that line of code. Is that the best line of code for for what I know right now, I just had that meeting. How did that meeting go? Could I have done differently, I just delivered that product. I just lived another year I you know, and so for me, I'm always looking for opportunities to reflect and improve and to teach others to do that as well. And I think fortunately, I sort of have that in my genetic code somewhere. I come from a very, and this may be a sensitive topic, so but I'll try and be sensitive with it is, I come from a very religious family. And they're very sort of faith based in their belief system. And I was born without a faith gland is the way I like to describe it is I'm just not capable of believing something purely because somebody else said, it's got to make sense to me, it's got to figure it out. And so I both have a drive to figure things out. And then to reflect afterwards on, you know, what did I actually figure out is this truth, and I think that's something that I've I've applied at various levels of my life and has served me well. Hello,

Tim Bourguignon 1:27
and welcome to developer's journey to podcast bringing you the making up stories of successful software developers to help you on your upcoming journey. I'm your host team building your own this episode 232. I receive Kevin three few weeks. Kevin has been in the software industry since 1998. And currently works as a chief explorer at explore AI. Throughout his career, he has had the opportunity to work in and observe projects, teams and organizations investigating different environments, and seeing different levels of success amongst them. And through those experiences, he has grown an understanding of the values, principles and practices that are required for healthy systems, as well as gaining deep experience in how to bring this into organizations. And expect that's what he's doing as its chief explore. Kevin, welcome to the afternoon.

Kevin Trethewey 2:20
Thanks, Tim. Thanks for having me on the show. I'm looking forward to the conversation,

Tim Bourguignon 2:24
though. It's my pleasure to have you on this warm day in Germany and cold day in South Africa. And you might hear the fireplace cracking behind you at some point.

Kevin Trethewey 2:32
Yeah, apologies. And I'll move away if it gets too noisy. But I do have a nice warm fire on my back, which is great, because it's pretty cold here today.

Tim Bourguignon 2:41
That's quite alright. But you should move in case it becomes too warm for you. But I guess avoid listeners hurt hearing a fire plays crack in the background adds up to this story. Exactly. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew, and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. Kevin, as you know, the show exists to help listeners understand what your story looked like and imagine how to shape their own future. So as as usual on the show, let's go back to your beginnings. Where would you place to start if you were deaf during

Kevin Trethewey 3:44
the start of my journey would probably be before the start of my dev journey. So I wasn't sort of kid that was always super curious and trying to understand everything and anything that my parents owned that could be opened by a screwdriver was. And so if you're a parent now and you've got a kid that is constantly leaving the trail of destroyed electronics behind them, then maybe you've got a dev on your hand. But I grew up in a family where you know, my parents were not office workers. My dad was an electrician. My mom was a nursery school teacher and wasn't really exposed to computers or anything like that. In fact, when I left school, I didn't even know how to turn on a computer. And then programming sort of found me as I went through. I started I went to a technical high school and I studied to be an electrician. But the problem with my brain is the moment things become repetitive if I know how to do something. It's just boring very quickly to me. And so I got bored with that pretty quickly and started becoming a I was a waiter for a while. And then there was a coding bootcamp, one of the sort of early prototypes of those back in the 90s. And they were teaching programmers because they needed a lot of people to get into COBOL for the y2k bug, and this was 98 So probably just missed out on the money that everybody made trying to solve their problem but you I went and did an aptitude tests having no computer and programming background, they had an eight hour aptitude test. And if you did really well, in the aptitude test, then they gave you a bursary to study a six month programming course. And I did well, in the aptitude test, I did well in the course. And from there, I started my dev journey, I found a company that allowed me to work on hardware and software and got going and over the first few years of that, hardware became, for me quite repetitive as well. But software, the limit was always my own brain. And there was always a better way to do something and always something new coming out. And anytime something got repetitive, I could just automate it away and get to another level. And so that's that just became my complete passion. I, I didn't have a TV I programmed I got paid to program, which I was super excited about, because I wouldn't be I would have been doing it anyway. And when I got home, I had just programmed some more. And the other thing that really excited about me is I didn't have to talk to people. And so that was just the perfect thing for me. And it took me about 10 years to realize, actually that the real big problems are actually with people and outside computers, but I got there eventually. But for the first 10 years of my life, it was just really coding and loving it.

Tim Bourguignon 6:16
Wow, at what point did the passion really kick in since since programming found you more than you found it, when did it's really become this, wow, I need to do this.

Kevin Trethewey 6:31
I think the moment I executed my first piece of code, you know, to be able to write something down and then have it come to life by running was just a magical thing to me. And the fact that I could sort of, you know, the limit of it was my own brain, I think one of the things at the time, because I had a very old motorbike and I was always frustrated with the motorbike because the limit of the motorbike was the you know, it was a small engine, and it couldn't go really fast. And I was always writing the you know, the motorbikes limit, not mine. And then programming just seemed to be something where I was the limiting factor. And you know that that got exciting to me. And then with that first job I was, you know, I was writing code to print out barcodes on printers, it was a warehouse logistics company. And so there was this interplay between the code and the physical and, you know, being able to figure out where the forklift must go and pull stuff off the shelves. And you know, just just a fascinating problem to me and to my brain. And so that got really, really interesting to me.

Tim Bourguignon 7:31
That that's interesting. The this this link to reality was something that was very, very pregnant to me as well, I started in my career working from engineering for big MRI style machines, and really making the machine move, understanding that, hey, if I execute this command, this happened in the real world was really a factor in hooking me in did you need that? Did you need this visual response or this, this real life connection? Back then,

Kevin Trethewey 7:57
in the beginning, yes. And a lot of the work I did in the beginning was was that way, but I then fell in love with back end development a bit more and modeling things in code, I've always been pretty good at living in my head and modeling things in my head, and then to be able to take that out of my head and get it to run in a computer. You sort of mind meld with your code. And then And so over time, I graduated more to two domain modeling and back end engineering and that sort of thing. And then how it actually worked out for me is I got that first job, because I'd been through that boot camp, and that boot camp had a good reputation in the industry. And I worked with a colleague at that first job. And then he got headhunted to an r&d company. And in that r&d company, you know, it was really, you know, computer scientists, really smart people, very qualified people. And he was very qualified as well. But then when they were looking to hire more inexperienced programmers, because I had worked with him, he knew I could code. And he recommended me and I got into his recommendation. And then I got to work with people who very well, 30 Sorry. So the thing you should know about me is I'm and I've actually learned this a little bit later in life and happened particularly when I started working remote is that I have some sort of ADHD thing where I'm a bit timeline and my brain pings all over the place. And that can be a real strength in programming, because I can also do the hyperfocus thing, but I've had to learn little tips and tricks along the way. And that one you heard just now is that my computer reading out the time to me, and so I've got a little bash script that reads out the time every half an hour and that way I'm, I'm only ever five minutes late for meetings and sort of. And so yeah, it's probably jumping a little bit too far ahead on the journey, but I think that's something that's actually always been there for me is, you know, my brain is probably not neurotypical and in programming that's become a strength because I'm super curious. I'm able to focus for very long times and I've learned little hacks along the way to kind of use it to my advantage. I do need to changes take the little script off, because it will interrupt us again in in half an hour's time. You're done. All right. All right. Where was I? Oh, yeah, so so so I joined an r&d company and should never have got in there wasn't qualified to be the guardian on a recommendation. And that's been true for my career pretty much ever since is that it's grown and developed through the network of people I know, rather than through the recruitment agents and CVI, I don't have you know, an academic quality, I never went to university, either. The phrase I sometimes use is, you know, I don't have a black belt in karate, I've got a fan belt in street fighting. So I came up by by doing it and trying it and figuring it out and failing and doing it again. And in this r&d company, they had a whole lot of little experimental projects across various different industries, they'd been quite successful in a few of the things they did, and they were taking the money that some of that revenue and investing it into r&d. And so that's where I worked for five years, and really cut my teeth on a vast range of different projects and different technologies and experimental work. And I think that was very, very formative for me. And that was probably my university, in a sense, when it comes to to Dev is working with people that really knew what they were doing and were available to to mentor me and helped me grow.

Tim Bourguignon 11:12
Since this is still in the first 10 year time frame that you mentioned before, how was your relationship with people at that time?

Kevin Trethewey 12:08
Yeah, it's a good question. So I was happiest when I could have my head down and coding. But you know, it's nice to have some people around that when you're stuck, they can advise you and, and show you the right approach. So I got into programming, so that I didn't have to talk to people. And but the thing that really has always driven me is trying to find the most important problem and solve it. And so in the beginning, the most important problem was, well, how do you do this piece of syntax? How would you what pattern would you use? Yeah, how would you model this and around about 2004. So I'm sitting in in Johannesburg in South Africa. And so there was a Danish guy who'd worked on an XP team, and he had fallen in love with the South African girl and moved to South Africa. And he was quite keen on starting up an XP team in South Africa. As far as I know, it was probably the first XP team. And so I started working with him. And he is the one sort of ignited my interest in test driven development and pair programming. And so that was really aware, I then started to see the value of two brains apply to a problem instead of one. And that started my journey on Well, the biggest problem to solve is maybe around technique, not around language, because now I had a bit of a handle on language. And then it was around pairing. And then I got to the point where I was looking at the whole team and what they were doing and, and I realized that actually, for me to get slightly better at TDD, things would get slightly better. But to help somebody else get good at TDD would be a massive improvement for the team. And sort of in that spirit of always trying to find the bigger problem to solve that started to draw me out of the computer kicking and screaming at first. And I think, you know, to be perfectly honest, one of the things there was probably that it paid better, you know, to become a team lead and start to do that. And that was probably a part of the incentive of getting me out of my box a little bit, but then fell in love with, you know, how to build software from from a larger perspective. And that journey has sort of still continuing on today and to to, you know, seeing the bigger picture organizational design, and a bunch of other things that I've done on my journey.

Tim Bourguignon 14:13
A couple of things I want to impact, which which I started with, it's rebounding that you said, kicking and screaming You You You You fought against this, do you did you really fight? Did you refuse jobs? Did you really say no, I want to stick to working with this computer? Well, I'm

Kevin Trethewey 14:26
very much an introvert. And so I'm probably was a shy introvert. And I remember the first time I went to a community meeting, I sat right in the back row, somebody was doing a presentation and I remember distinctly, I thought of a question to ask. And I started, you know, my heart started beating, I started sweating, I sunk down into the chair, just the fact that even thought of a question kind of terrified me. And I made the decision at that point in time to work on that and push myself on that. And I said, Yeah, my goal is to one day, see a talk in front of a community and so I sort of went on that journey and got involved with that community and helped organizing in the background and eventually got to the point where I could introduce the speaker. And then I got to the point where I could give a bit of a talk myself and, you know, just kept improving, kept getting better at these things, because I could see that it would benefit me if I did. So sort of just pushing me outside of my comfort zone. And, you know, it led to huge opportunities, I actually got an opportunity to speak at agile 2015 on the spine model, which is one of the models that has emerged through the work that I've done and collaborated on other people with an OSI model is something we should probably talk about at some point as well, because it's, it's become quite central to my approach, and would never have been if I sort of just didn't push myself out of my comfort zone on that. And I've sort of scratched that itch. And these days, I don't do conference talks anymore. And you know, it's not something that's that maybe one day, I'll get back to it. But for me at the moment, I've got a nice, big, meaty challenge in the work that I'm doing. And that's my focus. Now,

Tim Bourguignon 16:00
I totally understand that kind of the same place before we come to the spine model. And that will be a very nice place to go. I wanted to ask you something you presented yourself, when you are not yourself, your employment at this new company will restate your wasted for five years saying, Well, I wasn't qualified. And actually I shouldn't have been hired, at which point did this feeling go away?

Kevin Trethewey 16:21
I mean, in part, it never has. I mean, it's something that's always in the back of my mind, particularly when I meet people who are heavily qualified at what they do. But I think it's, it went away in just working with other people and seeing that, you know, I could keep up and I, I can learn very quickly if I'm paying attention, and just through paying attention and working on my own skills and improving and I find myself able to catch up with people. And then because I keep pushing and keep learning often, you know, get past what, what they're able to do. And so I enjoy that challenge. And I've done that now for 22 years. And, you know, there's days when I think I haven't learned anything, but you know, then then when I work with some people who are fairly new to the industry, I can see okay, well, you know, there's a there's a couple of things that I have learned along the way. But yeah, I don't think that feeling ever completely goes away, particularly when I'm bad at something, which you know, is always going to be true. And it's the first time you do something and then there's always a few moments of doubting yourself. And I guess these days now I'm 45 I'm starting to go well, am I too old to do this as opposed to Am I qualified enough. So there's always something that your head will start to that inner voice comes back up and you just got to you know, find a way to break it into smaller pieces, get some momentum, get a feedback loop going and that's that's worked pretty well over my career and I've got sort of a general rule that if it scares me, I should do it and and I've sort of ordered myself if it scares you, you got to do it. And I haven't given my permit self permission to say no and for some some reason that works for me

Tim Bourguignon 17:56
disciplines very a very deliberate approach toward toward learning toward finding your I don't want to call it flows but but your your weaknesses and really tackling them observing them making plans, how I could change them, do I want to etcetera, would you would you say your your deliberateness in this regard?

Kevin Trethewey 18:17
I think that the number one superpower for a developer is introspection. And I think it's something that can be worked on explicitly as well. It's kind of a meta skill, but it's definitely something that is one of the things that is a big distinction for me on really good software engineers and developers and ones that aren't so good is an ability to introspect. And there's levels to that, right. There's, I just write wrote that line of code. Is it the best line of code for for what I know right now, I just had that meeting. How did that meeting go? Could I have done differently, I just delivered that product. I just lived another year I you know, and so for me, I'm always looking for opportunities to reflect and improve and to teach others to do that as well. And I think fortunately, I sort of have that in my genetic code somewhere. I come from a very, and this may be a sensitive topic. So but I'll try and be sensitive with it is, I come from a very religious family. And they're very sort of faith based in their belief system. And I was born without a faith gland is the way I like to describe it is I'm just not capable of believing something purely because somebody else said, it's got to make sense to me, it's got to figure it out. And so I both have a drive to figure things out and then to reflect afterwards on you know, what did I actually figure out is this truth and I think that's something that I've I've applied at various levels of my life and has served me well.

Tim Bourguignon 19:43
And I see how that would serve you, as a team lead as an engineering leader, really helping others reflect on multiple levels of technology, processes, interactions, communication and really see the whole picture see how things interact. and really getting to the next level?

Kevin Trethewey 20:04
Absolutely, most of the problems we have is because people aren't talking to each other about the work. That's, yeah, that's, that's what I found to be true. And so a lot of what I do is just getting people talking to each other, and then talking about the work. And that seems to help. And if we can convert that into some useful actions and changes, and, you know, one of the things that I think we've gone wrong in software development is that we've separated out the doing of the development from the process with which it's done. And I think that's a mistake. And I think you mentioned earlier that you're an ex peer, and I think that's something that we got right in the XP world is that these are not different things. And so that's very much core to my approach, as well, as is how we do the work and how we break up the work and how we deliver the work. That's still a software development problem. It's still an engineering problem. And it's not something we should outsource. Absolutely,

Tim Bourguignon 20:56
I'm really you're fighting with my engineering teams right now, to have the product not be something outside, really, it's part of the development work, talking to your customers, understanding them building empathy, it's all part of it, it's not something you can and should outsource it is it is your job as a team.

Kevin Trethewey 21:19
Well, it's the problem with with people who are good at software development and sort of get into it is we tend to fall in love with symbols and objects and models. And what we're building is to solve a real world problem. And so if you can help people fall in love with the problem, and you tend to get a much better result. And where I'm working now is it's a data science focused company. And it's been fascinating to watch that a good data scientist naturally falls in love with the problem. And it's sort of just baked into the way they approach things. And it's you can often tell the difference between a data scientist and a data engineer, just sort of, broadly speaking, as the data scientist is obsessing over, you know, what is the problem? Where's the customer at? And the engineer is already looking at the tech stack. And, like, I understand enough now, can I start programming? And bridging that gap is an interesting one.

Tim Bourguignon 22:09
How do you make someone fall in love with the problem, if they're not already?

Kevin Trethewey 22:15
Well, you can't make people do anything. So and that's sort of one of my my core beliefs about software development is you can't teach it to anybody, but you have to teach it to yourself. And so you can create an environment in which people can teach themselves. And that can happen. And I think it's the same with the problem is, if you design your organization in a way that the software engineers aren't interacting with the customer and the problem, then then it's going to be very hard to get them to fall in love with it. But if you can immerse them in that a little bit, and really get some empathy going, and some understanding of what they're doing, and why it really matters, then that can emerge out of it. So I definitely don't think you can force it. And that's true for all sorts of social practices and software development, you need to create an environment in which it works. And software engineers like it when it works. And so getting early feedback, and immersing people in that is really important.

Tim Bourguignon 23:10
I saw on your webpage that you have an hypothesis page, and I would have talked about that, at some point. But before we get there, there's there's one hypothesis that I've been working with for for four years now, which is the it takes a lot builds on the metaphor of the aquarium. So when when you're when you're you have a bunch of fish in an aquarium and they're and they're dying, it's not a problem with fish. It's a problem with the aquarium, and really trying to see the problems I face in organization. As problems of the aquarium. The only variables I allow myself to work with at first is the user environment variables is the system and how the system's imprint, thinking methods, imprints, thinking processes, imprints, constraints on the people and try to work only with that first and see how that goes. And then only then if I have the feeling I reached a dead end. Maybe consider how people are because we're still humans and individuals. But but try to avoid thinking about this as long as I can. How would you react about this? Yeah.

Kevin Trethewey 24:11
100% agree. And, you know, maybe a little bit of an anthropological expedition there is one of the ways I like to learn if I want to learn something is to, to find the people that did the original work and the original thinking on it. And so you know, if I'm going to learn Scrum, I'm not going to Google Scrum and read the first page of links and as well who, who came up with the word Scrum? And where did they get it from? And if you go down that road, you actually end up with the new new product development game. And the NACA and the work he did on knowledge management, which is a brilliant explanation of the underlying principles of Scrum. But if you take what you're saying, and you look at you know, what is the main practice we do there? It's retrospectives. The the lady who wrote the book on retrospectives is Esther Derby got a lot of experience in them. She's one of the people who brought it kind of into our industry. And if you look at who her mentor was in where she was getting ideas from that Virginia Satir. And Virginia Satir was one of the first psychologists that said, when there's a particular person that's experiencing dysfunction, or addiction or some sort of problems, you can't treat the individual, you have to treat the system, you have to treat the whole family. And so when people came to her with issues, she was one of the first two psychologists to say, well, let's let's look at the entire family system, let's look at the system around people and treat the system so that then the person will be able to improve. And that's really what retrospectives come from is that thinking of the problem is not let's find the person with matches and take away the matches. It's like, what does the system look like? And how do we improve the system. And I think an aquarium is a great example of that a great example of a system and I kept reef aquarium for for a long time. And I used to love coming home and watching it, it was sort of my TV, and it's very much that thing is, the whole thing is in balance. And if something is not working, there's a balance off somewhere. And you know, there's there's a saying then in the sea aquariums that nothing good happens quick. I think there's some sort of analogy, there are two teams, right is creating a long term stable successful system can be a, a slow process of just kind of shaping and moving the rough edges and creating a system in which people can succeed.

Tim Bourguignon 26:26
You have something to remind yourself in in thinking this way. And all we're thinking about the system and not thinking about something else was its natural now?

Kevin Trethewey 26:35
No, no, I find new ways to fail all the time. But the spine model is something that sort of emerged out of that as well,

Tim Bourguignon 26:42
let's do this by modeling was probably the right time at the right place now.

Kevin Trethewey 26:45
So if you look at XP, the the way XP is structured is extreme programming is one of those things that's beautifully named, if you understand why it was called that. But from outside, it seems like the wrong name. But Kent Beck's idea. And Ken Beck's really one of my role models is let's look at what we value, what should we value in an environment. And then if we know what we value, we look to optimize for those things. And so in extreme programming, it was communication, respect, trust, feedback, simplicity. And so Ken said, if if we turn those up to the extreme, we'll probably end up with a good aquarium. And then, so He then looked at, well, what are some good principles that would get us more of that. And so there's some primary principles. And second, it was primary practices and secretary for me, it goes values, principles, practices, as you already said, like if you know what you're optimizing for, here are some principles that, in principle will get you more of those things. And then here are some practices. If you value communication, then pair programming, test driven development for feedback, you know, that that's how I got it is those values, principles, practices. So over time, in my journey, you know, I started helping other developers, I started helping teams, teams of teams became a bit of a technical coach, find a bit of a niche with with companies that were sort of pivoting into scrum away from waterfall, but didn't really understand the technical practices that are required in order to deliver iteratively and become a nation, I actually started to build a company around that. And I was coaching with Daniel roux, a good friend of mine, brilliant mind and a great coach. And we started teaching on this sort of values, principles, practices model to get people to think like that, because we've both experienced, and we kept getting into these conversations around JIRA. And you know, well, yes, we're agile, because we're using JIRA. You've heard that. And other frustration, we said no, no, that that's, that's a tools conversation, like that's even further down below. And so we shouldn't talk about tools, let's first talk about the practices that we're doing. And if we, if we can agree on the practices, then we can come down to the tools and we can figure out how to use the tools properly. But before we can understand the practices, we have to get into the principles and decide and up to values and Assata started becoming an order of things and, and around about the same time in nonviolent communication as becoming quite known in sort of areas that we were working. And nonviolent communication is really about starting with needs. And it just seemed to fit there at the top right is, the first thing we should start out with with a new team is what is the purpose of the team? Why are you here? But how do you know that you're fit for purpose? So that's the questions you're asking earlier about falling in love with the problem? That's, that's the question. And if you can get people aligned at that, it becomes far easier to have or what should we value? What are the principles maintenance tools and, and that's where the sort of the metaphor of the spine comes in is to start at the top and the line at the top and come down, you get a nice aligned spine. Whereas if you start at the bottom, you're always going to be you know, appealing to a higher power or working with things that aren't completely aligned. And so, that model emerged out of the coaching work that we were done, were doing and it's become quite central. I mean, we use it all the place now and explore AI if a new team is Starting up, or if we're starting a new particular process, the first thing we do is create a spine map, every team that I work with, they've got an architectural spine. This is the need we have for our architecture. This is what we're optimizing for in our architecture. And particularly when you're starting out in a new environment, that's a huge asset to have a conversation around when a new person joins a team to be able to see okay, well, this is this is the shape of what we're doing. And so that's that's quite a central model to what I'm doing. And where it's particularly useful is to disagree usefully. Because if you're having a disagreement, the the optimal way to disagree is to find a point of agreement first. And if you can start by finding something to agree on, you can then get into the disagreement and get a useful resolution. And that's where the spot model is super useful to me is, you know, should we use this tool or that tool? What I don't know, what's, what's the practice? What's the principle? What's the need? Our Yes, we all agree that we really want as much of this thing as possible, well, then let's come down and see how we could do that. And, and that often is a way of unlocking those intractable problems. And so that's, that's a model that I've kind of internalized over time, and is quite central, but I forget to use it and fall into these traps as well. Because at the end of the day, I am a developer.

Tim Bourguignon 31:18
One thing I listeners couldn't see but but I observed when you were talking about it, you were really visual in your in your explanation, going up and up and up and down and down and down with your hand and just making the moves and say, Well, if we disagree at that level, then we go and level up we hand and say it looks very visual, logical and and almost graspable? Is this the reaction that you get from people who are new to this and whom you introduced the spine? Well,

Kevin Trethewey 31:48
the one thing I miss most now that I'm working remote as a whiteboard, I think the most useful software developer tool that's ever been invented is a whiteboard. So I am a very visual person, and I like drawing maps and pictures. But what I have found with this model is that when you talk to very technical people, and you start talking about needs and values, they sort of switch off and they say, Well, you know, let me know when we're going to talk about the real work. And then when you get down to the practices and tools, very strategic, big picture, people start switching off and saying, Well, that's detail issues, you know, that's, that's going too far down the rabbit hole. And what I love about this model is that it connects right is the needs all the way down to the tools you can, you can take everybody on the journey up and down that and I think that's, that's a very valuable thing to get the whole room talking to each other and connecting. And I don't think we talked about principles enough, it was one of the things that I learned along my journey is, I got to the point, after six or seven years were the fact that things are always changing, there's always a new version, we're starting to become a bit of a burden, I learned quite a wide field of things. And now, you know, had to learn the next version of SQL and the next version of C sharp and the next and the next. And I thought, Well, how long can I keep this up for? And that's the point at which I started thinking, Well, you know, maybe I shouldn't learn the new syntax, maybe I should get a little bit deeper. And so instead of learning SQL, I went and learnt relational databases and sort of like get to the principles and the actual fundamentals behind it, because the rate of change is much slower there. And if you understand the principles behind something, you can learn the new things very quickly, because they just sort of fall into place and make sense. And so that's one of the ways which I both was able to learn more and learn less was to to get to more of the fundamental level of things. And so that's definitely quite central to my approach as well is to to really understand the principles and the science behind what I'm doing as a way of minimizing the surface area to learn, but then also to be able to extrapolate in many different directions using those principles. And

Tim Bourguignon 33:49
yeah, it all helps as well to, to to grasp what the whole company is doing. I mean, you're now at an executive level in your in your work. And so you must have many teams doing different things. And if you have to be in the weeds of everything to understand what you're doing, you will, you will never find the light. So you have to understand things that principle level, and then be able to abstract away the details and say, Okay, now I see where you're going with this and still be able to add value, which is always missing.

Kevin Trethewey 34:17
And as a leader in knowledge and software field, it's far more effective to hold people accountable at a principle level than at a practice level. I remember once I went into a bank that I was working at, and there were three people working together and if you just mentioned the word Scrum, they would kind of spit on the floor and look at you dirty. And what I realized was happening was theirs is that the company decided they were going to do Scrum, and therefore every single team had to have a board and they had to everyday stand up in front of the board and tell each other what they did. This was three people working on one computer and one problem they all knew exactly what they were doing all day every day. And they had to get up and stand next to a board and tell each other about it and it was a complete farce but they would get into trouble if they didn't do Oh, gosh, and you get into these ridiculous situations not because you have stupid managers, the stunning I found in my coaching as you see stupid things happening and you assume there must be a stupid person somewhere but you look around and there's very smart people making the best decisions they can they just are sitting with a limited set of data are locally optimizing, or making a decision that just doesn't make sense in all contexts. So if that person had said, you must, at least every day know what is happening in your team, and where the work is, and where things are blocked, they would have said, Good, yeah, we can do that. We've done that. And the manager could have gone and said, Are you doing that? And they could have said, Yes, but instead, the rule was put in at the practice level. And it just didn't allow for any local variation or misstep. So I'm very always trying to be sort of aware of that, and putting in the accountability at a principal level, so that people can then figure out because it's the people who are doing the work that are going to know best how to do it. And I think, if you look at I believe in the spine model, the rate of change increases as you go down. Which means that a tool level is where the highest rate of change should be, we should be constantly modifying our tools and changing them and scripting things out. And, and particularly in large organizations, they almost inverted and they said, Well, we're going to have one tool, we're going to lock it down, nobody can change it, because that's dangerous. And that's from my mind, it's not the right approach, I

Tim Bourguignon 36:22
want to be too extreme. When when you're when you describe this team, working three people on the same computer, it sounds like a very, very intimate autonomous gelling team. And I could almost hear them say, well, but we're aligned at the value level, the rest of the rest is details. So how do you help teams realize that, yes, you have to be aligned at the value level, but you also have to express your principles. And you also have to write down some of the practices that might be important. And and maybe it's important to align on the tools as well, even though we are extremely aligned at the top level already. And the rest could seem like common sense for the whole the whole team.

Kevin Trethewey 37:04
Yeah, so one of the principles that I have is that all practices are training wheels, there is no practice that you can't, you know, as you get up to a certain level, take those training wheels off and not need them anymore. And then within that, there's sort of two or three things that I think is really important for a team to do. The one is visualize your work, make it visible, because if it's not visible, you can't really understand what's happening with it. And the other is some sort of retrospective on a cadence, have a reflection 00. And so I think with a team that's working, and the other thing is that teams are item potent, right is any change to a team, and you have a new team, if a new member comes into the team, it's a new team, if somebody leaves, it's a new team. And I think that's where I've seen, the danger was, if you have a very high functioning team, they've taken a lot of the training wheels off, they understand each other that's got this meta brain going and they're capable of doing things together that they just can't do alone. And that's, that's the ideal that you're going for. But then those sorts of teams can stop communicating, and they can stop talking about these things. And then these little problems start to creep in and entropy sets in. And one of my favorite words, that makes me sound really smart is schism. agenesis, which is this idea that yeah, I love losing. It's mighty, it's a really simple idea is that if if a crack happens, and you repair it immediately, it takes very low energy. And in a human system that could be, you know, people are just, you know, somebody forgot to brush his teeth, and his breath smells. And you can just tell him to brush his teeth and blows over. And it's not a big thing. But if crack forms, and it's not repaired, it can get bigger and bigger and bigger. And the amount of energy required to bring it together gets larger and larger. And that's. So that's the importance of having retrospectives. Even if a team is going great. Even if everything's wonderful. Let's step out of the work. Let's leave that system and say those people over there, how are they doing? What are they doing? Well, that they should keep doing, you know, always in retrospectives. I see like, we do this sort of mad, sad, glad. And we pretend to look at the happy ones. Here's the problem is fixed the problem. And that's one of the things that I really like about Kent, and his approach is like, what can we turn up to 11. But let's amplify the good until the bad is out of the system. But the importance of being intentional about that, and it even in a team that's going well, and that's again, where the spine model can help us like we all agree, but let's let's all just write it down. So that if any point is not an agreement, and that spine is a living document, and the value of it is not in the writing down, it's in the conversation. And it's nice to have agreements, and disagreements like a dispute quite boring if everybody agrees all the time. And so if you're in a team that knows how to disagree, and then still hang out afterwards and be friends, like that's where Real learning can happen. And so if a team is never disagreeing, I'm super worried about them because it probably means there's some really big cracks that people are too scared to even to go close to, whereas a team that's cracking jokes and ribbing each other and disagreeing the whole time but still the smiles on their face, it's like assets, that's where you want to get to, because that's where the really good work and

Tim Bourguignon 40:06
even the you still find or make time to code or to pair with your folks.

Kevin Trethewey 40:13
I keep promising to there's a few languages and things I want to learn. But the challenge I have at the moment is twofold. The one is that the bigger problems are not at that level. And the other is I have two young kids, I'm trying to get them into coding because that feels like then an opportunity to, to kind of get into it with them. But for now, my focus is being a dad and being there for them. And then at work, trying to get to a point where we are focusing and solving really big problems. So ballerina is the language that I really want to get more into it, it looks quite interesting. But I don't get a lot of time to code anymore.

Tim Bourguignon 40:53
I have the same problem. And we did a hackathon a few months ago. And it was so fun to just forget about all those big problems and focus on code for one week, it felt so thrilling, I was led to come back to my big problems after coding for a week was so great.

Kevin Trethewey 41:09
Well, it's a good reminder, actually, before locked down and COVID, we used to do a lot of code retreats. And actually maybe that's an opportunity is to set up another code retreats. And that was one of my favorite things where you could explore a problem with a bunch of different languages with a few different people over a day. So I really did enjoy that format. This last weekend, we just had an unconference which I really enjoy that format is 20 to 25 of us went to a game reserve spot just outside of Johannesburg. And it was just people doing interesting stuff in software and we an unconference style, you basically just create the agenda when you get there and then run that conference. And I really enjoy that level of format. And that level of exchange is sort of where I'm at now in my career is I want to break down ideas and exchange them as much as possible. I

Tim Bourguignon 41:55
love in conferences as well. COVID put a hard stop to that. And we need to get that rolling again. That's, that's such a great form. I fear I know already what your answer is going to be. But I'm going to ask it anyway, with which we will be your your advice for somebody saying, Hey, your spine model seems interesting. How do I start with this with my team today?

Kevin Trethewey 42:19
What was my answer gonna be? Because I'm not sure what

Tim Bourguignon 42:23
I would have expected you to say well do prospective.

Kevin Trethewey 42:29
If you're not doing a retrospective, yeah, I mean, absolutely find a way to visualize your work and doing doing a retrospective, but my instinct on is actually read a book there. One of the things that that particularly, I'm gonna sound like an old fart, but the younger generation doesn't really a lot of the good thinking was done 4050 years ago, in the work that we're doing, and the Kent Beck's book on extreme programming was written 20 years ago, but it for me, it's still one of the best books on these things. And so I highly recommend this embracing change is the title of it. That's, that's a really good book to start out with to get some ideas from, and I guess that's, that's a pattern that works for me is to, to read something and then try and apply it and then get that feedback loop going and retrospect on that. And my my style of reading, because I don't have a sort of photographic memory as to try and read to improve my compiler, sort of the metaphor that I use. So I, I'm always on the lookout for things that just trigger something in my brain or interesting to me, and then I'll get that book and I'll make friends with it. Well, I'll I'll sort of read the first chapter and know what's in the book and smell it and you know, like, actually have it take up space in my physical environment, and then they'll put it on my shelf. And then as I'm going through things, I'll start to struggle with something or I'll have a question like, Chapter three yellow book, third shelf, and then I'll go and read the chapter. And that's when it kind of makes the most impact and gives me something to try in what I'm doing. And I've my sort of fundamental assertion is that software engineering is easy. It is simple, and it's easy. And if it's not, it's because there's something I don't know. So now it's my job to go and figure out what that thing is to make it easy. And so that's, yeah, that's, that's a useful approach to me.

Tim Bourguignon 44:16
Again, when I posted this, that's probably on your page somewhere, we'll have to leave

Kevin Trethewey 44:20
the hypothesis. The thing was, I can never say that word well, is every now and again, I have some sort of random brain fart when I'm working or something I think might be insightful, but I'm not sure. And I tweeted. And then every now and again, I just go through my Twitter stream and and take because that was part of reflecting like in a year's time, does that still seem like an insight? Or was I just done a dark tunnel, and if it still feels like it might be onto something, then I pop it onto that page as a hypothesis. And that also gives me a nice, simpler way to go back to those ones every few years and reflect and see because it's kind of like talking to my my self from a few years ago, to kind of see where I was at and It's

Tim Bourguignon 45:00
fin tastic giving, it's been delighting Thank you very much for opening up and sharing your story with us and introducing spine model and talking a lot about values, principles, practices, or topics that I love. So thank you very, very much.

Kevin Trethewey 45:15
Well, thank you. And I hope some of it some of that was useful. I'm

Tim Bourguignon 45:18
sure it was, where would be the best place to find you online and continue this discussion with you.

Kevin Trethewey 45:23
I still check in with Twitter every now and again. So that's probably one place to to reach me is Kevin theory is my Twitter handle. Other than that, I mean, the one thing that I did do, which seems to have sort of passed the test of time, a little as a few years ago, I gave a talk at DEF CON. And it's up on YouTube. And so if you're interested in, you know, whose shoulders I'm standing on, I did referenced that a little bit of, you know, the books that have been useful to me and the fields of study that have been useful. And then that might be a useful thing to people if they just look for my name plus dev conf on YouTube. So they'll find it. But yeah, in general, I'm always super open to having a coffee conversation and connecting and meeting people. So you know, you can find me out there. If anybody wants to chat further. I'm very open to that.

Tim Bourguignon 46:06
And you heard him and we'll have the links to show notes. So you don't have to scroll in search and YouTube will will add it right there. Karen, thank you. Again, it's been like,

Kevin Trethewey 46:16
Awesome. Thanks for having me on the podcast. It was an honor. And this

Tim Bourguignon 46:19
has been another episode of developer's journey with each other next week. Just thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m o t h e p or per email info at Dev journey dot info. Talk to you soon.