Agile Development

Summarized using AI

Why and how to introduce pairing to your team

Madelyn Freed • February 27, 2024 • online

In this talk, Madelyn Freed, a software engineer at Gusto, discusses the importance of introducing pair programming to development teams. Freed makes a compelling case for how pairing improves coding quality, fosters a joyful workplace experience, and enhances team collaboration. She emphasizes that pairing is a technique where two programmers work together on a single workstation, switching roles between Navigator and Driver, which aligns with the principles of Extreme Programming. Here are the key points presented during the session:

  • Advantages of Pair Programming:

    • Enhances code quality by producing better-designed, more readable code with fewer bugs.
    • Reduces silos in the team, allowing any member to pick up tasks easily, promoting efficiency.
    • Facilitates faster learning of new concepts and techniques, increasing overall team capability.
    • Improves team bonding and collaboration, making work less isolating.
  • Personal Journey:

    • Freed shares her initial struggles with loneliness and difficulty in adapting to a complex codebase while working remotely. She initiated pair programming to alleviate personal isolation, which led to various team benefits, including improved onboarding and fewer code reviews.
  • Addressing Criticism:

    • Freed tackles common objections to pair programming, such as the perception of inefficiency in paying two developers for one task. She counters this by explaining the substantial gains in focus, reduced distractions, and overall productivity benefits that come from pairing.
    • Additionally, she discusses overcoming personal challenges, such as introversion and nervousness, by fostering a supportive environment where admitting ignorance is seen as part of the learning process.
  • Implementation Steps:

    • She recommends starting with manageable pairing sessions gradually, fostering good communication and mutual trust. Freed shares practical advice on how to initiate pairing—beginning with casual one-hour sessions and soliciting feedback after each pairing to continually improve the process.
    • Emphasizing that pairing can be structured to accommodate different skill levels, she notes that both juniors and seniors benefit from the partnership, deepening their understanding and skills through collaboration.

In conclusion, Freed advocates strongly for the implementation of pair programming as a transformative practice for teams. By enhancing collaboration and creating opportunities for mentorship, she believes pairing is a crucial technique for any developer looking to improve both their own work experience and the productivity of their teams. Overall, this session invites participants to explore how to incorporate pairing into their own workflows, thus reshaping their coding practices and team dynamics.

Why and how to introduce pairing to your team
Madelyn Freed • February 27, 2024 • online

Pair programming improves nearly every aspect of my technical work and transforms my job from lonely to joyful. In this talk, I make a case for why pairing improves code, products, and teams, and gives practical steps on how you can introduce it.
https://www.wnb-rb.dev/meetups/2024/02/27

WNB.rb Meetup February 2024

