Todd Sedano

Software Engineering, Improv, Craft of Software Development

Considerate Pair Programming - Part 1

Why We Pair

Hi. I have come to love Pair Programming. I enjoy the collaboration, cross-training, and better solutions that emerge while I pair.

Continuous Pair programming with Overlapping Pair Rotations removes knowledge silos to increase teams’ resiliency to team disruption [reference] and builds collective code ownership [reference] as described in Sustainable Software Development.

Pair programming is a complex practice requiring skill to master. Although Pair Programming has been around for 20 years and is well researched, some teams simply drop engineers onto a team expecting them to figure Pair Programming out.

As a practitioner, I am still discovering ways that I can improve the pair programming dynamic.

This article describes 1) several techniques that can improve your pair programming experience, 2) strategies on what to do when things get frustrating or go wrong, and 3) concludes with success stories of converting difficult pair-programming relationships into successful pair-programming relationships.

Like any relationship, such as friendships, family dynamics, dating, or marriage, when pairing works well, it is an amazing experience; when pairing falls apart, it can be frustrating and occasionally super hurtful. While unfortunate dynamics can happen while pairing, I have experienced the joy of finding each other in the rift.

Pairing exposes both our strengths and our weakness. How we handle our weaknesses may have a direct impact on the pairing relationship. One of us might not be comfortable exposing our weaknesses. If we are experiencing imposter syndrome, feeling that we are not qualified for the job we have, we might fear that our partner is going to find out that we are faking it.

I have been on a journey to be a better pair. While at Pivotal over 3.5 years, I have paired with ~39 pivots and ~ 20 client developers. I am grateful to each person who has helped me better understand myself and have helped me assemble and create these techniques. If you paired with me and I did not apply the technique, it may be because I learned it later.

Considerate Pair Programming - Part 2

Strategies for Success in Pair Programming

In my software development practice, I rely on several techniques for increasing the probability of success with a pairing relationship.

This article contains a toolbox of techniques. Feel free to pick a few to try out and then revisit the list in a few weeks.

Become invested in your pair’s success is the major take-away. When I am taking care of myself and looking out for my pair, an incredible friendship can form. Consider “what are my pairs strengths? And how do they map to my weaknesses?” and vice-versa. Have I always been invested in my pair’s success? No. My pairs probably have stories on how I could have improved in my pairing. Shifting from “what is in it for me” to “what is in it for us” enables new pairing dynamics.

Considerate Pair Programming - Part 3

When Pair Programming Goes Wrong / Weird

Since pairing is a relational practice relying on imperfect communication, misunderstandings and slights can emerge.

What could go wrong with pairing? Here are some situations that have bothered me.

  • You come across some code that is difficult to read. Your partner tells you not to refactor the code.

  • Your partner dominates the keyboard for most of the day.

  • Your partner does all the work without involving you.

  • Your partner tells you how horrible is the code that you helped work on the previous day.

  • You discuss a situation and agree to a plan, but then your partner starts doing his / her own thing anyway.

In this section, I list out several strategies for coping with a situation that is getting tense, de-escalating a situation that is tense, and how to re-engage with your partner after a tense situation.

Software Engineering Grounded Theory Research

If you are using Grounded Theory to conduct research in software engineering, I would love to hear from you. Please contact me at [professor at]

If you are starting out on grounded theory research, I would suggest this plan of action:

  1. Determine with variant of Grounded Theory that you want to use. Options include:
    • Classic / Glasserian grounded theory
    • Straussian grounded theory
    • Constuctivist grounded theory
  2. Read Stol’s comparison of the three major variants and recommendations on how to write grounded theory research.
  3. Read my lessons learned paper
  4. Read a few exemplars (e.g. Software Development Waste, Becoming Agile)
  5. If you select Constructivist grounded theory, then read Charmaz’s Constructing Grounded Theory
  6. If you select Glasserian grounded theory, then read Hoda’s Grounded Theory for Geeks and read Glaser’s books in order.

This month I finished my Ph.D. I have used grounded theory for the last three years. I have found the method extremely rewarding. I loved interviewing, participant observation, and analyzing the data. There will be moments of confusion with the data. Embrace the confusion, on the other side tends to rewarding research results.

We Know the Way - Phonetic Lyrics - Moana

We Know the Way – Phonetic Lyrics – Moana

Thank you Opetaia Foa’i for this fantastic song. It is my favorite from the Moana sound track.

I wanted to learn this song, yet the official lyrics are in Samoan, Tokelauan, and English (I think). Since I only speak English, I created these phonetic lyrics.

I slowed the music to 70% normal speed and listened over and over again. Note, we might not have all the phonemes in English.

Ta-toe Ta-na-to-pho-low


Le’-tua-tsome knee-te-lay


Oo-ah-pah el-lay-lu-ah toa-le-eh


Oh-loh oh-loh tah-kah

Away Away


Te mah new lay lay A ta key A

