The Changelog: Software Development, Open Source - Pair Programming and Ruby (Interview)

Episode Date: May 22, 2013

Adam Stacoviak, Andrew Thorp, and Steve Klabnik talk about pair programming, distributed teams, workflows, Ruby and more with Avdi Grimm.

Welcome back, everybody. This is The Change Log, where members support a blog and podcast that covers what's fresh and what's new in open source. This show is hosted by myself, Adam Stachowiak, as well as Andrew Thorpe. Say hello. Hey, how's it going? And we're also joined by our fellow Change Logger, Steve Klavnik. Hey, how's it going? And we're also joined by our fellow changelogger, Steve Klavenick. Hey, everybody. And you can tune in live to this show like you can today.

It's Tuesday at 5 p.m. Central Standard Time right here on 5x5. You can check out the past shows we've recorded at 5x5.tv slash changelog. And this is episode 90, and we're joined by Avdi Grim, maker of Pair Program With Me, and Ruby Extraordinaire. Welcome to the show, Avdi. How are you? I'm doing great. Thanks for having me. So where do we kick off this call? I mean, I know we've got kind of a huge docket of things to talk about. Maybe for the uninitiated, somewhat introduce yourself. You're a podcast yourself, a writer, and all sorts of stuff. Where do we begin with you?

Well, I'm a hacker. I'm a hacker. That's me. I'm a hacker. I've been working a lot with Ruby for the past several years, many years. But I don't know. What else do you want to know? I'm a family guy. I've got lots of kids. Why don't you give us a little bit of insight into some of the work you've done with Wide Teams and Ruby Rogues and that kind of stuff? Okay, so that's the broadcaster side of my life. I have been doing a podcast of my own for the past few years. It's called Wide Teams. It's at wideteams.com. And it is dedicated to dispersed teams, remote workers, people that are working geographically

removed from the other people that they're working with. And the goal there has just been to kind of collect stories from people, find out how people are working on dispersed teams and, you know, what special strategies they have to make it work and what tools they're using and what they like about it, what they don't like about it, all that stuff, mainly just to sort of, you know, connect people like that and, you know, help us learn from each other because I was working remotely and there just didn't seem to be a lot of resources when I got started. Yeah, those resources are kind of plentiful now. And I remember two years ago-ish when I started my full-time remote job, it was difficult to find any kind of resources out there to help me just know what would make my life easier.

Right. me just know like what would make my life easier right so looking at some of the stuff you've done um you know with wide teams specifically um and now you know even a little bit more with with the idea of pairing and and remote pairing and things like that man it would be nice to uh to have these resources at my disposal when i first got started a few years ago um i love the name man why teams is such a perfect name for distributed teams. I mean, where did you come up with that? Thanks. Same way I come up with all my naming ideas. I go for a long walk.

Go for a long walk. What about your Twitter bio? How many questions do you ever get about that? I mean, do people think you're a demon or a daemon? Yeah, so that's 80% angel, 10% demon, and the rest is hard to explain. Actually, I don't know if anybody's ever asked me about that, but it is a reference to an Over the Rhine song. Nice. First here. I stuck in the sort of the eunuch's spelling of demon just, you know, because nerd.

See, I was thinking you were really just playing on the fact that you know what a demon is, and you were hoping that maybe nobody else did, but anyways. So the resources on Y-Team. So you started this podcast how long ago? You know, I'm not even sure. I'd have to look, but it was a couple of couple years ago um actually probably more than a couple now yeah we're on you're on episode 81 now so however long ago it was you've definitely uh you've definitely gone into the depths of distributed teams with some of these people here i see here on the front front page you have ernie

miller of living social um i got a chance to hear him talk at – I want to say it was Ruby – it was Big Ruby Conference in your job? And it's not money. It's not – he even went as far to say it's not the people you're working with because you'll find people that you love to work with at a lot of places. And to him, what he said, the absolute most important thing about being happy in your job is being happy at your job, wherever that might be, whether you're driving, working from home, whatever it is. And he's obviously a remote worker for Living Social. And so he was saying, you know, kind of what we're going to echo here today, which is that like, if possible, the idea, the ability to work from the comfort of your own home is tremendous. And you kind of hit on it when we chatted a little bit earlier, Avdi, with, you know, you love that you can work from home because that means unlike the traditional business mindset that comes out of the Great Depression and on in America, we as workers, as people that are in the workforce, get to spend more time with our family.

And to me, that's something that makes up for any level of financial compensation that you could find. Yeah, it's a huge deal and exactly, you can't really count it up in monetary terms. Here's a question for you, maybe to kick off this conversation. Are you part of a distributed team right now? I can't really say that I am. So, I mean, I was part of many different distributed teams for years, but my job has recently changed kind of dramatically. My job description is now, I guess, screencaster primarily because I launched Ruby Tapas, which is my screencast service. Yeah, that's awesome. screencast service and it became popular enough that I was able to devote myself to it full time.

So, um, that's kind of a, a one man gig. So I'm not, I'm no longer, you know, working with other freelancers on a job or, you know, working as part of a distributed startup or, you know, any of the other things that I've done. Yeah. So for those of you that don't know Ruby Tapas, and you can go to at rubytapas.com, the description of it, like many of your projects is just perfect as short screencasts of gourmet Ruby. Yeah, it's awesome. And so these are some, you know, some great resources. It's very, very affordable. I highly recommend them. My question is, how much of an influence did Ryan Bates and Railscast have on you when you were starting this? Well, I mean, people like Ryan Bates, you know, I mean, well, particularly Ryan Bates,

really broke ground. He's a pioneer. Yeah, I mean, I think the influence there is the fact that he was there and just made it clear that it's possible to do a professional screencast and to do that as your job, him and others. I suddenly had a brain fart, but somebody help me out here. Well, Ryan, I think he was a pioneer in terms of like just leading the way i mean he was one of the very first at least in the ruby spectrum doing screencasts and he did it very simply right like he was just breaking ground on like how simple it was he had this de facto template for all of his you know all of his screencasts and i think he'd even gotten uh ruby hero in 2009 not so much that, but just his impact to the community. To kind of hit on a few other ones that you may

