Ted M. Young: How to Have Fun Through Learning?

Richard:

Our special guest today is Ted Young. Hi, Ted. Great to have you here.

Ted:
Great to be here.

Richard:
Could you introduce yourself to our listeners?

Ted:
Sure. So I’m Ted M Young and I use the M purposely because there actually are other Ted Youngs who are actually in the same industry as me. And so I’ve doubled down on M as being a prominent part of my name, but actually I’m probably better known as JitterTed, J-I-T-T-E-R-T-E-D, JitterTed, both on Twitch, which is where I do my live coding and on Twitter where I do a lot of, obviously my tweeting. And so I’m an old white guy, software developer. So I’ve been doing the software thing for, I can say 40 years as a professional, if you classify professional as actually having made money because I’ve been making money doing software since I was 13. And I got into the Agile stuff really early with extreme programming way back in 98, 99 was part of, so I’m in the San Francisco Bay area, and I was part of the Bay XP group in the early two thousands and was involved in that.

Ted:
Did actually an Agile project for the San Jose County government, where we did a contract where we said month to month, we’re going to do the most important things. And at the end of the month, you can decide whether to move forward. This was astonishing because like, I didn’t think it would work, but it was, it was truly an Agile project in like we were sitting literally with the customer in their offices. And I know I’m on a tangent here, but like that’s what Agile means to me is are you getting feedback from the people who this software effects. Now, are you getting that on a regular basis? Everything else is just detail. So we did that and we were able to get really good feedback and have good conversations.

Ted:
And since then I’ve worked at companies like eBay and Google, and it was at Guidewire that sort of, I really was able to really explore Agile with a larger team in the context of a larger organization and stayed there for a while, went over to Apple for a little bit. And then a few years ago decided, you know what, I miss doing training and coaching and teaching. And so now I’m back doing that at companies large and small, and also spending a lot of time live coding online in front of sometimes one person, sometimes 50 people, so that’s what I’m doing.

Richard:
I love this idea of live coding streaming as you code. One sense, it’s like, “Why would anybody want to watch that?” Another sense is, “That is so cool. Of course I want to watch that.” And it’s like a sort of like a dream. What if we were like a team of people writing code in the middle of a football stadium and there was like 65,000 people cheering us on.

Ted:
Well, what’s really amazing. And I’ve had that question. It’s like, “Why would people watch?” And so the kinds of thing I like watching are, I want to know what was going through your head when you decided to do it this way versus that way. So for one example, I’m trying to get better at design, design of web apps, websites, and so on. I kind of know what’s good, but getting there is hard. And so watching people say, “Okay, I’m going to do this and do this”, like, “Oh, that’s why you did it that way. Or that’s why you did it this way.”

Ted:
And generally, if you go to online courses or look on YouTube, you don’t get that sense of here’s a mistake I made or here’s a decision I made, and here’s why. And I know for myself, when I produce sort of the dedicated learning videos, I don’t usually include mistakes. Whereas if I’m live coding, I’m making mistakes all the time. Like yesterday I made a mistake. I was like, “Oh, I’ve let the code in a bad state. And I don’t have a failing test, and I know exactly what I did wrong, and okay lesson learned again.”

Richard:
Yeah, yeah. Yeah. Lesson learned again. So you mentioned, as you introduced yourself, you mentioned some team or some teams you’ve been part of. This is the podcast about teams and the best teams of people’s lives. What was the best team that you’ve ever been part of in your life?

Ted:
So, I think when I first joined Guidewire Software back in 2007. So, Guidewire produces, the software is large, but the software they produce is insurance offer for large insurance companies, the property and casualty. So, you’re near your Geicos your State Farms, those companies for their core claims billing and policy systems use Guidewire software internally. So I joined the billing team, basically became the tech lead, and it was a perfect for me to join because they were sort of transitioning from… This was one of the newer teams in the company. They’re sort of transitioning from getting on their feet, getting moving, but not really having much of a process. And ad hoc works great up to a certain point. Like if you’ve got four or six people who were all working together and all know what they’re doing and all know what they need to do, you don’t need much of a process, but once you get a little bit larger and things start needing to be formalized a bit more, I was able to inject my Agile knowledge, and trying out things.