Away Away


Nah echo hockey lee-ah

Kah-ang nah-A

One of my hobbies is improv, and I play a game where we get our partner to guess multi-syllabic words by acting out each phoneme.

Remote Pair Programming

Developer pair programming

While at Pivotal, I have iterated on remote pair programming while working on two distributed teams. This shares what I have learned about remote pairing.

Best Practices

  1. Periodically check in with your pair about the audio, video, and screen sharing quality. Fix issues promptly. If you are experiencing issues, bring them up. Quickly iterating is the key to improving the remote pairing experience.

  2. Setup a video feed (zoom,, hangout, slack) that is always on and instant messaging (slack) in the secondary window. Much of communication is nonverbal. Seeing my partner excited or frustrated is super helpful.

  3. Leave the video feed running during breaks. This allows each person to see what is happening at the other end. If my pair is in an office, I might see that my pair is talking to another member of the team.

  4. In the office, leave the microphone open. This allows a remote person to feel connected to the office vibe when their pair is away from the desk. Osmatic communication can still happen.

  5. When a team is distributed between two offices but pairing locally, setup a remote video feed. This allows either office to get the attention of the other office by waving frantically. (Often pairs do not check slack frequently while pairing.)

  6. Use screenhero for screen sharing and zoom for video and audio. The audio in screenhero does not work as well as zoom or

  7. Have all pairs join the same channel. Mute everyone but your pair. Whenever you need a team huddle, just enable everyone’s channel. This reduces the friction for team huddles.

Here the team is in one channel with multiple conversations. Note that the team has an extra camera setup to see what is happening in the aisle: Brady Bunch View

  1. Ask for feedback about the development environment. While Pivotal uses workstation-setup for consistent development environments, the screen resolution difference between a laptop and an iMac makes that combination super tricky. I prefer iMac to iMac.

  2. If you are working across timezones, have empathy and be mindful of break times and lunch time.


  1. Use a two display system. One screen is shared. The other is for supporting remote pairing.

  2. In the office, use an audio splitter. Have two headsets on the splitter. When another co-workes interrupts you, ask them to join the conversation. Having a second headset makes this easy. At the minimum, use a splitter to reduce friction. I use Scotch 35 Electrical Tape on black Belkin Speaker and Headphone Splitter

  3. In the office, use an expensive headset with a boom microphone.

My personal favorite is the Sennheiser PC 363D Headset (shown on the left).

In the office setting, avoid using earbud headsets as they tend to let in too much office noise. If you prefer these, check in with your pair about audio quality.

I updated this page on 10/3/2017 with the reasons behind the recommendations.

Team Code Ownership

Team Code Ownership is “the ability for any developer on a team to change any of the team’s code.”

I’m presenting a paper on Team Code Ownership at EASE 2016 next week.

Read the paper on-line: Or download the pdf:

Summary of Paper

  • My observations clearly indicate that team code ownership is a feeling that can be engendered, not a policy that the team adopts

  • Pivotal developers more acutely feel team code ownership when i) they understand the system context; ii) they have contributed to the code in question; iii) they perceive code quality as high; iv) they believe the product will satisfy user needs; and v) they perceive team cohesion as high.

  • The paper shows that diverse events and trends that can undermine sense of ownership

  • The paper replaces Beck’s definition of Collective Code Ownership (“anyone can change any piece of code in the system at any time”) by introducing the new term Team Code Ownership (“the ability for any developer on a team to change any of the team’s code”)

Theory of Sustainable Software Development Through Team Code Ownership

The theory describes how teams can continue to deliver value in spite of team disruptions. The theory is a collection of synergistic principles, policies, and practices encouraging a positive attitude towards team disruption, knowledge sharing and continuity, as well as caring about code quality. The Theory of Sustainable Software Development through Team Code Ownership is fully presented in the paper.


The theory underlying principles are as follows: Keep a Positive Attitude Toward Team Disruption by recognizing the value that new team members bring with their fresh perspectives and challenging team assumptions; Encourage Knowledge Sharing and Continuity by enabling the knowledge to spread from one developer to the next, eventually reaching the entire team; and Care about Code Quality by recognizing that a well cared for code base makes modifications easier.


Team Code Ownership empowers engineers to modify any part of the system under the team’s responsibility. When engineers agree that a section of the system needs to be changed, the team proactively and tacitly authorizes the change. Shared Schedule aligns the team’s work schedule to enable efficient daily rotation of the developers working on a track of feature development. Avoid Technical Debt enables a team to balance feature development with Continuous Refactoring. When a team is pressured to finish work by a deadline, it might be tempted to focus on feature delivery, stop refactoring, and hence take on technical debt. The team should prefer consistent software development by caretaking the code and leaving the code base in a state where any member of the team can pick up the next story for that part of the code base. This requires product and management support to avoid unnecessary thrashing of developers rushing incomplete work by taking on technical debt to deliver a feature early.