have heard of, you've got PeepCode. Yeah, absolutely. Rails Best Practices and RailsTutorial.org, those guys. And Gary's Destroy All Software when it existed as well. And my short-lived project,

Watch.Steve, which no one forget no one knows about which is amazing that's what i always tell people is like if you're gonna try something try it because if you fail no one will ever know or remember anyway so like i totally did this a couple years ago and no one cared and so it disappeared off the face of the internet and now no one knows so gary bernhardt was a big inspiration for me as well. Cool, cool. Yeah, this is – it's cool. I mean to see – so you're not – I don't know how – what's the best way to say this? To do screencast, to get to some level of credibility is the right word.

But at some point you have to prove to people that the code you're writing is good code. What you're doing is quality stuff, and you call it gourmet Ruby. So what do you think it was that – because for me, I think the first time that I ever heard of Avdi Grim was probably when I read Exceptional Ruby, which is a tremendous book. Thank you. How do you think – what do you think kind of gave you a little bit of that credibility? I don't know if notoriety is the best word, but just the ability to go out and start to sell your – what ultimately isn't even necessarily a product.

It's your sharing knowledge. So what do you think got you to that point? It's just an incremental process really. I mean I think it's probably similar for anyone. You start to write things here and there. I started to blog, you know, a while back, long around 2006 or 2007. And, you know, I found that people seemed to like some of the stuff that I wrote. And eventually I got around to doing a talk or two. And that's where Exceptional Ruby came from, was I did a talk and then I was like, wow, I've done all this

research about exceptions. It would be cool if I could kind of recoup some of the time somehow. So I turned it into a book and people like that too. So it's really just like the confirmation of the market. People buy something. People don't seem to hate it. People don't ask

for their money back and they actually say nice things about it and eventually it kind of breaks through my assumption of I'm just another dumb programmer that maybe some of the stuff that I have to say, not everybody knows. Before we get into what I think the meat of the show is going to be with pairing, I have a question for you. What do you think about, what are your thoughts on being an exceptional master? What are your thoughts on exceptions as control flow?

I'm not a fan. So would you do Exceptional Ruby as a talk before you actually wrote the book or no? Yeah, I did. Okay, so would you get that question often when you would talk on exceptions? I think a few people probably ran that by me. I think I did make a point, if I recall correctly, I think I made a point of including catch and throw even in that talk. I was actually, I got to use that transformation just the other day. I was working on the discourse code base, and I submitted a pull request converting an exception used as control flow

into a throw and catch, which is sort of the approved Ruby way of doing that. Right, right. Cool. Yeah, I think that might come out of my Java days back in college, but that's a question that I think I've had many long arguments with developers on it. So for a non-local return in a language that doesn't have something like throw and catch or continuations or anything like that, sometimes it's the only thing you can do. Do we need to give some background to some of this context just for those who may not be Uber Ruby developers

but want to kind of catch up with what this means? Yeah, go ahead, Avdi. Whydi once you explain um uh which part so you get exceptions what's this method of catching and throwing okay so uh a catch and throw in ruby is a construct that's actually very similar in implementation to exceptions it's it's another way of sort of tossing something up the call chain and it unwinds the call stack until it gets to something that can catch it. So it actually, you know, describing it, it sounds a lot like exceptions and it is, but it's specifically intended for non-exceptional cases. It's specifically intended for the case

where you want to, you know, just do an early termination, but you need to kind of do it non-locally. The circumstance that I saw this in most recently was a SACS parser, which, of course, is you hand the parser off to, or you hand an event handler class that you write off to a parser, and the parser then calls event methods on that event handler that you wrote. And at some point in the one I was looking at,

they realized, okay, we're done now. We don't need any more XML. But how are you going to tell the parser that? There wasn't any way to tell the parser yet. Parser, okay, stop pulling data. Stop going through. We don't need any more. Just end it here.

And so they were using an exception. They were raising an exception up the call stack and then catching it higher up. And using throw and catch is a bit nicer in Ruby for that. It's cleaner. It actually looks better. There's less code on the page. You don't need to define a special exception just for it because you're throwing a symbol instead of an exception. It's just generally better looking.

Down into the rabbit hole, Adam. Yeah. i'm there with you i'm so right there with you honestly it's kind of neat though i mean because it seems like um it might have came about as like a hack but it's a good technique a good method and it's you don't really have any other way to get around it but it's a good way to use contracts and ruby to achieve your goal yeah well it's one of those cases that you almost never need. I mean, I would hate to see a code base that was using them all over the place because that would be really scary. It doesn't seem like it's the most reliable way, but... Every now

and then you need to break through a layer of somebody from your software through a layer of somebody else's software back to your software again, and that's where those sort of non-local terminations come in. Gotcha. And the notion or the concept of an exception is very old. It's not anything new to Ruby or anything.

So that's an argument. That's a debate that has been had for years amongst developers. So I think it's going to continue. I think throw and catch specifically, I think they may have originated in like a Lisp scheme or something. I'm not certain. Yeah. Cool. uh like um scheme or something i'm not certain yeah cool so okay so to kind of get to the topic du jour um to keep up with the gourmet ruby oh yeah i caught that i'm with you uh okay so

one thing we want to the thing we kind of want to get to is is pair program with me um and why don't you give us an introduction it's a like i i think the best way to describe it um abdi instead of calling it a product necessarily it's more of a movement or more of an idea yeah is kind of building a community so why don't you give us some insight into what it is where we can find it and where you'd like to see it go okay well let me let me start off with a little bit of history um i've i'm a big fan of pair programming. I'm going to – should I assume that most listeners are familiar with pair programming or should I introduce that? Why don't you go ahead and introduce it?

Yeah, I would definitely say introduce it. Pair programming is the very simple idea of programming – not programming solo. Instead, sitting down with somebody else and programming. So it's not exactly groundbreaking, but it was part of the original extreme programming practices and probably one of the most controversial of them. Partly, I think, because a lot of programmers like to think of themselves as solitary beasts,

