Pair Programming Economics
wiki.c2.com
wiki.c2.com
Some observations: team cohesion on the pp team was much higher, code quality was higher. Flexibility, not surprisingly was lower: we had a very fixed schedule: "Stand up" at 8.06 (despite the name, it was unrelated to the scrum event, instead it was more time for sharing news and interesting things before the workday started), team stand up immediately following (this was closer but not quite the same as the scrum stand up), then breaking into pairs and working until noon, then an hour for lunch, then working 1-4 then an hour for individual work like training, administrative junk etc. Remote work was not typical although there were two or three remote team members who lived elsewhere and tele-paired three weeks out of four.
I'm hard of hearing so this was a somewhat draining experience for me thus my switch to my current team. Here, team members typically work remotely 1–2 days per week (largely a consequence of corporate policies which have fewer desks than employees). Each team has 2–3 offshore teams that we work with. It seems like we spend an inordinate amount of time in meetings (my calendar has 11 hours blocked off for meetings in a "normal" week and more is not uncommon). There's a tendency for information to only be passed on orally which isn't great with my hearing loss.
It's not strictly a comparison of PP vs non-PP but overall, I would return to the PP team without hesitation.
My suspicion is that the jawboning about pair programming has more to do with the fact that it's a legal way to weed out older programmers than for any real economic benefits. We're more likely to have hearing loss, and will seem like poorer programmers in a pairing situation. Plus, we're overall less likely to put up with trendy bullshit like PP.
The "extreme programming explained" book that (afaik) popularized it came out more than 20 years ago.
> Here, team members typically work remotely 1–2 days per week...
> Each team has 2–3 offshore teams that we work with
Does not sit well with this point:
> There's a tendency for information to only be passed on orally
I have found a key part of successfully working in a distributed team is overcommunication via some persistent medium.
Perhaps you can be an agent of change to improve this aspect of your new team, both for your own sake and the team's. Good luck!
The reason I ask is that the effectiveness of pair programming seems to depend on a lot of factors. Including the above mentioned factors.
- hard for remote teams. Only good if everyone on the team can easily pair up.
- only good if everyone follows a strict schedule
- only good if everyone understands the problem and solution space equally. If one of us needs to go into a cave for an hr to read documentation or experiment, it all falls apart.
- very mentally intense. You're always on. Can only keep it up for a few hrs without some massive mental drainage.
Overall I like PP for small problems to help teach someone. I dislike it for day-to-day.
That's a goal of pairing up. Together you'll get it better than you would have separately, if for no other reason than the one person who already knows it has to be able to explain it. And as a bonus, now that knowledge belongs to two people instead of being siloed with one of them.
Not necessarily. I pair with a guy who's probably 10 times as productive as I am(I really try, but I understand that I'm relatively slow), and he'll ask me to pair with him because I might come up with an idea for something that even he is stuck on. I often do, despite the fact that I'm much slower than he is at implementing things.
So while I do think that it can often be the case that a pair will only work as fast as its slowest member, most likely when tackling a large problem or even doing something tedious, that doesn't mean that there aren't times where a more productive member can value from pairing with a less productive member.
EDIT: This is entirely from my point of view, so it's possible that this person I mentioned feels differently. However, even if they were frustrated by my slow performance, I don't think they'd inquire my assistance on problems if they thought they wouldn't benefit from it.
He is forced to stretch himself and expressing ideas and concept one level clearer than otherwise. This helps him to move on another level skillwise.
I generally find the axiom "If you want to go fast, go alone. If you want to go far, go together." applicable to this context.
----
Benefits of pair programming (IMHO):
* It eliminates the need for code review (most of the time) since another dev is providing input as you write.
* Pairing senior and junior developers is an excellent way to build the abilities and confidence of the latter.
* Pairing decreases siloing of knowledge and one individual's "ownership" of a particular feature or system. You much less frequently see things like "Oh, you have a question about our Widget Framework? Go ask Sally, she's the only one who touches that part of the code."
* You're less likely to implement hacky solutions just to get something to work because someone else is working alongside you. (At least, I am.)
* It's easier to find and fix bugs (in my personal experience) when you have two sets of eyes on the code.
* You have to slow down and explain your ideas before immediately jumping in and implementing them. I generally find that reaching consensus with my pair about the strategy to solve a problem helps surface edge cases I might not have thought of alone.
Hiring for pairing is important. It's not for everyone, although not everyone has been in an environment where it's done well. I make sure to let people know they will be pairing full time on my teams and ask if they are comfortable with that. Also won't hire anyone that would be significantly slow to work with (can't touch type, slow thought process)
* Really talented junior engineers blossom extremely quickly. They will easily be a multiple better after a year vs not pairing.
* Middle of the road junior engineers can be stunted and continually depend on the decisions / skill of the more senior pair. Pairing them more frequently with same level or lower helps. Sometimes this doesn't happen because this lower quality pair goes significantly slower and the result may need some code review/cleanup cycles, but it's a worthwhile investment.
I was offered a position with full-time remote pair programming. That sounds like a nightmare to me and opted out of that one.
At my current job I pair maybe 2 or 3 hours a week, and for my working style that's perfect.
So, the cost of losing one or both of the programmers in the process must be considered too.
Perhaps true, but not really the point the authors were looking at.
Sadly, it's dismissed out of hand as a "people problem" and "irrelevant". It really deserves more attention.
First of all, if you're looking for programmers to maintain a VB6 app, you really should factor into the economics of that endeavor the fact that most people don't want to code in VB6.
Second, no matter how potentially beneficial the pair programming approach is, there is a question of psychology in play. There are people who are introverted enough that the constant company required for pair programming will wear them down and cause them to quit or change teams. Dismissing it as a "people issue" and misrepresenting it as being unable or unwilling to be a team player is an oversimplification.
My other point is that pair programming is a learned skill. If you just put two unprepared programmers by a computer, you'll most likely end up with two annoyed programmers, and not great code.
This is a popular argument among pair programming enthusiasts, which suggests there may be some merit to it. How do we reconcile it with another popular argument, that many programmers will naturally pair up on an ad-hoc basis when they're working on something challenging and/or interesting?
I can't imagine not wanting a second opinion from time to time, and I've certainly missed having one sometimes when I've been working solo on something and there was no-one else to talk about it with. But personally, I also can't imagine being comfortable in a full-time pair programming culture with necessarily restricted schedules and limited solo time. Sometimes, I just want to do some research or think through some ideas or play with quick and dirty prototypes for a while, even if I might be very interested in discussing my results or initial conclusions with other interested developers afterwards.
I don't think I've heard this argument, and I haven't observed programmer behavior in the wild :)
I'm happy working solo 1 day a week or so, to do things maybe only I care about, or explore/learn things.
Pair programming certainly isn't for everyone, but don't knock it until you've done it for a few weeks, hopefully with some good pros!
I've never learned so much about programming as during my first ~6 months working together with people and learning their wisdom and tricks.
You're right that the restricted schedules are a downside.
I don't doubt that you can learn a great deal and obtain other benefits as a result of pair programming. I'm just questioning whether making it a formal, quasi-full-time arrangement is necessarily better than the ad-hoc version I see happening all the time for similar reasons and with similar benefits.
Sure, people help each other in various ways in most places. But that's the solo programmer on a task asking someone else for help. Two people work on a something together, from start to finish, is a quite different thing
If you're pairing, don't read your e-mail. Even if you're just in a solo work session, don't read your e-mail. It's incredibly disruptive and constant inbox checking will drop your productivity like a rock.
It's okay to pair with multiple workstations (or a single workstation set up for multi-user mode, that's the dream I guess). Looking away from the "main screen" to check docs (or VCS, or the build, etc.) is perfectly fine, just don't get drawn in so deep that you forget about your partner. And certainly don't use that as an excuse to check your e-mail or slack!
One strategy to apply is "show, don't tell". If you have a hard time explaining what you're going to try to do, just do it, the code will probably be clearer than your explanation alone. If it's not, use the conversation to drive the uncovering of assumptions, which can then be encoded in the source.
Remember that pairing isn't simply two people, one keyboard. There are defined roles: the driver and the navigator. The driver handles mechanics, the navigator observes and questions assumptions. Then switch roles. The driver should fearlessly try the experimental things. If the navigator wants to experiment, ask to drive.
Maybe its just because I get along with my coworkers, but when working on something difficult we naturally collaborate and end up in an unofficial "pair programming session"
However, for short bursts (10minutes to max about 90) that are focused on a particular goal makes me feel both re-invigorated and more satisfied with the completeness of the ideas.
The re-invigoratation (for me) comes from not having to run my brain at 100% for the duration. In auto racing terms, my partner and I can take turns drafting off each other’s thoughts, increasing our mental efficiency.
When differences arise I love hearing their thoughts and finding ways to merge the best of both ideas- or completely tossing my own because theirs are better. I’ve heard it (no clue where or from whom) described as idea sex. I’m very okay with my ideas being promiscuous and having lots of better little idea babies.
I still haven’t figured out how to keep my skin from crawling watching people fumble around their UIs though...
Your skin crawling while your pair is fumbling for buttons in the IDE is likely displayed by you physically as well, maybe holding your breath or twitching your hands towards the keyboard, your pair is probably then also thinking “what are they thinking but not saying, have I just done something really stupid” which leaves everybody feeling very uncomfortable, and is unproductive. However if people are comfortable with each other and importantly, open to being shown something new, the whole situation is fixed with a simple “hey, did you know there is a shortcut for that”. Over the weeks simple interactions like that add up to mean the whole team is using all of the keyboard shortcuts. The same is true of software patterns and useful library functions, they spread like gossip in the group because everyone is excited to show the next person.
I totally understand that pair programming isn’t for everybody in fact I think it is only for a specific type of person and group. Pair programming only works in groups where each member has high levels of empathy and trust is high within the group. Everybody on this thread that turned down pair programming jobs because they thought it sounded awful were definitely right to do so. But for some it can be an extreamly productive and fun way of working and learning at the same time.
my favorite time in college was the one time I met a similarly minded guy, we cracked through problems with such a positive energy. It was like a biking race, I'd find an idea, then get stuck, he'd try something, so on and so forth.
- Pair programming works better remotely than people say, in my experience.
- It is a great way to share unwritten/unspoken information and best practices.
- PP is excellent for team cohesion and allowing engineers to get to know each other and their strengths.
- Not every engineering problem warrants PP.
- Some problems are better solved by one person as it can take too much time to get the other person up to speed with the issue.
- Pair programming often leads to better code, but you have to balance that with the overall reduced amount of work being done at once. If two people are working on one issue, you have to balance the benefit of that versus two people working on two problems.
- I'm more effective when I can focus, and sometimes I need to spend an hour deep-thinking about a subject and perhaps pseudocoding something. Pair programming with someone remotely and having long periods of silence would be... weird.
- People seem to view PP as a measure of success. The more a team is pairing, the more success being experienced. Right?
- If someone isn't into pair programming often, that's seen as a negative.
- 95% of people who pair remotely need better microphones or accoustic environments. I wish remote companies would ship their employees a pair of AirPods, a Yeti mic, and some acoustic foam squares.
- Pairing is more consistently useful for reviewing large code changes where it can be difficult for a reviewer to reason about the work that was done. Going through it with the author and doing a screen share can make all the difference.
My conclusion is that pair programming can be good for some things, but I would consider it a red flag if a company highly emphasizes pair programming or coerces people to do it. Treating pair programming like a panacea dismisses the fact that people of different personality types have been writing perfectly good software without pairing since time immemorial, and that there are other ways to improve code and product quality. What I think can be nearly as effective as pair programming is getting code reviewed early and often. I'm not the best at this yet, but I've noticed that life is just better when I don't do a ton of work and wait for it to be reviewed when it's "done".
Anyway, I've done some pair programming when I was younger, and I like helping some new folks with a 1-hour pair programming sometimes, but I don't think I could stand having someone pairing with me all day. Furthermore, there are other ways to keep code quality high (code reviews, tests and so on).
I've always wondered if the people who move into decision-making spots are extroverts, who then go on to make decisions affecting introverts, like open-plan seating.
1 Manager 1 Scrum Master 1 Team Leader 2 Regulars 1 Expert
TL;DR Experts quit max after one year and teams are left with 3 regulars dying inside to keep stuff working.
ps. When mentioned that we have too many middle managers - instant push back - coz they all cover each other, fearing someone will fire them if not. Worst part is those people have zero technical knowledge and make stupid decisions based on things they have seen on PowerPoint presentation. Last such a stupid idea was to move our platform from stable AWS environment to crappy/buggy Azure ecosystem. (simply because one of managers most likely got paid under the desk to push company into this direction). After losing over 1Million Euro on Azure we scrapped this idea..
https://martinfowler.com/bliki/CannotMeasureProductivity.htm...
Outcomes are hard to measure, so we measure productivity instead. At least that's how it goes in my organization (and it does not turn out well, as suggested by the literature.)
Edit: but we are for the most part not developing software as our core competency in this company, so it turns out that fixing this is a pretty low priority...
The first idea is rather obvious - the teams you build while learning may be enjoyable but that does not directly translate to hireability. PP Exercises are still scored primarily through correctness over contribution, so a slacking student can do less and potentially learn less without fear of too much penalty to their course grade.
The second idea is more an opinion about the state of CS ed. In an English class, if I wrote something that wasn't good, I could rely on peers to help. If I need help on my weight lifting form, I can show my form to others for advice. In CS, how dare you show your code to anyone because Copy and Paste are so easily done. I've literally had students swear off StackOverflow and helping peers for fear of being labelled a cheater. PP to me seems like its trying to solve that fear rather than deal with the cause of the fear.
Better yet tell him to just stay home and get the job done right.
"Trouble Encountered https://c2.com/wiki/remodel/pages/PairProgrammingEconomics can't fetch document
See github"
I'm guessing the site is overwhelmed with more traffic than it can handle.
Pair programming sounds great and all but if even one person from the "pair" is not good at it, everything falls apart. Also, the pair's chemistry has to be on point like Jeff Dean and Sanjay from Google :p
Now there are certainly times when it is very valuable to do collaborate, such as rubber duck debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging or mentoring or simply doing a 'desk check'. But these are the exceptions, not the rule. Having someone breathing down your neck or be a back seat driver all day is at best a waste of productivity, forcing the driver to think at the pace of the observer, and at worst, a complete waste of time and effort.
Even if it was scientifically the fastest and best way to program (engineer productivity is unmeasurable so we'll never know) there's still a huge number of developers who will hate it for a number of reasons. They are all valid and no one should be forced to do things they hate if they can add similar value some other way.
I believe it's instrumental that the entire team is at peace w/ some working agreements to make it work:
- Splitting work between pilot/guide(s) (otherwise, it turns into a monologue)
- Rotating roles often
- No pressure to stay or having to leave for a while
- Have adequate installations (quiet space, standup desks, large screens, 40"+ displays if possible, ambient sound for remotes to join in the session)
- Naturally leads to egoless programming
Pair programming is about the relationship first. Code second. Overall system quality last.
It doesn't always work for me, but I found that it offers a surprising amount of benefits.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Just emphasize to everybody to keep it friendly, and make an effort to +1 ASAP every time.
- 2 seniors tackle hard problems
- 1 senior and 1 junior is good for teaching the junior
- 2 juniors together is a recipe for disaster.
Yes, an ASSUMPTION. Not proven. Not studied. An assumption.
> There's an implicit assumption there that all bugs take the same amount of time to fix.
No there isn't.
> Now, I'm about to make a crucial assumption: that Alice and Bob's "difficult tasks" are disjoint, such that what's difficult for Alice is not necessarily difficult for Bob and vice-versa.
... Followed by some anecdata to validate the assumption, followed by "calculations" using hand-wavey numbers.
The rest of the article is similarly filled with hand waving, assumptions, strawmen, and outright fabrications. If you have a valid point, use valid reasoning to argue it.
I did pair programming at two different companies full-time, one was over 200 people and that was one of the most productive companies I've ever worked at, hands down. That is also highly anecdotal, but I know it's true because I did it for 5 years and also have seen what it looks like without it for at least as many. It doesn't work for everyone. Some organizations just attract better people and that is a confounding factor. Remote pairing is hard. All these things are true, but if I want to try it at my next company, as I'm doing right now, I need articles like this to prove I'm not crazy, and yes, it's worth trying if you have problems with communication, or want to train young developers, or learn something new, or reduce bug rework from poor code reviews. It's a very useful method of developing software and I'm happy this guy made an attempt to quantify it, however poorly, because software is just a hard thing to quantify.
- ML involves making lot of assumptions. That created some fatigue in me, and it helped to have someone giving out their thoughts actively. Even when not aligned on a common view point, simply going by one's approach first based on ease-of-implementation sounds practical. we could try other ideas always right..
- Creating bugs became more apparent. i.e., every software bug is someone's creation, and pair programmer would actively think about what's going on, makes the code less buggy
- Software architectures and designs are easy to justify at the end, because you've one more already on board, at least to some extent. If the person isn't aligned with the other's thinking, its very easy to pin point the item. Usual management style is, someone with different eyes (managers, tech leads) review once its gotten to some place.
- What was mild inconvenience was: my pair programmer was Vim guy, I'd like sublime text. Our style of thinking was also different. It made few things better, but ultimately you are asking someone to push their approach onto you. Some adjustment needed.. but okay. I'd prefer reading papers in depth before finding a common theme to implement, they'd prefer jumping into code, and then tweaking and hacking. My motivation/internal agenda is to write novel work, they'd want to simply get best numbers out. Aligning on something at this high level I thought has pros and cons..
- Overall, pair programming really helped me see myself. Its like getting active feedback, but not in the formal feedbacks designed in companies. If both like to some extent doing it together, its a good way to grow as a person and engineer.
- In workplaces there persons would not say I don't like pair programming with this person, unless do/die situation, at least in small companies. This pushes everyone to learn some people skills to see how things are going on.. I felt some discomfort at this aspect, but okay.
- I always had some insecurity about whether I am good enough for my goals or current project. I admired how many things are done by my pair programmer, and that made me feel whether they like working with me. It was always running on the back of my head. I think this dragged my personal contributions..
I'd always suggest someone try pair programming, see how it goes.