Jon Reid, book author and iOS Unit Testing Champion

Jeroen Leenarts: Hi, and welcome to another special edition of my podcast. I'm sitting here with John Reed, you might have heard of him online under the acronym cue coding, because he has a website quality coding. And he does a lot of stuff for iOS developers, and also Mac developers in relation to unit testing. So if you look for unit testing online, there, you're bound to end up on his website. So John, Hi, how you doing today? Hey, Jeroen, Jon Reid: good to see you. Good to be with you. Again. Jeroen Leenarts: It's been a while. Jon Reid: It's been a very strange two years since we were together. Because Jeroen Leenarts: John and I actually met each other in person. It's close to two years ago, or so not entirely in 2020, I think it was. And well, we decided to do a workshop in Amsterdam. And John had some other engagement in the area. So and then, hey, let's do it. Let's sell tickets and see what happens. And pretty much that was right at the beginning of the very first lockdown we had in the in the Netherlands. And actually, John was very lucky to afterwards be able to get home to the US afterwards, because it was a bit tense. In hindsight, Jon Reid: it was it was a little dicey there as well. Yeah. Jeroen Leenarts: So but fortunately, yeah, we're both of us are still in one piece. We're almost two years later. And this is actually the first time that we're speaking again, face to face. So has been too long, because I really was. So looking forward to interviewing you for my podcast. But to put the focus back on your job, quality coding, you're known, at least in my book for unit testing. How did that happen? Jon Reid: How did that happen? Oh, you got some time, I've got a story to tell. Yeah, um, you know, when I first started coding, I, for the longest time, I would be like the only programmer on a project. So I wasn't working for any software companies, I was working for any place that needed a coder. And I was the coder on a project, which means meant I could do whatever I wanted. And that was fine. And it wasn't until I moved to Silicon Valley that I joined a real software company and understood that it was a very different game, very different, to have so many people in a code base, and quality issues and bug tracking and all that kind of thing that you don't normally have to worry about as a solo developer. So that was, that was a sort of a rude introduction for me into how things really work. And along the way, I became very interested in very passionate about working better about having a better sort of coding home as it were making your code a good place to live, making it a happy place and not a painful place. And I saw one of my managers saw that I was not very engaged with the actual work. And to his credit, and I still thank him, instead of firing me. He said, You know, why don't you start writing? Internally, like, put up some best practices, make a wiki, wiki use Word, we're new then. And so I started exploring what that was like and started writing, just for our group of developers try to document what what our practices should be in that environment. And that was the start of me being trying to write and trying to shift a group into better practices. Eventually, then that will that sort of kept going. And then eventually, I thought, You know what, I've been doing all this internally. Nobody outside in the outside world knows what it is. I wonder what if I set up a blog, what would happen? And that was the start of quality coding. Jeroen Leenarts: So that's a very concise and condensed version of, of history, because how long have you actually been been coding by now? Oh, gosh, Jon Reid: I know. Jeroen Leenarts: I am I even at liberty to ask so. Jon Reid: I mean, it's been a long time since I first started as a junior high kid. Working in basic Well, I did a little Fortran before basic on punch cards, believe it or not there that dates me. I have punch card experience, Jeroen Leenarts: I know what computer where you're working on. Or, of course, you had to bring your bucket of punch cards to the operating room, and then they would like load them up. And then you got your results. And there was a buck in there. Jon Reid: Yes, that was that was part of the painful sort of introduction to feeling the how long of a loop you have, how long does it take to get feedback on whether what you did is correct or incorrect. And in high school, actually. So I grew up in Japan, in Tokyo, going to an American school there. And the way it worked, I wasn't even part of the programming class, I sort of begged the teacher can I do some things? I'm very interested in this. And what teacher turns that down. So the teacher let me submit programs along with the other students. And they would package up the cards on Friday and send them to downtown Tokyo over the weekend, where a company had donated time on their mainframe to run over the weekend. And then we would get the results back on Monday. Think of that as far as like a loop goes in a if you do all that. And then you find out you have a syntax error. Jeroen Leenarts: Yeah, on your first card, right. Jon Reid: It's, it's terrible. It's terrible. So I think my journey has been a lot of it has been about making that loop smaller and smaller. And certainly IDs have helped with that. We used to be that you had to compile to see if you had a syntax error. Now the IDE sort of picks it up and puts a red squiggly line, or something underneath anything it detects, and gives you gives you some good clues there. But IDE s can only know about the programming language and about any types you define. But not about the behavior, not about the logic. They won't really help you with that. And so that's where for me, unit tests have come in as as the strong way to say how do I how do I validate that the behavior I want is still good. And the cool thing that cool, cool, cool thing about working in tight feedback loops is that when that feedback loop, as that feedback loop gets faster, and faster and smaller and smaller, something changes, you're no longer saying run tests and then going to get a cup of coffee. In fact, you're no longer running tests and then having your mind go off somewhere. I'll check Twitter for a little bit. While I'm waiting for the results. You're if with fast running tests, you get the results immediately. And this means you can be free to fool around and have fun again, and say well, what happens if I try this? Does this work? Yes or no? I did work. Hooray. Jeroen Leenarts: So what it means to showcase is that you are have the ceh for high passion for like helping other developers reach those same goals. We'd like short feedback loops. But I wanted to dive into you as a person a little bit first job, because you're you're from Japan originally, but at what age did you well basically skip over the pond and became somebody who was situated in the US. Jon Reid: That was to go to university. Jeroen Leenarts: Yeah. So it was education that brought you to, to the United States. Yeah. Jon Reid: I was, as they say, made in Japan. Jeroen Leenarts: And you have your full Japanese parents, right? Jon Reid: I'm half Japanese, half German. My mother was Japanese and my father was American. Okay. Jeroen Leenarts: And and your family lived back then. In Japan, I guess. Yeah. So what year was it that you started your education? Jon Reid: Started going to Purdue University in 19 8019. Now, now you can date me. Jeroen Leenarts: Hold on, let me get my carbon data here. Jon Reid: No. And honestly, that year that freshman year at college, they were still using punch cards. I was disappointed because I had moved beyond punch cards by that point. Okay. But I went to university and that was the last year that they were using punch cards. Jeroen Leenarts: So that There was like a. Well, a bit of a setback maybe. But what came after punchcard? Was it like immediately floppy disk? Or was tape or what was it back then? Jon Reid: It was? No, it was CRTs plugged into a mini computer. Yeah. Yeah. Jeroen Leenarts: So yeah, the terminal in the true sense of the word. It was just a screen and a keyboard and a very long cable into the server room. And that's all it was. Okay, cool. Because what's very funny, actually, is that the year that you started your studies is actually the year I turned one, so I can't remember anymore. What's going on then? But I know by the time it was 1986, I think, I think I was I think I got my hands on like my, the first bits of computer actually, my dad, he was really into this set expectrum space by seeing things like a bit of a Commodore 64 type thing. Yeah, yeah. And but did you? What was the time that you got your own computer at home then? Was it also around that time or a little bit later? Jon Reid: Oh, I didn't get a computer. Actually, it was around that time that I got my first computer, but it was a big, heavy. So called portable, compact, portable, which was basically running. It was called compact, but it was basically running an IBM System. It was like a sewing machine. Jeroen Leenarts: Yeah, huge battery and like, tiny, tiny screen and then you if you're just getting the train thing around, it required a wheelbarrow, right? Oh, yeah. Jon Reid: It was heavy. Jeroen Leenarts: Okay. Jon Reid: I don't use it very much. Jeroen Leenarts: Yeah, those terminals were way better. Right. So but um, you did your studies. And then you were already I think in San Francisco by the upper universities in San Francisco. Jon Reid: No, Purdue is right. In. I was going to say the middle but that's not true. It's in the Midwest. It's in Indiana. Okay. So under the under the Great Lakes. In the towards the center right of Northern USA. There are a whole bunch of lakes, big giant lakes there. And under that, Jeroen Leenarts: it does show that I should have paid more attention during geography class. Back in the day. So yeah, I know where it is right now. But then why Purdue University then back. Jon Reid: I was close to where my family? My father grew up. And I wanted to be around his family. Jeroen Leenarts: Okay. Yeah. Because then you have some social network around you. That's something different than Facebook. Oh, by the way. So but you got started at your first job? What was it like back in the day? Because for me, it's just, you know, PC computers and stuff that you were working on? But I don't think that was the case back then. Right. Jon Reid: Actually, no, I, my first job was working on a PC. Literally an IBM PC. Jeroen Leenarts: Okay, so the couldn't get any blue or a PC compressor that then so but what what was your first job then Jon Reid: a company that made a radical idea at the time that was to have a full powerful database running on a PC. And so this is a company started from probably from a professor at Purdue University because it was in the area. And they had a nice relational database, full relational database running on on PCs, and then a lighter version. and, oddly enough, I didn't work on either. Instead, I worked for the finance department to help them with their bookkeeping, they not wanted somebody to code up ways to keep track of their business. Jeroen Leenarts: Okay, and this database is it's something that's still around today or now No, it's long gone now because I know sometimes you have like this, this this piece of software that are around today and that have like this whole backstory that goes well, in computer science, it goes back to the Stone Age, so to say, some of you were working on like financial software then was it like, what you were expecting back then? Or you just what was your path then? Because Jon Reid: I just went along and wasn't very creative or inspired. I enjoyed programming and that was programming. So that was good enough. Jeroen Leenarts: Okay. And when did you meet that manager that told you To start writing some stuff down, and that they're the, the the seed was planted for you to well, at some point, create your own business in consulting and, and coaching and teaching other developers. Jon Reid: Yeah, well, that wasn't until much later when I moved to California. And I started work. When I first moved to California, I worked for Clarus, which was Apple's software company. It's still exists, oddly enough. But I lost my job within two years, because Steve Jobs came back and said that he didn't like this company that was making Mac and Windows software. And thought most of it was waste. So that was my first time losing my job. Yeah, I went from there to Adobe. And it was at Adobe, that the manager, I had my that my good manager, Evan Robinson, who spotted something, something in me that what, what a great manager to see something inside of you that isn't expressing itself yet and say, Why don't you try this? Jeroen Leenarts: Out? But that's always the case, right? Let people experiment and discover what they're good at what they're passionate about. And also what drives them. Right? Jon Reid: That's if things go well, yes. Yeah, things have gone. Well, things have gone well Jeroen Leenarts: sometimes says things that drive you crazy. That's true. But so you worked at Claire's in California. And then by circumstance, she had to switch over to Adobe, because I imagined Claire's had to downsize? Because pretty much they couldn't do a big part of their business anymore. Yeah. And then at Adobe, how long have you worked for Adobe? Jon Reid: Adobe, I was there for five years. And that was also the time that I felt the most pain with software. The group I was part of, had, we were working on basically a cross platform UI framework, so that Adobe, programmers could write to our framework, and it would work on Mac or Windows. And none of us had written this. It was inherited software. It had grown. Over time, as a big ball of mud. I'd had no automated testing whatsoever. There were sections of the code that we were afraid to touch. And that got worse and worse. And and then we started to assert ourselves started to say, you know, we're under such pressure that this isn't right. And so when, when we would get requests, essentially, our clients were the other development teams inside of Adobe. And they would say, we want this and we want this by by this date. And that and they were also competing with our for our attention. And we started to say, hey, no, we can't deliver that at that date. Because we knew that the code was a mess. Well, it turns out, that wasn't a very politically wise decision to say no to Photoshop, and say, you know, we're not going to obey your commands. And we ended up losing our jobs, because the code was such in such a state that we were afraid of it. Jeroen Leenarts: Okay. And do you have any clue? What happened with this chunk of code? After the whole incidents happened? Jon Reid: They rewrote from ground zero. They scrapped it Jeroen Leenarts: basically what the entire team was saying, right? Jon Reid: Yeah, we had wanted to rewrite it. And normally, I would not advocate for rewriting. Yeah, right. Normally, that's a bad idea. You want to take your existing system, which is serving you and, and reshape it slowly. And we had some ideas about how to how to do that. But we had shot ourselves politically. And we're too naive about the consequences of that. Yeah. So we were all let go. Jeroen Leenarts: Yeah, that's usually a one way street if you're in that area. So then Adobe, you did a lot of work and probably learned a big lesson there that if there's like, a big ball of hairy code, that's not something that you that you enjoy working on. Then you need to find ways to make it enjoyable, I guess. So after Adobe what, what was your next venture then? Jon Reid: Where did I go? I'm trying to remember I think I went back to Apple. At that point. I also had some time unemployed. I thought I would hold out for an apple job. I worked sort of as an Apple employee, but not really inside of Apple proper. Yeah. Clarus had its own culture. And I thought this is the dream. I want to work for Apple. I got in. And in my case, it didn't work out. Yeah, it was, it was not a good fit. It was actually my first time being a remote worker. Now that I think about it. Because I got the job. I was so excited. I went to Cupertino. And the rest of the team was not there. They were in Washington state up north. That's a bit of a way. And I didn't know how to be a remote worker. And they didn't know how to have a remote worker. Yeah. So it was unfortunate. circumstance. And so that Job didn't last either. Jeroen Leenarts: So what what are some things then? Because if you if you look where we are at now 2022. You had your stint at Apple? And and what is the process in between? Because how many jobs did you have? Since then? Jon Reid: us so many, like, my, my time at Adobe for five years, that was the longest job I have ever had. Most of my jobs would last a couple of years. And then something would happen. Yeah. After after at the two year mark. He usually it started well, and then it ended sour, something would change. Jeroen Leenarts: So that or the company would change or what kinds of things. Are you referring? Yeah. Jon Reid: Like? At one point I was working. Much later, I was working at Skype and on their iOS app. And then they said that they wanted to switch everything to common code base based, essentially react, although I don't know if it was react, and scrap, native development. And I wasn't interested. Yeah. I wanted to continue to grow as as a native iOS developer. So I at that point, I started looking strongly elsewhere. Jeroen Leenarts: So but would you say that? Yeah, you had different jobs over the years? And, of course, there's always reasons that you either have to move on, because of the day job isn't there anymore, or you decide to move on? Because there's greener pastures elsewhere? Yeah. But what's the common thread that you think that's been going through all these years of software development for you, then? Hmm. Jon Reid: common thread? Wow, that's a big question. I think it's that. Everywhere I went, I, I started to give like, internal talks, start really trying to teach and promote unit testing and test driven development and refactoring. And a lot of places weren't interested. They just didn't think that was valuable. In fact, at one company, I was told to stop writing unit tests for view controllers, that that was a bad idea. And I said, no, it's actually a very helpful idea. And then I was given permission to write the tests as long as they were not run as part of the build system. Which it's like, well, what is that? What's the point? What's the point? Um, so. So there were times I guess, when when my message as it were, wasn't received. I feel like I have continued to have a dream. I have this, this desire for the way I wanted to work. And in some places, it worked. In some places it didn't. One of the better places that I experienced, oddly enough, was Microsoft. I had a short contract I work, I started to experiment with contract programming, not just full time employment, found out that that can work also. And that I worked for Microsoft, as a Mac developer, that was a pretty cool experience. Because they had all these think different posters up in the, in the Microsoft campus, it felt like going into secret territory, it was a lot of fun. And so there were some places that that having a strong test, essentially a test driven mentality was received in other places where it wasn't. But I kept on keeping on, kept on getting better kept on trying to influence the people around me. Jeroen Leenarts: But could you say that over the years this, this stance on efforts has changed? Jon Reid: Yes, there has been a definite shift. Now most places are still not keen on test driven development, but they recognize the value of unit testing. Yeah, I think there's been a real shift there. So that's good, then then the next step is to say, Wow, that's great. But you're doing things the hard way, writing tests to exist, of existing code, that's hard. It's not as much fun. And it's not as effective. Jeroen Leenarts: Throughout all these years, you've been advocating, promoting, and basically, trying to convince people that test driven development is, is the smart thing to do. But at what point in your career? Did you make this revelation to yourself really, that test driven development? is a thing that people do? Or is it something that's that that that grew into you gradually? Jon Reid: Now, that was, during my time at Adobe with, with that manager who encouraged me to, to start writing and promoting good practices, we started to, oh, well, I found this book that was pretty new at the time called design patterns. You know, that's the now classic Gang of Four, design pattern book, and I started to share it with my teammates. And, and it's like, here are some tools we can use. Like, there. It was like, these are idea tools, which was an interesting new thought, to me, most of the tooling until then had been, you know, very literal, tooling. Design patterns were like a tooling for the mind as it were, you don't have to sweat so much. Here are some things that work for these circumstances. And so I started to consume books start to look for where else can I get information about design patterns like this is really good stuff. And went out on to the very young worldwideweb and did a search and found a site. This was a site that was a turning point, for me, it was called C two.com. It's still there. It was the site of the original wiki, created by Ward Cunningham. And he wanted a place that was more in line with it, as it were the original vision of the world wide web, which was basically that things would be very dynamic. And you could go in and edit something. Or you could have a half an idea for a link and not have a link destination, it would just show as a question mark to say here is a an idea that maybe you maybe somebody else can fill in what the details of this idea is, but it left a question mark there and you hit the question mark, and it would pop you into an authoring page. It was radical. There was a section on this wiki that was devoted to design patterns. There was another audience that was very active in there. And this was the Extreme Programming group. And I was very curious about this because I was desperate to to make my life better and my teammates lives better. And I started reading about extreme programming. And test driven development is one of the practices that was born out of out of extreme programming. So I started to apply what I could, even if it was just me solo. Because Extreme Programming is really it's a team thing. It's it's, it was agile before agile, Jeroen Leenarts: primordial, agile, really Jon Reid: primordial, agile pre, sort of a more pure engineering focused agile before? Well, it became whatever it is today. Jeroen Leenarts: Yeah. Basically before the Agile Manifesto, right? It was before the Agile Manifesto. Yeah, for those listeners who don't know what the Agile Manifesto is, I don't know the names anymore who were on that. But it was a couple of influential thought leaders back in the day that pretty much wrote down some guiding principles on what Agile software development is supposed to be, according to their views. And it basically is the start of all the agile practices that we well know and use nowadays. So it's very interesting to to look it up and just see what is agile manifesto is, and also all the mean versions of it. But yeah, I'll make sure to link that from the show notes. Jon Reid: So is that especially because that's something I think that a lot of people aren't familiar with the principles and the practices that on a second page that it it describes are so fundamental, but if all you know, about Agile is basically, you know, Scrum ceremonies, and you've never seen the Agile Manifesto, you're missing out? You're missing out? Jeroen Leenarts: Yeah. Yeah. Because that's, that's a reason to all the madness, really, with, with a proper execution of an agile project? That, yeah, sometimes you do notice that, that people miss some context, and they really don't know why they're doing what they're doing. And I've noticed that it's really helpful to just sit them down. Explain a little bit, why are we doing this? What's the purpose? What's the goal, and it's has these specific goals because it fits into a grander scheme of things that's ongoing, and that you as a single person are a part of, and and once people start understanding what their role is, and what influence they actually have, by their day to day actions, then yeah, quite often, you see something click, and then they basically start doing what, what they are well, called marks they are supposed to do so. And it makes everybody's life a lot easier. But yeah, so you started experimenting, really, with extreme programming. That's the XP methodology that that you're talking about? Yep. And what did it bring to you? Because it's, it's, I've read the XP book, years and years ago, go it was like this, this white book with like, extreme programming. And I remember some big X being displayed on the cover art. Jon Reid: I confess, I have never read the book. Your everything I've I learned was was from this wiki. Discussing, because I Jeroen Leenarts: think indeed, that everybody that was in the book was also on the wiki. Yes, I discovered that after I bought the book, of course. But um, so you learned a lot of things there. And and what do you do with it? Because I know that you've been thus far that you've been doing well improving your day to day life as a software developer since your time at Adobe, some hits or misses along the way, because yeah, sometimes the environment doesn't support it. But you did bring this experience to the table at every engagement that you have since then, and you've never stopped pushing for Agile methodology methodologies, agile ways of working unit testing, getting the feedback cycle is shorter and shorter. So but what kept you going despite all the people saying, we don't have time for this, and it's not worthwhile, and why are we why are we even considering doing this? In the first place? Jon Reid: Why indeed, you know, at at one company when they when, when when I joined, I think this might have been at eBay. You get to choose not some symbol that like a cartoon character of your choice to go on your company batch. And I chose Don Quixote, because I felt like I was the dreamer of the impossible dream. Chasing the, the monsters with little hope of success. But what what kept me going was a strange faith. Oddly enough, um, one of the, one of my core strengths. I know from taking a, a survey on, like, what are my strengths so that I can continue to reinforce those strengths? And curiously, one of my strengths was this notion that things work out that the universe is here and and everything is going to be fine. And that we're all connected. Yeah, um, it's not what you would expect, and certainly not what I expected to come out of like a business experience of like, let's find out what your strengths are. And that was one of my top ones. And I just every little bit of, of experimenting I had done had been so valuable for me. And I, I wanted others to have those good experiences also. And some did. And even in places where I left I, I think I was able to leave a good mark. Jeroen Leenarts: Okay, yeah. Because what's very funny is, every time that I talked with you, and we'll be we talked extensively, like, two years ago, close to two years, it's that you're like, you're just in a conversation with you. And it's like, and then you start, okay, you start making a list. Okay, so he works at Claire's, he worked at Apple, he worked at eBay, he worked at Adobe. Is there any place big brands in Silicon Valley that that you haven't worked? Actually? Because I think you've seen a lot of these companies that are nowadays considered like, well, big tech, and large tech in Silicon Valley. And, yeah, pretty much you've seen them all, it seems you've seen them actually start and grow into these huge companies that they are nowadays, in part as well. So would you say that having these experiences on all these different companies, does that make you like, is that part of why you are such a good coach in software development, and and especially the niche that you're in with unit testing? Jon Reid: One thing that it taught me is that the big companies don't necessarily have good practices, that they may be successful in spite of themselves, in fact that this then, is the story that I've come to believe about most companies. Yeah, is is that, wow, they're successful. They're making money. The programmers seem to be mostly happy. But it could be so much better. They have no idea how much money time and joy they're leaving on the floor. Hmm. That that, that's one thing I get from having been in, in a number of big places and famous places is that when you're on the inside, it's not necessarily wonderful. And the big, good practices you've read about may not be in practice. And, of course, these days, agility itself has been commodified into a business. Yep. And is weaponized as something a way to control developers, which is the exact opposite of its intent. And so I'm, I don't know if you know this about me. But, you know, I started quality coding, turned it into sort of a side business. And, and of course, that brought me You while You brought me, then to the Netherlands, with that business, and that teaching and coaching, but now, I find myself at a company industrial logic that does this teaching coaching from agile and extreme programming background and lean, real lean focus. that I get to be part of a group of people who are who are like this, so I feel so incredibly pleased that I found my people you find finally found my people to find your tribe? Yes. So that's a great feeling. Jeroen Leenarts: So how long have you been working at this company Jon Reid: then? How long has it been? Just since April? So yeah, I guess. Eight months is that right? Eight, nine months. Jeroen Leenarts: If my memory serves me correctly, like the previous time we spoke, you were working as a The reasonably large financial company, right? Yes, American Express. Yeah. reasonably large. So, um, but you find your tribe? And then what does that mean for you? Is that like that? Does that like accelerate your own growth? Or is it more like that you have can make a bigger impact, because there's now a company around you that supports this whole way of working in way of thinking about software development, both. Jon Reid: First, from a practical point of view, I don't have to scramble to find companies anymore that want to have me that I mean, I'm still expected to be part of that process and to and if I can, but mostly, the engagements are there for me, the clients are there, and they it's much more organic, and I don't have to sweat the business side of things. Yeah. But being among these people, who have just so much experience in so many different areas of agility, I am learning. My Learning has accelerated. It is it's thrilling. It's fun. Take, for example, the Clean Code Book, which was influential on me. Of course, Robert Martin's name is big. On the book, he's the main author. He's not the only author. I happen to work with three other authors of that book. There were there with me at industrial logic. It's it's Jeroen Leenarts: quite funny what you say that because even though you have like, a software development track records of I think now close to 40 years. Still, you're learning new things every day. Still, there are people that you work with that? Well, on paper or on record, if you look at how long they've been working. They're less experienced than you are, but you're still learning still learning every single day. Just because people have different perspective and different experiences compared to yours. The Do you think that's like one of the most important things that needs to be able to exist in an Agile team? Jon Reid: Yes, yes. And it's one of the reasons I've become such a believer in ensemble programming. What the, the, probably the more common word for that is mob programming. Jeroen Leenarts: Yeah, but that's like because the group in room is then pestering the one at the keyboard. That's the mob. The one coding and that's not the point. Jon Reid: I learned that the origin of the term mob programming was a joke, actually, that Llewellyn Falco was at Hunter labs, helping them and they they started to, to develop this style with Woody Zuill. And, and then, but they didn't have a name for it. And they then they were asked to describe what is it that this thing that you're doing? What is it and they said I don't know. We don't what? What is it? It's great. It's it's a it's a mob. And they said it as a joke. Unfortunately, it's stuck because it's a single syllable. It's it's, it's not as it is very catchy. Jeroen Leenarts: Yeah, everybody, everybody has this, like this picture with a mob, you know, pitchforks and all kinds of horrible things. Jon Reid: But that's, that's why I like ensemble better. Yeah, for coming from a musical background. It's a group of people, maybe with different roles. It's not necessarily that. Well, in pair programming, things can feel a lot more intense and a lot more tiring. Because you're with one other person. And are you a good match? Or not? Maybe maybe not. Is the is the other person a keyboard hog? Is the other person smarter than you are. And so you feel intimidated and all this stuff. And an ensemble because it's a larger group, it's naturally more diverse. People have different not only different skill levels, but the ensemble might include people from other disciplines, for example, to say, You know what, we don't know the answer to this. And so in good old extreme programming style, rather than submitting tickets or sending emails, or slack, even slack messages, well, I suppose slack might be the exception because it's more immediate. It's to say, let's get an answer to this. Let's pull the product owner or in or let's ask the customer. Let's have them come in and let's have let's sit down Let's have them sit with us as we code together, and they can be part of the solution, because they all catch things that we're not aware of. So an ensemble can be programmers mainly might have a quality expert, QA folks, for all my love of unit testing. QA, good QA people bring such a great, different way of thinking about things than programmers do. And so having some one of those people on your team, in the room coding with you to say, what about this edge case? Jeroen Leenarts: Yeah, for software, for a software developer, having like a good colleague, as a software developer, that's a person who is worth his weight in gold. But if that person is a QA type person, that's really good at Quality Assurance, their weight, they're worth their weight in gold, but then twice, at least that's that's my experience, because they they I don't know, it's some kind of mindset that Jedi mind tricks even. But they can just see things and come up with things and looking at your solution in a way that really makes like, Okay, I haven't thought about that educate yet. And they can break break everything, which is good while you're developing it, because then it doesn't happen in production, right. So but the company that you're working at is really a company focused on, on teaching agile development, teaching solid software development skills. And, of course, unit testing is a part of this toolset that you need to have as a good quality software developer. But But how does working for industrial logic play out for Q coding for you? Because it is a bit? Oh, the you could say that are some some overlapping areas in the market that the company and you serve? Jon Reid: Very much so very much. So in fact, I, I have basically shelved the business side of quality coding. Jeroen Leenarts: Yeah. So that's the that's the teaching and the workshops. Part of things. Yes. Jon Reid: Yes. So So basically, anyone who wants me to come and teach for them? Well, I'd love to, I would love to, but you have to talk to industrial logic. Yeah. Jeroen Leenarts: That's, that's obvious. And and you can still write your books, or what's the deal there, then? Jon Reid: Yeah. So I don't know that I'll ever write another book. We'll see. Yeah. But, and for, for those of you who, listening who aren't familiar, I'm the author of iOS unit testing by example. And, yeah, they encourage us to, to get out there to, to write, to speak, to keep promoting the good practices. On the one hand, cynically, it's good for business, for the company, for us to get out there. But more fundamentally, it's that I am with a bunch of believers, we all want people's lives to be better. We want teams to function in a more sane and relaxed and effective and fun way, and get stuff done. And that belief is so so at the foundation of this company, and everyone there. Okay, so, yeah, Jeroen Leenarts: start doing unit testing people. It's where it starts. And then from there, you can slowly adopt more good practices and, and just come to grips with the complexity that software development really brings. But John, did, did we forget anything that to mention anything that we could talk about? Or are we pretty much full circle because I underestimated your your resume a little bit, because with all the things that were on there, because there was so much that we could dig into there. But I think we covered most of it, right? At least the important bits. And I think the DD biggest important bit is actually that one manager at Adobe, that mentioned to you, Hey, start writing some stuff. Maybe it's useful to your colleagues and then from there things over the years, sort of like snowballed for you into something that was completely different than you initially expected, then ending you up at at the job that you're currently at right now. Industrial logic, and, yeah, well, what do you expect for the next couple of years? It's It like, just keep on, keep on preaching the way of software development in an agile way with unit testing in place, or what do you think? Jon Reid: Um, yeah, probably more and more of that. There, I am continuing. I do want to get back to more of my personal blogging, I feel like I, the volume of traffic on of my content has gone down significantly on my site, mainly because I'm spending so much of my time doing what I love, professionally, that I no longer feel the great desire to do it on my site time. Jeroen Leenarts: In a way, that is a good thing, right? Because it does feel that like the, with cue coding, you really enjoyed what you're doing there. But it was, if I read through the lines, hypothetically speaking a little bit, it seems like that it's a relief for you that you don't have to fuss that much and more about the real business side of things, you know, getting lining up the clients for keeping a steady income stream that says now people in place who take care of that aspect of business really is that is that the case in your situation? Yeah, Jon Reid: yeah. But I do want to start getting more content out there. And I have been working on a project, which is only just now gone, I've released the 1.0 version of. And this is a new testing tool for swift folks called approval tests. Approval tests have existed for some time in many other platforms. They were created by Llewellyn Falco. And essentially, you can think of it as like snapshot testing, but not for images. And it is a fascinating and fun way of working. It's a tool I've wanted. And so being able to be part of helping to create that has been has been fun. So yeah, go check out approval tests, I'll be putting out more information on that. Another thing that I've enjoyed doing, has been getting active on Twitch. I'm in live coding, trying to show people that the what when you look at a blog post or or a video that I spend time producing, it all looks wonderful, it's perfect. It has no flaws. And that's not the reality. In reality, I make mistakes. Jeroen Leenarts: It's like the the conference talk that somebody has like spent hours preparing and they do live coding, but I don't know how to do it, but they have to have snippets ready. And just at the at the blink of an eye, they just build up this entire complex thing that you go like fantastic. And you think like, oh my god, they're like, they're like superheroes. They're on stage. But it's the preparation that that makes it look that way. And with Twitch, I haven't fisted one of your live streams yet. But twitch your then live coding actually platform aimed at gamers but hey, sharing your screen. And that's and have fun. Why not? Yep. And and what are you doing then in these Twitch streams, you're just coding something or you have like a challenge that you then try and solve or what's the deal then with these sessions? Jon Reid: Well, he I've been coding and like I put up what became a long series longer than I planned of a tool that I wanted for my own purposes. And so I thought, well, I could work it on on it on my own. On the other hand, lots of folks wonder, yeah, okay, TDD looks great for FizzBuzz for something very simple toy code, but, you know, how do you actually do it? What does it actually look like? What does it feel like? And I wanted people to see that. And that's been a surprising amount of fun for me. Especially as as also Pete, you will get to see that I'm not the best programmer. Viewers who come in, they know much more about about details of and of systems of the things I'm trying to write. And that's great. It's super helpful for me. I just happen to come in with these good habits. And so we combine those powers and come up with good stuff. Jeroen Leenarts: So because I'm looking at the repository for approvals, approval tests dot Swift, and it's a lot of commits and most of them are either your name or some actions users. So I think some surface use that does something for you. But could you say that these Twitch streams that they basically have been a way for you to generate your own ensemble? So that you could do some ensemble programming on this specific bit of code? Jon Reid: It hasn't been for approval test. Okay, I have been I have been preparing regularly with Llewellyn on that. But it has been with other things, and yes, it is very much kind of like a not quite ideal ensemble, and that I am always the person at the keyboard. Yeah, you know, that's, that's, that's the drawback. But it but it is, I'll get stuck. And I'll say, Help. Help. And that's my call for ideas, like, you know, and, and my good viewers jump in, they start looking things up and offering suggestions. Jeroen Leenarts: And what is, what is the code base that you're mostly working on during your Twitch streams, then Jon Reid: it has been a thing to analyze. Until now, it's been a thing to analyze a survey I took of what people content people are interested in from me. Jeroen Leenarts: That's, that's kind of meta, but not in a bad way. Jon Reid: But that's finished. And now, I'm actually well, I have another GitHub project. That is a good tool for unit testing, alerts, alert controllers and presenting views and dismissing views. But it is not in Swift package manager, because it's partially swift and partially Objective C. And Swift package manager doesn't accommodate mixed languages at this point. Yeah. And so I thought, well, I need to rewrite it into all Swift. Well, why not do that together. So that's what I've started doing. The last couple times, Jeroen Leenarts: that's a, it's always worthwhile to have like a goal and then just start chipping away at it. And it seems like one of these tools, just a, let's see how much of this objective C code we can get rid of in this session. And that sounds like something that you can do in a perfect way in refactoring it with unit tests in place and not breaking those unit tests while you're working. Jon Reid: Oh, yeah, they have caught me and saved me. Jeroen Leenarts: Okay. So yeah, that's that's your Twitch streams? There was something else that you mentioned just back there. And that's the that's the approvals test. Can you explain in just a few words, what it is because you mentioned Yeah, it's kind of like snapshot testing, but not but pictures. What is it 10. Jon Reid: So if you have an assertion in a unit test, and you say, the expected, we get the actual value from of whatever, you know, whatever it is that we're testing, or verifying, and we compare that against the expected value, let's say it's supposed to be, you know, some string or something. And that can work very well, when the expected values are not big and complicated. It's very easy. But as soon as they become big, for example, a really long string, then it's harder to tell. Okay, so the the test fails. But why did it fail? What's what's changed? What approval testing does, is it incorporates your diff tool, rather than trying to be very clever about it is it goes out and says, Well, I know about these diff tools, I will invoke the first one in this chain that I find, and then you get your diff tool, and you can see with the power of your diff tool, exactly what part of it is different. And so it's good for long strings, it's good for a race, maybe, you know, one item in an array has changed. It's good for composite types that is like a struct with many properties and something in there changes. You can see that and then you can decide, is this the change I want or not? That is do I approve the the new result and approving it is just telling your diff tool? Make this like copy from left to right now apply all the changes, and then Save, and then when you rerun it passes? Jeroen Leenarts: Yeah. So this basically allows you to put tests on anything that you can represent as, as a textual format, right? So if you hierarchies, data sets, as long as you can, yeah, basically punch it down to text, then you can run it through this tool. Jon Reid: Yeah. And it has some Have extra smarts because a lot of times, if you write out too much information, then it becomes oversensitive. And it starts to break on things that you don't care about, or shouldn't care about, for example, if you get some JSON, and it has a date and ISO date in it, like the current date, well, that's not something you want in a test, because that keeps changing the time keeps rolling forward. Yeah. So there's this idea of a scrubber in approval test that says, let me do a regular expression search for ISO dates. And I'm going to call this one I'm going to replace this call it date one, and everywhere it appears, I'm going to call it date one. And if there's another date, I'll call it date two, and then you can then have those tests continue to work, but not be sensitive to changing values. Okay. Jeroen Leenarts: And and how far along is the approval tests? For swift two, Jon Reid: it is ready for folks to start playing with right? Just rolled out 1.0 A few days ago. Jeroen Leenarts: Okay, because that's what I was wondering because it's not. If you look at approval tests.com. Then at the bottom, it says approval test libraries capturing human intelligence available for Java, C sharp, VB dotnet. PHP, Ruby, no chess and Python. So I expect some some extra language to appear there. Pretty soon, right? Jon Reid: You know, I should, I should. Yeah, I should put that in the list of cool. Jeroen Leenarts: So um, yeah, I will make sure to link your Twitch stuff. And the approvals test library from the show notes as well, because I think both of them are very worthwhile for people to just have a look at. I haven't looked at approval test myself yet. Because, yeah, I didn't know it exists yet. But it's new. But knowing that you're one of the authors are actually the main author on it that already gives me like, high level of confidence that it's, it's something worth checking out. And, yeah, I'm really curious to see if this is something that will take off and what people will think about approval test, because it's, it's a relatively new concept, I think, for most people doing software development. And yeah, I'm glad that we were able to talk about this as well, in the end of the recording that we did, John, Jon Reid: I'm glad you, you know, you said, what did we miss? And I'm like, I'm not sure we covered everything. Oh, except for this, that. And the other thing? Jeroen Leenarts: Yeah, well, that's always the case. Like, with natural, organic conversations, it's always like, people always have like memory that works in in strange ways that something that's very important to them. totally forget about it. And then at the end of the conversation is like, oh, I should have talked about this. And this and this, which is very normal, I guess. So I'm John. With that. I want to thank you for your time, because we're creeping up to already past our allotted hour of recording time. So this is going to be like one of the longer episodes from from a podcast, which is fine. And yeah, I just want to say like, I hope that we can meet again, rather sooner than later. But yeah, we'll circumstances because it never set set right with me that the way that we had to say goodbye back in 2000, to 2020. And because it was like, we had all kinds of plans. And then all of a sudden, like last minute, we switched everything to an online format. And we didn't even get to say proper goodbyes anymore. Because we had some in person trainings at my damn job. And then we did some extra work. Workshop and we had all kinds of plans, but it just, but it worked out in the end, but it was a little bit in the way that we just made the best of circumstances. And yeah, I think we should do like a retry of this social aspect of meeting people by get to say like a proper goodbye at the end of the interaction. Jon Reid: And I would love to get back out to your neighborhood sometime. Jeroen Leenarts: Maybe I'll I'll get to your side of the ocean as well. Because who knows? John, thanks for time and hope to talk to you soon. Jon Reid: Thank you so much for having me.