and partly because there was a perception that, well, if you take two programmers and you put them in front of one screen, then you're going to have your project speed. But it turns out that it's an incredibly effective technique for many, many reasons. Number one, it's kind of constant code review. I mean, code review has been found to be one of the most effective ways of avoiding bugs that we know of, and pair programming is a way to always be code reviewing. It's a great way to retain

focus. I've found that when I'm pairing with someone, I stay focused and I don't get distracted nearly as much because who – your pair probably doesn't want to pair with you on Twitter. So you kind of feel like I should probably stay focused on the task at hand. You don't know the kind of developers I pair with. Do you like pair every other word on a sheet or something? Careful, Angelic could be listening. Write this. Yeah,

you know, so it's one of the big benefits that I like about it is the effect on morale. You know, I've found that sometimes I'm having a bad day, sometimes I'm working on a piece of code that just bums me out and I really don't want to touch it and I don't want to deal with it, but I have to. And having somebody to deal, to go through that with you can be

a huge pick me up. And gosh, there are so many good things about pairing. Pairing keeps you, uh, pairing makes you smarter. Um, programming alone, you can do some really dumb stuff I've found. Like, um, let me give you an example. Uh, recently I was writing some, working on some backend code for Ruby Tapas. And I was basically trying to pull some data out of the shop front service that I use. It's a third-party shop front service called DPD. And earlier, I had actually worked with them to define and, like, to get a feature rolled out, which was that you can sign up to the Ruby Tapas videos as an RSS feed in iTunes or Miro or a bunch of other programs. And I'd actually worked with them on that.

I'd sort of laid down what the RSS format should look like for it and all this stuff, and then I'd moved on. So later on, I was working on some back-end code, and I was working alone some back-end code, and I was working alone, not pairing with anyone, and I was working on pulling data out of their website, and it was just basically screen scraping because they don't have an API for this stuff yet. And I had finished all this really complicated screen scraping code

when I got into a conversation with somebody on Twitter about the screen scraping code when I got into a conversation with somebody on Twitter about the screen scraping code. And they said something about, well, it can't be that hard parsing the RSS feed to get that data back out. And this huge light bulb sort of crashed down onto my head as I realized that I had been sort of blindly screen scraping information that was in this RSS feed that I had helped define. That is the kind of stuff that happens when you program alone, or at least when I program alone. And it's not just that either. I mean, if you think like, if you're a developer and think about, you know, oh, this problem before and it might not be the best, most efficient way to do this, but here, let me just copy and paste this code.

Well, you're not going to do that if you have your colleague watching over your shoulder. And just to kind of real quick, to fill in a gap, in case anybody doesn't understand the concept, I don't think we actually said it, but when you have two people in the same room pairing together, typically there's one person that is actually sitting at the keyboard doing the typing and another person that's watching, that's like, you know, looking over your shoulder and you're talking about what you're doing. He's watching what you're doing, pointing out things as you do them, if they're incorrect, kind of a idea. Yeah. And there are a couple of different, I mean, there are different models of it. You have sort of classic navigator driver pairing where basically the navigator is sitting back, hands off the keyboard, but they're actually doing most of the thinking.

They're telling the driver what to do, what to code. Driver is responsible for actually getting it onto the page, making sure that they don't make too many typos and hitting the button to run the tests and all that stuff. And the navigator is kind of freed up to sort of wave their hands and think, and, uh, maybe look up documentation and stuff like that. Um, and they may, they may well switch off periodically. Um, you know, traditionally if, if like the navigator ran out of steam, they might switch around, switch around and, you, and maybe the driver says, oh, I think I know what to do here, and so they switch off.

And then there are other things like ping-pong pairing, which is a method of pairing that works well with test-driven development, where basically one person will write a test, and then the other person has to make it pass, and then they keep going back and forth like that. And sometimes it's less defined. It's more organic. It's just two people sitting there and trading the keyboard off as they see fit. Some people actually set up desks. If you're co-located, they actually set up desks where there are two keyboards plugged into the same machine.

And I've noticed that with remote pairing specifically, the more organic style is what kind of seems to fit. And that we're talking to each other as we're looking at – we're sharing a screen with Wiimux or something. And as we're looking at that, we're talking to each other. And you kind of just have to get a feel for the other person and how the other person works. And so me and some of my coworkers, as we do it, if I notice something and I know how this person works, I know when it's appropriate for me to jump in and type something and to back out. And it just kind of happens naturally for us. So I think that tends to be – what do you think? I think that tends to be more common with remote pairing.

I don't know. Because it is hard. I think it depends on the technology you're using and the kind of connection you have. I mean, so I've actually done a fair amount of – quite a bit of remote pairing using screen sharing and um that tends to be less of an organic handing the keyboard back and forth kind of thing just because uh most screen sharing software has latency that's high enough that it's really impractical to type if you are on the remote end right um so it partly depends on what kind of technology you're using so So what happens whenever – I mean it's great if you're in that situation when you're sitting in the same room. But what happens – and I know some of the answers to these questions, but I'm just kind of curious from your perspective.

And the reason why we're having you on the show is to talk about this deep pair programming topic. But what happens when you're not? And obviously you've got answers for that because you do the podcast, Why Teams? You've talked about this heavily. How does the situation change when you're not face-to-face? You're not in the same room. I think the truth is that it doesn't change a huge amount.

Obviously, there are some technical hurdles. There are various technologies to bridge that gap. Like we said, there's screen sharing. Another very popular technique is to use some form of Tmux to share a terminal. And the nice thing about sharing a terminal is that it's very low bandwidth, and so it actually becomes practical for somebody remote to type on your screen because they don't have to send that

very many you know that many bytes um and there are various i mean there are sub categories of that there's hosting it on a like a shared machine in the cloud versus hosting on somebody's own machine stuff like that so you mentioned vmux and tmux i mean how much andrew you think we should explain some of these things because i I don't want people to assume. Well, we can link to that kind of stuff in the show notes. Yeah, we can. I want to say that I actually don't find the technology all that interesting. We're at the point where it's totally possible, and that's kind of all I care about. Right.