Ted:
And the idea of cards on a wall was new experimenting with different, so they had sort of this very loose one month sprints. This was when Scrum was saying, sprints are one month. So they were doing one month. They weren’t really sprints anyway. So it didn’t quite matter. So we were experimenting with that. And just a lot of experimentation, a lot of playing with things, a lot of working together on so I’d bring in stuff and then things would be tried out and different needs would come up. And that worked out really well. And eventually I became the dev manager for that team, but it really was sort of the start of Agile at Guidewire and spread to other teams. And I sort of was coaching other teams on how to do things. And that was my first realization of watch what you say, because people will take that and without thinking, do exactly that. I’m like, “What are you doing here?” It’s like, “Well, you said it’s like”, “No, that’s not what I meant. I know that’s what I said, but your context is different. So let’s talk about your context.”

Richard:
All right. Yeah. And when you take yourself back to this first team at Guidewire, and then if you could, re-experience the work that you’re doing, sort of like feel what it was like deep within yourself, deep within your body, like physically feel what is like working together with those folks, is there one word that you could use to describe that team and that experience?

Ted:
If we go more on the feeling side, it was fun.

Richard:
Fun.

Ted:
It was fun. Not in like hilarious, but in enjoyable. There’s a book called, The Progress Principle. And the idea is as you make progress and visible progress on things that is compelling and its own reward, and I think we were just making progress, and that was fun. And we were doing it in a way that was where we just worked well together. So, fun is probably the one word description of that.

Richard:
All right. Is there anything else about that fun related to this?

Ted:
So, I think if you think about like, what makes things fun, you have to sort of be willing to experiment and try things out and say, “Oh, well, that didn’t work. Oops.” And be willing to accept failure all the stuff that we talk about being willing to take a chance and willing to try something. Listening to one another, right? We always talk about like good improv is listening and adding on. And yeah. And so there’s a fun aspect to, I think, just making visible progress and seeing things we get into this because we want to create, I think that’s a core aspect and what’s more fun than, than being able to create something, and see it work?

Richard:
Yeah, totally. Totally. Is there anything else subjective you could say about this team? How do you know subjectively that it was the best day of your life?

Ted:
Because I’m always referring back to it when I give various talks. It’s like, “We did this and we did this”, I think the flip side of fun and this relates to like this game I’m working on is you’re learning. Right? And I think learning can be fun. We sometimes think about learning is drudge work and learning is [inaudible 00:09:54] and learning is boring. And I think the best learning though is fun. Right? I mean, you look at kids play. I mean, there’s a lot of learning going on and it’s basically getting feedback and seeing that you’re on the right track or the wrong track. And so I think I did a lot of learning from there was one point that really stood out for me where the team wanted to run a small experiment.

Ted:
I was actually on sort of a committee of experiments. We were sort of the labs committee and I was like, “What you want to do? I don’t think that’s going to work. But you know what, let’s set out the experiment. What do we expect? What’s the hypothesis? How are you going to run it? How are we going to know that you succeeded or not?” And it worked. And I was like, “Okay, lesson learned. I can not predict the future.” And I really remember feeling so strongly, “This is just not going to work. There’s no way this is going to work”, and being surprised and happily so, that that’s like, “Okay, that worked.” And that kind of thing really stuck out for me. And yeah. So just a lot of learning ties and ties into the fun aspect.

Richard:
All right. And it’s got fun, we got learning and learning is fun and progress. How about objective measures? Is there anything that you could have as like evidence that somebody outside the team could have looked at? Any metrics or anything else subjective that shows that this really was a great team?

Ted:
Yeah. Well, I got a bonus for my work of spreading Agile to bo- I mean, clearly it was seen as successful. Sometimes it’s hard to see right. You’re in the team. And especially if things are going mostly well, right? Nothing goes a hundred percent well all the time, but clearly, we seemed to be doing well, but when people outside the team is saying, “What you’re doing is working, can we do that too?” To me, that’s a huge saying that the success is visible enough that other people want to copy it. And then we had your typical good metrics of, we were able to measure how much work we were getting done. We were able to do it in a predictable manner. And this was 2011, 2012, when I think that kind of metrics was not really widely known.

