I spent the first fifteen months of my current job on a 100% pair programming team before transferring to a more traditional scrum-based team.
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.
Agreed. This has been my experience as well. I've mostly pair programmed over the last 15 years. Very similar schedule. Same pros & cons. There's a counter intuitive key element to Pair Programming - you're slowing down in order to go faster. You make fewer mistakes and correct them an order of magnitude faster when you do. You spend less time "thrashing" on something. You're less likely to loose the better part of an hour going down an implementation rabbit hole. Once you let get of the illusion that you can be better long term "by just going off and cranking this out on my own" (e.g. cowboy coding / hacking / JANGIT - Just Add New Garbage Ignore Testing), then the value of pairing really shines. 18 months into a project, you're looking at something that is still high quality, still manageable, and you still actually want to work on because you're proud of what you and your team have done.
Other than "code quality was higher", I don't see anything else directly related to pair programming in your observations. Seems more about team culture and organization.
I have some hearing loss as well, and this clearly would kill it for me, even if I thought it was a good idea otherwise. I actually walked through the programming floor of what might be the largest pair-programming operation in the US and was shocked to see (and hear!) that it was concrete floors and ceilings with no sound treatment. Awful.
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.
- 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.
I find it really hard to try things I'm not sure will work, or noodle around, or feel my way toward a solution, when someone's watching. Just incredibly uncomfortable. Since those sorts of things are where a lot of my value comes from, count me out on PP. It's fine in very small doses for specific purposes when both people want it and are already comfortable working together but I'd go fucking crazy being forced to do it every day on a schedule.
> only good if everyone understands the problem and solution space equally
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.
> A pair works at the speed of its slowest member, so it take at least 8 hours for them to finish the "easy" coding.
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.
I work at a company that does full-time pair programming whenever possible. There can be drawbacks for sure, but overall, I love it. However, one caveat is that our hiring process places emphasis on finding people that are collaborative and easy to work with as opposed to know-it-all "rockstar" developers. We also do test-driven development, so in addition to the most common pattern (driver / navigator) we sometimes do it a different way wherein one person writes the failing test, then their pair writes the implementation to get the test to pass along with the next failing test. Rinse, repeat.
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.
I've seen the following from pairing Junior and Senior engineers:
* 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.
Paring with Ping Pong TDD works really well. Improves paring with frequent driver/navigator switches and improves TDD by having the navigator thinking ahead. Been doing it almost exclusively for 14 years.
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)
Some people hate pair programming. I happen to be one of them. It kills my personal job enjoyment/satisfaction and if I was coerced into pair programming too often, I would find a job elsewhere.
So, the cost of losing one or both of the programmers in the process must be considered too.
True. It's also true a lot of people hate solo programming, and do not want a non pair programming job.
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.
Next time on Hacker News: an article about the economics of strong typing, with someone threatening to quit if they have to use a strong typing system, demanding that be factored into the economics as well.
Perhaps true, but not really the point the authors were looking at.
I don’t know if I would say I “hate” it, but the one time I tried it (at the behest of my then-employer), I and the rest of my team found it to be unworkably impractical. We had half as many computers as we had programmers, so we each shared a workstation. However, each of us had our own individual e-mail addresses, so we’d have to take turns checking and reading e-mail while the other one sort of looked away. When we started using something new (I think it was Apache Struts back then), we’d have to take turns reading the documentation - we even tried putting two different copies up side by side so we could scroll individually (but we still had to take turns moving the mouse). Beyond that, everything seemed to take way longer than it might have taken individually because neither of the people in the pair would be comfortable doing anything experimental unless they could quickly explain it to the other, so there was a lot of time spent talking about whether some approach or other might work instead of just trying it to see what happened.
Pair programming can be fantastic in short burst. The other day me and a coworker were working through a difficult solution and having another set of eyes was needed.
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"
Over the last few years I’ve come to this exact realization as well. I used to think about it as a couple devs sharing a keyboard for interminable stretches and it made my skin crawl. Watching someone “drive” fumbling for buttons in the IDE and not using shortcuts makes me want to shoulder them out of the way and take over.
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...
isn't how pair programming emerged ? a natural realization that teaming up helps searching through space at high speed, keep motivation up, anxiety low.
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".
There is a construction site in front of my office. When I walk close by, I always see a guy working and another one standing next to him apparently checking if he is doing correctly the job. Wondering if this is the equivalent of pair programming in the construction industry.
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 imagine this could be chain-gang hell for introverts.
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.
It definitely is. What happened is software paid so well that people who can talk more than think, which is the vast majority of people, crowded it out.
I'm pretty sure it's not that nobody bothers, it's just that there is well over a decade of research and literature strongly suggesting that it's either (a) impossible to do this kind of direct productivity measurement accurately, or (b) gives the wrong idea, creating wrong incentives that generally fail to improve outcomes (or worse, that the measuring directly hinders many positive outcomes.)
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...
I think PP is great; however, I do not like to use it as an educational practice. Why boils down to two ideas - a) you are not hired in teams, so you cannot rely on classmates; and b) we've made students so scared to help each through fear of academic integrity and copyright violations that we had to create a special activity centered around looking at someone else's code.
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.
Being forced to pair program all the time blows (IMHO). It's just too rigid. I was recently paired with another guy way below my ability. Great for him, not so great for me. PP is amazing when you and a co-worker decide to pair because it's the perfect approach for a problem you're trying to solve, or because one of you needs help figuring something out.
This sentence from the blog is key, "Caveat: Pair programming is a learned skill. It takes time and work to do it well."
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
Pair Programming is a complete crock of shit. If you hire someone to do a job, either they can do their job, or they cannot. If you cannot trust someone to perform and deliver work up to a certain standard, do not hire them. Is there any other industry where you hire two people to do one job?!
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.
I'm one of the right people, I love pairing and have been doing it for a decade full time. That being said, I'm also very much aware 80% of developers will never want to do it, and that's okay. Even though it's a skill to learn, and I'd guess a good many of those 80% would come to enjoy it with more practice, it's ok to not like it.
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.
My experience pair (and mob) programming for the past months has been very positive, both with in loco and remote peers (sometimes mixed). New hires feel they get a lot of context faster, and experienced peers feel it improves quality, as it forces code to be understandable.
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)
[+] [-] dhosek|6 years ago|reply
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.
[+] [-] swagtricker|6 years ago|reply
[+] [-] ggregoire|6 years ago|reply
[+] [-] bborud|6 years ago|reply
The reason I ask is that the effectiveness of pair programming seems to depend on a lot of factors. Including the above mentioned factors.
[+] [-] zizee|6 years ago|reply
> 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!
[+] [-] downerending|6 years ago|reply
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.
[+] [-] Justsignedup|6 years ago|reply
- 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.
[+] [-] karatestomp|6 years ago|reply
[+] [-] odyssey7|6 years ago|reply
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.
[+] [-] ravenstine|6 years ago|reply
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.
[+] [-] heisenbit|6 years ago|reply
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.
[+] [-] bakedbeanz|6 years ago|reply
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.
[+] [-] hendershot|6 years ago|reply
* 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.
[+] [-] hendershot|6 years ago|reply
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)
[+] [-] MockObject|6 years ago|reply
[+] [-] quaffapint|6 years ago|reply
I was offered a position with full-time remote pair programming. That sounds like a nightmare to me and opted out of that one.
[+] [-] Trasmatta|6 years ago|reply
At my current job I pair maybe 2 or 3 hours a week, and for my working style that's perfect.
[+] [-] hising|6 years ago|reply
[+] [-] programminggeek|6 years ago|reply
So, the cost of losing one or both of the programmers in the process must be considered too.
[+] [-] BurningFrog|6 years ago|reply
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.
[+] [-] fennecfoxen|6 years ago|reply
Perhaps true, but not really the point the authors were looking at.
[+] [-] commandlinefan|6 years ago|reply
[+] [-] tentboy|6 years ago|reply
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"
[+] [-] manyxcxi|6 years ago|reply
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...
[+] [-] agumonkey|6 years ago|reply
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.
[+] [-] ravenstine|6 years ago|reply
- 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".
[+] [-] ggregoire|6 years ago|reply
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).
[+] [-] m463|6 years ago|reply
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.
[+] [-] pts_|6 years ago|reply
[+] [-] pjc50|6 years ago|reply
[+] [-] yebyen|6 years ago|reply
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...
[+] [-] granshaw|6 years ago|reply
[+] [-] muffelsong|6 years ago|reply
[+] [-] swagtricker|6 years ago|reply
[+] [-] tsumnia|6 years ago|reply
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.
[+] [-] potta_coffee|6 years ago|reply
[+] [-] wolco|6 years ago|reply
Better yet tell him to just stay home and get the job done right.
[+] [-] zadkey|6 years ago|reply
"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.
[+] [-] mkchoi212|6 years ago|reply
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
[+] [-] antonyme|6 years ago|reply
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.
[+] [-] JackMorgan|6 years ago|reply
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.
[+] [-] hcarvalhoalves|6 years ago|reply
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
[+] [-] 5cott0|6 years ago|reply
[+] [-] house9-2|6 years ago|reply