I mean, it's constantly progressing. We keep having new stuff. There's a new screen sharing service called Screen Hero, which is kind of cool because it's really, really fast. And you each get your own cursor, your own mouse cursor on the screen. And there will be more interesting tools in this space. But in the end, it's more about what you do with the tools. Right. And real quick, the technical hurdles involved are typically hurdles you have to jump over once.

And once you get over those hurdles, you don't really have to deal with them anymore. Yeah, pretty much. So we don't need to focus too much on the tools because that can be different for everybody. So to kind of move on – again, we'll share all that stuff in the show notes. But to move on from this to pair program with me, so now we kind of have an idea of what pairing is and so yeah, it's beneficial. So go ahead. Yeah, I mean, so I I'm a big fan of for all those reasons, I'm a big fan of pair programming. And then I did something kind of crazy last year for like the latter half of last year, I stopped, I kind of stopped doing traditional consulting work, which is what I've been doing for a while. And I became what I think of as a consulting pair programmer.

And basically what I did was I took appointments with people to pair program remotely for two hours at a time. That's what I did for my job for probably like six or eight months. And it was awesome. I really enjoyed it. And, you know, a lot of people seem to really get a lot out of it. And at the end of that, that sort of came to an end. I still do that. I still do open source pairing sessions. But I'm not doing that as my job anymore because, like I mentioned before, Ruby Tapas really took off.

And so I made that my main focus. But, you know, coming out of that, I just felt like I wanted more people to have that experience, especially more people who maybe are not part of a team, a co-located team, where they get to pair program every day. I really wanted to see more people who are isolated or who are living. Maybe they're in a city, but it's not a big tech hub city, so they're not around a lot of other programmers, or they're like the only programmer on their team,

or for whatever reason are not getting a chance to pair program. I want to see more programmers benefit from the experience of pair programming. And so I decided that I kind of wanted to just basically start a movement. And that's kind of where – so the URL is pairprogramwith.me. Yeah. There's a couple of these out there, but it seems to be that – and maybe this is because of people like Steve Klabnick who – I don't think you've said a word yet, Steve. I've said one or two very briefly, but yeah, staying out of it.

But Steve has kind of embraced this, and I think we have some of the more – without trying to sound like a suck-up – some of the more well-known Rubius in the community that are starting to embrace this concept. And I think that that will help this to move forward. So pairprogramwith.me again is the URL. And the idea is that you can basically, you're just, there's nothing special that's necessarily happening with this project. This is just making it, this is helping you to get an idea to share with the world that you are available to pair. Yeah. I mean, the website is almost incidental. Um, you know, I wanted some sort of focal point. Um, but when I launched it, it had a badge and nothing else. So it had a badge you could put on your site. And that's, you know, the badge says pair with this

says pair program with me. Um, or maybe it says pair with me and he said, but anyway, pair with me. Um, but you know, it's, it's kind of like the, it's kind of like the badges that you see on some websites that say fork me on GitHub. That's, that was kind of my inspiration. Um, and, and that was really all I launched with. And, and that's, that's when i kind of kick things off with a talk um at ancient city ruby um a couple months ago and yeah i mean it's it's really it's an idea the idea is uh you know number one pairing is awesome number two you don't need to be in the same room to do it um and number three all you really need to do is ask um i guess, you know, for me, the biggest thing is sort of inspiring a culture where we ask each other, hey, do you want to pair on this? And half of that is

the asking. And half of that is having an environment where it's okay to say that, you know, having an environment where it feels natural to say that. And so I kind of wanted to get people to start putting this badge up just to kind of put a welcome mat out, to make it feel like, yeah, it's okay to say, hey, would you pair it with me on this? And I think that the one thing that you find, especially in the Ruby community, and I've spoken to some Python guys, and this is, I think, in every community, but in the Ruby community, one thing that you find in especially in the ruby community and and i've spoken to some python guys and this

is i think in every community but in the ruby community one thing that you find and when we had our uh a few episodes a few episodes ago we talked about get tip and one of my concerns for a project like that is that you have all these rock star ruby developers that get together and this is just a way for them to to make each other feel like even more of rock stars right and so the whole idea behind pair pair program with me we need to say ppwm we need to say you can just say pair with me the whole idea behind pair with me is kind of taking that barrier away right so this is like if if you're a i don't know ruby rock star i don't know what to call yourself but if you know you kind of know, hey, I have some clout. Like, I work on some bigger projects.

You know, like Steve, you work on a bunch of stuff. You're on the, you know, do Rails contributions. You do a lot of stuff. If you make this known to the general public, then you're bringing that barrier down a little bit. And you're saying, hey, like, you might look at me as a Ruby Rockstar, but I'm available to help you learn, to help you solve a problem, to help you do whatever it is that you need to do. That doesn't necessarily even mean that every single – like Steve Klabnick is not my coworker who I'm going to reach out to every time I have a problem to fix my problems for me.

But it does say that you are making yourself available in cases where you're needed and if you have the time and if you have right you know whatever i mean like i said i i do open source pairing sessions um and um and those have been those have been really neat for me and and what i really like about them is you know those are free sessions obviously and and uh they've they've often been times when I get to work with someone who's really new to programming or new to Ruby or new to whatever technology we're working on. And it's a fantastic experience. I highly recommend it to anybody who's kind of advanced at what they do because it's just – you get to experience that – vicariously experience that thrill of learning something new, that, oh my – wow, I didn't know you could do that. That's amazing. You get to experience those moments all over again. It's like we forget that there was a time where you had to learn what it meant to assign a variable. Yeah. I mean, I fear that maybe sometimes people might look at the idea of pairing with a newbie and think, wow, that's going to be tedious. But the truth is it makes you feel amazing. And so I guess really like my biggest call is out to people who are kind of in that position of, you know, knowing knowing whatever whatever language they work in, knowing it pretty well, being pretty good at it, you know, maybe being seen as as a guru or a master or whatever.