00:00:00.320 hi everyone I am mateline freed um I'm a
00:00:04.839 software engineer at Gusto um a company
00:00:09.000 in the United States I think um
00:00:11.240 headquartered in San Francisco but I'm
00:00:13.719 in Brooklyn uh with my living with my
00:00:17.400 wife and dog who you will see a lot of
00:00:20.039 my dog I'll let me uh share my
00:00:24.199 presentation with you and today I'm
00:00:26.240 going to be talking about um why and how
00:00:30.320 to introduce pairing to your
00:00:32.079 team um uh I pairing has been incredibly
00:00:37.239 important to me um in making my work
00:00:40.600 life better and I want to share uh some
00:00:43.160 of that with
00:00:44.800 you co-hosted by my little dog um Nancy
00:00:50.079 who's going to be in many many
00:00:52.079 pictures um uh the other thing about
00:00:55.680 this hosting is that I would really like
00:00:58.519 um I love when it's people's names I
00:01:00.680 love the name Nancy I would love um
00:01:03.000 people to contribute in chat um and ask
00:01:07.320 uh questions as you have them or or
00:01:09.159 comments one of my favorite things is
00:01:10.640 when somebody disagrees with me um and
00:01:12.840 comes up with kind of like a question or
00:01:14.720 argument I haven't heard before um so I
00:01:16.920 would really love to hear those
00:01:19.360 things
00:01:21.240 okay so um in this talk Nancy and I will
00:01:25.680 make the argument that pairing is good
00:01:29.280 uh go over some common arguments as to
00:01:31.520 against pairing and my rebuttals to
00:01:33.320 those arguments and describe how to
00:01:35.560 practically imp Implement pairing on
00:01:37.240 your team especially if it's just you
00:01:38.960 making cultural
00:01:40.759 changes um so raise of hands or in the
00:01:44.520 chat um who's familiar with pairing who
00:01:47.799 feels that they've done it before has
00:01:49.680 anyone feel really experienced and um
00:01:52.439 does anybody hate
00:01:53.840 it and yeah please share some of your
00:01:56.240 experiences in chat and I'll try to
00:01:58.000 address those as we go go long um some
00:02:02.039 some thumbs up some love pairing
00:02:06.079 um yes yeah tup is great um anyone not
00:02:10.479 experienced at all impairing um good
00:02:14.280 good okay because a lot of this is
00:02:15.879 focused on like convincing you that
00:02:17.680 pairing is good um and giving you some
00:02:20.480 arguments to to implement it okay what
00:02:23.360 is it very basic um uh like standard
00:02:28.959 definition a it's a technique where two
00:02:31.519 programmers code together on a single
00:02:33.720 workstation um one plays the Navigator
00:02:36.640 and directs the other the driver to
00:02:39.519 write the code and they switch jobs
00:02:41.680 frequently um this technique is often
00:02:44.560 associated with something called Extreme
00:02:46.440 programming um if people are familiar
00:02:48.360 with that line of thinking um which is a
00:02:51.239 philosophy is if collaboration is good
00:02:54.440 then we should collaborate all the time
00:02:56.400 like if testing is good we should test
00:02:58.159 all the time so this is uh true with
00:03:00.080 pairing as well um and the pairing I'm
00:03:03.480 talking about is a specific technique
00:03:05.599 I'm not really talking about one-off
00:03:07.159 conversations or having a friendly team
00:03:09.080 that's like always open to it this is
00:03:11.000 sort of like dedicated um extended
00:03:13.959 period of times regularly scheduled um
00:03:16.680 like for a whole afternoon for example
00:03:18.680 for the benefit of the code and each
00:03:25.040 other so what's the argument why is it
00:03:28.120 good um why would you do such a thing
00:03:30.439 that seems on the face of it very
00:03:32.480 inefficient
00:03:34.000 um the code written and there is
00:03:37.280 research done on this is better designed
00:03:39.879 it's easier to read and it has fewer
00:03:42.040 bugs um if pars rotate frequently all
00:03:45.840 team members are equally ramped up
00:03:48.920 oops I'm accidentally
00:03:51.280 touching uh my next buttons okay um all
00:03:54.640 team members are equally WRA ramped up
00:03:56.799 on all parts of the code and I feel like
00:03:58.680 this is a really important
00:04:00.360 thing for um making the argument for
00:04:02.640 your team that pairing is good is that
00:04:04.640 silos are inefficient and pairing makes
00:04:08.200 you makes you forced to not work alone
00:04:10.200 in silos um and therefore any person can
00:04:14.519 pick up any ticket at any time much more
00:04:17.479 efficient process for getting things
00:04:19.400 done um and uh it's an unparalleled way
00:04:23.440 to learn you can learn everything from
00:04:25.800 design patterns to keyboard circuits in
00:04:28.040 warp speed compared with trying to learn
00:04:30.199 them by yourself um so like higher
00:04:34.240 quality everything team efficiency is
00:04:36.759 way up and team overall Improvement
00:04:38.759 through learning and
00:04:40.919 sharing so that's good um it's good for
00:04:45.479 me personally the reason that I
00:04:47.560 implement it was not even really because
00:04:49.880 of the like research done on how it's
00:04:52.440 better it's that I do not like working
00:04:55.199 alone it doesn't work for my neurotype I
00:04:58.600 can concentrate
00:05:00.199 I have trouble breaking down tasks by
00:05:01.720 myself uh and I was hired to Gusto as a
00:05:06.199 all remote person um I was very lonely
00:05:10.240 to be honest um and it didn't feel like
00:05:12.400 I was learning the codebase at any
00:05:14.440 reasonable rate so um after I was a
00:05:19.160 complicated codas and I was feeling real
00:05:22.000 dumb after six months of having worked
00:05:24.120 out long um so uh what I ended up doing
00:05:28.160 because of experiences that I've had at
00:05:29.919 other companies and much
00:05:31.960 more enforced dedicated um pairing
00:05:37.000 environments um I decided to introduce
00:05:39.880 it to my team and I did it sort of as a
00:05:42.639 very personal project like I knew it was
00:05:44.800 going to make my life better um and I
00:05:47.160 think that it has had a good impact uh
00:05:49.800 on the team as a whole but it really was
00:05:51.400 sort of like a selfish um move uh that
00:05:55.560 has overall benefits but mainly for me
00:05:58.840 um so I introduced pairing to my team I
00:06:01.280 have a three-hour block with every
00:06:03.759 single person on my team rotating every
00:06:06.680 single day so every single afternoon I
00:06:10.080 work for three hours with a different
00:06:11.479 person on my
00:06:12.840 team we decide what we're going to work
00:06:14.919 on depending on what's interesting to
00:06:16.440 pair on what the team's priorities are
00:06:20.000 and what context most needs sharing
00:06:22.360 sometimes we're working to just smash
00:06:24.560 through a feature sometimes we're
00:06:26.039 working on like we do a lot of project
00:06:28.199 planning as Engineers our on the team so
00:06:30.440 sometimes we're pairing on that so like
00:06:33.080 really what's most meaty um and uh this
00:06:37.080 has been transformative to me it has
00:06:39.440 been so positive for me it's why I wrote
00:06:42.080 the whole talk uh my team is fairly
00:06:45.120 small um to answer your question mine um
00:06:49.360 uh we have uh right now it's five people
00:06:52.880 so it actually fits perfectly in the
00:06:54.520 week and I have one day off um I don't
00:06:56.879 know how I would do this if I had like
00:06:58.599 10 people on my team but probably rotate
00:07:01.840 with some more
00:07:02.960 rest okay
00:07:06.759 um so yeah um so that's sort of like my
00:07:11.479 personal reason um it's good for my team
00:07:15.840 is why pairing is good uh pairing has
00:07:18.080 been positively mentioned in every
00:07:19.759 single retrospective that we've had
00:07:21.720 since its introduction other people have
00:07:24.080 started pairing with each other separate
00:07:26.360 from me um for like those long blocks
00:07:29.000 because they've enjoyed those what you
00:07:31.039 can get done in that level that amount
00:07:33.919 of time um onboarding members is a total
00:07:37.599 Breeze um because they just hook right
00:07:40.280 into the pairing um most PR reviews you
00:07:44.360 don't even have to do because everybody
00:07:46.599 has already looked at the code and
00:07:47.919 that's one of the biggest like classic
00:07:50.000 saves of pairing is you do not really
00:07:52.800 have to do code review um because
00:07:55.000 everyone has already reviewed it uh and
00:07:58.360 Designs iterate and improve as I work on
00:08:00.680 with everyone on a piece of work just as
00:08:04.039 I I bring my piece of code to every
00:08:06.479 brain on the team and it you can feel it
00:08:10.039 improve
00:08:11.720 uh and finally a sort of an aside it's
00:08:14.680 good for the company too I think it's a
00:08:17.319 good argument to make to bosses um my
00:08:20.039 team works on one of the most complex
00:08:22.560 and
00:08:24.199 operationally uh critical parts of the
00:08:26.400 code the more collaborative close and
00:08:30.599 communicative we are as a team the
00:08:32.680 better we accomplish what is asked for
00:08:34.560 asked of us and I think um good evidence
00:08:38.440 of this uh it's sort of anic data but
00:08:43.560 this is um of this is that though my
00:08:46.800 company has suffered dozens of major
00:08:49.959 incidents in the last couple of weeks
00:08:52.080 because we're a tax calculation company
00:08:53.720 and it's the end of the year for last
00:08:55.640 year's tax year it's been really rough
00:08:58.839 um tons of tons of incidents almost none
00:09:02.640 were caused by us and many were solved
00:09:05.040 by us we are just like a high performing
00:09:07.399 team at this company and I attribute
00:09:09.760 that to one testing and our commitment
00:09:12.279 to testing as a team whole other topic
00:09:14.200 for a whole other talk but also the high
00:09:17.079 quality of work we contribute because of
00:09:19.760 our collaboration because of how
00:09:21.640 connected we are to each other's work um
00:09:24.120 how knowledgeable we are about our
00:09:26.120 section of the
00:09:27.440 code okay somebody did ask a question
00:09:30.519 question does someone not get involved
00:09:32.680 in the pair review at the pr they do I
00:09:34.560 mean we we don't allow any code to get
00:09:36.720 in you have to have a pair review just
00:09:38.720 structurally uh or a code review just
00:09:40.959 structurally but usually it's kind of a
00:09:43.320 rubber stamp at that point because
00:09:44.760 everyone has been deeply immersed in
00:09:46.519 writing the code together and has
00:09:48.600 already demonstrated what criticisms
00:09:51.160 they have so kind of Happens Live
00:09:53.560 including design another good part of it
00:09:56.120 is you don't have to do a code review
00:09:58.720 after you're all done and make
00:10:00.560 structural changes to something that you
00:10:02.240 thought was almost finished that has
00:10:04.079 been happening as the process goes on so
00:10:06.279 much
00:10:07.959 better okay and it could be good for you
00:10:11.720 if you'd like to make stronger
00:10:13.200 relationships at work if you want to
00:10:15.040 learn much faster if you're interested
00:10:17.279 in mentorship both getting it and re and
00:10:20.480 giving it um if you don't like code
00:10:22.720 reviews but do want to improve and you
00:10:24.320 want the the process of it if work is a
00:10:26.839 little lonely and if you want to
00:10:28.839 transmit your good ideas to the people
00:10:30.640 on your team consistently without having
00:10:32.600 to like Drop criticisms at the end of
00:10:35.079 their work paing might be for
00:10:38.839 you um okay so that's my big pitch of
00:10:42.200 why pairing is good we're about to get
00:10:44.160 into why pairing is criticized sometimes
00:10:48.240 um but please uh if anybody has any
00:10:51.320 questions at the midpoint or
00:10:54.720 um uh has any criticisms of themselves
00:10:57.760 or suspicions if you could be brave
00:11:01.240 enough to put them into the chat I'd
00:11:03.639 love to hear
00:11:06.000 them okay first and Main business one is
00:11:10.880 always why pay two Developers for the
00:11:12.680 workout one um so this is something when
00:11:16.639 I used to work as a consultant a
00:11:18.079 software consultant uh this is what
00:11:20.160 people hiring us would always say um
00:11:22.320 because we would pair all the time
00:11:23.880 Consultants love pairing
00:11:26.800 um and the consult rebuttal is you're
00:11:30.639 paying two Developers for the work of
00:11:32.720 three um and I do believe that but I
00:11:36.279 think a lot of the times the gains are
00:11:38.320 in the preventing of procrastination and
00:11:41.200 distraction you have to stay focused so
00:11:44.079 you just gain all that time back so you
00:11:46.320 immediately kind of like double the
00:11:47.680 output of every um developer who's
00:11:51.320 working um and then that quality build
00:11:54.240 over time uh you see gains of that later
00:11:58.120 um but the immediate improve
00:11:59.200 improvements are also like no turn you
00:12:01.680 don't accidentally have people um doing
00:12:04.639 and undoing things you don't have a a
00:12:07.360 turn of communication lag at all because
00:12:10.120 you are concurrently working with each
00:12:13.079 other
00:12:14.920 um and yeah for me focus on a task I can
00:12:18.360 complete so many times more things in a
00:12:20.839 day um if I have that person with me you
00:12:23.199 just can't kind of like distract
00:12:24.959 yourself with
00:12:28.160 procrastination
00:12:30.560 um another argument I'm an introvert
00:12:32.760 pairing doesn't work for me um and I
00:12:35.839 have to say pairing is truly not fun for
00:12:37.920 everybody you can be a kind of person
00:12:39.720 who it just does not work for so fair
00:12:41.839 enough um if you've tried pairing a
00:12:44.800 million times in a million different
00:12:46.399 ways and still don't like it it might
00:12:47.959 just not be for you but if you think you
00:12:50.680 wouldn't like it because you're an
00:12:51.880 introvert I would challenge you to say
00:12:55.279 actually this works for a lot of
00:12:57.199 introverts I am not an introvert
00:12:59.360 unfortunately so I can't speak from
00:13:01.000 experience but um The Many Many
00:13:04.040 introverts I have worked with like this
00:13:06.320 manner of working with a group or
00:13:08.760 because you don't have to work with a
00:13:10.240 group uh people who are better oneon-one
00:13:12.560 um people who need a lot of structure to
00:13:14.880 the conversations that they have um you
00:13:17.320 know who aren't good at small talk but
00:13:18.959 are good when you have a task to do with
00:13:20.959 somebody else that's actually what
00:13:22.320 you're doing and pairing um so but it is
00:13:26.320 for everyone socially tiring so consider
00:13:29.199 giving yourself a lighter load in other
00:13:31.120 regards on the days you're
00:13:33.079 pairing how about I'm a junior I would
00:13:36.360 be too nervous to type in front of
00:13:38.079 somebody else um and yes
00:13:42.560 uh um it can be intimidating you have to
00:13:46.959 reveal yourself to another person I
00:13:49.959 can't write Vim commands in front of
00:13:51.639 another person I get two Spooks so I'm
00:13:53.920 always doing things inefficiently when
00:13:56.160 I'm pairing but it's okay because the
00:13:58.240 other person knows what idea I'm trying
00:14:00.399 to express um you will have to admit you
00:14:03.839 don't know something in front of
00:14:05.639 somebody else uh but if you compare with
00:14:08.160 generally Safe People admitting your
00:14:10.680 ignorance is a critical part of learning
00:14:13.120 and honestly being a software developer
00:14:15.639 for a long period of time you're going
00:14:17.440 to have to admit you don't know
00:14:19.759 something and I find as a practice it
00:14:22.320 gets easier immediately um I pair every
00:14:25.839 single day so I never feel the guilt of
00:14:28.360 like showing that I haven't gotten
00:14:29.839 enough stuff done um if there's other
00:14:35.320 ADHD girlies in the chat maybe you'll
00:14:39.120 know this
00:14:40.560 experience but this is like to get
00:14:42.639 myself to not procrastinate and it
00:14:44.399 really works um and if you are still
00:14:47.560 really intimidated can't figure out um
00:14:50.959 how you'd be brave enough to do it
00:14:52.360 here's a consultant trick um figure out
00:14:56.000 what you're going to be pairing on
00:14:57.399 beforehand uh and do it yourself before
00:15:00.680 the pairing session secretly then throw
00:15:03.440 that code away and do it fresh even if
00:15:05.360 you don't actually complete the task at
00:15:07.560 least like get a lay of the land and and
00:15:09.920 have understanding of what functions are
00:15:11.440 there just the basic um and that gives
00:15:13.800 you a lot more confidence to uh not be
00:15:16.320 kind of during headlights in the
00:15:22.519 moment okay another argument I've tried
00:15:24.680 pairing it's boring to just sit and
00:15:26.360 watch someone else code if this is what
00:15:28.199 you are doing this not the pairing I'm
00:15:29.959 talking about um we uh I have a good
00:15:35.519 article that's describing the pairing I
00:15:37.720 am talking about I'll share it in the
00:15:40.120 chat um that describes the highly
00:15:43.959 structured pairing that you could do and
00:15:46.240 that I would recommend um where who's
00:15:49.399 the brain and who's the hands are split
00:15:51.399 amongst two people so if I'm the brain
00:15:53.480 I'm telling the hands what to do and
00:15:55.440 vice versa so both people are engaged I
00:15:58.199 would also suggest starting with
00:15:59.639 stricter pairing
00:16:02.040 rules switching very consistently 15
00:16:05.319 minutes each that kind of thing and then
00:16:07.199 you can loosen the rules as you become
00:16:08.680 more comfortable but starting strict at
00:16:12.600 first
00:16:14.160 about three hours are you serious that's
00:16:18.120 a long time um my preferred length of
00:16:21.399 pairing time is actually all day every
00:16:24.480 day but I'm compromising on just the
00:16:27.920 afternoon um I that's this is how I like
00:16:30.839 to work but um this is not a unbroken
00:16:35.519 three hours that no one can ever make
00:16:37.160 exceptions about if you are tired that
00:16:39.319 day or you have an appointment or
00:16:41.279 another meeting even you can pause and
00:16:43.440 go do that um and you should remember
00:16:46.839 you should be taking regular breaks be
00:16:48.880 very flexible to other people's needs um
00:16:51.480 physical needs emotional um and
00:16:54.600 generally forgiving and do the kind of
00:16:57.079 overcommunication of I'm gonna be a
00:16:59.560 little late or let's do 10 minutes and
00:17:01.399 really stick to 10 minutes um the long
00:17:05.240 block allows for all sorts of deeper
00:17:08.199 investigation to a problem um and it
00:17:12.120 gives some time to chat and be social
00:17:14.039 which helps when you know sometimes
00:17:15.880 those hourlong meetings are just so
00:17:17.760 strict um and to cover several important
00:17:21.079 topics so those long periods of time I
00:17:22.720 am actually a big fan of especially if
00:17:24.480 you do it in sort of a humane
00:17:27.840 way
00:17:29.760 uh how will it work when two people are
00:17:33.520 vastly different levels so Junior person
00:17:36.120 gets a chance to really learn senior
00:17:38.120 person gets the chance to reinforce
00:17:39.720 their understanding and transmit the
00:17:41.440 craft software is a craft not an
00:17:44.960 academic Topic at least in the way at my
00:17:47.720 job um these pairs are sort of like
00:17:49.919 apprenti ships so if you feel yourself
00:17:52.720 always being in one of those roles
00:17:55.000 remember that's what an apprenticeship
00:17:57.159 is um and uh also double down on those
00:18:00.760 pairing structures so the junior person
00:18:02.480 has a lot of room to give their
00:18:06.080 ideas it's too tiring to pair I just
00:18:08.520 like to get into the zone and crank out
00:18:10.159 code by myself so this is my big um my
00:18:14.240 biggest uh point in the last one which
00:18:16.760 is um it's true that it's tiring to pair
00:18:19.640 because you are front-loading the
00:18:21.679 thinking um and uh if you're a person
00:18:25.080 who just sits there and cranks it out
00:18:26.679 remember you are not doing the hardest
00:18:28.120 thing with which is your apis interfaces
00:18:30.679 variable names structures designs
00:18:32.720 thinking about them from the person
00:18:34.200 who's going to use them next so yes it
00:18:37.039 is harder to talk it out with somebody
00:18:39.200 but it means you're immediately having
00:18:40.679 to think about that and so if you are a
00:18:42.960 crank it out kind of person challenge
00:18:45.200 yourself to consider if other people
00:18:47.039 like working with the code you wrote and
00:18:50.400 consider frontloading some of that
00:18:53.400 transmission uh and pairing is a good
00:18:55.760 way to do that I know I'm I'm
00:19:00.480 uh short on time is that right do I need
00:19:03.280 to finish up I'm good okay okay are you
00:19:06.960 interested in trying it for yourself um
00:19:10.840 paring for me is best is social
00:19:13.200 challenging and productive um I'm a good
00:19:16.159 programmer only as much as I've gotten
00:19:17.960 to pair with excellent programmers um
00:19:22.159 and here's how to implement it by
00:19:24.360 yourself even if you don't have
00:19:26.360 structural support like this is a thing
00:19:28.039 that you can actually change the culture
00:19:30.400 on your team by yourself that's what I
00:19:32.200 did nobody gave me permission to do that
00:19:35.919 um so I would say start with one hour
00:19:41.080 recurring weekly meetings with somebody
00:19:43.159 that you know is going to be fun and
00:19:45.440 chill um I asked I asked in a way that
00:19:49.000 seemed like a favor to me um and people
00:19:51.159 were really happy to do it um if you're
00:19:53.159 a more senior person you probably might
00:19:56.440 like if you have more more technical
00:19:58.960 cache or something you can say this is
00:20:01.159 going to be good for our team but I did
00:20:02.840 it more like this is something I like to
00:20:04.960 do would you do that with me people were
00:20:07.280 happy to do it so start with an hour
00:20:09.200 start with somebody easy if that works
00:20:11.600 out uh set with everyone on your team
00:20:14.799 including the more difficult people um
00:20:18.080 and see if you can uh make those
00:20:22.880 pairings feel productive with
00:20:26.120 them then try long
00:20:29.400 with the single trusted
00:20:31.039 person and my suggestion is 3 hours um
00:20:35.799 but plenty of
00:20:37.440 breaks and also another tip start with
00:20:39.960 the experiment like don't let your
00:20:41.440 reoccurring meetings be indefinite it's
00:20:43.679 actually socially harder to cancel the
00:20:46.440 meeting that has been going on and
00:20:48.400 saying like it's not working um so make
00:20:50.640 sure you say like we'll try it for five
00:20:53.320 weeks something like that um so that you
00:20:56.039 have an out if it doesn't work
00:20:59.440 invest in good pairing hygiene you know
00:21:02.200 like take the breaks um come back when
00:21:05.520 you say you're going to come back overc
00:21:07.480 communicate do the pair switching thing
00:21:10.559 um uh all of that kind of good stuff
00:21:13.880 it's all um really well laid out in the
00:21:16.600 Martin
00:21:17.679 f.com
00:21:19.760 piece and include feedback so at the
00:21:22.799 start I would say the last 10 minutes of
00:21:25.080 every pairing session should be how did
00:21:26.600 it go what did you like what did you not
00:21:28.640 like um it's just a good habit to get
00:21:30.559 into uh and it makes giving negative
00:21:32.960 feedback just a little bit easier one
00:21:35.440 thing I did not touch on is how much
00:21:37.360 feedback can be included in this process
00:21:40.200 um sometimes it's hard to pair with
00:21:41.760 somebody else and you really have to
00:21:42.600 work it out with them um so skillfulness
00:21:45.200 in feedback is also really critical
00:21:48.679 sometimes and that's it uh thanks so
00:21:51.600 much for listening um and time for QA if
00:21:55.080 you have
00:21:56.039 any
Explore all talks recorded at WNB.rb Meetup
+21