Ted:
And we were doing things like we were able to predict, we were gathering data on a story by story. These were cards on a wall, and we were able to figure out what the life cycle, the full cycle time of those things were. And we were able to then use that and say, “You know what? There’s this big feature we wanted to get into this release, not going to happen.” And they were fine with that because we had data and it would have been risky to… For better, for worse, we were producing sort of old style software where it was a two year version cycle and it would take 18 months for a company to install it and get it customized and all that kind of stuff.

Ted:
So it really mattered that if we put in a feature and it was half done, we would have then had to undo it. And so that kind of predictability, and it was really cool. I was plugging stuff into a spreadsheet and we were looking at it and it’s like, “Yep, we were right.” It didn’t fit, or it wouldn’t have fit. So getting predictable progress, being able to really drive based on that data, I think was clearly objective stuff. We did things like we changed the way we estimated. I would never do estimation the way we originally did it, which was the typical poker cards and spend four hours, sorry, one hour estimating, four stories.

Ted:
And it’s like, “Was that really useful?” Yes. We learned a lot by talking about it, but did we really need to do that to being able to estimate 20, 30, 40 stories in much less than an hour, and it really made no difference from the data. And so that was nice to have that objective data as showing us that we were doing the work in a way that was predictable and everybody wants predictability. And so that’s why I love to try McGuinness’s is stuff around metrics and that kind of thing. It’s like, “Yes, we need more of that.”

Richard:
Cool. You’ve mentioned some of the concrete behaviors that you engage in together, cars on a wall, computing cycle time, it’s estimating practice. What are some of the other concrete behaviors that you’ve engaged in together as a team?

Ted:
I think some of it is willingness to take on tedious tasks. So for better, or for worse, our merge process was hell. Our merge process, because… So we eventually got our iterations down to two weeks because we tried, we actually tried more, that clearly was too long. We tried one week and the overhead of merging because we were doing it once a week. It was literally the entire Wednesday was merging because we had a complex process and lots of other teams to deal with. And that was just hell. But somebody else I had to lead that and manage that and do that. And so everybody might grumble a bit, but we did it, and we took it on and because we know that that was important to let other folks get actual work done instead of just merging.

Ted:
So, for the responsibility aspect, I think was a good behavior. Being curious, and I think people always ask me because I’m on my live stream, or wherever. And it’s like, “What do you look for when you’re hiring someone?” I look for curiosity. If you’re curious, how can I know more about this? How can I do things better? That is really, really important to me because if you’re not thinking or being curious about what you’re doing or how to make it better, you’re almost just a zombie and walking through the work. You can get by with quite a lot of zombies, but that’s not going to really improve the team. And so experimenting that goes into the experimentation and being willing to try things. And then I think there’s being vulnerable. And I know this was… I’m sure it’s hard for everyone.

Ted:
It was very, very hard for me, especially being like the tech lead and dev manager to admit when I’m wrong, and being able to do that, just sort of knits everything else together. Being able to say, “Oops, I goofed”, or “I have no idea what we’re doing here.” And now I try to really model that on my live coding streams, like “I have no idea what I’m doing right now. Let’s go and see if we can figure this out”, or, “Oh, I just totally messed that up let’s…” To show that even someone who’s been doing this for 40 years, we still make mistakes. And this very much ties back to learning. It’s like, you can’t learn if you think you know everything. And I think people like that where they think they know everything they’re not going to learn.

Ted:
And so it’s sort of like, I may be improving only… I may be at some arbitrary score of 80, out of a hundred, but I’m improving. Whereas maybe they’re at a hundred, I’m going to pass them. Right? If they’re just not improving at all. And maybe they were better when they started, but they are not improving who’s going to win? In the long run, I’ll win. And I’m sure I came across as arrogant and a know it all earlier on in my career because I thought I knew everything. Right. And this is fairly typical. It’s like, as you learn more, you realize you know less.