I would love to see more people in that position kind of put up the welcome mat and say, yeah, come on, pair with me. It'll be fun. Um, I think it, there's a lot, I've seen a lot of people, you know, who are, who are newbies who feel like, um, you know, these people are unapproachable, you know, their, their programming heroes are unapproachable. And, um, you know, I, I think we all know. Well, I guess the newbies don't know. But, you know, we're not unapproachable. I try not to be unapproachable. I don't really think any of the people that I, you know, see at a lot of the Ruby conferences are remotely unapproachable. And, you know, we're all just programmers. People still think there's like sauce like i so

i've done a couple of these sessions a lot of these sessions now i wasn't actually even an obd's talk i just saw him tweet about it i was like sounds good tweeting and then i was like oh i have like 15 appointments this week now which is awesome looks like i'm pairing and it went real well and i actually did yesterday and today as well um random pair with me stuff as well but um i had somebody literally say to me like hey i'm real sorry that we keep writing this code and this test fails and then like it's taking a while to get it to pass and i was like i don't know what you think i do all day i run my tests and they fail and i try to fix them and they don't work and then i run them again and then they fail and so like you know it's all we're all just programmers it's not it's not a big deal um but you're steve klabnick

you don't have to write tests everything works that comes out of your fingers stupid so this is actually what happened to me obviously said earlier like you know when you feel really bad about code it's great to pair with things um and so actually that's what i did today um assuming it passes a little bit of review i'm going to commit this to rails later today but like um so i found a regression in rails because of the readers of the rails for an action book found a discrepancy between like beta one and r RC1 and so I figured out what it was and I got a failing test and I tried to fix it and it didn't work and I was like wow this feels really stupid like basically just when the password confirmation is nil or empty string don't worry about it which like super trivial and not complicated but I couldn't get my freaking test to pass and so i

ended up like tweeting finally like hey i'm feeling really dumb could somebody pair with me on this and we paired and i thought we got it working but it turns out we didn't so today i did the same thing i was like hey is anybody interested in like working on this bug and so finally after two pair with me sessions i've managed to like the the diff is like a three-line diff or something it's not even complicated it's just that like talking with someone is so helpful um you know and what's hard is different based on time and how you're feeling and all that other stuff too so so how how concise do you think the topic needs to be so if you if somebody reaches out to you and says hey can you pair with me on this how exact does that topic need to be before if the topic is too broad right there's too big of

a learning curve for somebody that you don't know to maybe want to get involved. So how exact on a – that specific instance for you, Steve, you were like, here's the test. This is failing, and I can't figure out how to get it passed. That's pretty specific. You don't need to understand anything else other than what you're doing. But if somebody comes to you and says like you know hey um i need to i need a shopping cart like that you know what i mean like that that's too broad to to be able to really sit down at one time and say let's work on that together so where do you at obvi and steve maybe where do you

consider the kind of the sweet spot with like how precise do you need to be with the with the thing that you're trying to work on um i don't know. I haven't really thought that hard about it. I try to avoid... If somebody approaches me and is like, I want to make a new Facebook, then I'm going to say, hey, can we sort of contract the scope a little bit?

But it's kind of, I don't know, it's one of those organic things. It's each, I think each pairing session kind of works out its own parameters. I don't have anything specific on scope, but I just like limit it to time. So I'm like, oh, I only have one hour. I only have two hours.

And then, you know, if the goal is to learn, then you can get two hours worth of learning, regardless of whether the scope is huge or small. So I find that's much easier in terms of also with people's scheduling and expectations, you know, that it's not going to last, like, longer than a particular amount of time. So that was one of the things, yeah, the other day was like, hey, I have a call in an hour and a half. So we can work on this up to that amount. But, like, you know, I have this other hard boundary. Yeah. With your interests and some of your skill sets,

that means that typically I'll get an hour to two to build a hypermedia API with you? Yeah, basically. I haven't done that with anybody yet, but, you know, that would be fun. Mostly it's been Rails and Rescue so far is what I've done most of my pairing on because people are very interested in, like,

how to work on Rails, and then, like, it's the same as any other Ruby project. You clone it, you run some tests, you write a new one, you make a pass. But I mean, obviously it's a big project. So, you know, that can be complicated. To be perfectly honest, and maybe I shouldn't let this on, but I've had, I mean, I've had pairing sessions that kind of just devolved into answering questions or having a conversation. And that's good. I mean, because what, so Kenneth writes on a show a few weeks ago,

talked about in Python, and we have this in Ruby too, like you can read all the books you want, but there's this set of tribal knowledge that you pick up as you go and as you do things wrong and as you read other people's blog posts and you watch Ruby Tapas

and there's this tribal knowledge that isn't necessarily in any book, right? It's hard to just teach all of Ruby in one book. So for newbies to come to you and they might have a very specific problem, but if it kind of breaks down into just like a question and answer and education session, that's good because that's an opportunity for you to share that tribal knowledge, to share like this is best practice. This is what we tend to do in this world. So here's some insight. And, and I mean, who knows if that's, if that gets the, the, the Ruby newbie, the, uh, most confidence that they can have to, to continue on it, that's probably the best use of that time. Is it not? Yeah, absolutely. And that's one of the biggest reasons that I kind of got this started was the idea of just spreading ideas, spreading knowledge, what I think of as kind of mimetic diversity, diversity of ideas. And I think that pairing does that better than anything else.

And it's good for us as programmers. I mean, having a wider, getting to learn from a wide variety of other programmers' experience, I think, you know, makes us well-rounded, makes us better at what we do, gives us more tools in our toolbox when we're confronted with a problem. It's just all around good. If I could jump in here real quick on the, on the notion of approachability and some of the, I guess, potential of like having a,

and we have this question here at the end of the show and I'm excited to hear what your answer is, Avi, but like, you know, you have your programming hero and you want to maybe, you know, for some you might just have a problem you want to solve. Like for example, what Steve and Andrew were mentioning earlier. But how is this breaking down the barrier, breaking down the wall of actually getting to pair with your programming hero? Well, I think the ideal scenario for me is maybe that programming hero puts out a Pair With Me badge or tweets Pair With Me. And you say, hey, can I do you know, tweets pair with me and, and you say,

