DAVID:
Probably the biggest perk of working for the NSA is that you get the Ruby Rogues episodes a week before they air.
[Laughter]
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[This podcast is sponsored by New Relic. To track and optimize your application performance, go to RubyRogues.com/NewRelic.]
[This episode is sponsored by Code Climate. Code Climate’s new security monitor alerts you immediately when vulnerabilities are introduced into your Rails app. Sleep better knowing that your data is protected. Try it free at RubyRogues.com/CodeClimate.]
[This episode is sponsored by SendGrid, the leader in transactional email and email deliverability. SendGrid helps eliminate the cost and complexity of owning and maintaining your own email infrastructure by handling ISP monitoring, DKIM, SPF, feedback loops, whitelabeling, link customization and more. If you’d rather focus on your business than on scaling your email infrastructure, then visit www.SendGrid.com.]
CHUCK:
Hey everybody and welcome to episode 126 of the Ruby Rogues podcast. This week on our panel, we have Josh Susser.
JOSH:
I will not be making any jokes today.
CHUCK:
James Edward Gray.
JAMES:
We do the government shutdown, we’re all doing this podcast without a paycheck.
CHUCK:
Katrina Owen.
KATRINA:
I don’t make jokes anywhere or anytime.
CHUCK:
David Brady.
DAVID:
[keyboard typing] I've just got to get this last piece of code to compile and…go!
CHUCK:
I’m Charles Max Wood from DevChat.TV. I just want to remind you to go check out my freelancing video at GoingRogueVideo.com. We also have a special guest and that is Sam Livingston-Gray.
SAM:
Hello from the sunny Portland, Oregon.
JAMES:
Woohoo!
CHUCK:
Since you haven't been on the show before, do you want to introduce yourself, Sam?
SAM:
Yeah, sure. I'm just this geek, you know. I've been writing code, I don’t want to say professionally. But let’s say I've been writing code for money for about 15 years, and professionally for somewhat less than that. I've been doing Ruby for seven or eight years now and I work at LivingSocial.
JAMES:
So, you were that guy at the back of the truck on, “Hey buddy, you need some algorithms?”
SAM:
Yeah, totally. No, I am absolutely deeply ashamed of some of the code I wrote on my first few years as a programmer.
JAMES:
[Laughs] We all are.
JOSH:
I think all artists feel that way about their early work.
SAM:
[Chuckles] I hope that means I'm learning.
CHUCK:
[Laughs]
JAMES:
[Chuckles] Yeah. That’s what we hope it means.
DAVID:
Learning shame.
JOSH:
I guess if you [inaudible] know enough to be ashamed of your early work, then you're not learning anything.
JAMES:
I'm pretty sure I'm deeply ashamed of some code I wrote yesterday. But, you know.
CHUCK:
[Laughs]
JOSH:
I thought we were [inaudible] there.
JAMES:
Sam, we asked you on to talk about remote pairing.
SAM:
Yeah, I've been doing a fair bit of that. I've been working for LivingSocial for about 18 months. And pretty much in that time, I've been in the office about 30 total days, maybe five of those in the past year. I work from home with a bunch of people all over the place and I pair at least half of the time and it works pretty well. So, I guess that makes me an expert.
JAMES:
It’s kind of cool, actually.
SAM:
Yeah. There's a lot to talk about. Which should we start with?
JAMES:
Probably a definition. [Chuckles]
JOSH:
Yeah. Thank you, James. You literally put the words right out of my mouth. You reached into my mouth with the right words.
SAM:
You just did a [inaudible] because Josh was about to be lo and told. [Chuckle]
JAMES:
Remote pairing is like where you paste pictures of the sock that you only have one of on the website and then someone else helps you find the match, right?
DAVID:
Nice. You post your menu and then somebody else tells you what wine goes with it.
JOSH:
Or beer, you can do beer pairings now. So Sam, help. [Laughter]
DAVID:
You post an apple and somebody else peels it.
SAM:
So, there's pair programming which is two or possibly more developers who are working together on the same bit of code. Then, there's the remote angle on top of that which is why those two developers are not like bumping elbows with each other and staring at the same screen. And I used that definition deliberately because after doing a lot of remote pairing with people who are in different cities at different time zones, I found myself using the same tools to pair with people in the same room.
JAMES:
That’s interesting.
SAM:
Yeah.
JAMES:
Give us the breakdown. There are different schools of thought in how to do it, right?
SAM:
Yeah, absolutely. The way I think about it, there's a whole lot of tools for doing remote pairing but they fall on to several different categories. Obviously, you have to have voice connection and ideally, it’s nice to have video on top of that. But then as far as actually sharing your coding environment, there's three main categories of things. There's the screen sharing stuff where you basically share either a screen or a particular window and there's an app that basically looks at all the pixels and pushes them across the network for you. There's terminal sharing environments like GNU Screen has been around for a while and tmux has come up in the past couple of years and that is pretty much what I use. And then, there's this weird third category of like Cloud-based tools that do some sort of cleverness around stripping the contents of a local buffer and putting them up somewhere that other people can look at them. There's some interesting work there. But it’s not a category of tools that I've used very much.
JAMES:
What's an example of that? I don’t even know this.
SAM:
There's one called Cloud9 IDE. It’s specifically written around JavaScript and I think it does a couple of other languages as well. Of course, we can't use that in LivingSocial because our security team would go bananas.
JOSH:
That’s like Floobits. Are you familiar with that?
SAM:
I've heard of it and I know somebody that I worked with has used it but I haven't tried it out yet.
JOSH:
And the only reason I haven't used it is because they have to have access to all of your code in your repo and all that. But there's also similar kinds of approaches where like using a Google document for being able to share. It’s probably not good for pair coding but for other sorts of remote pairing, you can use a Google document which is going to be shared and you can get live updates.
JAMES:
That’s kind of an interesting point. We always think of pairing as kind of coding. But the truth is sometimes, we do pair on other things. Like I know I've personally just sat there with somebody before playing an OmniGraffle trying to get our head around some kind of [inaudible] or something.
JOSH:
And Google has a shared drawing tool now, so you can get anything…
SAM:
Maybe we can bring back Google Wave. [Laughter]
DAVID:
I loved Wave. [Inaudible]
JAMES:
You were the only one.
SAM:
Well, my [inaudible].
JOSH:
My tool of choice these days is Screenhero. Have you guys been using that or are you folks been using that?
CHUCK:
It was a funny story. I was using Screenhero with Joe Kutner, he wrote The Healthy Programmer. I tried to share my browser and I was using Chrome Canary which is their experimental version and it totally crashed. But it did work with some of the other windows I shared. And I know that it’s still in beta so, it’s not perfect. But some of the things that it does, it does work pretty well for some of that stuff.
JOSH:
It’s a pretty good model. Yes, they're going through some growing pains with stability and all that.
But the trend is getting better. So, I think it’s a pretty cool idea.
CHUCK:
Yeah. And it works well enough, enough of the time to be something that it’s useful to know about.
JAMES:
Let’s talk about it just a little bit. So, if you use something like Skype; Skype can almost be viewed as like the simplest thing that met Sam’s definition of the tools you need, and that we all have this voice connection right now. Actually, we can't on this many call unless we have a pro account. But if it’s just two of you, then you could share your screen and the person could see what you're doing. But there's not really any interaction beyond that. And then, if you wanted to share the other person’s screen, then you would have to stop screen sharing and the other person would stop screen sharing. So, it’s kind of this annoyance if you want to flip kind of thing.
SAM:
As I recall, Skype is screen sharing but it’s not keyboard and mouse sharing because the other person on the other end just gets to watch.
JAMES:
That’s right.
JOSH:
iChat or Messages, I guess, does screen sharing where you can actually interact with the remote machine.
JAMES:
That’s right. So, that person has full control. But that can be kind of annoying because you have to agree on who’s typing right now or who’s running the mouse right now.
JOSH:
Right. So, Screenhero is like the iChat where the remote person can have access to the machine. But the cool thing with Screenhero is that you can see both of the cursors and the other person’s cursor has a label on it with their initials.
SAM:
Yeah. That feature is really awesome up unto the point where the label obscures the thing you're typing on.
JOSH:
Well, there's that. [Chuckles] There has to be like some key thing that makes their cursor go completely invisible because I was always telling my pair, “Can you move your cursor? I can't read the word underneath it.” [Chuckles]
CHUCK:
Yeah.
SAM:
We’ve totally derailed James. He was talking about something important, I'm sure.
JAMES:
No, no, no, no. I was actually just trying to give a [inaudible]. These are all the different kinds of screen sharing. Now, with Screenhero, you do not have voice, you have to use something else for that. [Crosstalk]
CHUCK:
You have voice and chat. And the other thing is that with the screen sharing in Skype, you show the entire screen. And with the Screenhero, you can share individual windows, so you can be working with somebody in one window and gossiping about them in the other and they wouldn’t know.
JAMES:
[Laughs] Excellent.
SAM:
You got to have multiple screens for that.
JAMES:
I think, Chuck, most of us would have just [inaudible] so you can save some bandwidth by not sharing the whole thing. [Chuckle]
CHUCK:
Yeah, that’s what I meant.
JAMES:
But [inaudible] is intriguing. [Laughter]
DAVID:
Save bandwidth? I've got a use for that.
JOSH:
We call that the snide band.
CHUCK:
There you go.
SAM:
Oooh, nice. Speaking of bandwidth, that’s a wonderful [inaudible] to one of my rants about why I use the tools that I do which is that I am really high maintenance when it comes to lag. I love screen sharing because it’s the most versatile thing there is. If you can put it on a screen and pretty much everything you can, then you can share it with the person that you're pairing with. And it’s almost like being there, right? But the tradeoff of that is that there's a lot of pixels on your screen and each one of those is an RGB value and that just turns into a lot of bytes to push [inaudible] the network. And so, I don’t mind sharing my screen with other people but when I'm on the receiving end, if there's any kind of perceptible lag between when I type something and it shows up on the screen and just [inaudible], I'm really impatient about that sort of thing. I tried using Eclipse years ago and the actual visible lag between when I typed something and when the code showed up on the screen was like, “I'm done here.” So, the alternative to that is using a terminal-based or SSHbased environment which obviously limits your options but gives you a lot more responsive interface.
CHUCK:
Since you should be using Emacs anyway, it’s not as painful as you would think.
JAMES:
[Laughs] Yeah, right. Actually, that’s a great point because I've always been kind of partial to the screen sharing side. So, I’ll try to give the other side the argument. And my reason is I am super picky about my environment and what it need to be the way what I want it to be. And so, when you do these terminal sharing and stuff, I think it’s harder to get that the same since you're either doing it on someone’s computer or on some third party. So, one person will not have their environment guaranteed or both won't.
SAM:
That’s true with all pair programming as far as I can tell.
JAMES:
Yes, I see what you mean. That leads to a good question: how easy is it to flip in Screenhero to go to the other person’s screen.
JOSH:
Disconnect and reconnect.
JAMES:
So, it’s about disconnect and reconnect. So, that’s maybe about the same house rule as Skype or maybe more, right?
JOSH:
It only takes a few moments. And given that Screenhero is a little flaky these days, you have to disconnect and reconnect pretty often anyway, so it wouldn’t be a big deal. [Laughter]
JOSH:
Yes. We call that damning with faint praise. [Chuckles]
JAMES:
Ouch. Okay, explain the thing to us, Sam. How do we do that?
SAM:
It’s actually pretty much the same thing. You have to have one person host or use some third party server. But the difference is that instead of sharing in a pair of screen, you just have tmux or screen which is designed to manage multiple terminals for you and then take the input and output from different clients and basically make sure everybody sees the same thing all the time. So, I launch tmux on my machine, I have somebody else SSH in and attach to the same tmux session. And then from that point on, we’re all looking at the same thing.
JOSH:
I've seen a lot of people talking very recently about setting up a dedicated remote pairing server. I've seen people having discussions on the Parley List about that and tweets and various other places. It sounds like it’s becoming a thing. And it’s a thing that I'm not too familiar with. I'm wondering if you are.
SAM:
Only somewhat. I typically share a tmux session on either my machine or the laptop of somebody else that I'm working on. And that because we’re often -- I mean, I mostly do my remote pairing in the context of my day job and the apps that we’re working on sometimes they're fiendishly complicated to set up or you have to run four or five of them at the same time to get what you're doing done. And so, it’s just easier to not have to lose half a day to set up your pairing server for that. I gave a talk on remote pairing in a conference in June and I actually just set up an EC2 node and had people SSH into it. And I did have, it think, 16 or 17 people in the same tmux session.
That was fun.
CHUCK:
I have to say you're brave.
SAM:
It was a disposable node. I threw it away when I was done.
DAVID:
Chuck and I did this at a recent client where we had an insanely complicated setup. And we actually reversed our thinking on the economy of setup. We basically burned the three or four days to setup Chef and Puppet so that you could stand up an EC2 box, set up all of the workers, all of the backgrounds, all of like Apollo and [inaudible] and set up the entire engine for everything. And then, we had five machines. All of us had the Amazon keys to start and stop them. And we would log in, we would run the hitch gem to pair ourselves together on that machine for commits and then we would go there. It also helped that everybody on that team was new to Emacs and to Vim, they’d come from .NET. And so, I was able to say, “I have a really god Emacs config. So, let’s just all use that.”
SAM:
Yes.
DAVID:
So, I got around two of the tricky points of that basically.
JAMES:
You just made a really good point, I think, that we should talk about, like Vim/Emacs. That comes into play when we do this.
SAM:
Sure.
JOSH:
I don’t use either Vim or Emacs in my daily life. But when I remote pair with someone, I much prefer to pair with people who use Emacs than Vim.
JAMES: Why?
JOSH:
because when I use the arrow keys to try and navigate in Vim, it says, “Don’t hot that key, hit J.” [Laughter]
SAM:
Really? I must [inaudible] disabled.
JOSH:
And any editor that knows that I want to move my cursor down or up [inaudible] knows I want to do that and can tell me that that’s the key I should be pushing but it doesn’t do it for me, is dead to me.
JAMES:
That’s like Python when you type ‘exit’ in the Python console, it says, “Don’t type exit, type quit.”
JOSH:
Yeah. [Laughter]
SAM:
Really, any experience the Vim user will tell you, Josh, that what you really need to do is install the hardware extension that just gives you a minor electric shock every time that you even look at the arrow keys. [Laughter]
DAVID:
Emacs has the same thing but it’s a timer. If you have not pushed down Ctrl, Alt, or Shift in the last 30 seconds, you get a shock. [Laughter]
JAMES:
This is an interesting point. Sam and I paired when we were at Aloha Ruby Conf on this cool problem he was playing around with. One of the things he asked me right off the bat was, “Is it easy for me to get your Emacs config?” And I thought about it for like half a second and I thought, “No, it’s a freaking nightmare.” [Chuckles] And I said, “No,” and we didn’t do that. I just used Vim with him. But I want to say that he did inspire me to rebuild my Emacs config over the summer. And now, I have it where it is actually super easy to get my Emacs config. You can pull it down [inaudible] directory and when you launch Emacs the first time, it will set up everything exactly the way I like it.
SAM:
That’s great. Yeah, that was one of the things that -- so, we have this toolkit at LivingSocial, it’s lspair. And that, by the way, is made from Avdi’s PairProgramWith.Me site which is wonderful. But one of the things that we tried to solve with ls-pair was this problem of not knowing everybody else’s editor config. So, we just set up a simple curated set of Vim plugins with a standard set of key bindings for both Vim and for tmux.
JOSH:
Sam, I'm curious how bad the fighting was over that.
SAM:
I did not get involved. I said, “I don’t really know Vim all that well. So, why don’t you two people, who care really deeply about this, go and work it out.” And they did, it was amazing.
JOSH:
Because there was a standard key binding that got used at Pivotal Labs for RubyMine.
SAM:
Cool.
JOSH:
And I have never seen any fight as big or intense or as passionate as the fights that people had over that key binding set.
KATRINA:
What was the key binding for? I don’t care what it was technically, but what was it meant to do?
JOSH:
Because everybody pair programmed on just random machines all the time, all the machines had to be set up similarly so that anyone can sit down at any machine and be effective working there. So, everybody had a similar set of tools that they use on all the machines. There were definitely variations. It wasn’t like, “You must do it this way or we will fire you.” It was a way to reduce friction when you are pairing with someone you haven't paired with before. And there were key bindings for things like move the current line up one line or indent this block of text, or insert a method definition snippet. Just the standard editor-type things you do when you're writing code. And there were people who prefer the Emacs style bindings, the Vim bindings. The big one was like what does the End key do or the Home key do because Windows users are like, “To me, in the beginning or end of the line,” and Mac users are like, “Oh, it’s the beginning or end of the buffer.” I remember in a meeting saying, “Why are you turning standard Mac commands into something that Mac users aren't familiar with?” It was crazy crap like that. So Sam, if you guys were able to come up with a common conventional set of key bindings or editor commands or configs, then everyone in your organization is using and nobody got a black eye over it, I think that’s a pretty amazing thing.
SAM:
I don’t want to overstate it. It’s not that everybody in the organization is using it. In fact, I think probably most of us still don’t pair on a regular basis. But those who want to use ls-pair, for those people, it comes with a default Vim config. It also comes with a feature where if you already have a vimrc, we won't blow it away. Somebody wrote a little script that will actually toggle between the one from ls-pair and whatever you already had. So, that was pretty sweet too.
DAVID:
Nice. I think it’s a good empathy test. I'm sorry. Let me finish one thought. Are you on the same thought, James?
JAMES:
No, go ahead.
DAVID:
Okay. I was going to say that I'm being unfair when I say that I was the Emacs user at this contract because Chris Meadows was also working there and he was also a pretty good Emacs user. And so, we had to do that. We had to sit down and decide how much of whose config. And we did two things, one is we were very respectful of each other and said, “Oh, I like that.” And then we ended up like stealing stuff from each other back and forth. The other thing we did is we came up with -you can go to github.com/dbrady/emacs_libs and download that, and boom! Your Emacs is now configured in the same way that everybody else’s on the team was. But the third thing that we did is we went to everyone on the team and said, “If you want to change emacs_libs, go ahead. Just make sure you don’t turn anything off without telling anybody. But you can add anything that you want.” And there were a few things that I used that only I used. And so, I made sure that they were slipped into most of the machines I worked on, but they weren’t actually in the repo because they were just stuff that I wanted. The reason I bring this up is the environment -- I guess what I'm saying is pair devopsing has to happen before pair programming can happen.
SAM:
Part of the reason that we put together this ls-pair toolkit is because it’s been my experience and I'm sad that Avdi is not with us because he has done a lot more pairing with a lot more people than I have. But it was my experience that every time I paired with any person, you would lose an hour to, “I can't SSH to your machine,” and, “Wait, what was your key again?” And all that stuff. So, we were just like, “Can we get to the point where I can be pairing with a new person within five or ten minutes or with the same person in 30 seconds?”
JOSH:
If I may, I would like to reorient the conversation a little bit. [Crosstalk]
SAM:
So, you want to talk about tools for hours?
JAMES:
One sec, one sec. I got one other question.
JOSH:
Okay, so finish that thought and then I want to try reorientation.
JAMES:
Okay. So, what are we saying here? Are we saying like for example, I am an Emacs user and I have a very horribly complicated Emacs config that I have worked on over the years and stuff. So, are we saying that when two people pair, one person should [inaudible]? Are we saying it’s better to go to a lowest common denominator that we should have this kind of minimal config that we can all agree on?
DAVID:
No.
JAMES:
Are we saying there's a lot of value in just trying it the other person’s way for a little while so you can experience new things? What are we saying here?
SAM:
I think all of those things are true but for me, having ls-pair just have a default that you could revert to is kind of like the convention over configuration.
CHUCK:
So, I want to jump in on this just for a second because I'm going to give you the same answer I give my clients. It depends.
SAM:
Classic.
JOSH:
He wants to be a developer. [Laughter]
CHUCK:
Yeah, I said something very developer-y, didn’t I? Anyway, so what I found is that let’s say I'm pairing with James. There are a lot of reasons that I could be pairing with James. I mean, I could be wanting to learn a lot of Ruby awesomeness from him. In which case, I may think that I would be better served by just having him work in the environment he’s most comfortable in. And then if there's something there that I don’t understand that he did, I can ask questions about. If I'm pairing with him specifically to learn about his Emacs setup or whatever, then obviously, I want to be using his setup. Unless I want him to help me with mine, in which case, I'll use mine. So, I think it really depends on what you want to get out of it. And you can discuss it beforehand and just say, “Hey look, this is what I want to learn from you. What do you hope to learn from me?” And then, from there, you can kind of figure out which direction you want to go and maybe you wind up switching halfway through. I mean, who knows, right?
SAM:
Yeah, absolutely.
DAVID:
And you find things from other people that you didn’t know about. And so, it’s not a lowest common denominator. It’s a greatest common factor. I don’t know. [Crosstalk]
SAM:
…pairing with people is, “Wait, what did you just do?”
JAMES:
Yes.
CHUCK:
[Laughs]
JAMES:
I would say that like, if you are a super Vim person or a super Emacs person or whatever, take the time to be not -- it doesn’t have to be amazing in the other one but at least [inaudible].
DAVID:
At least be fluent, yeah.
JAMES:
Yeah. To the point where if somebody fires it up, you don’t have an absolute connection fit. PeepCode had this really good blog article. I'll see if I can find the link to it for the show notes. But it was about how you really need to learn the six things to get started with an editor. But it almost seemed like there were kind of arbitrary things that they play to. I mean, they are generally useful and stuff. But it was kind of this neat idea of at least go this far and know that much. When I did find myself pairing with Sam and he’s like, “Can I get your Emacs config?” And I thought, “No way!” Then we used Vim and I knew enough Vim. I'm sure he laughed at me sometimes when I did things in a horribly inefficient way.
SAM:
Are you kidding? I was such a fan. I was like, “Oh I get to pair with James. This is so great!” [Laughter]
DAVID:
I'll do it in [ed], I don’t care.
CHUCK:
I'm so making that into a sound bite. [Laughter]
DAVID:
Ringtone! [Laughter]
JAMES:
Okay, Josh. Now, it’s your turn, reorient.
JOSH:
Okay. So, we’ve been talking about tools for, I don’t know, half hour here almost. And I'm reminded of -- Amy Hoy has said this on many occasions when she’ll come up with a cheat sheet or an infographic or something and someone will go, “Oh my god, that’s an amazing infographic.” Or, “That’s an amazing cheat sheet. What tool did she use to build that?” And she’ll look at them and say, “I used my brain.” [Laughter]
CHUCK:
That’s a good tool.
JOSH:
And her point is that if she has a lot of skills that she’s developed for how to communicate information in a really dense mutable way. And the tool that she uses is just incidental. So, when I'm programming, the editor that I'm using is, to a large extent, just incidental. I think it’s the same thing with pair programming. We’ve talked a lot about tools here. Those tools will all enable us but they're not about actually doing the pairing. SAM: Yes, thank you, Josh.
JOSH:
So Sam, I would love to shift the conversation here and talk about the stuff that’s not about tools.
DAVID:
Yes.
JOSH:
And there's stuff that’s going to be common to just pairing in general but then there's stuff that’s different when you're remote. And I'll throw one thing out to get started. And that’s something that I learned doing a lot of pairing when I was at Pivotal especially when we had a lot of remote people was it’s really helpful if you can meet in person and work together for at least a week to establish a rapport, learn some trust, figure out your communication patterns, what are the subtle cues that you use to swap back and forth. And then once you’ve established that rapport, then remote pairing is a heck of a lot easier.
SAM:
Definitely.
CHUCK:
But if you can't, sometimes you can work it out the other way.
JAMES:
Yeah. It’s kind of a new trend we’re seeing, right? With Avdi’s Pair With Me stuff, he’s really pushing, “Just jump in there and try it.” And I've seen so many tweets of people going, “Hey, I suddenly find myself wanting to figure out X. #PairWithMe.” It’s like, what an awesome concept. You're going to try something new, “Be great to have a little help, can we try this?”
JOSH:
I'm not saying don’t do that. I'm saying if you're going to be working on a project with somebody for two, three, four months, sometimes longer, it’s really useful to accelerate how quickly you can get up to speed with that person and how effective you can be pairing by getting -- nothing really beats in-person face-to-face interaction for bandwidth.
SAM:
The embarrassing fact is we’re all still primates. We’re all still made of meat and that meat has conventions. And our brains are really good at picking up all that communication that’s outside of the verbal channel. And when you're in remote, it’s harder to replace that.
JOSH:
Yeah, totally.
CHUCK:
On that team that David was talking about where they did all the setup, I did go out to Chattanooga and I met some of the guys on that team. But a lot of them weren’t there when I was there. And you can work it out with people who you haven't met in person but I have to say the thing that made that a whole lot easier was the fact that we did have those common conventions that we had been talking about. So, we already have the pairing setup set up, everything was ready to go, the team already had a lot of those conventions that you're talking about for communication, do this this way, that kind of stuff.
SAM:
Yup.
JOSH:
So, Joe, is there other stuff that you think about in terms of the people side of things?
CHUCK:
Who’s Joe?
JOSH:
I'm sorry. Sorry. [Chuckle]
JOSH:
You know, my brain just said, “Oh, I'm saying something about people interactions, so I'm going to use the word ‘Joe’ because [reacted]…” [Crosstalk]
DAVID:
[redacted] is the metasyntactic variable for talking about people interactions. [Laughter]
SAM:
You know what? I'm using foobar [inaudible].
DAVID:
Yes.
KATRINA:
I thought it was Joe because Joe Kutner’s writing a book on pair programming. [Chuckle]
JAMES:
Yes.
SAM:
A better one. [Crosstalk]
SAM:
That leads into an interesting development over the past year or so which is that when I first started doing remote pairing, I was pairing with somebody that I had come to LivingSocial with from a previous position. And we both came over the other, we both already worked really well together. And so, for us, it was like, “Yeah, we’re good with tmux and voice connection.” And that’s all we really need. And then, somebody discovered that we had a bunch of iPads lying around. This is apparently what happens when you work for a funded startup. And said, “Hey, why don’t we give these to the developers and see what they can do with them.” And I was like, “Hey, free iPad. I'll take that. I'll try it.” But I was really surprised to find that having that extra layer of video communication on top of pairing and also like having it on a separate screen that I couldn’t cover up with other windows, it really made a huge difference in making it feel more like I had a magic window into somebody else’s room. And we were just sort of sitting there and it was much more natural to stop and take my hands off the keyboard and swivel to face the iPad. It really made a big difference.
JOSH:
Telepresence like that can be very cool. Were you just using Facetime on the iPad?
SAM:
Yes.
JOSH:
At Pivotal, they actually had a robot that would roll around that was basically like an iPad mounted on top of a wheel-y thing. It’s like an iPad on a Segway, basically.
SAM:
I've seen those, they're great. They're ridiculously expensive but that was really cool.
JOSH:
I think Pivotal was testing one out for some garage shop.
SAM:
That’s nice.
DAVID:
You can do that on a budget. The shop that Chuck and I worked on had a library AV cart with a cheap laptop on it running Skype. And that was the robot. And if you wanted to move the robot, you had to say, “Hey guys, can you move the robot?” [Laughter]
DAVID:
But it worked.
SAM:
Yeah. In one of my previous teams, we had somebody who moved away for a year and then, eventually came back. And when he was away, we basically set up a laptop and a TV on the wall and then connect the webcam. When you wanted to go and talk to [inaudible], you just walk over to [inaudible].
KATRINA:
One of the things that someone, and I cannot remember if it was you, Sam, or perhaps Avdi, who was telling me that they mount the iPad to one side of their computer and their pair mounts it to the other side of their computer so that -- it was who?
DAVID:
It was me.
KATRINA:
Oh! Okay.
SAM:
David was talking about that like two years ago.
DAVID:
Yeah.
KATRINA:
Tell us about that.
DAVID:
So, this is a subtle brain hack. I have two monitors in their own swivels. And so, I can actually turn my telepresence monitor 90° and my partner does the same thing. They do it from the other side. In fairness, I learned this trick from Jim Weirich. This creates telepresence where you get the illusion of being side by side because in order to turn and look at my pair partner, I have to turn my head. When I turn my head to my left, I'm looking through a camera that is off to Shaun’s right and it’s now looking at -- and so, it feels like you're actually side by side. And it’s very natural to turn your head to look to your partner and talk to something. And then you turn back to the code. And I was going to point that out for Sam with the iPad off to the side. Having it off to the side is actually almost as much of a hack like a good brain life hack as having a separate telepresence machine
MCS.
SAM:
I like having it off to the side for a couple of reasons. One is that my pair partner, if they want to look over and see what I'm doing, they can tell whether I'm looking at them or whether I'm looking at the code. And that’s a nice signal. But I should probably try your setup out before I dismiss it out of hand because it sounds to me like that seems like a really good way of replicating one of the worst aspects of physical pair programming which is that you have to turn your head to look at somebody and talk to them. [Chuckles]
JOSH:
Sam, unless you're using a tete-a-tete setup like I pioneered at Pivotal.
SAM:
Yes. I stumbled across that accidentally after Aloha Ruby Conf.
DAVID:
What's a tete-a-tete setup?
JOSH:
You know they had like little tete-a-tete couches where it’s two seats basically face-to-face. Tete-atete means face-to-face in French, or head-to-head. And so, it’s a way that you can have both people facing a monitor. I'll put a link in the show notes to make sure of it. So, I programmed that way for a year or two when I was at Pivotal.
DAVID:
I've relaxed the 90° thing. Like, my monitor is permanently canted at about 30° now. And it’s enough that I have to turn and look and they can see that I'm turning and looking. But it’s also close enough to flap that if I'm not pairing, I don’t feel like I have to push my monitor back to feel like I'm in my own space.
SAM:
Yeah, that’s about where my iPad is.
DAVID:
Yeah.
JOSH:
Slightly different direction here. Another thing that is also something I wouldn’t want to try and replicate remote pairing that I think is a big advantage, is just the kind of personal space and, not to get too detailed, hygiene issues that you often run into when pairing in person, are not really an issue at all when you're doing remote pairing.
DAVID:
There is a cognate, though. The office behind my camera is very cluttered and messy. And I'm actually very self-conscious about it.
SAM:
So am I, which is why I'm working in my basement, carefully constructed a façade of some bookshelves that are right behind me. And they have like some books and some toys on them. And if I turn my camera just a little bit to the side, you can see the concrete wall of my basement. But the sightline is just right so that that’s what you see behind me now.
DAVID:
There's a filing cabinet behind me and I had a client meeting with their Vice President and COO, and I dropped an 8-foot long whiteboard into the top drawer of the whiteboard so that it looked like I was in an office, like there's a whiteboard behind me. You can't see anything else.
JAMES:
I really appreciate when I'm in my own space like I'm happiest when I'm programming in my own space. Regardless of what the other person sees on the camera, at least, I feel great because I'm in my office. That makes me very happy and stuff like that.
SAM:
That goes back too to like when I first started doing this, I thought about things in terms of, “These are tools for doing remote pair programming.” But really, I found myself using them, pairing with somebody like sitting in a coffee shop, face-to-face on a two-top, with our laptops back-to-back. I call that [inaudible] like you sunk my battleship pairing configuration. The nice thing about that is you can look down at the code and you look up and there's your eye contact right there. And then, I mostly work from home, as I think I mentioned, but I host coworkers once or twice a week. And so, I can be pairing with somebody who is sitting on my couch and I'm sitting in my comfy dad chair and we’re able to share screen and talk. And we don’t have to scrunch together and look at the same screen and try to find an angle where the lighting won't give me a headache in an hour or so.
It’s a nice thing just to have a bunch of different options at your disposal, I guess.
DAVID:
We’ve kind of been done with tools. I've used teleport before which lets you move your mouse and cursor off to somebody else’s screen. And so, side-by-side pairing where I sit down next to somebody and then we hook up teleport so that I can drag my mouse over to take control, works really well for side-by-side. And then, we work on their machine but I've got my laptop and then if I
need to -- and this is probably bad pairing and this is why I wanted to bring this up because this gets into the key problem with remote pairing is distraction and losing your pair. And sometimes, if I've got my laptop off to the side and I'm having a really bad ADD day, instead of going and looking up the documentation for the thing that they're trying to figure how to type, I end up looking at the documentation and then going to Twitter and then, going to YouTube and that sort of thing. At one client, I recognized in myself that it was so bad going in that I didn’t even take my laptop. I just took a keyboard and I plugged it into their computer to do that. How do you deal with attention in a remote pairing because it’s exacerbated, right?
SAM:
Absolutely.
DAVID:
How do you tell when your pair is becoming disengaged?
SAM:
I have ADD as well. And so, that’s frankly one of the reasons I like to pair, is that it helps keep me focused. One of the tools that I like best for that is practice, just doing a practice of ping pong pairing which is where I write a test, you make it pass, you write the next test, I make it pass, and so on.
DAVID:
Ping pong pairing, yeah.
SAM:
Yeah. And it just passes control back and forth often enough especially if I’m working with somebody who’s sort of at my same level and is a little bit devious and they’re going to write code that just makes that test pass but is obviously horrible. That’s super fun and that keeps me really engaged. But I also know that control is coming back to me in 30 seconds and I’m going to have to know what they did and why it’s funny and how to fix it and how to shoot the next joke back at them. So, that’s actually a really nice hack for being even more engaged, I think. And remote or local pair programming, it doesn’t matter.
JAMES:
One of the biggest tricks I’ve found for managing distractions is just to remember that I can turn things off. For example, Twitter.
DAVID:
What?
JAMES:
You can actually quit that application and Mac OS notices, you can actually click up there and shut them all the way off, just things like that. And then if I do that, I will sometimes, like you say, I’ll go to the documentation and I think I’ll have a second. I should go to Twitter but I’ll start to switch between apps and it’s not in the apps anymore and that’s enough of a trigger for me to be like, “Oh yeah, I’m not doing that right now.”
DAVID:
I paired with Katrina at the Rogues Retreat and she can attest to this. Some days, I have to shut Twitter off. Some days, I need Twitter on as an outlet. And the workaround I’ve done is -- some partners can’t handle this. And so, I don’t do it. Some, I love it when they can. And when we say something really freaking funny, I take control and I say, “Okay, we are now pair tweeting.” And we go to Twitter, we write the tweet, we send it and then we go back. And we laugh at the joke and then we go back. That way, there’s no secret cheating with Twitter. [Laughter]
DAVID:
If you’re going to tweet as a pair, go pair tweet and then come back to what you’re doing. You’re introducing yourself to the elephant in the room and saying this distraction, we’re going to go do this together. And then we’re going to leave it together.
SAM:
Very nice.
JAMES:
I’ve listened to you talk on this episode Sam and you’ve talked about how LivingSocial lets you host these developers and do all this pairing and stuff and help develop this pair setup. Was that a concept they had before you came on? Is this something you kind of talked them into? How has all that worked with the big company and how has it gone over?
SAM:
Well, to some extent, that’s just purely self-defense on my part. I don’t work well by myself and I especially don’t work well by myself in my basement. When I was in school, I was doing a lot of that and my partner would get home and I’d be like, “Hi. How are you?” And she’s like, “You haven’t talked to anybody else all day, have you?” [Laughter]
DAVID:
The pressure valve. Yes.
SAM:
Right. It’s like, “Oh hey, I get to be social now.” But they’ve actually been really great about remote work in general. They have a good tradition of hiring people wherever they happen to be. And when possible, hiring other people around them so they have a small local community. I’ve been trying a little bit to bring pairing into that. And it’s definitely there are some cultural issues around having an environment where nobody’s used to pairing. It can be very hard to break that inertia. But just from a logistical standpoint of having support and getting all the tools that I need, it’s actually been pretty great. I’ve been very well-encouraged by my managers in taking a bit of time and writing ls-pair and then taking a week and scheduling 15 appointments each an hour long with fellow developers to get them all set up and using this thing. So yeah, it’s been fun.
JAMES:
Do you think the company’s noticed any positive benefit?
SAM:
Yeah, I think so. I will let other people speak to that. I know you’ve had Glenn Vanderburg on the show before but maybe you can call him back and ask him.
JAMES:
That’s cool.
KATRINA:
I was wondering. So, pairing is kind of intimidating in person and it seems even more intimidating remotely. If I’ve never paired before or barely paired before, what would be a good way to approach it in a way that is not so intimidating?
SAM:
We kind of touched on this earlier, this concept that somebody is going to have their setup. That’s one of the contributing factors to something being intimidating or pairing being intimidating, is if I’m joining an expert on a programming language as a newb and I’m joining them on their computer with their special Emacs config that’s tricked out seven ways ‘til Sunday, then I’m going to be sitting there and I’m afraid to touch anything, basically. So, if you can flip that around and say, “No, that’s fine, I’ll join you.” That’s a nice way to have somebody feel a bit more at ease. And it’s easy enough to set up something like Screenhero where as long as you’re willing to tolerate the lag I talked about, then you can join them and help them out. And I think that goes a long way, is having somebody who’s a little bit more experienced to sort of help shepherd things along. If you’re both new, I have no idea. [Chuckles]
KATRINA:
Is there a type of problem that is less intimidating to start with than others? Because sometimes with problems, you need so much context to understand what’s going on. There’s a ton of code. There are a ton of tests. The tests might take an hour and a half to run. How do you go about easing into something and being able to communicate about what you’re going to do when you don’t even know how to pair?
SAM:
Email about it beforehand? Also, there’s this wonderful site that maybe you’ve heard of. It’s called exercism.io. [Laughter]
JAMES:
Wait, what’s that site? No, I’m just kidding.
DAVID:
I love that site. But I hear the maintainer’s a jerk.
[Laughter]
KATRINA:
Yeah, they’re not very good at open source. Don’t pay attention to them.
DAVID:
Yeah, yeah.
SAM:
Right, right.
DAVID:
Let’s just hope they don’t go into training.
KATRINA:
Oh, yeah. That would be a disaster.
SAM:
They really need to learn how to refactor things too.
DAVID:
Yeah.
KATRINA:
Okay. So, getting back to the topic.
JOSH:
Okay, enough inside jokes. Okay. [Laughter]
CHUCK:
For those of you who aren’t following, Katrina set up and maintains exercism.io. We’ll put a link to that in the show notes.
JAMES:
Thanks for spoiling it for everybody else.
CHUCK:
It is awesome.
DAVID:
Yes.
KATRINA:
Okay. So Sam, you had a point here.
SAM:
Yeah, my point was, and again, actually this comes back to what Chuck was saying about ‘it depends’. What do you want to get out of this particular pairing session? And depending on what you want to get out of it, you can pick a toy problem or you can say, “I need help with this thing that I’m working on,” or, “Hey, I hear you’re working on that and I’d like to learn a bit more about it. Let me ride along.”
JAMES:
I think I really like what you just said there, Sam. One of the things I’ve seen with Avdi’s
#PairWithMe movement that I thought is so cool is when someone wants to learn something that they don’t know and they’re going to be looking at whatever for the first time, or whatever. And then they say, “Pair with me. Help me out,” I think that’s almost a perfect on-ramp. Because it’s like, “I need to know this thing that I don’t know, how about somebody who knows.” They don’t have to be that much higher than you. Just a little bit farther down the path than you, they can help you onramp into that topic and it gives you that great natural in, that reason to be talking to them.
SAM:
Right. And an external commitment to get your environment set up before you get started.
JAMES:
Right.
JOSH:
I think another way to look at some of this is granularity. And what’s the granularity of the pairing. And exorcism, I think, is a fairly good model of either low granularity or high latency interaction where you’re looking at things at a fairly high level. It’s a small piece of code, relatively speaking, but you’re not doing character by character or even line by line edits. You’re looking at, “Oh, here’s a new version of this code. Let’s get some interaction on it.” In a lot of ways, it’s like pull requests on GitHub where it’s very often teams. This is maybe even something like a sidebar we could explore. But how you balance things, like maybe we’re in different time zones, we can’t pair together eight hours a day. Even pair together eight hours a day in person is exhausting. But you can do some of your work together pairing live and other work you can do either independently and then submit a pull request. And then, that gives someone else a change to take a look at your code and do the code review that doesn’t happen when you’re pairing. So, I’ve worked on setups like that before. And you can change how close your interaction is a couple of times throughout the day pretty easily. It’s like, “Oh, I’m going to go for lunch,” “Okay, I’m going to keep working. And then when you come back, you can look at a pull request of what I did or we can spend five minutes going over the code together.”
JAMES:
Yeah. That’s a good point.
JOSH:
Yeah. But I think that works. “Oh, let’s go take a look at what that other pair did. We can take a look at their pull request and respond to it.” Or we can just be emailing things back and forth talking about a piece of code and maybe one person isn’t working that day. So, there’s a lot of ways that you can interact remotely to accomplish programming and they don’t all look like looking at and editing together the same piece of code at the same time. Enough rambling on that. [Laughter]
JOSH:
Sam, did you have something to interject there?
SAM:
No, not really. Although I will point out that you mentioned time zones in there. And frankly, you could probably do a whole episode talking about time zones if you wanted to lose your iTunes family friendly rating. [Chuckle]
JAMES:
We would. I would also get kicked off the show because I have zero time zone skills.
SAM:
But yeah, time zones or just, I guess, scheduling compatibilities are probably the biggest barrier I’ve found and the least tractable barrier to a pairing as much as I’d like to do. Because some of my teammates are in Texas, some of them are in D.C.
JOSH:
Oh, yeah. I was pairing with someone in Eastern Europe last year. That was exciting.
JAMES:
One of the fun things that you can kind of do with these pairings, Josh and Avdi did this a while back and I just got around to watching the episode recently. But they decided they were going to pair on Discourse. They set it up, did it over Google Hangouts and then recorded it. So, that was kind of neat, just in that they had their pairing session but then at the same time months later, I was able to sit down and watch what they did, which is kind of cool.
JOSH:
Yeah. So you got to see my face half the time. [Chuckle]
CHUCK:
It’s like the Play by Plays.
JAMES:
Yes, yes. Seeing how developers work and think about things, I always find that very interesting. Like, “Wow, why did they do that?” Or, “What are they thinking about now?” And being able to see that inside in the pairing session and how the interaction’s going and stuff, that’s also interesting I think. And maybe a trend I would love to see more of.
KATRINA:
One of my favorite parts of those are the brain farts, the places where clearly this person is not a stupid person but they’re totally missing something. And it happens to everyone and it’s really a big relief to see that it’s not just me.
SAM:
I love finding places where I’ve missed something. I’m like, “Oh great, I get to learn something.” And that one thing, I get to carry that forward for the rest of my life and the rest of my programming career. It’s wonderful.
JOSH:
Yeah. Katrina, I see those things happen sometimes, too. The ones that I love are the ones where I am absolutely convinced that they miss something. And then later on, you realize, “Oh, they didn’t miss it. They intentionally skipped over it,” because they’re three levels above me and knew that that was a dead end. [Laughter]
JAMES:
Yeah.
KATRINA:
That is so cool.
SAM:
You think that’s air you’re breathing now? [Laughter]
CHUCK:
Awesome. Alright, we’re about due to get to the picks. Are there any gaps that we need to fill before we…?
JAMES:
Sam had one more thing. What is it, Sam?
SAM:
I did. Calling back to something, Katrina, that you were talking about earlier, is how do you make pairing less intimidating? I was procrastinating this morning, or I thought I was procrastinating. And then as it often happens, I ran across something that is absolutely appropriate to what we’re talking about, is this little blog post. It’s called ‘The Shame of Pair Programming’ and I’ll throw a link in the show notes in just a second. But the basic idea is that pairing requires vulnerability. And you have to be humble and be ready to learn from your partner no matter where you are in the spectrum.
And yeah, it’s a nice little reminder that we have to be human and empathize with one another.
JAMES:
It is a good blog post.
JOSH:
I have one last question, Sam.
SAM:
Absolutely.
JOSH:
And that’s, there are a few things that very rarely get spoken of explicitly when talking about pair programming. But if you’ve done pair programming long, then you know these things and you can joke about them with people. At Pivotal, one of the things is, “Oh, if you want to pair program, you just have to get your ego in check.” And that’s something that’s hard to communicate to the people who are new to the experience. But then, there are things like it’s really important to shower and to keep breath mints around when you’re going to be pairing with someone side-by-side. And that’s not something that -- Kent Beck talks about that in ‘Extreme Programming Explained’. He says this is an important issue. But it doesn’t get as much coverage as some of the other issues that are more interesting and require a lot more dealing with it. I’m curious. Is there something like that for remote pairing that you would say, “If I could just tell you this and you would get it, it would avoid a whole bunch of problems for you in the future.” Is there something like that that you would love to have the chance to tell people?
JAMES:
Great question.
SAM:
I’m not sure there’s anything that I can separate from just pair programming in general. Obviously, if you can’t get a connection to the other person’s machine, you’re not going to get very far. But that gets back down into the tools discussion that we avoided earlier.
JOSH:
If I were going to try and pick something, it would be like, “Use a headset.”
SAM:
Oh, yes. Yes, actually. Thank you. There’s a whole bunch of stuff about that in the ls-pair readme actually. [Chuckles]
JOSH:
Okay.
DAVID:
Oh, there’s actually something I found as well, which is I use a keyboard that has cherry mx blue key switches. And it sounds like I’m typing on a machine gun. And you have to make sure your pairs are okay with that amount of noise coming off of your keyboard. If they’re not, you either need to get a mute switch or you need to switch to a keyboard with mushier key switches while you’re pairing. Because when you type, it sounds like you’re angry at the alphabet. [Laughter]
CHUCK:
I can second that.
SAM:
Or use a headset, yeah.
CHUCK:
I can second that, having been on that team that Dave and I talk about every so often. He convinced at least one, maybe two other guys, to get the same kind of keyboard. And yeah, sometimes it was impossible to pair with them and communicate at the same time because if they were typing, they couldn’t talk.
SAM:
Yeah.
JAMES:
Or pair over Google Hangouts which now automatically mutes you when you type and it’s so freaking annoying because you have to remember not to type and talk at the same time.
SAM:
Worst…feature…ever.
JAMES:
Yes, agreed.
DAVID:
There’s a hack going around Twitter right now for disabling that on a Mac.
JAMES:
Wow, I didn’t know that.
JOSH:
Yeah, there’s a setting you can do.
CHUCK:
I’m looking at the README for the ls-pair and this is actually really, really cool. So, I’m going to recommend that people go check it out.
JAMES:
Let’s do some picks.
DAVID:
Does that mean we’re picking?
CHUCK:
I think so. David, do you want to start us off with the picks?
DAVID:
Sure. At the start of the show, I didn’t actually have any picks. And then we got talking in the precall and I realized that I do have a couple. One, I can’t believe I haven’t picked this before. But I wrote a blog post in 2007 called ‘Editor Wars: Revenge of the… oh, whatever’. And it talks about Vim versus Emacs versus TextMate, which were the going editors at the time. I use all three. At the time, I used to be able to say that I was better at Vim than everybody I’ve ever met that hated Emacs. I can’t say that anymore. But the point of the blog post, if you want to just TLDR it, is life is too short to be upset with somebody else for their choice of editor. And if you’re going to program, you need to be fluent in all, in Vim and Emacs and a GUI like RubyMine or Sublime Text or whatever. TextMate’s kind of fading a little bit. The other two are just silly. The first one is a mashup. There’s a user on YouTube named flipboit4midles. I’ll put that in the show notes. And this person does incredibly, incredibly amazing mash-ups. He does a mash-up of ‘Gangnam Style’ with LMFAO’s ‘Sexy and I Know It’. And the resulting song is incredible. It’s in pitch. It’s in meter. It’s fantastic. And the third pick I have is another one by flipboit4midles which is a mash-up of Katy Perry, Green Day, and Coldplay. And the song that he wrote, or the mash-up is called, ‘Wide Awake on Paradise Boulevard’. And it’s hauntingly beautiful. He just did an amazing job mashing those up. So, those are each about five minutes of just goofy fun and great music. And if you’ve seen the videos for those, then watching them mashed up is lots of fun. That’s my picks.
CHUCK:
Awesome. James, what are your picks?
JAMES:
I have two and the first one is for Katrina. When we were at the Rogues Retreat, Katrina asked at one point, what was a good book for actually getting in and learning JavaScript? I think a lot of us just gloss over that step, pick it up here and there, bits and pieces. I know I definitely did. Recently, I got into actually sitting down and learning the language, really, really learning it. And I picked up this book called ‘JavaScript: The Definitive Guide’ and it’s exactly the kind of book I love when I’m learning a language, in that it goes into every single conversion that JavaScript will do on primitive types and what that will become. Or how does variable scoping work explained in heavy detail. So, it’s an O’Reilly book. It’s got a rhino on the front of it. It reminds me very much of the Camel book from Perl and just this really in-depth analysis of the language. So, if that’s the kind of thing you enjoy, I know we talked at the retreat, some other people like ‘JavaScript: The Good Parts’ and stuff. But if you like the really in-depth, explain the whole thing, this might be a good book. The other pick I have is something I picked up in a novelty store in San Francisco which is kind of interesting. It’s a journal which is weird for me. I super hate journals because I can’t stand the commitment to writing them. I hate anything that obligates me to write in them all the time. But this one is kind of neat. It’s a five-year journal and it only gives you the tiniest bit of space for each day, enough for one long sentence or maybe three short ones. And I find that constraint is very intriguing for me. I come to it every day, and I'm like, “What one thing do I want to say about today?” And I have no room to elaborate or anything. So, it’s also a really low time commitment. Just the time it takes me to write one sentence and I’ve actually been having fun doing that. So, if you hate journaling like I do, this might be an interesting hack to get around it. JOSH: It’s like Twitter for your diary.
JAMES:
Yeah. Kind of like that. [Chuckle]
CHUCK:
Awesome. Josh, what are your picks?
JOSH:
Okay. I’ve just got one this week. I think I’ve probably picked this before. But Joe Moore, about the first person I pair programmed with, at Pivotal Labs. He maintains a blog called RemotePairProgramming.com because he does a lot of remote pair programming. And he has a lot of really cool information on his blog talking about it. He does reviews of tools and answers questions and posts articles about all sorts of pairing practices. So, it’s worth checking out if you have an interest in remote pair programming.
SAM:
Yeah, it’s a good blog.
JOSH:
And that’s all I’ve got this week. I’m still deep in the novel I was reading last week, the Peter F. Hamilton stories. So, I won’t have a new read for a while. So, that’s it for me.
CHUCK:
Awesome. Katrina, what are your picks?
KATRINA:
I have two picks today. The first is AllTheBadges.io which is created by a fellow named Jason Waldrip. Basically, you put in your GitHub username and it gives you all the badges for gem dependencies and Travis builds and Code Climate grade point average and then code coverage. And then it gives you all of the various links so that you can stick them in your readme’s. I just thought that was really cool. The second pick comes from the people I used to work with in Norway. They just released the most awesome thing ever. It’s called Terrafab. Basically, they took open data from the Norwegian Mapping Authority and have created an online 3D map of Norway where you can drag a little square and click, “Yeah, I want to buy this piece of Norway,” and they send you a 3D printed model of it.
CHUCK:
Cool.
JAMES:
That is awesome.
KATRINA:
Yeah. So Terrafab.bengler.no. I’ll put the link in the show notes.
CHUCK:
Alright. I’ve got a whole bunch of picks. I’ve got a lot of stuff going on and I’m just excited about some of it. The first one, if you’re having time zone issues, EveryTimeZone.com. I know it’s been picked on the show before but it’s really awesome and a great way to go. I’ve also had to do some testing in Internet Explorer. So, I’ve been using Parallels because I already had it. I really like Parallels for running your Windows apps on your Mac, so I’m going to pick that as well. I’ve done a lot of both presenting online and pairing online, and I’ve done a lot of it with some of the stuff we’ve talked about. One thing we didn’t talk about that I use for more the presenting than the pairing is GoToMeeting. So, I pick them. I’ve also picked on the show before Evernote and I’m going to pick them again. But the reason is because the mastermind group that I’m a part of, we’re all doing a video on how we use Evernote. So, I’m going to be putting that video together and I thought I’d share it with you folks as well. I don’t have it done yet, but I’m going to be getting it done later today. So, if you want to see a copy of that, go ahead and follow me on Twitter. My Twitter handle is @cmaxw and I’ll try and post it right after this show goes live next week. That way, you can get that and have a look at it. Finally, the last pick I have is Amy Hoy and friends, Alex Hillman in particular, did the Bacon Biz Conf in May. And they’ve started posting the videos for it on their website. So, if you go to BaconBiz.com, you have to give them an email in order to watch the videos. But I think they’re worth it. So, go check that out if you’re looking at building a product or going freelance or whatever. And those are my picks. Sam, what are your picks?
SAM:
Alright. I have a whole bunch of picks and I’ll try to be as quick at getting to them as I can. My first pick is Ada Developers Academy. This is another one of those coding schools that all the kids are starting up now. But there are a couple of things I like about this one. First off, it’s a one-year program rather than the three months that a lot of them are doing. It’s six months of classroom and then another six months of internship. Also, it’s free. The students actually get a small stipend. Third, one of the organizers is Elise Worthy who herself, she came out of Hungry Academy and she’s freaking awesome.
JOSH:
She was also in the podcast last year as one of our Ruby Nubys.
SAM:
Oh, that’s right. I forgot about that. Yeah, that was great. And then last but not least, this coding school is for women only, which I think is really interesting. I’m curious to see what effect that has on the learning environment and I’m encouraged by that. They have an IndieGoGo campaign right now. So, if you want, you can donate. I’ll put a link to that in the show notes. But the school itself is AdaDevelopersAcademy.org. Let’s see, next pick. Related to that, I’ve been talking to a bunch of people who are just getting started in programming and I find I keep giving them the same, “If I could only give one bit of advice, this would be it,” which is to find people near you that you can learn with and learn from. So, that’s my second pick. Find or make a community that you can learn with and learn from. If you’re lucky, that’s a local community. But with the #PairWithMe, locality isn’t quite as important as it used to be. Let’s see. For my third pick, Portland has this wonderful population of all kinds of hackers and geeks. About five years ago, one of them got tired of maintaining this giant Excel spreadsheet to keep track of all of the different user group meetings that she wanted to go to. So, in proper hacker style, she got a couple of local Rubyists together and built a site called Calagator.org. That’s short for calendar aggregator. This is a wiki-style calendar where anybody can post events that might be of interest to the Portland tech community. But it’s not necessarily just for Portland. The source is up on GitHub. If this sounds like something you want in your area and you don’t have one, fork it and deploy it because this is great. Let’s see. This next one requires a little bit of explanation. Here in Portland, we have this guy by the name of Marcus Roberts. Marcus is one of those people with crazy beards who’s been programming for decades and he just takes this great gleeful delight in finding new and horrible ways to abuse code and then he goes and tells you about it. And he finds these things you should never ever, ever use in production. And then he boils them down to just a few lines of code. And then he takes that code sample and replaces most of the characters with underscores, wraps a story around it, and brings them to the Portland Ruby Brigade every month and we all play Hangman. I managed to get one of these on video in February and I uploaded it to YouTube. I’ll put a link in the show notes. So technically, my pick is this video. But I guess really, it’s more like the performance art of Marcus Roberts. Catch it when you can. And as I believe you all say around here, those are my picks.
CHUCK:
Awesome. Well, thanks for coming, Sam.
SAM:
Thank you. It was fun.
DAVID:
Yes, this was awesome. Thank you.
CHUCK:
Just want to remind everybody. In two weeks, we’re going to be reading Confident Ruby by Avdi Grimm. And if you go buy it on his website, you can get 20% off by entering ROGUESCLUB. Other than that, I don’t think there are any other announcements. So, thanks for coming guys and we’ll catch you all next week.
KATRINA:
Bye.
DAVID:
See ya!
JAMES:
Bye.
SAM:
Have fun storming the castle.
JOSH:
Ciao!