Removing Knowledge Silos Practices

By sharing knowledge throughout a team, any pair will have enough context to understand what needs to be done and know who to ask if they need more details. Continuous Pair Programming reinforces that there is no single owner for any line of written code. The team owns the code. As two developers collaborate, they generate shared context. That knowledge will spread around the team the following day via Overlapping Pair Rotation which explicitly rotates people off a track of work in order to cross-pollinate knowledge and avoid emergent knowledge silos and individual ownership. Knowledge Pollination is activities that promote knowledge sharing in unstructured ways between pairs and includes activities such as daily stand-ups, writing on whiteboards, overhearing a conversation, calling out an update to the team, or simply reaching out to others to ask questions as needed.

Caretaking the Code Practices

By caretaking the code, the team enables any pair to be able to work on any story in the backlog. Test Driven Development (TDD) / Behavior Driven Development (BDD) creates a safety net of tests that give any pair the courage to modify the system without the fear of breaking some other part of the system unexpectedly. The tests become a specification on how each component is used. Continuous Refactoring increases code quality by increasing code discoverability (knowing where to find the responsible code), increasing code readability, and increasing the simplicity of design. Live on Master enables the team to perform Continuous Refactoring as the code is easy to integrate. When teams have long running development branches, merge conflicts discourage Continuous Refactoring.

Performance Pair Programming

Performance pair programming is when one developer drives the entire implementation while the other watches. It is as if someone is solo programming with an audience. The performer prefers accomplishing a task more than taking advantage of the teaching opportunity.

When this occurs, there is no collaboration or discussion about how to proceed. Questions that the watcher asks are often ignored. Typically the Performer is unaware that their pair is not learning anything.

Since one of the most effective learning technique is “learn by doing,” the pair is missing a great learning opportunity.

The Origins of Collaborative Software Development

Collaborative Software Development is the combination of practices from Extreme Programming, Kanban software development, User centered design, and Lean Start-up.

Kent Beck’s Extreme Programming serves as the bedrock foundation for the practices at Pivotal. The company through Rob Mee experimented and piloted these ideas which formed the DNA for our software development practices. Over time these evolved. 1) The core technical practices remain the same. 2) Managing the backlog evolved from managing commitments for an iteration to just in time scheduling of work. By creating small stories, the need for story to task decomposition disappeared. Iteration planning meeting morphed into bi-directional communication about the immediate work to be done in order to create a shared context for the whole team. This removes unnecessary team task breakdown waste, mid-week checking in on programmers waste. It enables product to change the backlog whenever necessary by shifting stability from the iteration to the story. It enables developers to be present with the work and not focused into the future. 3) While Extreme Programming shifted the definition of features from engineers to product, XP did not specify how product determines these features (See below for more details.) XP enabled the developers to focus on the how and product to focus on the what.

When I first learned about Extreme Programming, it was described to me as “cowboy programming” and an excuse for developers to run amok with little discipline. I have been programming and teaching it since 2005 and can currently cannot imagine a saner way of developing software. I find it incredibly disciplined, applicable to many contexts, and I rely more heavily on it for challenging projects.

Collaborative Software Development’s programming in the present comes from Kanban software’s idea of no iterations. The team looks to design and product to periodically communicate and discuss the next bit of work to be done. Typically this happens weekly or more frequently. Since the team is not focused on a fixed amount of work for a period of time, changes in priority do not necessarily interrupt team productivity. If design discovers a problem with a user interaction, a story to fix the issue can be added into the backlog and prioritized as the next most important thing to be done. Problems can arise if the team has no context on the work to be done, and performing an impromptu shared understanding meeting alleviates this problem. If too much trashing happens, the team needs to understand why there are daily fluxes in prioritization.

When I first heard about no iterations, I thought the idea was crazy. However, having experienced it myself, I appreciate the ability to show up at work and see what is the next important thing to get done.

Collaborative Software Development’s validation of features by users comes from user-centered design and popularized by Lean Startup. The approach prioritizes the user’s needs over perceived business desires and suggests that conflicts between the two should result in examining the business desires in order to align with what the consumer wants. This idea also comes from Lean Thinking which defines delivering only what the user wants as value and delivering anything that the user does not want as waste.

Lean Software Development is not a direct influence on Collaborative Software Development. Several of the ideas of lean thinking for reducing do show up. (Co-located teams, short feedback loops, anyone can stop software development by starting a team huddle.) Just as it is problematic to apply construction practices to software development, so to it is to apply manufacturing practices to software development. In Lean Thinking, most of the attention is on optimizing the production of identical components on an assembly line, not discussing how to optimize the design process of creating new products. While some software products are simply configured, at Pivotal, most it is rare for us to build the same component over and over again. Whenever that occurs, we design it once or refactor the code so that adding more is a trivial exercise. Since the work that we do is not repetitive like an assembly line, applying manufacturing technics to software development can be problematic.