Subscribe
Share
Share
Embed
The development world is cluttered with buzzwords and distractions. Speed, focus, and freedom? Gone.
I’m Nicky Pike. And it’s time for a reset.
[Dev]olution is here to help you get back to what matters: creating, solving, and making an impact. No trend chasing, just asking better questions.
What do devs really want?
How can platform teams drive flow, not friction?
How does AI actually help?
Join me every two weeks for straight talk with the people shaping the future of dev.
This is the [Dev]olution.
Ted Young (00:00:00):
I don't want to deliver software faster. I want to deliver software sooner. In other words, I want to get value out to people sooner.
Nicky Pike (00:00:08):
This is [Dev]olution, bringing development back to speed, back to focus, back to freedom. I'm Nicky Pike. Okay, so here's what nobody's talking about. Most developers write code first. They figure it out as they go. They add Else conditions midflow that they never intended, and they ship complexity that nobody asked for. Then they write tests afterwards to cover what they built. Problem is, that's just cleanup on code that was never designed to be testable. Whether you're coding solo or you're working with an LLM, coding without clear specification gets you the same result. More time debugging, less than shipping. Joining me today is Ted Young. He's a technical coach with 25 years of a companies that like Google and Apple. Ted wrote test-driven development and he broke that down into nine distinct steps and then he did something wild with it. He turned it into a board game.
(00:00:58):
Today we're looking into the why the word test is killing test-driven development, how predictions change everything and why specifications matter more than you think, especially when you're working with AI. Before Ted and I get into that, here's the challenge on the table. We've been doing this all backwards. We write code, we make it work, and then we write tests to cover it. It feels productive, but you're actually coding without a clear destination. Discovering requirements as you go, retrofitting tests on a code after our intentions and our brains have moved on. Now we're teaching AI the same broken workflow by asking LLMs to generate code without clear specification, and then we're left debugging the mess. So here's what we need to figure out. Can we actually afford to keep coding without thinking first? Ted, welcome to The [Dev]olution. Thanks for having me. Before we get started, man, is there anything you want to kick off?
(00:01:44):
How was your Christmas?
Ted Young (00:01:45):
It was great. Played some board games, some rest. So just relaxing this time of year and not a lot of noise going on in the outside world.
Nicky Pike (00:01:53):
That's awesome. You've spent 25 years at places like Google and Apple and you've spent those writing code. Was it these experiences that made you want to become Jitter Ted the TDD guy?
Ted Young (00:02:03):
I've been coding longer than 25 years. I've been coding since I was in my early teens. The way I learned how to code is probably the way anyone who started when they were like 10 or 12 learning how to code is trial and error.
(00:02:16):
And so what is trial and error? It's you try something and you see if it does what you want. And that's great, except how can you see it if you can't see it? So there's a lot of things that code does that we don't necessarily see. And so even back then I had always written some little pieces of code that helped check that what I wanted it to do actually happened. And I was working on a stock market charting technical analysis app for my dad who was a stock market investor. And there's a lot of formulas in there and there's things like moving averages and so on stuff you could just call a library and it's really easy, but we were writing it all from scratch. And how did I know it worked? I literally had like paper and pencil and calculators to make sure and I would have the code dump the numbers.
(00:03:04):
And so that's sort of the essence of TDD. It's like, I know what I wanted to do. I have these 10 numbers. What's the average? I add a number. I drop off the old one. I have a new average. Are those numbers correct? And so even back then, this idea of checking our work is sort of intrinsic to what I do.
Nicky Pike (00:03:24):
So hold on. You're telling me that you kind of cut your teeth with a stock trading app?
Ted Young (00:03:28):
Yes. I did some fun stuff before then, but that was like the first real professional and it was a commercial app. We sold it, but it actually got licensed by Dow Jones, paid for my college. So yeah.
Nicky Pike (00:03:39):
Nice.
Ted Young (00:03:40):
On the deep end.
Nicky Pike (00:03:41):
Was it that app that got you into test-driven development or did you kind of know about it first and just start applying the principles at that point?
Ted Young (00:03:47):
I mean, Kent Beck didn't talk about test-driven development until many, many years later, but it was this idea of what do I want it to do and how do I know it does it? And it's very different than the way most people are taught how to code. Usually it's code first and then try some staff out later, but really being precise about what I want it to do, what is the desire behavior. And so I got into sort of that idea. And back then there weren't unit testing frameworks. I had to write some stuff here. And it was actually a lot of manual checking. It was like print out some numbers and then check it with what I had written down. And now with the unit test frameworks and better tooling and then Kent Beck writing around test-driven development really connected everything for me.
Nicky Pike (00:04:30):
All right. Well, and you kind of mentioned this is a different way of doing things and test-driven development can get kind of polarizing. People either love it or they hate it. What was the moment that you kind of realized that TDD was broken in the way that it was being taught or that there was a better way?
Ted Young (00:04:45):
I think what's broken is how people are taught how to code. I think that's broken. I think it is the wrong way around. Let me go do a bunch of things and then go back and see if I did it right. There's the old adage of, let me burn my toast faster and scrape it off the burn stuff. That's how we program. And it's like, that's the way we're taught because the way we're taught how to code is based on 50-year-old ideas. We're taught to code and then check it, except we have now an emotional investment in the code we just wrote. And so are we going to really try to break it? Because that's really kind of the purpose of writing these tests is make sure we've captured everything, all the edge cases. If it was all happy scenarios, life would be easy, but there's a lot of edge cases that we have to cover and make sure that we handle them correctly.
(00:05:34):
And I know before I was doing TDD, I would have this sense of like, "Oh, I don't want to write that test because I know it might break." If you're not even aware of that, and I think most people are not aware that that is happening, you're not going to write good tests. I've taught developers, sort of junior developers, how to do TDD. TD is not hard. It is just a real shift in the way you think about how you develop software. For years afterward, I'd have these people still in college come to me and said, "Ted, that was the best thing ever. It really changed the way I developed software." And so I think we have an entire industry built on a way of developing software that is wrong.
Nicky Pike (00:06:12):
When you say that, I imagine there's a lot of developers out there, Ted, going, "Whoa, you just said everything that we know is wrong, right? We've been taught the wrong way." But we've been doing this for a long time. Most of the software that's written out there was written before test-driven development, before this concept, but you've got interns and other people that are coming in, new folks that are coming in saying, "This changes everything for us." Where's that breakdown line of trying to convince the old guys that there is a better way versus, well, is this just a new fad that people coming out of college are learning? Where's the difference there?
Ted Young (00:06:44):
Test-driven development's not new. It's at least 25, 30 plus years old, and how people are taught how to code has not really changed very much. When you're first learning, you're trying to code stuff and you get stuff to work and then it's like, "Oh my God, it worked." And you're really happy, but why is it so hard? It's one of those things where it's amazing that software works today. So lots of software is being written-
Nicky Pike (00:07:07):
That's a big statement.
Ted Young (00:07:08):
It really is. And unfortunately, maybe it's me, I'm old and so old man yells at cloud, but I think software has gotten worse over the past five, 10 years. And TDD is certainly not popular. It's not the common way of doing things. It's still the, I don't know, few percent in terms of people who are really doing it correctly and not saying that they're kind of doing it or think they're doing it, but they weren't taught correctly. And so I know that when I develop software and use TDD, the problems that come up are not in the code doing what it wasn't supposed to do. It's we didn't quite understand interactions and how people would actually use it and maybe the behavior that we thought we wanted wasn't right. There's no magic to it. It's not like it's going to magically make things do exactly what we hope it does.
(00:07:58):
It does exactly what we tell it like computers do. And so it boggles my mind that we've always been in a software crisis. We've always been where there's just so much code and there are bugs that are happening all the time. I remember I was working on insurance software and we would do this annual or every release, which was 12 to 18 months. This was back when we had releases and there'd be 3,000 issues and we'd go and triage them. And it's like, "Look, we're just not going to fix these." And not all of them were bug bugs where we actually made a mistake. They were just like, "It didn't do things quite right." And so when we encounter this massive amount of code that just doesn't do what we want or is hard to understand, right? So there's this idea that test development is all about testing or whatever, but it's about getting what we want out of it and that the code remains maintainable.
(00:08:47):
And I think that last part is often overlooked in general. When I teach TD, we spend the first three and a half of four days on refactoring. And then the last half day is basically now we're going to actually do TDD because now you have the raw skills to do it.
Nicky Pike (00:09:03):
So I've got this rant where I go on and talk about software engineering and how it's an engineering discipline that's different from all other engineering disciplines. And I think you just kind of explained that in the fact that in the last 10 years you think the code's gotten worse. Do you think that's because we're teaching people frameworks, we're teaching people what codes lines look like, but we're not teaching them the engineering portion behind it of this is how you design the product, this is what you want the product to do, just like we do in all the other engineering disciplines. Do you think that is something that maybe we've been failing people that are coming through software engineering education?
Ted Young (00:09:38):
Yeah. The education aspect of software development is we've never taught people how to work with larger code bases. And so larger code bases is where a lot of us exist now. We were never taught how to do that. Heck, we weren't even taught how to work together as a team. We weren't taught how to take code and maintain it. We were taught about how to write new code. And so all this other stuff that you have to do, in fact, that takes probably the majority of our time integrating with other systems, talking to other people and negotiating, fitting in new functionality into code that might not have been prepared for it, all these things people are learning on the fly. And there's sort of this pendulum of very, very precise and detailed requirements upfront, and then the pendulum swung the other way, too far, I think, which is, we'll just play it by ear and figure it out as we go.
(00:10:36):
And I think there's the happy medium there somewhere, but I think we're starting to see, ironically, a little swing back to being a bit more precise about what we want with AI. But the thing that we're still missing is we still have to keep the code something that we as humans can work on.
(00:10:52):
Until whatever we want to call AI gets good enough where we never have to read the code and understand it, we still have to read and understand it.
Nicky Pike (00:11:01):
Well, and all this led to, you saw that the way we were writing code was missing something. You saw that test-driven development was kind of misunderstood and you decided to do something about it and we're going to get into that in a little bit. But before we get into that solution, let's go ahead and kind of level the play and field for everybody here and make sure that everyone knows what we're talking about. So let's start with the basics for anyone that's not encountered this. What are the core principles of test-driven development for someone who's never heard of it before?
Ted Young (00:11:27):
So the core piece is what do I want this new thing that I'm about to embark on? What do I want it to do and how will I know it does it? Those are the key first steps. So if I want to add functionality to, let's say, a concert event ticketing system where you buy a ticket and you should be able to get an email with some PDF that has a QR code on it that'll be used as a ticket and you distill it down, it's, here's an input and here's my expected output. That's it. It's basically, given this input into the system, I expect this output. Now the key part is, and this is what often trips people up is like, well, how do I know? So one of the common complaints about TDD is like, well, I don't know what the code's going to do.
(00:12:12):
It's like, of course you do. Of course you do because- You're writing it. You're about to write it. So of course you must at some level of consciousness understand and have a future in mind. I have a destination that I'm going to where given this input, somebody pushes a buy button and goes through the sales process, the output among other things, is they get an email. And I think that's the essence of it. And so the technical aspects of it, of writing a failing test is basically saying the system does not do this yet. And so writing that failing test, it's funny, it's like we see the word fail in there. That's really a good thing. It's like we're seeing that it does not do the thing that we want it to do, but it doesn't do it in a way that I can observe.
(00:12:59):
So let's say it used to be that people got emails for their tickets. Now we want them to get a text message. Okay. Well, if I observe the system and I say the ticket was bought and they didn't get a text message, well, that's good because the system doesn't do it yet. And I know I'm done when the system does do that. And so I've done it in a precise enough way that I can have an automated code-based test tell me when that piece of functionality is done.
Nicky Pike (00:13:31):
So I imagine there's a lot of developers out there going, "Well, yeah, but that's what we've got requirements docs for. " Requirements docs tell us this is what's supposed to happen. That's how we know what to go write the code. So is there something that's a little bit different in the way that you're doing test-driven development versus just the requirements documentation?
Ted Young (00:13:48):
Yeah. And so there are a couple of things. One is, how do I know I'm done? So requirements documents are often in English and even with LLMs and things like that, it's like English is still imprecise. And so there are times when it says something and it's like, well, what does that mean in terms of the code? So there's that. And I think that the biggest part though is breaking the problem down into small enough pieces that you're not basically testing the entire system every single time you're implementing something, this idea of end-to-end test. End-to-end tests are useful, but you don't want that to be the majority of them because they tend to be very brittle. They tend to run slow. And when they break, they don't necessarily isolate where the actual problem is, what's missing in your system or what decision making is incorrect in your system.
(00:14:37):
And so that's why we want to write more precise tests. And so breaking the problem down into small enough little tiny pieces, that's hard, but I think that's necessary because then it's not just when somebody buys a ticket, they get a text message. It's this method returns this value that contains this piece of information. And once I get down to a test at that level, now it's easy. And in fact, the hardest part becomes, and the focus of our thinking energy, which we don't have a lot of, is on what do I want it to do? We can talk about whether AI can do that or not, but then the implementation is easy. If you look at how much time I spend thinking versus typing the production code, production codes may be five, 10%. Sometimes it takes a little longer because I have to figure something out that I'm not aware of, but most of it is in the thinking part and then in crafting the test so that it can say, given this input, this is the output that I expect.
Nicky Pike (00:15:41):
All right. And I think, so if I'm hearing you right, most developers when they hear test driven development, they do think it's all about testing. And you're saying that that's backwards. What test driven development is, is really defining the end state so that you know what you're programming to. Exactly. Oh, exactly. All right.
Ted Young (00:15:57):
And what's great about it is there's this funny, weird feeling that I'll get when I'm writing and the code is like, is that enough? Let me try this. And so what you tend to do is like real expert test driven developers tend to say is, write less code. Can I write this in just one line of code that suffices this specific test? And some people say like, "But you're going to have to handle another condition." It's like, yes, then I'll write another test. But what happens is you end up with less code that does the job that's needed as opposed to more code that may handle something that maybe nobody asked for.
Nicky Pike (00:16:33):
And see, now I like that, right? Wait until something comes up before you start looking for edge cases. Don't try to build the edge cases in at the start. Make sure it's something that you're actually going to need before you spend the effort on it. Make the code that you're doing elegant, but make it perform a function rather than trying to write a whole bunch of other stuff.
Ted Young (00:16:52):
Right. And the common thing is like, well, but then you're going to have to do a lot of work to change something. It's like, yes, but we do that anyway. And that's why it's really important to get good at refactoring and changing the structure of code to make it more amenable to the next change you're going to put in. It's not that you don't think about the future, it's that you treat the future as, "I can kind of see where we're going, but I'm not sure." If you could predict the future, then life would be different, but we can't. We can guess and the further out to the future we try to guess, and I've experienced this as a developer where I try to say, "Oh, I'm going to make this aspect of the code super flexible because I know that's what's going to be needed." And it turns out that flexibility is useless and it's actually this other place that I hard coded stuff that they need the flexibility.
(00:17:36):
It's like, "Oh, well." And so it's a bet. It's a bet on, I think this is how it's going to happen. And I prefer to say, let me just make sure that the code is always in close enough shape that I can fit in something new or that it's not too difficult to fit in something new rather than try and predict where it's going to go.
Nicky Pike (00:17:55):
Well, and you keep pitching refactoring. And I think when most people talk about TDD, they talk about red, green and refactor, but you break it down into nine steps. People are missing something when they try to oversimplify it to just those three words,
Ted Young (00:18:09):
Yeah? Yeah, because what does it mean to have a failing test? Do I write a test and just see that it fails and then start to write code to make it pass? Well, there's an important step there, which is, did it fail for the right reason? Things go wrong for all sorts of reasons. So for example, in our buy ticket scenario, I expect that after the ticket is purchased, the concerts start out with a hundred tickets available, I purchase two of them, I expect 98 to be left. Great. Straightforward input, output, right? Input. There's other inputs, right? There's that setup part which is like, okay, I'm going to create a concert. It's got a hundred tickets available. Then the thing I'm testing is if I purchase two tickets, then I expect 98 tickets to be left. Now, if I didn't implement the purchase part, I expect it to fail by saying, "Well, the two's never subtracted and so there should still be a hundred." Okay, so that's a good failure.
(00:19:03):
And if I see that failure, I know I'm on the right track. If I see a failure like null pointer exception or concert has zero tickets because maybe it was never even saving the number of concerts that it was told how many it should start out with, then I know I've got other things I need to do before I implement this feature. And that is really important because otherwise you're writing code and then maybe your code actually does work, but there's other code that doesn't work yet. And so you find out, it's like, "Oh, I didn't actually test when I created a new concept with a hundred tickets, are there hundred tickets available if I ask it? Oh, let me go write that. " And so you find out the things that, what I call these baseline tests that you might be missing. It's like, "Oh, let me go write that.
(00:19:49):
" Or you just didn't understand something in the system because we can't understand everything in the system all the time and it just went wrong for some reason that you have no idea about. And now you have to be concerned with this lack of understanding of something. And so now you need to go explore, why did it do that? Why am I getting zero or why am I getting a thousand? What the heck is going on? What's going on? And so the other part of this process of not just failing, but failing as expected is that it verifies that you understand how the system is working and that if you don't, you need to go and figure out what are you missing. And sometimes that's like, oh duh, and you missed something or it's like, "Oh, actually my test is wrong." And that happens sometimes.
(00:20:36):
And so common thing I used to hear is, "Well, okay, we're writing tests for code. Well, who tests the test to make sure they're correct?" It's like, that's the part that does it, making sure they fail in the right way.
Nicky Pike (00:20:48):
So it's an iteration because as you find stuff, going back to your concert example, "Hey, I went and bought two tickets, but they're saying there's no zero tickets. Okay, I know I need to go write that. " I'm probably going to write another test to make sure that when I go and write that code that, okay, it does give me the proper amount of tickets this time.
Ted Young (00:21:05):
Exactly. Right. And as building these, I always think of these as building solid foundations that we can then build more stuff on. If we feel really confident in our foundation, we can have a little bit more freedom and mostly confidence that then the next thing that we build will be solid and really something that we can continue to build on. If we don't have that confidence, then we're always kind of nervous as like, is the whole thing going to fall over at some point? And so I think finding those baselines and there's some techniques, ZOMBIES from James Grenning is an acronym that I love and the ZOM part is zero one many. When you're writing tests and you're building the system, you start with, let me start with a zero case. What happens when I create this new concert event, can I get that baseline thing of if I create it and I say there are 100 tickets available, can I query it and say, "Do you have a hundred ... How many tickets do you have?
(00:21:59):
" And says, "I've got a hundred." When you first start writing that code, obviously it doesn't have that and you write that piece by piece. And then you do things like, now I sell two tickets or they're 98. Great. Now I've got confidence that works. The other thing is I can also, during this test failure part, I can make sure that when it fails, the message is useful. There's nothing worse than seeing a test fail and says, "Expected true, but was false." Thanks. Okay. And I can go look at the test and if it's well written, I can figure it out, but it would be nice to have a little bit more information.
(00:22:33):
And so using that failure opportunity to check that it fails in the right way and that we understand the system, but also that it gave us useful information when it does fail because if you write code and then test after, you kind of expect the test to pass and then you never see it fail.
(00:22:50):
And so you don't know if it's going to provide useful information.
Nicky Pike (00:22:53):
So this is really a method of giving yourself an internal feedback loop.
Ted Young (00:22:56):
It's exactly that. It is exactly the feedback loop. And the shorter the feedback loop, the faster we can go. And it's kind of this weird thing. It's like, wait, I'm going to be having to write tests in addition to writing code at the same time and I can go faster. It's like yes, because you're always getting feedback that you're on the right track. I do distance running and if you didn't have feedback frequently, you'd be off the trail in the mud. And so the faster the feedback we get, the easier it is to correct.
(00:23:28):
"Oh, wow, I'm trying to do this and it's telling me that doesn't work. Hmm, maybe there's some assumption I have about the system that's wrong. If you didn't have that check every three minutes or every minute, then you could go hours under this incorrect assumption and then find out later, oh, I made a wrong assumption.
(00:23:48):
Now I have to go back and fix hours of work. And so that's a lot of waste. And so what people don't count on is all that waste and all the time sitting in a debugger. I was using the debugger the other day because I was trying to fix a problem, which is rare that I'm a debugger. And I was like, " How do I use this functionality again? Because I haven't used it in so long, I've forgotten some of the things. "And that's the thing is I almost never spend any time in the debugger, certainly on my code. I may go through the spring framework code and it's like, " Why is it doing that? Do I understand the document correctly? Because it says this thing and not something unclear. Let me go and step through it. "But I almost never sit in a debugger for my own code when I'm doing test driven development.
Nicky Pike (00:24:30):
Well, and like you said, it's that fail fast, fail often. And I think that's a portion where a lot of people kind of get disenheartened is they go on this metric of how many lines of code did I write today, not how much useful code did I write. And there is a difference there. Absolutely. You can sit down to your point, you can write all of this code and it can be great code, but you had a wrong assumption. Now you've got to go back and either rewrite the whole thing, you got to refactor the whole thing. But if you're breaking it down into smaller steps, well then, okay, I'm only getting a hundred lines in before I figure out something's broken and I need to go fix it rather than a thousand, 2,000 lines in.
Ted Young (00:25:06):
Or 10 lines or two lines.
Nicky Pike (00:25:09):
Even better.
Ted Young (00:25:10):
Yeah. Right? I mean, this idea of ... And so this, again, this is what's in my game is like less code. Less code is helpful, fast feedback and that frequent feedback, right? So it's fast and that fast enables you to have that frequent feedback, which means this constant checking of, am I on the right track? Am I on the right track? In addition, you're making progress. Yes, it's little tiny steps, but how do we get anywhere is with steps. And so one of the things I love about TDD is unlike if I go and write code for four hours and then maybe I write some tests, during those four hours of writing code, I have no information as to whether I'm on the right track or not. It may feel that way because you get into the flow and you're writing code and I've been there and it's great.
(00:25:56):
And then you sort of pop back up into the real world and it's like, does this do what I expected to do? And whereas with TDD, it's these such tiny pieces and they're always smaller than people think. When I'm teaching a coaching test driven development, it's like, no, no, let's take a smaller step. Let's not write less than or equals. Let's just write equals. That will satisfy this test. When we get the less than, we'll have it with another test. And a lot of times people say like, "But I know it's going to be less than equals." Yes, maybe, maybe 90% of the time it will, but maybe we don't need that because maybe somewhere else is handling that situation and this piece of code doesn't need to be concerned with it. And this is what I like about the failing as expected and that word fails like, oh, but actually I love it because it's like, oh yes, it fails as expected means I'm on the right track.
(00:26:45):
And so you get all of this positive feedback frequently and it's almost like a game.
Nicky Pike (00:26:52):
Well, there you go. And that is the perfect segue. So we've talked about the core fundamentals. Now let's talk about the fun stuff. So you've got this board game that you created and I want to dig deep into this. So you mentioned when you started this board game that you kind of started out with this idea of like a memory card to flip your cards and match game and now you've got this full board game that teaches development practices. What made you come up with this idea? Because I think that's a very unique approach to teaching somebody something about technology is to have a board game that does it. How did you come up with this?
Ted Young (00:27:24):
At the time, two things were going on. One is I was teaching test driven development and I'd finally crystallized on these nine steps of what we actually do when we're doing TDD. It's figuring out what should it do, figuring out how am I going to be able to see that it did it. And then it's, okay, let me write a failing test and it should fail in the correct way and there's compilation is part of that. So it doesn't compile and now I can get it to compile, right? If I'm testing against like a new method in languages that have a compiler, it's going to say, "I can't compile this because the method that you're trying to call doesn't exist yet." And then you write that. And so all these steps, and I wanted people to memorize that. I wanted people to have that because one of the things that I did a lot of study and research on how people learn.
(00:28:06):
And one of the things that's really important is having good, solid, automatic foundation habits. In other words, this understanding of like, "I know what to do next. I don't have to think about it. I don't have to actively work to recall this information." It's almost like instantly I know exactly what to do next. And I wanted them to get to that level of fluency. So when we talk about higher level math, it's like if you don't understand your times table, if I say seven times six and you don't immediately say 42, we need to practice a little more because that needs to become automatic. Otherwise, when you get to the next levels, you're now struggling with two things, the fundamentals of multiplication and this advanced thing that you're also, you're now trying to learn. And so it's the same thing with learning anything is you need to become fluent in these lower levels.
(00:28:50):
And so I want the people to become fluent in these steps. What are the steps? What is the order? What does they mean? What do I have to do? And so like you said, I started with, well, let me put a game where you have to put these cards in a specific order. But at that point I'd been active with some friends and playing a lot of different board games and it's like, I bet I can build more on it because it's more I wanted to get in there. There's this idea of this prediction of the expectation of how a test is going to fail and I want to get that in there. And over many months and years, a lot of different people helping me refine it and then also balance it because one of the difficult things in a board game is you don't want to be boring, but you don't want it to be ... And boring can be in two ways.
(00:29:28):
One is it's so hard. I don't understand what's going on. The other is it's too easy. There are also times when there are mechanics that you can break and it's like, well, now you can just sort of ... It's not quite cheating because the rule says you can do that. And so you have to modify the rules. And so adjusting that. So I did a lot of sort of play testing on that. And I have to say, I was completely surprised at how well it worked because I had never designed a board game before and I tried to get things in that I thought were As close to the real world, because you can't simulate the real world, but as close to the real world as possible that it was meaningful. Because a lot of education games, you look at when my son was growing up, we bought a bunch of education games and it's like, these are crap because these don't translate to the real world.
(00:30:18):
And if it doesn't translate to the real world, for me, what was the point? Because the whole point was that it needs to translate so that this provides good education, a good base for them to then actually do the real work. Created prototypes and tested it out and found that people were extracting things from it that I wanted them to extract, but I actually didn't expect that they'd get right away. And it was really gratifying.
Nicky Pike (00:30:42):
Well, and this is just in my mind, and maybe this is right, and maybe this is something that you made a conscious decision on, but like the memory flip game, that's recognizing a pattern and memorization. Whereas when you're going through a process, that's muscle memory. You're learning a process. Exactly. And that process can be different every time, but it's the same steps to get there. And once you develop muscle memory, I mean, this goes to everything that we're doing, walking, running, how to write, learning English, whatever that may be, is through a process. So was that a conscious decision when you came on that game to do this versus memorization?
Ted Young (00:31:15):
Yeah. And that's what builds fluency. What is fluency except that you've done something a bajillion times and now you don't have to actively think about it. So our active thinking energy, what we have available, what's you might call your cognitive load or cognitive availability is limited and we can't really change it. And so what we have to do is we have to turn some things that required thinking into automatic instant, right? Eight times eight, 64. I don't have to actively calculate that in my head. It just is immediate. And the more we build that up through that repetition. And so when you play the game, you're going around this board multiple, multiple times, and you can make different choices each time, but you're going through that multiple times. And so you're seeing, oh, I do this, I do this, I do this and I do this.
(00:32:07):
And the more times you do it and the more times you repeat things, that's how you become fluent. And then once you're fluent in that, then you can focus on the other things that are actually harder to think about and require more of your thought of like, "Well, what should it do? And how am I going to tell that it does it? " Then you can spend your energy on that as opposed to what is the next step. But you got to start somewhere and so the game can help build some of that fluency.
Nicky Pike (00:32:32):
Well, and I kind of looked over the game. One of the things that I really loved is that you have this risk mechanic in it where players can skip tests so that they can move faster, but accumulates risk. To me, this mirrors real world development. So what happens in the game when they do those that they take that risk mechanism, they skip test, but they accumulate risk. What happens in the game when that catches up with them?
Ted Young (00:32:53):
Yeah. So there are certain points where they can decide, you know what? Heck, with writing tests, I'm just going to skip ahead to implementing the feature because that's what I care about. That's what I want to do. And so you take on what I call cycle risk, which is basically at the end when you need to commit, it kind of is this idea of, okay, we're going to run a whole bunch of tests. We're going to sort of do all our integration tests and there's a risk that because you skipped testing your work, that it's going to fail. If it does fail, you basically lose all, in a sense, all the work that you've done going around the board and you basically have to back up and you don't get any points. Sometimes though, as it mirrors the real world, it passes all the integration tests, even though there's actually maybe a bug there that just hasn't been exposed by the tests that you currently have.
(00:33:37):
And so that builds up code risk. So you've committed your code, that risk is not gone. It's still there. It just hasn't popped up yet. And so if you go around the board again, that risk is still there. And you might have a problem that was from three times around the board ago that now kills you on your current turn. And again, that's kind of realistic.That bug's been sitting there for days, weeks, perhaps months, and then something you do triggers it and causes your thing to fail. It's like, but it wasn't my fault I did it correctly. It's like, well, that's what happens.
Nicky Pike (00:34:14):
Congratulations. You just got hit by the technical debt monster.
Ted Young (00:34:18):
Exactly. Exactly. And that was a mechanic I had to adjust. And there are ways to resolve it. There are ways to get that risk back down, which is refactoring and basically reorganizing the code. And then maybe it reveals some things that you didn't find. And the risk isn't necessarily just bugs. So you mentioned tech debt. Tech debt isn't always just that there's a bug and we haven't fixed it. It's the code is organized and structured in a way that is awkward.
(00:34:45):
It kind of worked, but then the next time we want to go in and add something, it's really kind of awkward. I've got 49 if L statements, do I add one more or do I refactor the thing? This was literally a situation I had when I was at Google. What did I do? I added the 50th because I didn't know enough about the code to refactor it yet and I didn't know enough about refactoring. This is a while ago. And the way that blows up is now we've got to add the 51st and you just can't. You just can't figure out how to do it because now you need to sit and refactor it. And so it's like any maintenance that we do on any physical system, the longer you leave it, the longer it's going to take then to fix it. If you dust every day, you don't get a pile of dust and have to then bring in cleaners.
(00:35:25):
You can do it every day and things remain in good shape. But if you delay it for like three months, well, now you've got a lot of work to do. And it's the same idea. And so this code risk is not just they're latent bugs, but that the next time you need to write your test, you observe something that's really bizarre and now you don't know what's going on because the code is hard to understand.
Nicky Pike (00:35:48):
Well, and you mentioned at the very start when you were talking in your teaching classes on this, that you get a lot of people who come in and says, "Okay, what happens if we do this? " Do you see the same thing in the game as the game opening up those type of conversations that maybe were a little bit difficult to have before?
Ted Young (00:36:02):
Yes, exactly. And this was sort of a part I didn't quite expect. And there's another part that I also didn't expect that I'll bring in is a lot of times when we're sitting in the code and we've written some code and trying to get people to do something different, it's hard because I'm showing perhaps my failure, something I don't know and so fear of not looking like what you're talking about, and we all get this, but when you're playing a game, first of all, it's fun. Any kind of group thing where maybe there's a little competition or just trying to reach a goal, it's fun and it can then shift the environment for having these conversations of like, "Hey, I'm going to try to take a risk to see what happens." And so people try things and then they see the repercussion or they say, "Boy, last time my prediction failed because I wrote too much code.
(00:36:52):
Let me write less code this time." And that's learning. And they may not realize it at that point, how it translates, but they're learning and they're talking about it. And I find that technical coach is something that I also do, it really helps have these discussions without sitting in front of code, perhaps even the real code and having all these fears and sunk costs and loss aversion of, "I don't want to touch this code and work with it. " And in addition, people started, when I was watching people play, people ask questions of like, "Hey, because it's an open card game, you can see everybody's hand what cards they have. It's like, Hey, I could really use that person's card. Can we trade?" And I'm like, "Huh, I hadn't thought of that. Sure, try it out, see what happens." And so they traded and so on.
(00:37:36):
It's like, "Hey, can we pair up?" Obviously the audience knew a little bit about pairing. It's like, "Can we pair up and combine ourselves?" Sure, go for it. And so what was fascinating is then how that again mirrored the real world of instead of trying to push four ponds around the board, maybe we push just two. And so there are two pairs or maybe there's just one and everybody's job is to push that pond forward. Wow, that pond's going really fast. It's like, yes. And if we do mob programming or ensembling, that's what happens as well. And so, okay, maybe it's not four times as fast, but it's faster and we're making fewer mistakes. And so it was sort of mind blowing and I was just thrilled when people started making these suggestions because what's the goal? The goal is to get functionality. It's not, like you're saying, works for writing lines of code.
(00:38:31):
Hopefully that's never a goal, although I've seen that as a metric and that's terrible. It's to get functionality out so that people can use it and have value from that. And so focusing on that, and so having these kinds of discussions and ideas really shows that people are thinking about, well, okay, how can I play the game better, but how well that translates then back to the real world.
Nicky Pike (00:38:55):
Well, and you sat there, you said, "Well, this is a game and it's fun." And I'm sure there's a lot of people out there that are listening and going to be, "Yeah, but this is a game about test-driven development. How fun can it be? " But you actually play tested this with non-developers who are just board game players. So did that help you develop the game? What did those people think of it and how did it hold up with non-technical people playing the game?
Ted Young (00:39:15):
At this retreat that I was at, which is sort of this unconference, just very small retreat. And a couple of the people that were in the session of helping me work on this game were not developers. One was totally not a developer, not even in software development at all, and another was more focused on graphic design, but they were board game players and then they were interested in the game. And they made some good suggestions on some of the mechanics, but ultimately it's a game. What is a game? It has a win condition, it has rules, how do you get to that win conditionist, bad things that can happen. And so even at that level, maybe I shouldn't have been surprised, but I was surprised of like, oh, they're actually having fun and enjoying it and they wanted to play again. That's always the thing that tells you is like, do they want to play again?
(00:40:02):
I was like, yeah, that was fine and then enough, but they wanted to play again and had ideas against some of the mechanics because they understood how board games work. And it's like, "Hey, if we do this or if we add on this, that might make this more interesting." And so I've had the game played by folks who are not developers and couldn't tell you were a factor from a stick. And it was still fun, which was really nice because it really told me that this holds up as a game and therefore something that people will want to play again. And it's not just, "Oh, here, go and play this game. We're forcing you so you can learn something." It's like, "Oh, it's actually fun."
Nicky Pike (00:40:41):
Well, and one of the things that I like most about your approach here is that we're always, especially in the technology field, we tend to get lost. We don't always put family first, but this seems like a good way to get kids involved in technology and development. And so I guess my question is, are you seeing people kind of pick this up as a dual purpose? "Hey, I want to spend time with my kiddos, but I also want to start teaching them about tech and maybe teaching them how to think like a developer."
Ted Young (00:41:04):
I know some people do that and I've tried to get my son to play it and we played it once and he's like, "Eh, this isn't my cup of tea." He's more of a magic the gathering kind of guy. I'm always thinking of my next ... The thing about boy games is like you're always thinking about the next game. I actually am thinking about the next game and it's like, "Oh, can I do a Magic The Gathering kind of thing?" But I think I have mixed feelings about ... I want kids to grow up with an understanding of technology and be familiar with it. I think this game is a bit too narrow to give some of that, but I think it's worked really well for folks who are just starting out learning. So I've had several folks who are in a university buy the board game to play with their peers and I think it introduces stuff that I think you want to be thinking about early on.
(00:41:53):
And so that's kind of my hope is that the people who are ... Or maybe if you're a kid and you want to do some programming, maybe this will put you on the right track to at least think about how you're approaching writing your little app. It's like if we can start shifting people to think about how you code from the beginning, then that can help. At least it can influence some of their thinking to say, "Maybe I can break this down into smaller pieces. Maybe I can take less risk by doing this other thing. Maybe I can do more thinking about what the thing is going to do and how am I going to tell that it does it at the beginning as opposed to later on what I have to write tests after."
Nicky Pike (00:42:31):
I like the game. I got the game. I've only went through it twice, kind of getting ready for this. I do think it's a neat way to not only bring in technology, but also kind of making some of those corporate meetings, the enterprise meetings where you want to talk about technology a little bit more fun. Here's a game that we can get started, this will be the basis. So I like that. We're going to make sure that we link this in the description below, but let's go ahead and let's move this on to actual practice, right? One of the things that you said was that you like to differentiate between test first and test driven. Kind of break that down. What's the practical difference and why does it matter so much?
Ted Young (00:43:06):
So I think it comes down to what I call right sizing the problem, which means, and as part of this breaking this ... So you get this feature, you talk with the people who are defining the feature, whether they're product owners or whatever you want, stakeholders, whatever you want to call them, they say, "Hey, we need the thing to do this. " And then you'll say, "Well, there's trade-offs. Let's talk about the trade-offs." Hopefully you're doing that. Hopefully you're not just an order taker of like, "Yes, yes, sir, let me go and implement this ticket," that you're figuring out what is the way that balances how much work we have to do with what are the benefits. So you figured that out, but now you've got, and it's well-defined, you understand it. Well, now what do you do? And so test first is a good place to start, but test first is not enough.
(00:43:56):
So the test driven part, a lot of people hear that word test and they're like, "Oh, I got to write tests. I don't like writing tests." And I'm always fascinated by people who are like, "I don't like writing tests." And you always explore why and it's because it's hard to test things after the code's written and often you have to write a lot and then you get into mocking frameworks and that disaster and all kinds of things. And so test first, I see as just the general way of let me think about, and it's a good first step, let me think about what do I want the system to do in a fairly precise way. Test driven means we're going to react to what the tests tell us, right? We're going to discover things along the way that, again, that fast feedback. So we're going to use that fast feedback to change perhaps the direction we're going.
(00:44:44):
And so that's really to me kind of the difference. And it might seem minor. It's like, okay, so now I'm taking smaller steps and getting faster feedback, but that changes how you do development. It's now, like I said, you might end up with less code that gives you the functionality you need. You might discover, oh, if we do this other thing, hey, we figured out that we can use this other thing and get where we need to go. And so to me, agile these days as a term, leaves a bad taste in people's mouth and has a bad reputation as being the opposite of what it initially meant, which is like micromanaging and tickets and all this kind of crap. And to me, it's really about if you have fast feedback, you can maneuver easily. If you're taking small steps, you can quickly shift direction.
(00:45:33):
And so what I want is I don't want to deliver software faster. I want to deliver software sooner. In other words, I want to get value out to people sooner. And so if I can maneuver more quickly and say, "Hey, there are actually these two pieces. If we deliver this first one and then the second one, people can start using this first one and get value." To me, that was the fundamental aspect of Agile is get people to use it because then that provides another avenue of feedback. And so really it's a matter of scale. And so it's, can I break things down to small pieces, but also have them be cohesive and valuable enough in and of themselves. And so I think that's the way I think about the difference between general test first, "Oh, let me write an end-to-end test and then three weeks later it passes versus the day by day, hour by error, minute by minute how I'm doing things."
Nicky Pike (00:46:26):
Well, and you mentioned people hate writing tests, but I think that's kind of a consequence of what you had mentioned earlier, which is kind of the traditional way is we write a whole bunch of code, there's this separation of concerns, we send it off to a tester. Now the tester's got to try to write test around all this code. We're kind of bringing this back in because we had another guest on who talked about bringing in developers where they think developers and testers are going to kind of blend and we'll see like this, what's the word I'm looking for, the discipline, right? "I'm a developer, but I'll have a developer with a discipline and test and so on and so forth." Your method helps the developer write the code in the way that it should be written, which leaves the tester, the person that's going to specialize really looking for the edge cases.
(00:47:07):
So they're not having to write huge, humongous batches of test trying to fix the code because the core functionality has already been done. We're just looking for edge cases and specialized conditions at that point, yeah?
Ted Young (00:47:19):
Yeah. I worked in companies where we had that situation, right? Your developers write the code and we would write tests too, but we'd write them after, but there were still developer tests. And then we'd have a QA group that would then go and basically do their own testing and sometimes they would write some automated tests like, "Well, why are they writing automation?" Like you said, it's like really what we want is we want the developers to be responsible for the code and say, "I think this is exactly what it needs to do. " And if you're doing test driven development, it's going to do exactly what you expected it to do. However, that may not be what it should do. And that to me is where testers who do exploratory testing and find out weird mixtures, like weird mixtures of things that they do that we said, "If you do this, it will do this.
(00:48:06):
" Guaranteed, we have a test that says so. But it turns out at higher levels, as you explore different ways of doing things and you understand what the system is supposed to be doing, you may find places where it's like, "Oh, when you do this, weird thing happens." And it's like, well, we look, well, at each individual piece, they all did the right thing in terms of, we said if it does A, then it should do B. But at a higher system level, it doesn't quite work that way, but at least we know what to do. And so the testers are not dealing with these little bugs where it's like, "This should have worked, this should have done." And that's where QA kind of get bottleneck is they're dealing with the stuff that developers should have fixed. They should have found and fixed or just not written in the first place.
(00:48:58):
These kinds of problems is the more holistic kinds of testing that I want the QA because they're really the domain experts. I worked with some really good exploratory testers and they're the domain experts. They understand things deeply and I want them to be able to explore the application from that point of view and not get bogged down with little errors like, "Oh, I typed in a 99 and it said it was more than 100 or something like that. " It's like, no, let me work at that higher level of abstraction.
Nicky Pike (00:49:25):
And so when you're coaching people and you're going through this or when you're doing your live stream on Twitch and you're doing your live stream coding, what's the one mistake that you see people make the most when it comes to TDD?
Ted Young (00:49:36):
Not breaking things down into small enough pieces. I do that all the time. It's like, "Ah, this is just too big." But again, what's nice is you get that feedback early. It's like, "Oh, this is no way I can test it. " The other thing is not reading carefully the failing test. So even if you're doing TDD and the test is going to fail and you're going to make changes to other parts of the code, and we haven't really touched on this, but you're right, you have now all these tests that are safety net. There's so many times where it's like, I thought that failure meant one thing, and so I go and try and fix that and I have the wrong assumption. And I'm like, "I don't understand this. " And you're looking at the code and maybe even asking an LLM and it's like, "No, this works." And then you go back and look at the test and like, ugh, it's like, where'd you lose your keys?
(00:50:26):
It's like while you're looking under the lamplight, you didn't lose your keys there. It's like, well, that's where the light is. And so it's like you're looking in the wrong place and so of course you're not going to find it. And that happens because we get habituated to things and we make assumptions. And the hardest thing is sort of battling against that and saying, no, let me read this carefully, this failure and really try to understand what is it saying. And if I don't, maybe I need to fix the error message or maybe there's something I need to explore, but it is so easy to look at something and our brains are pattern matchers and pattern match against the wrong thing. And then you go off and I've sometimes spent like, this maybe not seem like a long time to some people, but like I've spent 15, 20 minutes trying to figure this out and realize I am looking in the wrong place.
(00:51:11):
It's hard and it happens all the time. But if you're aware of it and you sort of time box like, "How long do you want to try to figure out what's going on? Let me set for 10 minutes. And if not, let me go run this again." And so you'll see me on stream or I'll watch people. It's like, "Why do you think it's over here? This test is saying something else." And they're like, "Oh, of course." And then you find it like two seconds later and it's like, "Oh, it's this thing." And then you go fix it and you go on your way. Yeah.
Nicky Pike (00:51:39):
Yeah.
Ted Young (00:51:40):
Lots of face poms.
Nicky Pike (00:51:41):
Yep. Well, you brought up LLMs, right? We can't go through this without talking about LLMs. We're going into 2026, AI's in the room now and it's changing the way that we code, Ted. So the fact that you keep mentioning work in small steps, specifications, writing tests for the outcomes, all of that stuff seems to fall in line with AI because right now the reality is a lot of developers are going out, they're prompting ... To your point, build me that shopping cart app or build me that ticketing app. And when they're getting garbage back that they don't understand, they're like, "Well, AI sucks." But it feels like the method that you're describing is something that actually would work very well with AI if you're able to take those small steps, those small increments and give it an idea of what good looks like before you ever ask it for code.
(00:52:29):
Are you doing that today? Is that something that you're trying out?
Ted Young (00:52:32):
It's funny that these techniques of being precise about the behavior that you want in a way that you can code, that breaking that problem down into small pieces so that it's not a lot of work and you can get this quick feedback, it's kind of funny how the LLMs seem to work really well with that up to a certain point. I've done a bunch of playing around with them doing ... I have to write the test. You can't get around that because you have to write the behavior that you desire, right? The LLM's not going to read your mind. So you have to define that behavior upfront. And I like to write it as a test because I know how to write tests and I know that the test is going to be concise. LLMs are code generators of the average of the code they've been trained with.
(00:53:22):
And I'll be honest, the average code is average. It's not great. I hope to write better than average code. And so if you say, "Here's some tests, go now write code that passes those tests," it'll do it up to a certain point when the problem and the context get large enough or it's changing something and then one test passes, but then other tests fail and then it's sort of going back and forth.
(00:53:50):
And so I think it can be helpful in some cases, but honestly, like I was saying before, the coding part, the production code part is such actually a small percentage of the time that I spend. If it's 10% of the time I spend and it can now make it 5%, great, I'm a little bit faster, but I also have to understand the code because I'm going to be working with it. As I said before, if it could generate everything and I never look at the code because it can do enough, that's a different story, but we're not there. I still have to understand the code. And so the way that we understand things is best when we generate them, when we write them. So I'm fine with sort of having it do auto completion, especially in test is sometimes a fair amount of boilerplate, although I try to refactor away from that.
(00:54:41):
It's great at that, although half the time it guesses stuff that makes no sense just because it pattern matched and saw stuff and it's like, "Oh, let me do more of that. " It's like, "Yeah, not this time."
(00:54:51):
And so there's a danger of having it write the code, which as I said, that's not the hard part. And that's what I think folks don't get when you're really doing test-driven development. You've basically said, "I want this thing to do something that's so trivial." And by trivial, I mean it's straightforward because you've already broken down the problem. You've already set up how things are going to work, the inputs and expected outputs, and you've organized it and you've already done the organization of where the code goes. And now I'm just writing some code. And to me, that's always the easiest part. The other danger is LLMs love to generate code. They love to generate lots of code. You want to write the least amount of code that solves this problem. Now, there are prompts and things you can do and ways you can modify the problems to have it try and do that, but it feels like a lot of struggling against what sort of the nature of the LLM is.
(00:55:50):
All less to say though, I think it has its place for me more as a smart rubber duck, a rubber duct that talks back. So I do a lot of like, "Hey, what things am I not thinking about in this case?" So I'm now more on the thinking about the problem, thinking about the solution, saying, "Are there any things that I'm missing here?" So one of the things I'm working on is vent sourcing. And so the way you learn about stuff is you've created a project. And so I had this concert ticketing app that's my example project for learning event sourcing. And I'm basically saying, "Well, I want to make sure that transactionally this stuff works and so on. " And I've read a lot, so I have now some baseline background knowledge, but now I can toss ideas at it. Again, assuming that it's going to be just generating stuff based on its training data so it doesn't know anything, but it provides me places, oh, I need to explore that more deeply.
(00:56:43):
Let's look at identifiers and sequence numbers and positions of whatever. I don't know a lot about that. Can you write me some code so I can see what that might look like? But that's just so I can learn and then I'm going to go and write it from scratch. So I find as this way to help me find things that I might've missed, and sometimes it is just talking it out, generating lots of code. If it's for a spike, the spike, which is I'm going to go off and try some stuff out, code that will never be committed to production, just so I can see, is this going to work? Because that's also a lot of time spent on, "I have no idea. I've never done this before. Is this even going to work?" Was this designed ... You don't want to commit to something and then find out, "Oh crap, I need to change this.
(00:57:31):
If only I had done a small example of this over here in a sort of a safer place, then I wouldn't have done that and would have saved myself some time." And that's part of the design aspect when we're designing our solution that we need to do. And so I think the LLMs can help a lot with that because they can generate a whole thing and I can look at it and try it out. It's like, "I think this is good and then I'll go back and TDD it by hand with some auto complete."
Nicky Pike (00:57:54):
Well, and that does seem like the benefit to me is because it can type, it can generate. And to your point, yes, it does love to generate code. It's the happy puppy that just wants to make its owner happy. So I'm going to give you all this stuff, but it does seem like it could take some of that toil out. First, what we were talking about, writing in specification, here's the specification. Now, based on that specification, let's create these tests and let's create this code. We get all that majority out of the way, maybe 50% of the code, 60%. Now I could go back and I can iterate on that, because let's be honest, that's something that the human mind does. Let's see if people get upset with me, but true creativity is not rampant. A lot of people take something and they improve upon it.
(00:58:33):
"Hey, here's an idea. I'm going to take this idea. Now, why does it do this? I'm going to make it a little bit better. "It seems like now AI can be that partner for us to go in and create something and now we can iterate on it without having to write it all from scratch. But 100% agree with you. You do need to know the code, you need to know what it's going to do. There's arguments that AI can help you learn the code because if you treat it correctly, but do you see that as a workflow as somebody coming in, here's my specification, let's go ahead and get some base test, base code out of the way and then take what that is and iterate on it and make it what I need it to be.
Ted Young (00:59:06):
I know people do that and I've seen them do it and people who are respect and learn from doing that. And I think it depends on your goal. Certainly for things like, " Hey, I want to do a side project because I want to learn this technology, "there might be places where you can sort of fast forward past some of the boilerplate, but ultimately you kind of still need to understand what is that boilerplate doing. I'll ask the LLM to do something, it'll generate some code. I'll look through. It's like, " Yeah, I understand that. If not, I'm going to ask, what does this mean? Why did you do that? "Or it generates something weird. And I'm like, " Well, what's this? "And often it'll say," Oh, you're right. It should do this other thing and then generates the correct thing. "And so as long as we treat it as just a very fancy template generator, I just think that we might be setting ourselves up for problems down the road.
(00:59:53):
That's my fear. We already have a lot of code we don't quite understand. And so the LLMs can help us with that because we can sort of ask questions Explore and it can point some things out and bring in information that we might have to manually go search. I think it's really good at that. But I honestly worry about all the code that's being generated that people don't understand and that works for whatever definition of works is. But then when problems come up, how easily are you going to be able to solve it and figure it out?
(01:00:26):
I run a book club, a technical book club. One of the books we've read recently was Balancing Coupling and Software Design by Vlad Konov. And it talks about basically modularization at every single level and how to measure it. And so there's this idea of distance and size and all these things have to do with ... We toss around words like coupling and cohesion, but this book really gets precise about what do these things actually mean and what's good and what's not. And I saw some folks actually try to integrate that information. There are little formulas in the book into these prompts for that. And I think if we start going that way and start basically having the LLMs generate in a much more constrained way where we're saying, "Look, if you put this code here and here and they're sharing this kind of information, that's bad." And if we can give more of that, then I think it can do a better job and I'd be more willing to let it run a little bit.
(01:01:17):
But ultimately we still have to define what that behavior is. And so for better or for worse, LLMs are forcing us to face that we may not have been precise before or we may not have understood what we wanted before. Now we really have to, otherwise it won't generate the right thing. And so I think ultimately, at least that's good.
Nicky Pike (01:01:37):
Yeah. And the speed at which things are going, Ted, I mean, who knows what the next six months is going to show as we get in there. And man, this has been awesome. I could probably go on and talk for another 20 or 30 minutes, but we're already a little bit over. So I'm going to go ahead and start wrapping this up.
Ted Young (01:01:52):
Sounds
Nicky Pike (01:01:53):
Good. So before we close, we ask every guest the same question. You've been working for years with TDD, coaching developers, designing your own teaching tools. What does it mean to you to be a coder?
Ted Young (01:02:03):
To make other people's lives better. So there's two parts to coding. There's the fun and creativity of coding. We've talked a little bit about creativity in the context of sort of AI and LLMs. And I like coding. I like the creativity because there are constraints that you have to fit in. It has to compile. It has to be organized. And so creativity comes from constraints. If you have no constraints, who cares? But ultimately it's the why. Why am I doing this? Why did I write the SOC charting app when I was a kid? It's like because my dad needed it. And there was nothing better than, "Hey dad, look at this. I implemented this technique called point and figure charting." And he was like, "Oh my God, that's awesome." There's no better feeling than thrilling your users. And to me, this is why I kind of never did well in situations where the person who's actually going to use it and get what they needed to get done, if I didn't have them face to face, it was a lot harder for me to be motivated.
(01:03:09):
So to me, yes, I enjoy the act of coding, but I also, I do it for that result of that thrilled user.
Nicky Pike (01:03:17):
Man, thank you. I think that's one of the most honest answers I've heard. And I love that answer because I've got this statement about the three most important groups of people I think in the world are going to be truck drivers, farmers, and software developers. And a lot of people look at me, software developers, you're crazy. Well, name one thing that doesn't have software in it. For better or worse, yeah, showing one person really that doesn't have apps that they rely on to make their day easier and better. Software developers are responsible for us having the lives that we've got today. So I love the fact that you said that's one of your motivations is just to make people's life better. All right. Hot seat question time. Give me your most controversial take on TDD that would get you viewed off stage. You right? What is the truth about test-driven development that the industry's not quite ready to hear yet?
Ted Young (01:04:04):
It's a faster way to develop. It's like, because everybody always says, "What? But I'm having to basically write at least as much tests, if not more tests than code. How could that possibly be faster?" And it's like, nope, it's faster. Faster, less code. Unless you've done it, you don't believe me. Your crazy talk.
Nicky Pike (01:04:20):
And do you accept that challenge on Twitch as somebody like, "Nah, Ted, you're wrong. If I got to write all this test, you know what? Let's jump on. Let's do this.
Ted Young (01:04:26):
" I've done that. I've also done experiments. And there are times when it's like, look, I just need to ... These days, I probably just get an LM to do it. But a few years ago, it's like there's some functionality I needed and I do it without TDD. And it worked because I've been doing this for a while, so I can get stuff to work, but I'm kind of afraid to touch it. It's one of those things, and so the balancing cumbling book talks about volatility. It's like it's not volatile code. It's code that doesn't get used much. It's code that the functionality doesn't need to change. And so it's fine. It's fine. But I can say, I think there's code in there that I'm worried about, but we'll get there when it breaks.
Nicky Pike (01:05:07):
Yep. All right. So for the folks that want to get their hands on the board game or they want to see you live coding on Twitch, where should they go?
Ted Young (01:05:14):
So for the board game, if you go to td.cards, that'll get you to a page with information about the game. If you want to find out about me, I'm on pretty much all the major social media from ... Obviously I stream on Twitch and so I'm Jitter Ted in most places. But if you go to Ted.dev/About, you'll see all the places on social media that I'm at. I also do a lot of talks at conferences and online. So if you go to Ted.dev/talks, I do a lot of TED Talks. Yeah. And you can see the talks I've got coming up and recordings from past talks. And then on Twitch, you can tune into JitterTet and watch me make lots of mistakes, but catch them early because I'm doing TVD.
Nicky Pike (01:05:54):
Nice. All right. And we'll make sure that we get all those links down in the show notes. So last question. Can we consider you a full-fledged member of the [Dev]olution?
Ted Young (01:06:02):
Absolutely.
Nicky Pike (01:06:03):
Excellent. Man, it's been a lot of fun. I appreciate it. I'm sure we'll talk again, but make sure you get to check out the links, go see Jitter Ted, make sure you try out the board game. It's a lot of fun. Thanks for having me.
Thank you for listening to [Dev]olution. If you've got something for us to decode, let me know. You can message me, Nicky Pike on LinkedIn or join our Discord community and drop it there. And seriously, don't forget to subscribe. You do not want to miss what's next.