Hey, can I do it? And they're like, sure. Um, you know, I think that's kind of the ideal scenario because it's, it's the lowest barrier to entry for somebody who might feel a little nervous about asking. Um, but, um, you know, in general, I, I'm sorry, go ahead. Well, I was gonna say it's a lot easier when you're invited than if you're trying to, you know, come knock on the door of a stranger. Yeah. But, I mean, something else that I'm trying to encourage. Yeah. You know, something else I'm trying to encourage is just to is that I think I mean, I could be wrong on this. One of the questions that I've asked people when I've talked about this is, basically, if somebody came to you and said, hey, I really like what you're doing.

I love what you're doing with Project X. Could we pair sometime? I ask that question, and I usually see a lot of... Or I ask, what would you say to that? Would you say yes to that? And I usually see a lot of hands go up when I ask that question and I usually see a lot of – or I ask, you know, what would you say to that? Would you say yes to that? And I usually see a lot of hands go up when I ask that question. You know, I think that most people are pretty open to this kind of thing. And so I think that if you have some way of reaching that programming hero of yours, you know, if they put their contact form up somewhere or if they make their email address available or if they're just out there on Twitter or something, if – I think if you politely say, hey, I really like what you're doing with such and so.

Do you think we could – do you think I could pair with you sometime? The worst thing that can happen is they ignore you. Yeah. It's true though, because I think that the fear of your, you know, people are afraid of the program, their, you know, whoever they would consider to be one of their heroes. And it's probably this self-made, you know, delusion that you have that they're going to, you know, treat you like you're an idiot. And it's kind of the whole crux of open source. And it's kind of what we preach to people is, you know, just ask because the community, while there is, you know, and again, I've seen this far too often where somebody will commit a pull request to some, you know, repository and say, hey, this is something that I would like

to do. What do you think? And they just get a response like, this is stupid, you're doing it wrong, and it gets closed. That does happen. obviously. It's unfortunate, but it does happen. But that's not the norm, right? Normally, when you submit something, even if it is something that's pretty questionable, the responses you'll get typically will be more like, OK, well, did you think about trying this way? This is what we tend to say is a better solution to that problem. And that's the norm, right?

So people are afraid of submitting their code. People are afraid of the world seeing their code because they're afraid of the response they're going to get. Typically, that response is a lot more positive than what they expected. And it's more encouraging than anything to get you to contribute more code. So when people finally break the wall down and start contributing to open source, you find that their contributions jump because they get encouraged about the response they're getting rather than fear of being treated poorly. Right. Yeah, and something that I kind of want to get into doing more is if I just don't have time or if I've got a huge backlog, I'd like to actually do more sort of referring people out. I'd like to, if nothing else, be kind of a nexus where people can say, hey, can I pair with you? And I'll be like, well, I really can't right now, and I've got a huge backlog of pairing requests.

But here's somebody else that you might enjoy pairing with. So I guess that kind of brings us to a good place then. Pair program with.me. So it's a Rails app, which for what it is might be a little heavy-handed but um yeah does is that is there a future is there would you like to see something like that maybe like a i don't know like a queuing system or something where you can maybe say hey i'm available right now and um then somebody else can come and say okay this person's available let me ask them like is there anything like that you would like to see there there are a bunch of young sites out there

um along those lines and i've tried to list most of them on pair program pair program with dot me see i have trouble saying it too um uh and i don't know like so, so the idea, I mean, the idea with the site is basically to be kind of a community owned thing. I mean, most of the stuff that's happened since I put it up has been pull requests that people submitted to me. And I think, you know, I've definitely talked to some of the people that are involved with it about something along those lines. I have some concerns about that it would be easy to make something that actually wasn't as useful as it seemed like it would be. I know that I don't want to get into the rabbit hole of scheduling because that's a huge mess. And I'm a little concerned.

What I don't want to do is build a system that winds up sort of reinforcing circles. Like you were talking earlier about sort of like the circles of experts all pairing with each other. And I wouldn't want it sort of reinforcing that or kind of leaving people out in the cold if they put just the wrong tags in their post or something like that. So I think it requires a lot of thought to be genuinely useful. But I certainly – I do expect that site to kind of expand and offer more features for, you know, more, more ways of finding people to pair with as time goes by. So then you're kind of leaving it open, right? Yeah, it's a true open source project, you very, very open. It's not it's not like I have a master plan for that site. I have a, you know, milestones or anything like that. You know, the idea was, I wanted to get

the idea out there first. And I wanted to then, you know, and attract some people to the cause and, you know, see, see what, you know, what other people felt like would be the most useful things to have there. Like, I think pretty soon, um, uh, there's going to be, it's a small thing, but I'm going to put like a little widget on there that, that, um, shows all the people tweeting with hashtag pair with me. Um, so at least you can go there and see like who's available right now. Yeah, I think that's good. I think we, you know, while the trend in open source has been to kind of have that, you know, BDFL on each project and that's, that's neat and all for somebody to have this master

vision and this is where the project's going to go. And I'm just using the open source community to leverage other people to help me get it in that direction. That's, that's cool. You know, that, that, that's definitely a useful, you know, one of the many applications of open source. community to leverage other people to help me get it in that direction. That's cool. That's definitely a useful – one of the many applications of open source. But I think what's even more unique and what I think should – what I would like to see grow is the idea that I'm just starting this ball moving and I want to see the community get behind it and take it wherever it wants.

And for me, the idea is – I want the idea to always be paramount. I mean the site is incidental. The site exists – it exists to support the idea, but ultimately it's – I don't want this to become like a technological problem to solve. It's not a technological problem to solve. It's a cultural problem. It's a cultural opportunity. It's a cultural opportunity to enable technical

problems being solved yes you know you said the word culture there and i'm we andrew mentioned this might have mentioned this earlier but uh so we he and i work in a distributed team at pure charity and we have a back channel it's also known as our hip chat so our our actual water cooler at pure charity serves as a water cooler here for this show for those that work with us actually listen to the show but uh beverly nelson i think you you might know her but she mentioned in our chat room she said 80 of her friends at ruby friends uh is is about bringing them into the culture not so much the coat and i think there's a lot of magic to what you know she said you guys are talking about

