Justin Searls

Interviewee: Justin Searls
Conference: SCNA 2012
★ Transcript Available Jump to transcript
Duration: 12 min · Published: Jan 22, 2013

Transcript

Hi, it’s Mike again with Yooktastic here at SCNA. Now I’m sitting down with Justin Searles, co-founder of Test Double. Justin speaks at a lot of conferences and talks about testing, but what we’re mostly talking about today is he wrote this very interesting article not that long ago about single purpose, single focus user groups and communities are kind of a dead end, that the future is really in general purpose. Can you describe a little bit about what you meant by that article? Well, there’s two major points. One is that obviously if you’re watching this, you’re probably familiar with user groups. In most communities, in most locales, the user groups are divided up by either the server side stack frameworks that people use or the languages that people predominantly identify as. I’m a Ruby developer, I’m a .NET developer, I’m a C-sharp developer, I’m a Java developer, I’m an iPhone developer or a JavaScript developer. I am a… Right. Right. And so, you know, I live in Columbus, so in Columbus we have C++JS, we have Columbus Ruby Brigade, we’ve got, I’m sure we’ve got a .NET group that I don’t attend, we’ve got an NSCoder night for Coco and Objective-C developers. Or S10 apps. And rather, I just think it’s a poor abstraction. So if you’re a developer, you’re familiar with designing abstractions that model something in a way that is going to, you know, maximize reuse or just help us communicate efficiently. And I think it’s… I think it’s a poor abstraction because regardless of what language you’re writing, you’re probably solving the same kind of problem very frequently. And maybe the tools change a little bit or maybe the syntax changes, but why redundantly have the same talk or the same solution broached in all those different dialects when we could simply come together as one group and either focus on, just find a new way to slice it. Like one way to slice it might be by problem, right? So like, we build web applications. Right. Or we are… Like an embedded hardware. So problem domains, not specifically, I write .NET apps because even then that’s too vague. It’s… Right. Do you write for the mobile? Do you write for… So they identify as tribes, not, you know, any sort of like specific passion or interest that people might have. And that’s one big piece. The other is that life changes and some of these groups have actually kind of evolved beyond themselves. Where, like, I go to a Ruby user group and I see so many people talking about, you know, maybe they diverge, some people are really into Erlang and other languages at this point, and other people are all about front-end development, so there’s lots of talks about, you know, CoffeeScript and JavaScript testing and stuff like that, all in the ostensibly Ruby user group, because it’s really easy to start up a new one, and because typically, like, it’s easy to get the word out with Twitter now, as opposed to traditional means, I’m all for killing user groups. Right. Like, let’s spin one up. Like, for instance, I talked in my talk today a lot about growing object-oriented software guided by tests. That’s a fantastic book, but it’s a very meaty, dense book. And I’ve been toying with the idea for a couple years now of just doing, like, a nine-part lecture series. Right. And have that be a user group and look and feel and be just like a user group, but then it will end and everyone will go and then do something else and it will free up one of the nights of the week for some other group to emerge. So it’s more like… I would say more like a training course, though. That would feel more like we’re going to do a study group that has… Or, yeah, study group is a good word for it. I’ll use that one, too. I mean, like, not to say that that’s what I think they should be, but if we relax this assumption that a user group’s purpose in life is to be a self-perpetuating organization, we can experiment and try new things. And even if we presume the conclusion, we know that things are going to, you know, eventually end. We can just experiment. We can experiment with different styles that are appropriate to what we hope to accomplish with that group. How, in that case, though, do you reach out to people and maintain a continuity? One of the aspects of user community is that we’re a community. Right. If it’s just a short-lived thing, how do you maintain a continuity? Well, one of the things I’ve observed in Columbus, and it might be a function of the size, Columbus is, like, a perfectly sized city because of the people… There’s two and a half million people in the metro area, but of the people who are engaged… …in the software industry, enough to, like, show up to someplace after work. Right. It’s the same, you know, couple hundred folks who either go to lots of different user groups, or have one home base that they go to. And we have these silos where, you know, I’ll pick a random name out of a hat, there’s a guy named Greg Malcolm in Columbus who, I don’t think I’ve ever gone to a user group in Columbus where he wasn’t there. Right. But he goes to all of them, and he is the glue that everyone happens to know across all these disparate communities. And so it’s a really inefficient communication mechanism, but it exists. I would much rather than have these silos just have an acknowledgement that there’s these 200 people, and we all kind of, sort of know each other, and get together for big social outings just to intermingle, and then let this stuff emerge. So you don’t think that having a specific group is what keeps people together, but these are people already inclined to gathering, so… As long as there’s events, these people are going to find each other. Right. As long as there’s a local conference, or… Anything to do, like we, I badgered Jason Long at GitHub to do a drink-up. Right. Because I wanted to meet more designers. Right. You know, in my particular circle, I don’t see designers very often, so I said, “Hey, Jason, let’s do another Columbus drink-up, intentionally invite designers, and then, of course, all the developers will come,” and it was this big, wonderful outing, and we got to meet lots of people across these, you know, party lines of… Yeah, so, GitHub, which is basically, if they blink, there’ll be 40 developers there. Well, if it’s free alcohol. More like 200. That hasn’t hurt, yeah, but the point is, is that, in order, you were able to take something where developers will already pay attention to this one aspect of, one aspect in the community, go to there, and by having that one focal point pull in another community, they were able to connect two communities together. Oh, yeah, absolutely. And get some nice cross-pollination. And that’s why I think that, like, and I think in the blog post, somebody said this, that language-oriented, or like… Like, organizing user groups by language can be very harmful, because when it stagnates, people become less engaged, so you get these people who started off as being highly engaged individuals, then they go to one or two user groups for 10, 15, 20 years, there’s a lot of Java user groups now that have been around forever, and once that gets stale, the person’s, you know, even if they keep going, they’re sort of, like, just, it’s another mechanical thing to do, and there’s, like, a lot less, you know, interesting cross-pollination and infusion of new ideas. Yeah, it’s like, it’s like an anachronism, it’s like the, you know, like a, what would you call it, like a Shriner’s Club meeting, or something like that, where it’s like this, like, secret society, and it’s just… Yeah, it’s the jobbers. Right, right, people who had something in common 20 years ago, and then just sort of, like, came to coalesce into, like, a small little group of, you know, people who know each other really well over a long period of time. And there’s nothing wrong with that, but I would much rather spend the time that I spend after work in a forum that I’m going to either… Be able to share a lot at a really high bang-per-buck, you know, frequency, or learn a lot, you know, from a lot of different people all at once. So it sounds like there’s kind of some different patterns. One is the long-lived, closely-knit, tight community, and then there’s the more dynamic, hey, let’s get together and just share and learn, and, you know, if you come, that’s cool, if you don’t come, that’s cool, but we’re going to share neat stuff. Yeah. And a little bit less tight-knit. Tight-knit, maybe smaller friendships inside of that community, but a little bit more high-energy. And there’s no one right way of, you know, meeting. Like, I think that having big mixer kind of events is great to kind of just, you know, stoke the coals and get people all in one place, and hopefully as an outflow of that, give folks tools to, or encourage folks to, or just let naturally occur, people coalesce and attract and so forth into having things. And one of the interesting things, when you talked about that one person that you see going to everything, it’s very much… Sorry, Greg. No, it’s… Yesterday, I talked to Patrick Walsh, and he talked about the concept of a network weaver. Yes. And it’s a person who… He’s got that on business cards. Yeah, but the idea is that it’s the one person that can go between these different communities. You even described it as maybe an inefficient way of communicating between different groups, but you see this… You see this one guy, he goes to the Python group. Yeah, it’s a ring network, right? Yeah, yeah. But he can be the one person that shares information, lets people know, hey, last month they talked about testing, and this month at the Python group, and this month we’re talking about testing at Ruby. Well, this is something I learned there, and then is able to transport those ideas in a fashion over to that. Yeah, absolutely. And it shouldn’t be just one guy’s job to do that. Right. Because it’s not a reliable, durable system. And we should be thinking about how we can proliferate good ideas and let them win in the marketplace of this precious time that we all have. Right. And discourage stale ideas from becoming rotely breached over and over again. I’ve been to a Java user group in the past where they’re talking, and I’m not selling, but bless his heart. Yeah. The guy giving the talk was just… Just sharing ideas and technologies that were very old and outmoded, in my opinion, and that group would have been much better served at, you know, literally a user group that was happening the same night on the other side of town. Right. And I would like to try to think about or have people who are, like, you know, passionate about user groups is, like, how do we discourage the groups that become stale or the talks that become stale or the ideas that are stale and encourage the ones that are fresh? Because it’s always easy. It’s always easier for the entrenched interests, like the long-running groups, to keep going. It’s much harder to start something new. Right. If you make it cheaper to start something new, maybe it’ll work out. One thing, though, is I’ve looked at this in my own experience running a group is a lot of groups still, and you talk about the new, it’s always the new ideas. I don’t know if it’s stale. I mean, I know what you mean in the context of stale, and the way I understand it is that stale is these are ideas that have been shared over and over. Maybe some of them have been outdated or superseded, but there’s also old ideas that get forgotten and aren’t brought forward and shared again with the new. Have you seen anything in the groups you’ve gone to where they’ve looked backwards? Oh, absolutely. So, you know, like in my talk today, for instance, I’m talking about Growing Option Oriented Software Guided by Test, which is a book that was, I think, initially published in 2005, 2006. Okay, so a little bit back. I’m talking back to the 60s. Yeah, sure, and so there’s, you know, I would love to see a small group that was just an interesting papers from the history of computer science, you know, group that got together every quarter or something. Like Jim Weirich at the Ruby User Brigade in Columbus, last year, two years ago, he gave a talk of like 10 of the greatest computer science papers in 60 minutes. Oh, really? Right, and he goes through each of them and makes the argument and does as much as he could possibly do until his timer runs out and he goes on to the next paper. I see that every now and then. I think that oftentimes what happens a bit more organically is an idea is stale, we successfully stop talking about it for a few years, and then somebody brings it up again because it’s new to them because they haven’t seen it. And so if it’s a good idea, it’ll keep coming back up. Yeah, it’d be nice to be able to say this one’s deprecated. Yeah, yeah. Well, thank you very much for taking the time to sit down. No, thank you, Michael. I appreciate it.