Richard:
Yeah. Well, so I love that story about admitting when you’re wrong, when you make mistakes, when you got lost in some code, you were writing, you started by saying, being vulnerable and it’s not just tell people to be vulnerable, it’s here’s some examples of behaviors that you’ve been modeling [crosstalk 00:17:32] and that people can use themselves to do this be vulnerable thing, admit you’re wrong, or you don’t know something or you totally messed it up.

Ted:
Yeah. And I think you have to model it and even if in a sense, sometimes I’m streaming and I don’t have many viewers and nobody’s interacting and I’m still modeling all that because it’s just good practice. Right? And this is where if you’re lucky enough to go to a workshop or something where you work on some of this stuff, you’re working on it by practicing it. And you’re not going to get more comfortable with something by doing it less. You’re not going to get better at something by doing it less. And to me, it always goes back to the XP of if it hurts, do it more, right? Turn it up to 11. It’s like, if it hurts, do it more.

Ted:
It’s like what? that sounds strange. But if it hurts, or it’s hard to do, you have to do it more. And hopefully in an environment where you’re safe. And so we always talk about psychological safety, but sometimes you might be… There’s a number of occasions where I come across as a rebel because I am both lucky enough to be privileged and able to take chances that other people can’t. And so then therefore, I kind of feel it’s incumbent upon me to do that. That I’m the one who can take a chance because I can go out. And for example, if I get fired, I can go out and find 10 job offers next week.

Ted:
And so I tend to do that and I tend to push things and therefore, I tend to be more questioning like, “Is this right? Does this look right? This doesn’t look right. What are we doing here?” Or I have no idea what’s going on. And so in a sense, leveraging my privilege to be vulnerable, I think is something that I can do. And that if you’re that type of person or you’re in that position of being a tech lead or something like that, being more vulnerable is a tremendous way to show that it’s safer to do that. That look I’m saying, “I have no idea what the best answer is here.”

Richard:
I had one of these, you ever had this experience, like just something rushes through your whole body? I just had one of these experiences listening to say that last paragraph. It was like, “Oh, this privilege that some of us have and how we can use that privilege to effectively, like, I’m the one who can take a chance because I am privileged. I can just get another job. It wouldn’t be that hard.” And so it’s incumbent upon us to use that.

Ted:
Yeah. And I think for me, it’s always been sort of that like, “Oh, what the heck”, right? What’s the worst thing that can happen? [inaudible 00:20:18] Because at a very young age, I was basically an entrepreneur and my father was an entrepreneur. And so sort of that’s… And here I am, again in 2020, I’m an entrepreneur. And so you might say, “Well, I have a hard time working for people.” That might be an aspect of it, but I know that I can always fall back on that. And so that always gave me a certain foundation, solid foundation that like, “Why don’t we speak up?” Right. It’s because we’re worried perhaps how we’re perceived, but also maybe that our job is in danger.

Ted:
And so while the first one may be a factor for me, how I’m perceived, but like the second one I can always figure something out, always land on my feet. And so I always tended to speak up and there are a number of occasions that immediately come to mind. I don’t think, I can mention anything other than like pointing out the obvious in the room, like, okay, we’re looking at stuff, at dates here, none of this adds up what’s going on. And it always fascinates me, like, am I the only one who sees this, or am I the only one who’s going to say it out loud?

Richard:
All right. Is there anything else that you want to add? Anything, you want to make sure listeners hear about it or know about or anything you’ve been doing with yourself working on recently that you want to share?

Ted:
Yeah. So, speaking of learning. I’ve been working on this game to help people learn, test driven development. So two things, one is I’ve actually been live coding, so setback, but in order to play test the game, I needed a way to do this remotely. And it’s hard to play test a physical game remotely. And so I basically create an online version, that online version I created live coding, and I created a TDD because all this stuff I do except for the front end, because I’m still a novice at, that was all TDD. And there’s kind of this funny meta thing that’s going on. It’s like, I am writing a TDD game with all the actions that you do in TDD and I’m doing a TDD, and so there’s this reference back and forth of what I’m actually doing and what the thing is in the game.