culture there i think it it becomes not so much uh oh I know Ruby well you know more better than you or you know I've got more experience it's really about just getting involved you know regardless of your of your level of activity and whatnot but just jumping in and that's probably the hardest part too about open source is you there's just this this huge intimidation that you have a bunch of assumptions before you're involved that this is how it's going to be and it's not at all really how it is and we're a lot more friendlier than people might think. But I think that's with that, is I started putting some of my pairing sessions up on

Google Hangout on Air. And I didn't really announce it or anything. I would be working with someone and I'd be like, hey, do you mind putting this up as a Hangout on Air? And then whoever happened to be around could tune in and watch us.

And I recently did one of these actually with one of my co-Ruby Rogues Josh Susser and put it out there and got a lot of really good feedback from it. I think some of the feedback that I think was most interesting for me was kind of the

the way watching was kind of the, like, um, the, the way watching it kind of took the, the magic out of it. Like, you know, took the, that aura of, you know,

the thing that those coders do is different from what I do. Um, and, you know, I think that if we, maybe if, if, if I,

and maybe others put some more of our pairing sessions up like that, um, other programmers can look at it and say, oh, wow, that, you know, basically the stuff they do is the same stuff that I do. And, and they make the same boneheaded mistakes and they sit waiting for their tests to pass. And, and, you know, and sometimes, sometimes they spend an hour and write three lines of code and, um, and it's not, you know, and sometimes they spend an hour and write three lines of code and it's not, you know, there's nothing magical about it. There's nothing unique about it. We're, you know, we're all just doing the same stuff. I think that's kind of something that Steve said, not so much said with his words, but that we're all doing the same stuff.

Steve, didn't you, for a while there, weren't you Vimeo-ing, if that's a word? Like basically just you hacking by yourself, but you were just hacking on Hackity, I believe, and you were sharing that on Vimeo and people were watching like, oh, yeah, he does the same thing I do. Or you would actually have your own commentary in there and you were just talking to yourself. Yeah, it was with hilarious results. So I didn't fully appreciate how to properly mix my audio, or I didn't notice that the audio was mixed poorly. And so there's one of me fixing a bug in RubyGems with Kesha louder than my voice.

So I tried to provide commentary, but instead it's just blasting Kesha. I wasn't sure. I thought it was something hilarious too, but I wasn't able to recall. Yeah, it was something hilarious too, but I wasn't recalling. Yeah, it was pretty good. So I would like to get back to doing a little bit of that, but it's just one of those things

where I did it a couple times and it was fun and people liked it, and I just haven't done it since because I haven't done it since, not because of any specific reason. Sometimes you've got to break the mold, man. Do something a little different. Don't follow the same rhythm and the rhyme.

It's also just funny because you're like when you're like recording your screen you're always like terrified that something is going to happen like what am i going to type or am i going to get like an im message that should be private or like you know how is this going to work out so that's also real fun too um but uh yeah you know i mean i think it's good uh just in general that was what i was trying to show with rubGems is that, like, you know, RubyGems is a particularly terrible code base due to its history and et cetera. And so, you know, watching, like, here's how I tackle this kind of bug, you know, you could totally do it too was definitely, like, the point of that. I was like, I don't do anything but just run the tests and cuss over and over and over again.

I can't imagine if I'm pairing with somebody and I am from my wife pops up reminding me to get the rash cream or something. That would probably be the worst thing ever. That seems bad. I just noticed on pair program. I know. Somebody might think that you're human or something. Yeah, I don't want that, man. They are supposed to like – I'm supposed to be a demigod of programming or something to them. Just kidding.

Hopefully everyone knew that. On pair program with.me me i just noticed the header you say pair widely pair often is that a uh shout out to the idea of wide teams a little reference to wide teams there that's the second uh last week we had docker on and they had a number they had their on their frequently asked questions they went numbers one two three four five and then to 42 so this is the second little uh nugget i found in the uh products you're so you're so keen man you know that's right so confident ruby another book that you are writing still i mean it's in betas i mean you're still writing it's in beta which means that I've pronounced it content complete after taking Kent Beck's advice to get it to 150 pages and then just stop.

And so it's – I'm still editing the crap out of it, but it's content complete. And this book, again, stemmed from a talk that you've been giving yeah um actually i think it was the first talk i wrote um which i called confident code and uh it's it's all about writing methods that tell a coherent story uh sort of a narrative style of of writing methods is how I think of it. And a lot of that involves writing code that sort of confidently progresses forward without a lot of tangents and diversions and provisos book of patterns that are strategies for making your code more confident, for telling those stories more coherently and isolating the error handling and dealing with input in such a way that you don't have to be uncertain about it in the midst of the method and stuff like that. Yeah, it's a – where can you – I couldn't find it anywhere other than on your store. Is there anywhere that... If you go to ConfidentRuby.com,

you'll actually... Actually, I think that'll redirect you to the blog post where I first introduced it. And so that's probably the easiest way to get to it. You can also find announcements about it on my blog, which is devblog.avdi.org. Yeah, we'll have this. I found the link. We'll have the link in the show notes.

For those of you who listen to the podcast, head to 5by5.tv slash changelog slash 90 to see all the show notes and links and everything else. So don't be lost. So, Avdi, what are your uh engagements planned for the future that you already have set up i keep meaning to put together like a an actual list of them um let's see uh next one up i know is going to be um uh yeah name god uh the one in DC Arlington not yeah oh gosh

it's Ruby Nation Ruby Nation thank you my mind wanted to be like Nation Ruby and then I was like no that's not right yes Ruby Nation and in just like a couple of weeks. And speaking of Ruby Nation, you gave this confident code talk there, too. Yeah, I guess I did. I'm doing a I believe I'm going to be doing a talk on coding and joy, basically.

Little little bits of Ruby that just make me happy, uh, this time around. So, um, yeah, that'll be fun. And then,

