Code quality is the least important reason to pair program(braintreepayments.com)
braintreepayments.com
Code quality is the least important reason to pair program
https://www.braintreepayments.com/braintrust/code-quality-is-the-least-important-reason-to-pair-program
52 comments
I used to feel the same way. It largely depends on who you are pairing with. Nearly every experience for me was unique. The part I keep chasing after is your first point. I usually work that way when solo. But with a good pair, it is the same effect without all the planning. If the other developer is just as good as you are, you will inspire each other. One of you will try something that doesn't pan out, but with give the first a new idea that does. It is an amazing experience when it happens, though a bit rare.
The exhaustion you get used to. I feel more tired after 8 hours of pairing than 18 of solo.
The exhaustion you get used to. I feel more tired after 8 hours of pairing than 18 of solo.
It hardly seems worth the trade-off. The more exhausted I am at the end of the day, the less inspired I am the next day. And trading two (experienced) developers' time for a rare chance at an epiphany doesn't seem worth it, either.
I meant that it was rare to find a pair that you function like that with. If you have two senior developers who can do this and are not letting them pair, you are introducing serious amounts of waste.
Couldn't agree more.
There seems to be a strong correlation between people pushing pair programming and people I wouldn't want to work with in the first place.
There seems to be a strong correlation between people pushing pair programming and people I wouldn't want to work with in the first place.
I love pairing. It is the right thing for me, and I work in a company that has pairing in its core culture. Feeling that pair programming isn't the thing for you is your choice and it probably works out well for you, but you wouldn't be hired by my organaization, or Braintree. That's the point that the blog post tries to make while also talking about virtues of pair programming. Not that it is for everyone and anyone who doesn't do it is foolish.
Yes, I definitely wouldn't work for a company that has pair programming in its core culture. I also wouldn't work for a company that has standing desks in its core culture, or Perl programming in its core culture, or Emacs or vi in its core culture. In fact, I avoid monoculture as much as I can, because it stifles innovation by reducing diversity.
I love pair programming. However 2 out of the 3 major pair programming exercises I have had were a disaster. Both were with people who were way advanced in the craft of what we were working on, but also unfortunately had piss poor communication skills. This meant that they would either mumble to themselves and then write a stream of code which I would struggle to follow. Alternatively, when I took over the keyboard, I could sense the impatience that they really wanted to pull the keyboard away from me and it would end up them dictating code to me rather than us discussing through the whys of a potential solution. The point I am trying to make is that some people just can't pair program, they either need to be trained to pair program or rather need to be helped to do this in a way that their productivity is not hampered.
how did this turn out in the end? Are you still with the team? And if yes, how did you cope with the knowledge difference?
I didn't pair program with those specific people again, instead we just split up chunks of work and I learnt more faster. Upon reflection, I still believe the failure is specific to how those people think and work through solutions.
Recently at my company we had an internal discussion about pairing after a colleague wrote a similar post espousing all the virtues of pairing. Pairing was something we as a group had once been zealot like in our belief in its value and would we would pair on everything we did. It was clear however from the discussion that most of us had moved on from this view as far too simplistic and dare I say naive.
Looking back at over 7+ years of pairing I still believe there is wide range of value to the practice and it has made me a much better developer but like anything its value varies greatly depending on your context. I've also come to realise there times when it can be wasteful and even destructive.
Innovation is one very good example where I believe there both needs to finely balanced tension between time to work alone and collaborate together. Take a look at the studies around problem solving by groups vs individuals as to why. Similarly, pairing can also have positive and negative effects on learning and varies greatly depending on an individual's learning styles.
The funnest thing came at the end of our discussion. Having collectively realised the folly of our pair programming crusade over all these years one of the group looked back to see what one of its biggest champions Kent Beck had to say on the subject in his book Extreme Programming Explained. Categorically he said that you shouldn't pair all the time.
Looking back at over 7+ years of pairing I still believe there is wide range of value to the practice and it has made me a much better developer but like anything its value varies greatly depending on your context. I've also come to realise there times when it can be wasteful and even destructive.
Innovation is one very good example where I believe there both needs to finely balanced tension between time to work alone and collaborate together. Take a look at the studies around problem solving by groups vs individuals as to why. Similarly, pairing can also have positive and negative effects on learning and varies greatly depending on an individual's learning styles.
The funnest thing came at the end of our discussion. Having collectively realised the folly of our pair programming crusade over all these years one of the group looked back to see what one of its biggest champions Kent Beck had to say on the subject in his book Extreme Programming Explained. Categorically he said that you shouldn't pair all the time.
This is great insight. We paired 3 hours per day for about a year at the company where I work for before realizing that a more flexible approach to pairing was needed. These days we use it as a tool for on-boarding new developers and collaborated on hard problems, but there are no minimum requirements of time. Keeps everybody happy and still encourages working together!
I'm skeptical on this point.
I've no doubt that pair programming is a great way to spread knowledge around an organization. However my suspicion is that there's a much less sexy practice, also primarily promoted as a way to prevent defects, that could do the job much more efficiently: Regular code reviews.
I'm really only thinking that way for one simple reason: In pair programming, a normal conversation will involve only two people. That means that when a concept's being explained, it's being explained to only one other person. When a new idea's being vetted, it's being vetted by only one other person. When a future challenge is being considered, it's being considered by only one other person. That's always seemed horribly inefficient to me, considering that with a code review you could stick six people around a projector and achieve the same spread of information in as little as one fifth of the time.
That said, for other tasks such as getting new developers up to speed and integrated into the team I doubt there's anything better.
I've no doubt that pair programming is a great way to spread knowledge around an organization. However my suspicion is that there's a much less sexy practice, also primarily promoted as a way to prevent defects, that could do the job much more efficiently: Regular code reviews.
I'm really only thinking that way for one simple reason: In pair programming, a normal conversation will involve only two people. That means that when a concept's being explained, it's being explained to only one other person. When a new idea's being vetted, it's being vetted by only one other person. When a future challenge is being considered, it's being considered by only one other person. That's always seemed horribly inefficient to me, considering that with a code review you could stick six people around a projector and achieve the same spread of information in as little as one fifth of the time.
That said, for other tasks such as getting new developers up to speed and integrated into the team I doubt there's anything better.
Some developers do their best work when alone, and suffer greatly wen forced to work in pairs (introverts). Other developers are the opposite; they are most productive when working in pairs, and are least productive when working alone (extroverted).
I hate these kinds of articles because it perpetuates this stereotype that introverted developers are unemployable.
In my experience, productivity and communication skills fall on a spectrum. Some people are very productive, but have bad communication skills; other people have great communication skills, but usually aren't nearly as productive. The first type hate pair programming, the second type loves it. Braintree is a company that culturally hires people who have great communication skills, but has to double up to be productive.
I think what is best is to just hire whoever, and let them work the way they want. If you want to work in pairs with someone, let them. If you want to work along, let them do that too. I hate this dogmatic thinking that its best that everyone work the same way.
I hate these kinds of articles because it perpetuates this stereotype that introverted developers are unemployable.
In my experience, productivity and communication skills fall on a spectrum. Some people are very productive, but have bad communication skills; other people have great communication skills, but usually aren't nearly as productive. The first type hate pair programming, the second type loves it. Braintree is a company that culturally hires people who have great communication skills, but has to double up to be productive.
I think what is best is to just hire whoever, and let them work the way they want. If you want to work in pairs with someone, let them. If you want to work along, let them do that too. I hate this dogmatic thinking that its best that everyone work the same way.
Nope. I hate pairing, I'm quite possibly a pain to work with, I get especially frustrated when pairing with someone junior who slows me down.
I still do it, because the code quality gains are too big to miss out on.
I still do it, because the code quality gains are too big to miss out on.
I'm genuinely curious about the meaning of your last line. Do you mean missing out on the quality of having two people looking at and collaborating on the same code (vs solo), or the quality of sharing the knowledge with the junior developer long term? or both?
The former. Pairing feels subjectively like a great way to teach, but I'm not sure how much difference it actually makes - those who want to learn will find a way, and those who don't always manage to avoid it somehow.
maybe he means that he cuts down the review time, because he avoids correcting mistakes after they happened.
I want to see statistics and studies. Until then, pair programming is just really one of those things where it seems like it's gone too far in one direction.
The only time I've ever used pair programming is during education, but at that point you're basically sockpuppeting the other programmer.
The only time I've ever used pair programming is during education, but at that point you're basically sockpuppeting the other programmer.
Dinosaur here. I think that these social programming ideas are nuts. At my first job writing production software, we did three things. We brainstormed. We wrote and critiqued designs. We coded (which includes writing unit tests and debugging).
There was basically no open source. If we needed something, we found it in libc, or wrote it, and if it was good, others in the company used it too.
It was incredibly productive and satisfying.
At my current company, I find much less up-front design. We don't do pair programming, so the collaboration tends to be at the end of the process, during code review. And good god, there is no end to the code reviews. I don't understand how anyone can do both good code reviews, and good software development. There isn't enough time or attention for both. I notice that when we're getting toward the end of a release, there is all sorts of shorthand in the code reviews. Reviews like "looks good to me", "nothing jumps out at me", "I only did a cursory scan", etc. This is shorthand for "our process requires code review, so I'm claiming that I've done a code review, but really I haven't." So we end up with no collaborative design at times. And of course, when code review does work, we're finding design flaws late.
There is far less NIH these days, and that's a good thing. There are high quality projects out there, and you can grab one, evaluate it, and save yourself a lot of time. This saves time on building things that are tangential to whatever it is you are trying to do.
But reuse can also go wrong in a few ways. You may spend a lot of time wading through crap. You may try something out, commit to it, and then discover the flaws only much later. You can spend a lot of time finding an open source solution to a problem, learn the API, tweak the internals to improve the fit, and then in hindsight realize that you would have been better off just writing the thing yourself. Frameworks are especially prone to this problem. Yes, they do a lot of things for you, but you have to drink so much kool aid to get the benefit. And then there is inertia, and you tend to fight the framework once you stray from the exact approved way in which it's supposed to be used. Another problem with just downloading something is that your less talented developers tend not to question how the thing works, and not have a good understanding of how it is best used, and what you'd better not try.
What I find is that with all this browsing, and downloading, and trying things out, and making things fit, and reading code, and fixing trivial things demanded by the process, and in general, just doing things in the modern way -- there is just no time for thinking about things hard, forming an idea, and taking the time to express it cleanly.
I won't even get into the latest, highly interactive project management cults. Daily scrums are the modern equivalent of TPS reports.
I haven't tried pair programming and I never will. I'll leave a job if asked to pair program. I'll leave the profession if necessary and program as a hobby. For me, the reason I put up with all the nonsense is those few hours a week when I can actually get a nice problem to work on, think about it, come up with a solution, make it simpler, simpler, simpler, code it, make it simpler some more, and make it fast. Put on the music, get into the zone, and think and hack. Seems much harder to do in recent years.
There was basically no open source. If we needed something, we found it in libc, or wrote it, and if it was good, others in the company used it too.
It was incredibly productive and satisfying.
At my current company, I find much less up-front design. We don't do pair programming, so the collaboration tends to be at the end of the process, during code review. And good god, there is no end to the code reviews. I don't understand how anyone can do both good code reviews, and good software development. There isn't enough time or attention for both. I notice that when we're getting toward the end of a release, there is all sorts of shorthand in the code reviews. Reviews like "looks good to me", "nothing jumps out at me", "I only did a cursory scan", etc. This is shorthand for "our process requires code review, so I'm claiming that I've done a code review, but really I haven't." So we end up with no collaborative design at times. And of course, when code review does work, we're finding design flaws late.
There is far less NIH these days, and that's a good thing. There are high quality projects out there, and you can grab one, evaluate it, and save yourself a lot of time. This saves time on building things that are tangential to whatever it is you are trying to do.
But reuse can also go wrong in a few ways. You may spend a lot of time wading through crap. You may try something out, commit to it, and then discover the flaws only much later. You can spend a lot of time finding an open source solution to a problem, learn the API, tweak the internals to improve the fit, and then in hindsight realize that you would have been better off just writing the thing yourself. Frameworks are especially prone to this problem. Yes, they do a lot of things for you, but you have to drink so much kool aid to get the benefit. And then there is inertia, and you tend to fight the framework once you stray from the exact approved way in which it's supposed to be used. Another problem with just downloading something is that your less talented developers tend not to question how the thing works, and not have a good understanding of how it is best used, and what you'd better not try.
What I find is that with all this browsing, and downloading, and trying things out, and making things fit, and reading code, and fixing trivial things demanded by the process, and in general, just doing things in the modern way -- there is just no time for thinking about things hard, forming an idea, and taking the time to express it cleanly.
I won't even get into the latest, highly interactive project management cults. Daily scrums are the modern equivalent of TPS reports.
I haven't tried pair programming and I never will. I'll leave a job if asked to pair program. I'll leave the profession if necessary and program as a hobby. For me, the reason I put up with all the nonsense is those few hours a week when I can actually get a nice problem to work on, think about it, come up with a solution, make it simpler, simpler, simpler, code it, make it simpler some more, and make it fast. Put on the music, get into the zone, and think and hack. Seems much harder to do in recent years.
I wonder if the type of work you are doing has anything to do with it. Web projects are typically mostly about UX design, architecture, security, and scalability. Very few of these tasks are "unsolved" -- you can do pretty much anything you want to on the Web with some code reuse and good architecture. Therefore, the knowledge sharing of pair programming might work here, since the main goal of a web development project is to have everybody on the same page in terms of best practices, architecture, etc.
Now, if you're writing novel code, new algorithms, working with big data, or writing performance or security critical software, then I can see how the heads-down approach might be more effective. For these projects, maybe understanding the whole system is less critical than, say, programming your component to be 100% optimized.
Now, if you're writing novel code, new algorithms, working with big data, or writing performance or security critical software, then I can see how the heads-down approach might be more effective. For these projects, maybe understanding the whole system is less critical than, say, programming your component to be 100% optimized.
I do work on writing novel code, that is multithreaded, and sensitive to performance. Maybe that is better suited to solo development. That's a separate issue from personality. Some people seem to thrive with more collaborative forms of development, some wither. I'm struck by that distinction every time there is an HN discussion of pair programming.
Yes, exactly. Unfortunately, every so often you get these companies that take on a process as "part of their core culture", when culture should be about principle, not process.
By taking a practice as a core value, they are implicitly stating that it is the One True Way to do things, which means that anyone NOT doing it the One True Way is doing it wrong (to the point that they refuse to hire anyone unwilling to toe the line). I wonder how these people would feel entering a company whose One True Way is waterfall development? Because up until a decade and a half ago, that WAS the One True Way.
By taking a practice as a core value, they are implicitly stating that it is the One True Way to do things, which means that anyone NOT doing it the One True Way is doing it wrong (to the point that they refuse to hire anyone unwilling to toe the line). I wonder how these people would feel entering a company whose One True Way is waterfall development? Because up until a decade and a half ago, that WAS the One True Way.
OP here.
I think this is a good point. There's definitely a risk of dogmatism when we start defining ourselves through a certain process.
I wanted to use the post to explore how a process like pairing influences company culture. I don't mean to imply that the process IS the culture.
I think it's fine, and probably very helpful, for development teams to be opinionated about process. But opinionated is not the same thing as dogmatic.
I mentioned this in a reply to comment on our site, but we also worry a little bit about creating a monoculture and groupthink. We try to fight this by leaving room every week for people to spike things out on their own in open dev time: https://www.braintreepayments.com/braintrust/walking-the-tal...
I think this is a good point. There's definitely a risk of dogmatism when we start defining ourselves through a certain process.
I wanted to use the post to explore how a process like pairing influences company culture. I don't mean to imply that the process IS the culture.
I think it's fine, and probably very helpful, for development teams to be opinionated about process. But opinionated is not the same thing as dogmatic.
I mentioned this in a reply to comment on our site, but we also worry a little bit about creating a monoculture and groupthink. We try to fight this by leaving room every week for people to spike things out on their own in open dev time: https://www.braintreepayments.com/braintrust/walking-the-tal...
One thing you should definitely be careful of (not sure if you do this or not) is requiring adherence to a process that demonstrably doesn't work for a sufficiently large percentage of the population. As another poster pointed out, they select against people who don't like to pair program, which cuts out a large percentage of the (good) developer population, thus fostering monoculture.
Agreed. The "open dev time" idea is attractive, and I can imagine developers getting excited about it, (or at least developers who enjoy doing side projects). But it doesn't seem to address kstenerud's point.
In our interview process, we want developers who like writing software, and want to improve. Asking about side projects, software topics they're researching on their own, languages they're playing with, seems to be a useful thing to focus on. Or at least, I tend to like candidates with good answers to those questions. That's a monoculture I think I'd actually like.
In our interview process, we want developers who like writing software, and want to improve. Asking about side projects, software topics they're researching on their own, languages they're playing with, seems to be a useful thing to focus on. Or at least, I tend to like candidates with good answers to those questions. That's a monoculture I think I'd actually like.
This hits on a latent suspicion of mine, which is that at its core pair programming is really just a way to make tedious programming jobs less tedious. Granted, I say that as someone who also spends most his time working on complex multithreaded performance-critical code and development of new algorithms, and I'm partial enough to that kind of work to have some uncharitable bias.
I tend to think that design by committee, even with a committee of two, reliably produces inferior results. So when really novel work is necessary a much better way to put two people on the same task is to have them both take a crack at it independently and then come back together to see what works best. Sometimes competition is the best form of collaboration.
I tend to think that design by committee, even with a committee of two, reliably produces inferior results. So when really novel work is necessary a much better way to put two people on the same task is to have them both take a crack at it independently and then come back together to see what works best. Sometimes competition is the best form of collaboration.
Well, I'm glad that you find writing algorithms not tedious, because I surely don't want to be doing that! Architecture and good software tooling are what really tickle my fancy. It's good there are people with interests along the levels of abstraction.
I agree, I dislike "design by committee". However, sometimes you get to work with those magical, rare people who are both seasoned architecture gurus and have very good social and speaking skills. Working with these kinds of people is an absolute joy -- I will learn more in an hour of watching a skilled developer program than I will from a month of reading online material.
I agree, I dislike "design by committee". However, sometimes you get to work with those magical, rare people who are both seasoned architecture gurus and have very good social and speaking skills. Working with these kinds of people is an absolute joy -- I will learn more in an hour of watching a skilled developer program than I will from a month of reading online material.
OP here. I strongly disagree with the assertion that pair programming isn't helpful in sensitive or mission critical applications.
Braintree's core product is a payment processing gateway. If we go down, get hacked, or introduce serious bugs, our customers can't run their businesses. As I said in the article, we pair for almost everything, and we find it helps us write great software that stays up and stays secure.
Braintree's core product is a payment processing gateway. If we go down, get hacked, or introduce serious bugs, our customers can't run their businesses. As I said in the article, we pair for almost everything, and we find it helps us write great software that stays up and stays secure.
I didn't mean to actually lay out categories where one style is more effective than another -- I don't have that experience. I was simply proposing a framework to think about the differences between development teams and how that might affect the effectiveness of pair programming. Obviously, "web" projects have significant security and performance requirements, which could definitely benefit from pair programming in your context.
I should have focused on the distinction between the size of companies -- that seems like a more accurate framework. I suppose I meant "performance" in the sense of low-level algorithm efficiency rather than high-level scalability and reliability. A misuse of the term on my part.
I should have focused on the distinction between the size of companies -- that seems like a more accurate framework. I suppose I meant "performance" in the sense of low-level algorithm efficiency rather than high-level scalability and reliability. A misuse of the term on my part.
Another problem with just downloading something is that your less talented developers tend not to question how the thing works, and not have a good understanding of how it is best used, and what you'd better not try.
Good grief, yes.
I've observed this not just in coding, but across the board. For example, the young accountant who accepted verbatim and as authoritative every number that came out of the system.
The point of a lot of those reports was really to raise questions, not to provide pat answers.
Writ large, a lot of this "social" endeavor seems, one way or another, to mask a shallow grasp of the material at hand.
And, personally, having experienced how distracting it is for me and counter-productive vis à vis deep thought, I can't but consider it also causative.
I do collaborate. Very well. But not "24/7" while trying to avoid spilling my ramen noodles on the other person's lap.
Good grief, yes.
I've observed this not just in coding, but across the board. For example, the young accountant who accepted verbatim and as authoritative every number that came out of the system.
The point of a lot of those reports was really to raise questions, not to provide pat answers.
Writ large, a lot of this "social" endeavor seems, one way or another, to mask a shallow grasp of the material at hand.
And, personally, having experienced how distracting it is for me and counter-productive vis à vis deep thought, I can't but consider it also causative.
I do collaborate. Very well. But not "24/7" while trying to avoid spilling my ramen noodles on the other person's lap.
Thanks for writing this. Your post conveys my own take on this particular tech trend/fascination.
I love to collaborate - at the whiteboard or during design review. When it's time to code, however, I'd much prefer to be left to my own keyboard.
I love to collaborate - at the whiteboard or during design review. When it's time to code, however, I'd much prefer to be left to my own keyboard.
Most of your response seems to be an off-topic rant against frameworks and new technology, and you're certainly not wrong on those points. But what I find interesting is the on-topic portion, where you basically say this:
"Social programming ideas are nuts." and then you follow that with "My company does collaboration wrong by saving it all until the very end of a project where it's too late."
The piece directly addresses this by stating that pair programming is trading a short-term cost (doubling up programmer resources on the project) for a long-term gain (far fewer errors, fixes and less review and deeper developer knowledge).
If pair programming meant you didn't have such painful, never-ending code reviews, would you still think it's such a horrible idea?
"Social programming ideas are nuts." and then you follow that with "My company does collaboration wrong by saving it all until the very end of a project where it's too late."
The piece directly addresses this by stating that pair programming is trading a short-term cost (doubling up programmer resources on the project) for a long-term gain (far fewer errors, fixes and less review and deeper developer knowledge).
If pair programming meant you didn't have such painful, never-ending code reviews, would you still think it's such a horrible idea?
Yes, collaboration is necessary, and yes, my company is doing it wrong. My preference would be to hash out a design earlier, before there is any code, rather than after the fact. Once you have code, you have wasted time, and it is often difficult to separate out ideas from implementation.
And yes, for me personally, pair programming is a horrible idea no matter what. Pair programming vs. code reviews is a false choice. Ideal for me is design up front, away from the keyboard, and then everyone goes off, by themselves, and does their thing. Or in pairs, if that works for both of them.
And yes, for me personally, pair programming is a horrible idea no matter what. Pair programming vs. code reviews is a false choice. Ideal for me is design up front, away from the keyboard, and then everyone goes off, by themselves, and does their thing. Or in pairs, if that works for both of them.
I posted this comment to your blog as well:
"I've had positive and negative experiences with pair programming. Your blog post only contains the positives. What are some of the negatives that braintree has experienced with your heavy emphasis on pair programming?"
"I've had positive and negative experiences with pair programming. Your blog post only contains the positives. What are some of the negatives that braintree has experienced with your heavy emphasis on pair programming?"
It is always difficult to explain this part to people. That simple typo that stops you for five minutes while typing? Your pair caught it before it ever happened. Saved five minutes right? Not exactly. The stoppage of flow to fix the trivial problem takes your mind off track. It is going to cost you far more than five minutes while you get your mind locked onto finishing your work.
Then there is the removal of code review meetings/gate keeping. Little to no team silos and higher team redundancy. Faster team member ramp up. Lastly, higher code quality.
Then there is the removal of code review meetings/gate keeping. Little to no team silos and higher team redundancy. Faster team member ramp up. Lastly, higher code quality.
A simple typo stops me for 2 seconds, because my IDE caught the error and highlighted it. My mind isn't taken off track because by the time I actually get to the typing part, the entire model is already clear in my mind.
"Then there is the removal of code review meetings/gate keeping."
I'm not so sure that pair-written code should be exempt from code reviews. The two people who wrote the code made a bunch of decisions in the heat of the moment (and possibly under time pressure), and both are emotionally invested in the code that they wrote. If it's reviewed later by people who weren't involved in writing the code, it's likely that they'll notice problems that the original programmers did not, or see better ways of doing things.
I'm not so sure that pair-written code should be exempt from code reviews. The two people who wrote the code made a bunch of decisions in the heat of the moment (and possibly under time pressure), and both are emotionally invested in the code that they wrote. If it's reviewed later by people who weren't involved in writing the code, it's likely that they'll notice problems that the original programmers did not, or see better ways of doing things.
I could never work at a place where pairing is mandatory for almost all development. I find it incredibly draining. I can do it for maybe an hour at a time, but any more than that is too much for me to deal with.
I think being forced to constantly justify and explain your choices is a great way to catch flaws in logic, but it comes at a high cost. Translating my (often vague, half-formed) thoughts into English is an intensive activity - it uses up brainpower that I would rather use to further refine my ideas and code.
I think being forced to constantly justify and explain your choices is a great way to catch flaws in logic, but it comes at a high cost. Translating my (often vague, half-formed) thoughts into English is an intensive activity - it uses up brainpower that I would rather use to further refine my ideas and code.
IMHO, pair programming is suitable for developers who can talk, think, type, and keep basic social interactions at the same time, or can switch between them smoothly.
I am able to make context switch very quickly and am very focus when working. So I am not bothered if my colleagues interrupt me for questions or jokes. I am willing to help as much as I can. I am not bothered if I am under the crossfire of a nerf-gun fight. Still, pair programming is not for me. My productivity would drop like a rock.
I am able to make context switch very quickly and am very focus when working. So I am not bothered if my colleagues interrupt me for questions or jokes. I am willing to help as much as I can. I am not bothered if I am under the crossfire of a nerf-gun fight. Still, pair programming is not for me. My productivity would drop like a rock.
tldr version: http://tldr.io/tldrs/50c222ad1a39f34847000d06
I personally don't like pairing very much. I like be in the zone and crank out code. Then I do a pull request and get one of my teamates review the code. He can spot mistakes, show a trick I could have used and so on. I think we get most benefits of pair programming without having to be 2 guys on 1 screen.
Probably just a matter of opinion though.
I personally don't like pairing very much. I like be in the zone and crank out code. Then I do a pull request and get one of my teamates review the code. He can spot mistakes, show a trick I could have used and so on. I think we get most benefits of pair programming without having to be 2 guys on 1 screen.
Probably just a matter of opinion though.
Question here: how do you teach a new developer using pair programming?
When and how often is it the newbies' turn at the keyboard?
And as the senior feels slowed down, how can he then cope with impatience?
When and how often is it the newbies' turn at the keyboard?
And as the senior feels slowed down, how can he then cope with impatience?
I'm a fairly junior developer at Braintree. I spent two months this summer working in our West Coast office pairing with one of our most senior developers. I spent almost the entire time at the keyboard. The senior developer provided guidance, a sounding board for ideas, kept me from diving too deeply into rabbit holes, provided context about the choices made in the project, etc. It was one of the most rewarding experiences I have had as a software developer.
Another thing to mention is that we generally rotate pairs fairly regularly. A developer will work with others with very different levels of experience both in general and within Braintree.
Another thing to mention is that we generally rotate pairs fairly regularly. A developer will work with others with very different levels of experience both in general and within Braintree.
OP here.
I think it's often hard to tell. One way of addressing this problem is to eliminate the friction associated with switching roles.
We always pair with two keyboards, two mice, and two monitors plugged into the same machine. There's just too much friction associated with switching spots if you only have one keyboard.
If you don't have the equipment for that setup, you can set up a virtual pairing station with ssh and tmux pretty easily.
I think it's often hard to tell. One way of addressing this problem is to eliminate the friction associated with switching roles.
We always pair with two keyboards, two mice, and two monitors plugged into the same machine. There's just too much friction associated with switching spots if you only have one keyboard.
If you don't have the equipment for that setup, you can set up a virtual pairing station with ssh and tmux pretty easily.
ok, definitely interesting to learn how you define "pair programming".
so basically both are fiddling around with the same cursor?
so basically both are fiddling around with the same cursor?
I guess you can skip the 2nd monitor and maybe the 2nd mouse
But yeah, 2 keyboards are a necessity
But yeah, 2 keyboards are a necessity
I think the physical space has a lot to do with it. If you are using one computer then it needs to be easily accessible to both people. Don't sit in a desk with the computer in the corner (ie. you don't want your partner sitting behind you).
The senior should assume he will be slowed down (if working with a noob). This is just a matter of how much patience the senior has. One easy solution is to take breaks.
The senior should assume he will be slowed down (if working with a noob). This is just a matter of how much patience the senior has. One easy solution is to take breaks.
Here's a seldom mentioned advantage of pair programming: reducing hand/wrist strain. If this seems irrelevant to you, wait 10-15 years.
I think this is a recommendation for a specific type of team working on a specific type of problem. I don't think Braintree is recommending you do this on your team -- this just how they do it on their team, and it seems to work for them.
For instance, I can see startup / smaller projects embracing this philosophy more simply because you probably have more members of your team who cross-cut components in terms of expertise and responsibility. In those instances, sometimes I want to know what's going on in other components (mainly because these components are, well, small). In larger companies, this would probably be less effective, since people are more specialized.
However, I think that the second point -- "Pairing accelerates new developers like a rocket" -- can and should be applied to all organizations. This is the biggest complaint I hear about internships -- too often, companies simply throw junior developers into the pool to swim because they're "not worth" devoting 2-3 days of "real" developer time to get the intern up to speed. Often times, the startup cost of learning the development process, learning the build, learning the framework, learning the test suite, etc., can slow down new employee onboarding by weeks.
For instance, I can see startup / smaller projects embracing this philosophy more simply because you probably have more members of your team who cross-cut components in terms of expertise and responsibility. In those instances, sometimes I want to know what's going on in other components (mainly because these components are, well, small). In larger companies, this would probably be less effective, since people are more specialized.
However, I think that the second point -- "Pairing accelerates new developers like a rocket" -- can and should be applied to all organizations. This is the biggest complaint I hear about internships -- too often, companies simply throw junior developers into the pool to swim because they're "not worth" devoting 2-3 days of "real" developer time to get the intern up to speed. Often times, the startup cost of learning the development process, learning the build, learning the framework, learning the test suite, etc., can slow down new employee onboarding by weeks.
I love pair programming. But it depends who you pair with.
1. Cluttered thoughts
When I develop software, very little of that time is spent typing. If you were to watch me program, what you'd see is someone sitting in a chair doing nothing. Before I write a single line of code, I'll examine my future program in my head, poking, prodding, trying out different approaches, weighing the benefits, considering edge cases, and so on. I cannot do this if distracted by talking or typing, as it clutters up my thought process (unless the task is quite trivial). Because of this, pair sessions tend to be awkward, with me not saying much and not typing much 90% of the time. What I can do effectively is design a system and then ask someone to critique it before I start coding it out.
2. Social exhaustion
I have a hard enough time dealing with the exhausting process of social interaction as it is. I don't avoid it entirely, because I know that it's important. However, my mental stamina is also important if I'm going to be doing anything useful, so I try to strike a balance between social obligation and isolation. I've never paired for more than a couple of hours, which is draining and becomes stressful before long. I can only imagine that I'd be climbing the walls after 8 hours of that.
3. The zone
I like programming in the zone. Everything becomes so easy and flows so nicely, but it can sometimes take a long time to get into the zone, and it's fragile and breaks easily. I find it impossible to enter the zone if I'm talking.