--- class: center, middle ![Smiling Tiger](squinting-tiger.jpg) # Thanks for coming! ![NU gear logo](nu.png) --- class: center, middle ![NU gear logo](nu.png) ## Continuity Engineering [engineering.continuity.net](http://engineering.continuity.net) Benjamin Oakes - [benjaminoakes.com](http://www.benjaminoakes.com), [@benjaminoakes](http://twitter.com/benjaminoakes) Tricia Ball - [@tricialball](http://twitter.com/tricialball) Daria Tan is an internet ghost ### TechCorridor.io Near Iowa City/Cedar Rapids? Sign up for our Meetup and Slack channel! --- ## Resources Intrigued? Here's some more info: * [026 RR Pair Programming - Ruby Rogues](http://devchat.tv/ruby-rogues/029-pair-programming) * Joe Moore: [RailsConf 2014](https://www.youtube.com/watch?v=156LdcEjfhs) * Joe Moore: [LA Ruby Conf 2014](https://www.youtube.com/watch?v=rIcUXcyC6BA) (better in Ben's opinion) ## These slides http://bit.ly/continuity-iacc-ama --- class: center, middle What follows are some topics we were thinking about while prepping --- ## Example questions * How do you get over being nervous/insecure? * When is it bad to pair? * How do you deal with differing opinions? * Is it easier to pair two very different people or two very similar people? * How have you implemented remote pair programming? * How did you get started pairing as a team? * What's made pairing the most valuable? * How do you decide when to go to the bathroom? ---
--- ## Our tools Specific to pairing: * Amazon EC2 * Wemux (shared tmux) * Vim * Homesick (shared dotfiles) * Hitch --- ## Why bother? Isn't it a waste of time (and money) to have 2 people do the work of 1? The answer: *time savings* * **Stopping dumb mistakes.** You can quickly fix something that would have taken 30 minutes to figure out. * **A tighter code review cycle.** Review code *as it's written*, not after days of work. This results in more readable code. * **Sharing is caring.** Best practices, shortcuts, problem solving strategies. * **Transferring knowledge.** More people know how the system works and why it works that way. * **Better architecture.** You tend to build to the highest common denominator, finding the best solution, and writing better code than either one of you could have written by yourself. * **Fewer integration problems.** If you switch partners often, then the entire team has a better chance of pulling the pieces together. (The left hand knows what the right hand is doing.) * **Team building.** We love working on our team! We have a lot of trust in each other. * **Interruptions are less disruptive.** The plan is understood by at least 2 people.