uh, after that, um, several others, I think, uh, well, I'm going to be going to Pittsburgh,

steel city, Ruby. Um, love Pittsburgh. Woo. Stack. Adam is from Pittsburgh. Originally born and raised in the Pittsburgh area.

So that's uh steve where are you at i mean i live in santa monica now but um i i lived in pittsburgh my entire life before moving to los angeles so there you go i thought so so everyone everyone on this chat has some connections to pennsylvania that's that that has happened in pretty much every chat that i've ever had i found it's weird It's weird. It's six degrees of Pennsylvania. Yeah. So you'll be at Steel City Ruby. When is that?

On the date that it is on, yes. Yeah, it doesn't matter. August, middle August sometime. Awesome. So for those of you who are new to the show and those of you that have listened, you'll know, we ask all of our guests these two questions. The first one, Abdi, is for a call to arms. And I guess in this case, you could give us a specific call to arms for pair program with.me, if you want.

Yeah. Or just kind of what you would like to see the community do around this. I don't think it's going to come as any surprises at all. It's just go out there and pair with each other. Go ask. If you have somebody that you've always wanted to learn from,

go ask them. If you have some time in your day that you would be working on open source or something anyway, welcome that out there. Put that badge on your blog. Put the day, you know, that you would be working on open source or something anyway, put that, welcome that out there, put that badge on your blog, put the, you know, hashtag pair with me on your Twitter feed if you do the Twitters. Make yourself available. I think you'll find it incredibly rewarding to pair widely, pair diversely, pair more

often. How do you feel about pairing on more conceptual, like if somebody's a Python developer and you don't have Python experience, pairing conceptually on an idea, how do you feel about that? I think it still totally works. Just the other day,

I paired with somebody on some.NET code, some C Sharp code, and granted, I have done C Sharp before, but it was years and years ago and I was totally rusty. And it didn't matter. I just basically had them be the driver.

It could have worked either way, but it worked. That was nice just because they already had their whole environment set up, and they had their IDE, and they knew the key bindings and how to make the tests go and stuff like that. But it was fun because I actually got to teach them something about C Sharp. Not because I knew it, but because I just sort of like basically figured that a particular library call had to exist and looked it up until we found it. And basically it was using a more functional approach to solving a problem than they were used to.

Maybe as an attachment to your call of arms, I have a couple ideas I can share with you on the fly. Maybe start a wiki page for those who, on the PPWM repo you have on your offer user, maybe a wiki page that says, hey hey i'm open for pairing and or moving this to an org and maybe having just a project for issues where you can kind of allow issues to coordinate the community potentially just an idea yeah yeah that's a good thought actually we've we we have started using the the wiki a little bit on the the page for it. Gotcha. It says, welcome to PPWM.

I'm just messing with you, man. Just one thing. I did want to give a shout out. This is a community project, but at the bottom, I noticed you said the design was done by Chris Radford and the badge was done by David Browning. So kind of wanted to give them a little bit of a shout out for getting in on this thing early with you.

Yeah, yeah. And they totally deserve it. Much gratitude to both of them and to everybody who submitted a pull request. All right. And our last question, if you could name a programming hero or, again, somebody in the idea of distributed workplaces or wherever you might think what would who would you say your hero would be um so i could obviously name any number of amazing programmers that have influenced me and then i look up to uh but i think i want to give a shout out to Angela Harms.

Because she's been doing some talks in the Ruby community lately. Well, in the programming community lately, not specifically the Ruby community. She's, I guess, maybe more part of the Agile community, you could say. I think that would be her background. It seems right, yeah. And she has been, she talks to programmers about compassion. And

she does it in a way that's effective and really is eye-opening and I think heart-opening. And I think that's wonderful. And I think it's much needed. Uh, so, so yeah, I'm going to say Angela harms. Uh, did she, I want to, like, I remember there was something like a radical something that she did or that I remember seeing her name on.

I'm actually not sure of like any of the, I don't recall any of the specific titles of her talks, radical love or something like that. But yeah, no, I definitely have – well, it's not RadicalLove.org. It's something that she did. But yeah, or at least I remember hearing her name with. But I agree with you. I think that there's something inherent that we need to see in this community and it's it's it's the idea of like i don't know just acceptance of people in this community and you can get bogged down in what you know the ruby

drama or whatever we we call it where um you just you get on and you follow some of the big names in the ruby community and it's there can be a lot-calling and a lot of just trash going back and forth. And I don't know if maybe that's what you're hinting at, but I would like to see less of that and more of just people genuinely respecting each other in the community. Well, you know, not just a Ruby thing. It's just a programmer thing in general.

I think we have a culture that's very rationality-centric, very logic-centric. In theory. Yeah, in theory. You know, very often. Yeah. In theory, we believe it to be. And of course, we also believe ourselves to be very logical. And I think a lot of, you know, a lot of times, you know, we think that solving a problem boils down to being the most rational person in the room. And I think the stuff that she's talking about will challenge that. And I think it'll challenge that in a good and important way. Yeah, that is true. I mean, I think it begins with

you, right? It begins with us as an individual to be different and to act differently. So don't be a hater. Repeat after me. We are all different. Somebody's got a... We're all... Yeah. Somebody's got... Nobody? The response is, I'm not.

Gotta be some Python fans in the audience at least. Yeah, hopefully somebody will get it. I don't know this has certainly been a definitely been a fun chat avi i definitely appreciate you taking the time to come on this show it's it's a fun conversation uh you're always invited back certainly appreciate all that you're doing in the community and what you've done with uh pair programming and just lifting that up and sharing what that can be and just starting the movement, as Andrew mentioned before. Definitely thanks to Andrew and Steve for coming on the show.

What a great show you guys put on today. And thanks to you for the listeners out there listening live. This show does broadcast live every Tuesday at 5 p.m. Central Standard Time. You're on 5x5. If you want to check out our backlog, you can go to 5x5.tv

slash changelog. This is episode number 90, so you've definitely enjoyed it. But let's close this one out and say goodbye. See y'all later. Bye. Bye-bye.