Ted:
And it’s really cool to see how much they align. It’s like, “I’m doing this thing, I’m doing this prediction thing.” So one of the big things I do in my TDD is you have to call your shot. You have to predict before you run a test. Is this test going to pass this test? Is this thing going to compile? Is this thing going to fail? I expect it to fail, but is it going to fail in this very specific way with this null pointer, exception thing and something I’ve recently been adding is in addition to predicting, what’s my confidence? So I’ve been doing one of the things that I do is a lot of research on how people learn as a trainer coach. That’s something that I really am passionate about. How do we learn best? What’s the effective way to learn? And I was reading some research about how, when students take multiple choice tests, adding in, and how confident are you in your answer?

Ted:
There’s some really interesting data that shows an increase in learning. And so I thought that’s really interesting because we can answer a question and say, “Yeah, I know this.” And if we say we’re a hundred percent confident, and we get it wrong. That’s very different than I’m like, “I don’t know. Maybe I’m 30% confident and I get it wrong.” I had very different outcomes and very different, how much do you actually know? And so I’ve been adding that into when I’ve been live coding. I think I’m 80% sure because there’s this little piece in the back of my head where I’m not sure about this thing and we’ll see what happens. And then there’s “Oh, I’m a hundred percent sure.” And boom, it fails and for the wrong reason. I’m like, “Oh, I was so sure.”

Ted:
And part of it is also like, we think we’re sure, this goes back to the experiment stuff I was talking about and sometimes we’re wrong. So it’s been really a lot of fun to get this kind of feedback between what I’m doing and the game I’m making. And so now I’m like, “Okay, do I add this confidence level thing to my game? Or do I get the thing released?” And this is just a general software, any kind of products like, “Do I add this one thing in?” The other thing has been balancing the learning aspects of the game with whether it’s fun or not. And that’s been really hard because it’s like, “Oh, this is a little bit less than realistic.” And I’m very careful that I don’t want to go and have people play a game and then have to explain, okay, in real life, you don’t really do this thing where you do this differently.

Ted:
I want to minimize that distance, but then it’s got to be still a fun game, otherwise people aren’t going to play it or not for very long. So that’s been just a totally unexpected, I did not expect to be doing this in 2020. I had very different plans for 2020. And so it’s been a lot of fun. I’ve gotten great feedback and now what’s really nice is I can use this in, when I speak at conferences, I can say here’s, instead of just showing people and maybe having people code, it’s like, “Okay, let’s play this game for 20 minutes and see what we learn. And then we can discuss it and sort of see that cycle sped up.” And so it’s basically you could say it’s a simulation game because I’m simulating a real world thing in ways that you may not be able to do otherwise.

Ted:
And so I think that, and it sort of opened up like we should do this more. We should be creating more and more of these types of games for all sorts of different things. Now I’ve got ideas for how do we do refactoring and all this kind of stuff. And it’s like, let’s get one thing done first before we start creating new things. So, that’s what I’m really excited about.

Richard:
All right. Yeah. That’s super exciting. I can’t wait to play this game myself.

Ted:
Cool.

Richard:
If any listeners want to contact you, is there a way they can do that?

Ted:
So, Twitter is always a good way to go. So, as I mentioned earlier, JitterTed, where I have Twitter. You can check out my YouTube, if you go to JitterTed.tv, and you can check out my live coding at JitterTed.live. And yeah, those are the best ways to get in touch. The TDD card game has its own site, tdd.cards, all these great domain names. So, yeah, if people are interested in the game and they want to find out more, or maybe they want to get an early access to it, tdd.cards is the place to go.

Richard:
Well, JitterTed, Ted M Young, thanks so much for joining us today. I really appreciate it.

Ted:
Oh, my pleasure. Thanks for having me.

Richard:
Hi friends, thanks again for listening. And remember to support this podcast, visit my website, kasperowski.com.