14 ms·

Pull Requests vs. Pair Programming

2 points by Chemaclass 5y ago

98lenvi 5y ago
We follow a mix OR only Pull requests (depending on the complexity of the feature). If the feature is a bit complex, or maybe a new team member would benefit with some extra eyes over what they are doing, we start with pair programming and then get the PR reviews by a 3rd programmer. If the programmer feels fairly confident about the feature, then we directly proceed with the PR. It'a mostly about striking a right balance of when to have pair programming & when not to. I personally feel pair programming for every PR will be exhausting
brigandish 5y ago
I've always wanted to try pairing in a kind of fun/competitive way where both program at the same time, one does the implementation while the other writes the tests and does their best to make sure the code breaks, kind of like a mini capture the flag. Have never had the chance to try it out though.
- sodapopcan 5y ago
  That's not how pair programming generally works. Ideally you're still using TDD and discussing code design together as you go. That is at a super high level, at least.
  - brigandish 5y ago
    I know, and that's probably why I don't like it and want to try something different. It's not for everyone, as this thread shows.
    - sodapopcan 5y ago
      Oh absolutely. I would never suggest it's for everyone, just saying that if you try doing it the way you describe, it's not going to be super effective... but also, who knows!
happytoexplain 5y ago
>PR’s are usually ready when the feature/bug is already being worked on and in the last stage of its development process. It’s an “already change proposal to be merged into the current system”, don’t forget that. What is the second sentence saying? I can't parse it at all.
- nighthawk454 5y ago
  basically means a PR is when the feature is done. you're not asking for code ideas, you're proposing a finished change.
  - reidjs 5y ago
    Sometimes I will use a draft PR if I need to show some intermediate code, but I mostly agree. If you put up a PR that means you’re proposing this code is solid and should go into production.
    - Chemaclass 5y ago
      Totally. This is a relatively new concept since a year or so, but there are still people who doesn't use them. But I think a Draft-PR is a great opportunity to show the progress of your changes even if it's not finished yet.
      - brigandish 5y ago
        What are the benefits of a draft PR over publishing a feature branch that others can access?
        jlokier 5y ago
        Assuming you're using GitHub: a draft PR has a comments thread, which you might choose to keep after merging; it can have linked issues (that close if the PR is merged); the draft PR is organised in the list of PRs so it has higher visibility than a branch (some projects have hundreds of branches but few draft PRs) and a more clearly presented one-line description, and you can promote it to a regular PR while keeping the comment history. Overall theme: With a feature branch, you'll need to announce and discuss it somewhere else. With a draft PR, those are features attached to the PR.
gregmac 5y ago
If "usually" PRs result in code style or architecture discussions, I'd suggest you have a team problem, not a process one. Start with the humans. I also object to spotting bugs as an example of misuse. I regularly point out possible bugs in PRs - even ones with unit tests. It often turns out to not be a bug, but does result in new test cases or a comment added. Not mentioned is one of the other big benefits of PRs (which applies no matter if you pair or are a solo project): it enforces some good discipline. If your PR description involves several unrelated things, it's too big and should be done in smaller chunks. I find it gives me a really good chance to scrutinize my own code: things like finding TODOs I missed, bad variable names (which maybe made sense in the first iteration but not in the final state), or bits that need some extra documentation. I don't pair a lot, but when we do (on my current team), we still use PRs, with both as reviewers, as well as getting someone else to come in. The 3rd person is always going to be better at spotting unclear code then the people who've been neck deep in it for a day or 5.
- Cthulhu_ 5y ago
  I twitched when the author's FIRST point was about code style; in this day and age that should not be up for debate anymore, run it through a formatter, change the formatter's rules if you don't like it, and have your CI reject it if the user did not run the formatter before anyone has a look at it. Code style is a distraction that a reviewer should not have to spend their focus on, not when the REAL problem is yet to be reviewed.
  - Chemaclass 5y ago
    Yeah, I am totally with you on this one. Code style shouldn't be up for debate anymore. Nowadays we have plenty of linters and code style fixers that automates the whole code style of the project. That wasn't even the point I was trying to share on this article. PR and PP are on another level, focus on sharing knowledge rather than "code style", for sure :)
- rpastuszak 5y ago
  > If "usually" PRs result in code style or architecture discussions, I'd suggest you have a team problem, not a process one. Start with the humans. +1 > Not mentioned is one of the other big benefits of PRs (which applies no matter if you pair or are a solo project): it enforces some good discipline. I found that pairing and frequent rotations result in a much more uniform adoption of good coding practices, following working agreements, etc... It just happens much more frictionlessly since people learn faster by doing. Again, frequent rotations and ensuring that people mix as much as possible is key. (one company I worked for adopted a so called "promiscuity table" to keep track of that) Also, to quote someone more experienced than me "I've never seen a +300LOC PR that didn't look good!"
razeonex 5y ago
I found pair programming really useful for a lot of situations like, ramping up new team members or teaching someone about some particular module and even learning together a new language, I think is also an awesome tool for team building and for avoiding knowledge silos. But like everything it also has its drawbacks, like sometimes is difficult to match agendas for pairs, to make an example. The social aspect is difficult for some programmers and also there’s people’s that don’t enjoy pairing, and still enjoy PRs more than pairing, and yes if you overcome your social barriers, you can benefit from both, nice post.
- Mup_TIpekpaceH 5y ago
  agree)) same with me
M2Ys4U 5y ago
>Pair programming is the joy of [...] There's supposed to be joy involved?! I have always found pair programming incredibly frustrating and frankly exhausting, both when driving and navigating. It's a useful tool, for sure. Bringing new people on to a team or in to working with code they've not touched before, or to help spread knowledge around a team. But I loathe using it any more than I have to. I also take issue with tone of the article as well, it's condescending as hell. "If you're not comfortable pair programming, why not go off and play around with a pet project, then maybe you'll be good enough to code in front of somebody else!".
- JasonCannon 5y ago
  My engineering team I run does Mob programming, which is like Pair Programming just with more than 2 people. It's an absolute joy. Every one of my guys says it's much more enjoyable and productive than working solo.
  - makeitdouble 5y ago
    I wager you try to hire people that fit your culture and would be very open to that kind of atmosphere in the first place ? Mob programming is a tool that can be useful on some circumstances, but I'm really not sure I'd join a company where the team is crazily enjoying it all day.
    - katbyte 5y ago
      I wouldn’t want t program like that, but everyone is different and teams tend to hire for culture fit, and thus “thier style”
    - JasonCannon 5y ago
      We actually started it as a trial 1 week after hiring our last developer. I had to convince the team to try it and told them to give it 1 month to see how it worked, but everyone was 100% on board within the first week. We are hiring people now, and yes we are going to be hiring based off of willingness to program like this.
ZhangSWEFAANG 5y ago
sort of like run time vs compile time
drenvuk 5y ago
This guy is blind to the possible styles and mindsets of other programmers. "Pair programming is the joy of working with an extra brain and another pair of eyes, where the key is to build a context where you two share the same goal in order to find the best possible solution." Like hell it is. The compiler is my teacher. The linter is my second pair of eyes. The performance benchmark is the guide that nudges me in the right direction. If you need another person to help you program you're useless. If you need the internet to program you're similarly useless. If you can't code in a tent miles away from the nearest internet connection or other human you should go off and practice yourself.
- dgb23 5y ago
  We do a bit of pair programming and pair reviewing from time to time. It’s helpful for quick knowledge transfer: Reading and understanding code is much more efficient when the author walks you through it and explains some decisions on the spot. Also helpful for review: a different set of eyes can sometimes catch design/logic inconsistencies much quicker than yourself or any tool. It’s not that we can’t code ourselves. Pair programming and review is another _thing_ entirely that has unique and useful applications.
- samwestdev 5y ago
  lmao you mad?
  - drenvuk 5y ago
    A bit, yes.
- rixed 5y ago
  Haha! Don't forget the famous (although slightly apocryphal) : - "If you need a visual editor to program you are certainly stupid" (~ Ken Thompson) - "If you need a computer to enter your program into, you are not really a computer scientist" (~ E.W. Dijkstra)
- atq2119 5y ago
  This is a reasonable position to take, except the last paragraph is phrased too carelessly. Somebody who really cannot do any programming at all without a second person probably really is useless as a programmer, but most people will likely interpret what you wrote differently and take offense because of that.
gleenn 5y ago
Having worked many years in a place that did 100% pair programming, switching to a PR company definitely leaves things to be desired. TFA does mention feedback coming back too late in the process, and it definitely feels like the feedback timing is too late for a lot of code. I've thrown away a lot of PRs over the years for reasons that varied from not getting good info up front, to not having someone to accept the PR in busy environments, to silly mistakes. Pairing just seems like a great way to avoid a lot of nonsense. It has so many upsides like cross-pollination of ideas and skills, training, avoiding getting stuck on little snags that end up sucking up time, and so much more.
- JasonCannon 5y ago
  My team does Mob programming (pair programming but with more than 2 developers). In addition to all of those benefits you mentioned, we also have noticed that it helps us keep focused on the task at hand (harder to slack off when the team is all there pushing forward) and has resulted in far less bugs than before. It also results in more code refactoring than we would ever do if we worked solo.
erik_seaberg 5y ago
> The pattern which rejects Pair Programing is basically “fear” That’s fair. I’m afraid a pair won’t stop talking and I won’t get a chance to think.
- Chemaclass 5y ago
  The whole point is to think loud together.
  - JediWing 5y ago
    and some people's brains just don't "work" like that. when someone else is talking, i try to listen, and i'll often lose my own thoughts. i also take time to put my thoughts into words, which the chattier end of people tend to take as an opportunity to speak into the void with filler, further distracting me and forcing me to try to listen, losing my thought. some people's brains don't work in a way that "thinking out loud together" is an effective strategy.
    - Chemaclass 5y ago
      That's fair enough. In such a case, I don't think pair-prog would be beneficial to apply every time for everything, certainly. However, I do think that small pair-prog timeboxed sessions might help developers to learn how to "think aloud" as a natural thing, where the goal is producing code while sharing knowledge at the same time. There are different strategies for doing pair-prog. Developers could/should change roles and not always be the same drivers/navigators, for example. I truly think pair-prog is a great practice for all developers who aim to work effectively within a team because it encourages communication between peers and a high-quality understanding of the business domain and technical knowledge.
Existenceblinks 5y ago
Those 7 fears, most are false. Just remove the word "fear", some of them are true. > Fear that they don’t know what to code or where to start. Not really a big deal, both don't know, and it's not about fear. Sometimes, we just laugh at each other, it's rather kind of funny. > Fear that others will laugh at their solutions. It's about one side blocks the other, make it slow, most of the time I have a good solution in mind already, but my politeness let the other runs, when he stuck I got a chance to interrupt "can we try this blah blah" and it's done this time. > Fear to don’t succeed in public. Not a big deal, no serious work is done during pair, it's for getting mutual understanding / agreement on something, just to make sure we are on the same page. The rest of work is done in isolate. > Fear to not be able to develop the expected solution for multiple reasons: misunderstanding the task or lack of knowledge. This one is true, I saw my team mate swam through randomly. It's ok, that's why pair programming is sometimes pointless. > Fear to change your mind in front of others. That's a sign of good thing is happening, something is getting more practical. > Fear to discuss and make decisions loud. People rather like this, shit talking like discussing works on tea table. > Fear of disagreeing with others. This is why pair programming is half-point, short-time debate is poor quality. Think longer, asynchronously, more research, and write disagreement in long form text .. on pull request.
- elcomet 5y ago
  > no serious work is done during pair I think that's the most important point you made. Pair programming is not for all programming, and in fact the goal is not to produce code. It's more about sharing thought processes with other people
  - twic 5y ago
    When i've done pair programming, the goal was very much to produce code.
    - barrkel 5y ago
      The goal in sole programming is also to produce code. The value-add of pair programming is usually knowledge transfer, rather than code produced. And it's not just knowledge about the code being written, but work practices too.
legerdemain 5y ago
Pair programming means writing code during a meeting. If you want to avoid wasting effort on coding up an inadequate design, the solution is design docs, not synchronous meetings.
- rixed 5y ago
  My thoughts exactly, but I'm surprised how hard it is to change the usual code review based routine where the design is only revealed with the actual code and tests when everything is done and it's too late to discuss the premises. My best guess is that developers just love code reviews. But now that I think of it, maybe they rather loathe writing plain English. Maybe there exist some simple yet more or less formal language that could be used to write design docs?
  - legerdemain 5y ago
    Everywhere I have worked, code "review" was a cargo cult of people mechanically rubber-stamping each other's changes with zero context or consideration. And these weren't particularly dysfunctional companies!
    - watwut 5y ago
      I worked in a place where it was not like that. And it was dysfunctional. Instead, people nitpicked to death and tried to one-up each other with findings. There are loooong arguments over completely irrelevant details. There were multiple rounds of review, sometimes changing the code there and back again. People attempted to code into review comments. And the expectations changed every week, there was no stable standard. It was more about taking control and showing yourself more caring by finding increasingly insignificant things and then insisting on them.
      - legerdemain 5y ago
        Code reviews are a smell.
thriftwy 5y ago
I think it ended up highlighting the importance of small, incremental PRs and the dangers of 'code bombs'.
- Chemaclass 5y ago
  Yes, these are the main points :)
j1elo 5y ago
I'm not sure if I'll be alone here. For me, pair programming (in ye olde times, both physically sitting together) NEVER worked out, because my brain interprets sitting there and watching someone code just the same as getting confy in a sofa and watching a Bob Ross video. My brain tries to follow along, but I cannot help it, I feel so sleepy.
- sodapopcan 5y ago
  That's because you're not supposed to be watching, you're supposed to be actively involved in designing and writing the code whether you are at the keyboard or not. The navigator can also manage the todos, take notes, and look things up while the driver continues on the discussed implementation.
lngnmn2 5y ago
Code-reviews and pull requests must be super because they are asynchronous, so the person is spared from unnecessary emotional load and could choose the more productive state of the mind (an appropriate time slot). Everything asynchronous (in human written communication) is just better. We, by the way, are not evolved for being constantly in the midst of a crowd.
alkonaut 5y ago
> Spot bugs. Bugs and desired behavior should be covered by automated tests. The developer is the first responsible person for this topic. Spotting bugs in PRs literally means spotting what bug exists despite the tests. A lot of the time a bug is coming from weak specification or misunderstanding of the specification. If the developer (and therefore the code) assumes that all addresses must have a postal code then the fact that people might not have a postal code is a bug present in the code. It will fail under circumstances the developer obviously didn't think about. The most difficult job for the developer is finding the holes in the specification.
knocte 5y ago
I really like this article. I'm a huge fan of synchronous feedback (pair programming) and asynchronous feedback (merge/pull requests). In my career I've always been irritated by managers that think that pair-programming is wasting time (as in, less paralleization of work). The best way to describe this situation is with an image: https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8ee4 https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8... I also liked the part where he says "Code style shouldn’t be discussed in a PR", however having the infrastructure set up to be able to avoid this is kinda hard (but we're getting there, in my company). It depends on the language, but for F# we're adopting fantomas (for automatic formatting/indentation) and FSharpLint (which has different rules which check things that the prettifier tool cannot catch). PS(offtopic): BTW if you agree with the above and are looking for remote positions, ping me at my andres@nodeffect.com (we're always hiring).
- vincentdnl 5y ago
  Hey knocte, thanks for sharing my drawing! :)
  - knocte 5y ago
    oh hi! hehe sure :)
- randunel 5y ago
  Your link returns a `404: Not Found`.
  - knocte 5y ago
    Ooops, I've put it here: https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8ee4 https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8...
- andreareina 5y ago
  I'm getting a 404 on your link.
djmips 5y ago
For particular pull requests, I like to have the person responsible go over the PR in an organized fashion, top down where they explain why they solved the problem in this particular way, then go into what they've done and finally a guided tour of the code they've added. This would involve several people on the team and they have the opportunity to ask questions and interact. For how worthwhile that is, I'm surprised it's not brought up as well. I think pair programming and regular PRs are good too but sometimes a presentation style code review is great.
coolgoose 5y ago
I'm confused on why this even up to debate. Is like discussing about desert and literally talking about appels vs pears. Different tools for different things by far.
andrewingram 5y ago
None of those "fears" reflect why I tend to be resistant to pair programming: 1. I just can't keep up with Vim wizards, they dart around a file at the speed of thought and I can't keep track of what they're doing. 2. It's too much social stimulation, which I find incredibly exhausting. Whilst I don't enjoy people watching me as I work, it's not one of the root fears for me, because I don't see pair programming as being a watching vs doing equation.
- Izkata 5y ago
  > 1. I just can't keep up with Vim wizards, they dart around a file at the speed of thought and I can't keep track of what they're doing. My rule of thumb when there's this level of knowledge disparity is that the person who doesn't know what they're doing is the only one allowed to touch the keyboard. That way the knowledgeable person is forced to slow down and explain until the other person actually understands what they're intending.
  - LR3sRdQ 5y ago
    This is a good rule.
- ryanar 5y ago
  Did you mean to say pair programming instead of code review? To address your two points, it is bad form for a person driving to move too quickly. If you are not explaining your thoughts and are moving so fast that your navigator can’t follow along you are no longer pair programming and have lost all benefit. Second, social stimulation can be an issue. But it is important to take lots of breaks, and to have time away from pairing to think and work on your own.
  - andrewingram 5y ago
    oops yes, editing!
  - barbs 5y ago
    > it is bad form for a person driving to move too quickly. If you are not explaining your thoughts and are moving so fast that your navigator can’t follow along you are no longer pair programming and have lost all benefit. That would make me uncomfortable as the programmer, since I'd want to code at my own pace. That said, I imagine I'd necessarily slow down if I needed to explain the code, to help pin down a bug or get feedback, for example. So I guess pair-programming would be useful sometimes. I wouldn't like it if I had to do it all the time, though.
unobatbayar 5y ago
"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks Jokes aside, pair programming is purely theoretical right? No one actually does it?
- Chemaclass 5y ago
  I practice pair-prog not every-time for everything, but every-week with different team members and for different topics. It's up to the context and the task. The goal is to think loud and work together.
- sodapopcan 5y ago
  No. My team pairs as default. Usually the only reason someone will solo is when one of the six of us is busy or out of office.
- ipsi 5y ago
  Eh? It's definitely done in practice, and at some places it's the default, done all the time.
- CRConrad 5y ago
  > Jokes aside, pair programming is purely theoretical right? No one actually does it? Holy crap, where do people even get these ideas from?
zegl 5y ago
I really liked this article. At Sturdy [1], we spent a lot of time thinking about this compromise between PRs and Pair Programming when designing our workflow. I've always felt that the PR code review happens too late, and that you might be tempted to ship code that isn't perfect, as you might have spent tens or hundreds of hours in the "wrong" direction without anyone noticing. But the PR might be the first time someone else on the teams sees the code, but since you've already made the investment in building the code, you might as well ship it. You might say that you'll come back and fix it later, but that rarely seems to happen. Pair Programming on the other hand, get's extremely tricky to coordinate. The entire team needs to synchronise their schedules to be able to effectively pair program, and even then, you only get a few hours of high quality programming time together each day. We've taken the real-time aspect of Pair Programming, and the "offline" aspect of Pull Requests (no voice/video chat required) and built it into the core workflow. On Sturdy, you start by creating a reviewable "Workspace", before you even begin coding. And after that point, you're "live streaming" your code up to the workspace as you're typing (through file system watchers)! Your team mates get an up-to-date status of what you're coding on, and can continuously give you feedback when it fits their schedule. 1: https://getsturdy.com https://getsturdy.com Disclaimer: Founder of Sturdy here
- eweise 5y ago
  What about a third option. Write a design doc so there's feedback about the approach before coding begins?
  - zegl 5y ago
    Writing design docs are a great compliment, and I like how collaborative that process can be when you're doing it in Google Docs! Writing a detailed design document takes a lot of effort/time, with diminishing returns after the first few pages, as you'll likely end up discovering new edge-cases anyways when you start hacking away on the implementation.
bob229 5y ago
Stating the obvious
brightball 5y ago
I tend to encourage my developers to pair program as a necessary part of our cross training processes. It's a good way to get people more comfortable with it. Usually I find that even the most hesitant people will start to talk about the benefits of pairing after they've done it a couple of times, especially with a more senior member of the team. People take for granted how many little things they can learn from other people that they don't expect. I've learned more IDE tricks and command line tools from pairing than I ever did on my own.
- arc-in-space 5y ago
  >Usually I find that even the most hesitant people will start to talk about the benefits of pairing after they've done it a couple of times, especially with a more senior member of the team. Is it possible at least some of them wanted to avoid being seen as bad team players, especially if speaking out negatively could also be seen as conflicting with a senior? Do you catch the softball if it means a higher chance of holding on to your job for longer?
  - brightball 5y ago
    Not really. At least on my teams where everybody has very open communication, people are more than willing to be critical. When you see the change from people adamantly not wanting to pair, then a couple of months later asking people to pair totally unprompted it's easier to read. The way I sell pairing is just this: 1. I want everybody to be able to take vacation without the phone ringing. 2. If there's a part of the system that only you are familiar with, your phone is probably going to ring when you're on vacation. 3. Have somebody else on the team do a couple of stories/tasks on that part of the system while you pair with them for cross training to ensure that your vacations are true vacations. Vacation Oriented Pairing :-) That may only work in an environment where we go out of our way to try to prevent people from overworking though. Might not work everywhere.
T3RMINATED 5y ago
Website blocked Not allowed to browse Music and Audio Streaming category
JediWing 5y ago
> If you still feel uncomfortable having another person next to you while you write code, it might be because you aren’t particularly happy with your own code, or the process that you follow in order to achieve some result. Or the process of constant all-day interaction with another person is just personally draining for you because you're introverted / have social anxiety, or because you have to juggle multiple responsibilities inside & outside of work and don't want the scheduling or social overhead to manage the back-and-forth, or for any of a plethora of reasons besides "something about your process is flawed". This sounds a lot like "if you have nothing to hide you don't need privacy" argument. Some people just hate pairing because it doesn't jibe with their personality or work style. Draft PRs + a culture of continuous reviews accomplishes much of this without taxing people who hate pairing.
- gwn7 5y ago
  > Or the process of constant all-day interaction with another person It doesn't have to be "constant" nor "all-day". The OP doesn't say anything like that. No straw mans please. > is just personally draining for you because you're introverted / have social anxiety I welcome different opinions on this but I personally think that this is something to be fixed, not to be accepted. I refuse to believe that introversion & social anxiety are unchangeable character traits (at least for most people). It is not ok to be introverted nor socially anxious. But if you to choose believe that it is, you won't be able to do anything about them. As a general rule of thumb the more extrovert a person is the higher possibility of their success in life because humans are social animals. This is known. (There are of course exceptions & outliers) > or because you have to juggle multiple responsibilities inside & outside of work and don't want the scheduling or social overhead to manage the back-and-forth Yeah, this is fair. If this is the kind of situation one is in, one probably shouldn't pair program unless the benefits clearly outweigh the costs. > or for any of a plethora of reasons besides "something about your process is flawed" I see your point but I think we also need to accept that the pair programming process of a lot of companies are indeed flawed. It may or may not always be the reason but it's not wise to outright dismiss it. > This sounds a lot like "if you have nothing to hide you don't need privacy" argument. Some people just hate pairing because it doesn't jibe with their personality or work style. I understand this. It is just that I don't want to work with that kind of people because I in fact think that it is not healthy. For me it is a red flag to lack the basic social skills such as sitting together in front of the computer and demonstrating part of your programming skills in a live manner. The only way I would accept to work with somebody like that would be if they were a 10x programmer of something like that. > Draft PRs + a culture of continuous reviews accomplishes much of this No, they don't. No process can ever have the bandwidth of face to face communication so it has some benefits that no other process can offer. In the end this is not a situation where we have to choose between PRs and pair programming. The article suggests that we can and should have both. The key thing is to find the right balance, as it always is. Note: I used to be the biggest introvert & socially anxious person.
agentultra 5y ago
> Pull Requests aren’t the best tool for everything A lot of teams I've worked with have had trouble with the listed problems. They're a sign that your team doesn't understand or hasn't defined the purpose of a code-review and how to conduct them. It's also indicative, if you have comments on architectural decisions in PRs, that you have broader communication issues within your organization. Another drawback of PRs: don't make it personal. A lot of folks have a hard time with this. A shared code-base doesn't belong to any one individual. So don't say things like, "You should do this," or ask, "Why did you choose to do it that way?" A constructive suggestion is about the code and is given in the direct, imperative tense: "If this function used a higher-order function parameter here it would map over the results and remove these two intermediate bound variables and make this function more general." You're not talking about the person or asking them to justify themselves. You're collaborating on the code. Offer constructive suggestions on improving the code. Keep in mind the style guide and the other suggestions by the OP.
coscreen 5y ago
Dragan Stepanovic did an interesting analysis [1] comparing lead and wait times times of async code reviews in contrast to pair programming. His conclusion: "The optimal size of a Pull Request is one line of code which is reviewed immediately", i.e. pair/mob programming. Disclaimer: I'm biased - founder of CoScreen [2] here, a pair/mob programming tool. [1] https://www.slideshare.net/kobac/async-code-reviews-are-killing-your-companys-throughput-248758692 https://www.slideshare.net/kobac/async-code-reviews-are-kill... [2] https://www.coscreen.co https://www.coscreen.co
LR3sRdQ 5y ago
I've done pair programming for a few years now. I've done mobbing, driver-navigator, ping-pong, demo-style, etc. What I've concluded is that the level to which one will like pairing is strong correlated with their personality. For me, pairing with someone that's at my skill level is a good time _assuming that we share most of the same core ideologies_. Pairing with someone that's at my skill level where it's a constant give and take is annoying, but still tolerable. Pairing this way saves a lot of time compared to fighting inside of a pull request (which can definitely happen). Pairing with someone that's far from my skill level, to the point where they're basically typing for you (apparently this is called _backseat navigator_, which is honestly a great name for it), is incredibly mentally taxing. Doing that for an entire day is really, really tough. Coordinating times is also an issue while pairing. Assuming core hours allow, I generally like starting my day between 11am-12pm and ending at 7-8pm. This basically doesn't work for people with families or early birds, but you don't know whether your pair is any of these going in. This is even worse if you're pairing with someone multiple time zones away. So pairing is almost always going to be a huge compromise against time preferences that can be avoided by relying on Slack/Teams and pull requests. Generally speaking, though, I much prefer writing code by myself, communicating through Slack, documenting like a madman, and doing code review through pull requests.
- CRConrad 5y ago
  > Coordinating times is also an issue while pairing. Assuming core hours allow, I generally like starting my day between 11am-12pm and ending at 7-8pm. [ ... ] This is even worse if you're pairing with someone multiple time zones away. Depends on which way the difference goes, doesn't it? If it happens to be two to four hours "the right way around", it would put you on track with someone observing "regular office hours" in their time zone.

2 points by Chemaclass 5y ago

We follow a mix OR only Pull requests (depending on the complexity of the feature). If the feature is a bit complex, or maybe a new team member would benefit with some extra eyes over what they are doing, we start with pair programming and then get the PR reviews by a 3rd programmer. If the programmer feels fairly confident about the feature, then we directly proceed with the PR. It'a mostly about striking a right balance of when to have pair programming & when not to. I personally feel pair programming for every PR will be exhausting

brigandish 5y ago

I've always wanted to try pairing in a kind of fun/competitive way where both program at the same time, one does the implementation while the other writes the tests and does their best to make sure the code breaks, kind of like a mini capture the flag. Have never had the chance to try it out though.

sodapopcan 5y ago
That's not how pair programming generally works. Ideally you're still using TDD and discussing code design together as you go. That is at a super high level, at least.
- brigandish 5y ago
  I know, and that's probably why I don't like it and want to try something different. It's not for everyone, as this thread shows.
  - sodapopcan 5y ago
    Oh absolutely. I would never suggest it's for everyone, just saying that if you try doing it the way you describe, it's not going to be super effective... but also, who knows!

happytoexplain 5y ago

>PR’s are usually ready when the feature/bug is already being worked on and in the last stage of its development process. It’s an “already change proposal to be merged into the current system”, don’t forget that. What is the second sentence saying? I can't parse it at all.

nighthawk454 5y ago
basically means a PR is when the feature is done. you're not asking for code ideas, you're proposing a finished change.
- reidjs 5y ago
  Sometimes I will use a draft PR if I need to show some intermediate code, but I mostly agree. If you put up a PR that means you’re proposing this code is solid and should go into production.
  - Chemaclass 5y ago
    Totally. This is a relatively new concept since a year or so, but there are still people who doesn't use them. But I think a Draft-PR is a great opportunity to show the progress of your changes even if it's not finished yet.
    - brigandish 5y ago
      What are the benefits of a draft PR over publishing a feature branch that others can access?
      - jlokier 5y ago
        Assuming you're using GitHub: a draft PR has a comments thread, which you might choose to keep after merging; it can have linked issues (that close if the PR is merged); the draft PR is organised in the list of PRs so it has higher visibility than a branch (some projects have hundreds of branches but few draft PRs) and a more clearly presented one-line description, and you can promote it to a regular PR while keeping the comment history. Overall theme: With a feature branch, you'll need to announce and discuss it somewhere else. With a draft PR, those are features attached to the PR.

gregmac 5y ago

If "usually" PRs result in code style or architecture discussions, I'd suggest you have a team problem, not a process one. Start with the humans. I also object to spotting bugs as an example of misuse. I regularly point out possible bugs in PRs - even ones with unit tests. It often turns out to not be a bug, but does result in new test cases or a comment added. Not mentioned is one of the other big benefits of PRs (which applies no matter if you pair or are a solo project): it enforces some good discipline. If your PR description involves several unrelated things, it's too big and should be done in smaller chunks. I find it gives me a really good chance to scrutinize my own code: things like finding TODOs I missed, bad variable names (which maybe made sense in the first iteration but not in the final state), or bits that need some extra documentation. I don't pair a lot, but when we do (on my current team), we still use PRs, with both as reviewers, as well as getting someone else to come in. The 3rd person is always going to be better at spotting unclear code then the people who've been neck deep in it for a day or 5.

Cthulhu_ 5y ago
I twitched when the author's FIRST point was about code style; in this day and age that should not be up for debate anymore, run it through a formatter, change the formatter's rules if you don't like it, and have your CI reject it if the user did not run the formatter before anyone has a look at it. Code style is a distraction that a reviewer should not have to spend their focus on, not when the REAL problem is yet to be reviewed.
- Chemaclass 5y ago
  Yeah, I am totally with you on this one. Code style shouldn't be up for debate anymore. Nowadays we have plenty of linters and code style fixers that automates the whole code style of the project. That wasn't even the point I was trying to share on this article. PR and PP are on another level, focus on sharing knowledge rather than "code style", for sure :)
rpastuszak 5y ago
> If "usually" PRs result in code style or architecture discussions, I'd suggest you have a team problem, not a process one. Start with the humans. +1 > Not mentioned is one of the other big benefits of PRs (which applies no matter if you pair or are a solo project): it enforces some good discipline. I found that pairing and frequent rotations result in a much more uniform adoption of good coding practices, following working agreements, etc... It just happens much more frictionlessly since people learn faster by doing. Again, frequent rotations and ensuring that people mix as much as possible is key. (one company I worked for adopted a so called "promiscuity table" to keep track of that) Also, to quote someone more experienced than me "I've never seen a +300LOC PR that didn't look good!"

razeonex 5y ago

I found pair programming really useful for a lot of situations like, ramping up new team members or teaching someone about some particular module and even learning together a new language, I think is also an awesome tool for team building and for avoiding knowledge silos. But like everything it also has its drawbacks, like sometimes is difficult to match agendas for pairs, to make an example. The social aspect is difficult for some programmers and also there’s people’s that don’t enjoy pairing, and still enjoy PRs more than pairing, and yes if you overcome your social barriers, you can benefit from both, nice post.

Mup_TIpekpaceH 5y ago
agree)) same with me

M2Ys4U 5y ago

>Pair programming is the joy of [...] There's supposed to be joy involved?! I have always found pair programming incredibly frustrating and frankly exhausting, both when driving and navigating. It's a useful tool, for sure. Bringing new people on to a team or in to working with code they've not touched before, or to help spread knowledge around a team. But I loathe using it any more than I have to. I also take issue with tone of the article as well, it's condescending as hell. "If you're not comfortable pair programming, why not go off and play around with a pet project, then maybe you'll be good enough to code in front of somebody else!".

JasonCannon 5y ago
My engineering team I run does Mob programming, which is like Pair Programming just with more than 2 people. It's an absolute joy. Every one of my guys says it's much more enjoyable and productive than working solo.
- makeitdouble 5y ago
  I wager you try to hire people that fit your culture and would be very open to that kind of atmosphere in the first place ? Mob programming is a tool that can be useful on some circumstances, but I'm really not sure I'd join a company where the team is crazily enjoying it all day.
  - katbyte 5y ago
    I wouldn’t want t program like that, but everyone is different and teams tend to hire for culture fit, and thus “thier style”
  - JasonCannon 5y ago
    We actually started it as a trial 1 week after hiring our last developer. I had to convince the team to try it and told them to give it 1 month to see how it worked, but everyone was 100% on board within the first week. We are hiring people now, and yes we are going to be hiring based off of willingness to program like this.

ZhangSWEFAANG 5y ago

sort of like run time vs compile time

drenvuk 5y ago

This guy is blind to the possible styles and mindsets of other programmers. "Pair programming is the joy of working with an extra brain and another pair of eyes, where the key is to build a context where you two share the same goal in order to find the best possible solution." Like hell it is. The compiler is my teacher. The linter is my second pair of eyes. The performance benchmark is the guide that nudges me in the right direction. If you need another person to help you program you're useless. If you need the internet to program you're similarly useless. If you can't code in a tent miles away from the nearest internet connection or other human you should go off and practice yourself.

dgb23 5y ago
We do a bit of pair programming and pair reviewing from time to time. It’s helpful for quick knowledge transfer: Reading and understanding code is much more efficient when the author walks you through it and explains some decisions on the spot. Also helpful for review: a different set of eyes can sometimes catch design/logic inconsistencies much quicker than yourself or any tool. It’s not that we can’t code ourselves. Pair programming and review is another _thing_ entirely that has unique and useful applications.
samwestdev 5y ago
lmao you mad?
- drenvuk 5y ago
  A bit, yes.
rixed 5y ago
Haha! Don't forget the famous (although slightly apocryphal) : - "If you need a visual editor to program you are certainly stupid" (~ Ken Thompson) - "If you need a computer to enter your program into, you are not really a computer scientist" (~ E.W. Dijkstra)
atq2119 5y ago
This is a reasonable position to take, except the last paragraph is phrased too carelessly. Somebody who really cannot do any programming at all without a second person probably really is useless as a programmer, but most people will likely interpret what you wrote differently and take offense because of that.

gleenn 5y ago

Having worked many years in a place that did 100% pair programming, switching to a PR company definitely leaves things to be desired. TFA does mention feedback coming back too late in the process, and it definitely feels like the feedback timing is too late for a lot of code. I've thrown away a lot of PRs over the years for reasons that varied from not getting good info up front, to not having someone to accept the PR in busy environments, to silly mistakes. Pairing just seems like a great way to avoid a lot of nonsense. It has so many upsides like cross-pollination of ideas and skills, training, avoiding getting stuck on little snags that end up sucking up time, and so much more.

JasonCannon 5y ago
My team does Mob programming (pair programming but with more than 2 developers). In addition to all of those benefits you mentioned, we also have noticed that it helps us keep focused on the task at hand (harder to slack off when the team is all there pushing forward) and has resulted in far less bugs than before. It also results in more code refactoring than we would ever do if we worked solo.

erik_seaberg 5y ago

> The pattern which rejects Pair Programing is basically “fear” That’s fair. I’m afraid a pair won’t stop talking and I won’t get a chance to think.

Chemaclass 5y ago
The whole point is to think loud together.
- JediWing 5y ago
  and some people's brains just don't "work" like that. when someone else is talking, i try to listen, and i'll often lose my own thoughts. i also take time to put my thoughts into words, which the chattier end of people tend to take as an opportunity to speak into the void with filler, further distracting me and forcing me to try to listen, losing my thought. some people's brains don't work in a way that "thinking out loud together" is an effective strategy.
  - Chemaclass 5y ago
    That's fair enough. In such a case, I don't think pair-prog would be beneficial to apply every time for everything, certainly. However, I do think that small pair-prog timeboxed sessions might help developers to learn how to "think aloud" as a natural thing, where the goal is producing code while sharing knowledge at the same time. There are different strategies for doing pair-prog. Developers could/should change roles and not always be the same drivers/navigators, for example. I truly think pair-prog is a great practice for all developers who aim to work effectively within a team because it encourages communication between peers and a high-quality understanding of the business domain and technical knowledge.

Existenceblinks 5y ago

Those 7 fears, most are false. Just remove the word "fear", some of them are true. > Fear that they don’t know what to code or where to start. Not really a big deal, both don't know, and it's not about fear. Sometimes, we just laugh at each other, it's rather kind of funny. > Fear that others will laugh at their solutions. It's about one side blocks the other, make it slow, most of the time I have a good solution in mind already, but my politeness let the other runs, when he stuck I got a chance to interrupt "can we try this blah blah" and it's done this time. > Fear to don’t succeed in public. Not a big deal, no serious work is done during pair, it's for getting mutual understanding / agreement on something, just to make sure we are on the same page. The rest of work is done in isolate. > Fear to not be able to develop the expected solution for multiple reasons: misunderstanding the task or lack of knowledge. This one is true, I saw my team mate swam through randomly. It's ok, that's why pair programming is sometimes pointless. > Fear to change your mind in front of others. That's a sign of good thing is happening, something is getting more practical. > Fear to discuss and make decisions loud. People rather like this, shit talking like discussing works on tea table. > Fear of disagreeing with others. This is why pair programming is half-point, short-time debate is poor quality. Think longer, asynchronously, more research, and write disagreement in long form text .. on pull request.

elcomet 5y ago
> no serious work is done during pair I think that's the most important point you made. Pair programming is not for all programming, and in fact the goal is not to produce code. It's more about sharing thought processes with other people
- twic 5y ago
  When i've done pair programming, the goal was very much to produce code.
  - barrkel 5y ago
    The goal in sole programming is also to produce code. The value-add of pair programming is usually knowledge transfer, rather than code produced. And it's not just knowledge about the code being written, but work practices too.

legerdemain 5y ago

Pair programming means writing code during a meeting. If you want to avoid wasting effort on coding up an inadequate design, the solution is design docs, not synchronous meetings.

rixed 5y ago
My thoughts exactly, but I'm surprised how hard it is to change the usual code review based routine where the design is only revealed with the actual code and tests when everything is done and it's too late to discuss the premises. My best guess is that developers just love code reviews. But now that I think of it, maybe they rather loathe writing plain English. Maybe there exist some simple yet more or less formal language that could be used to write design docs?
- legerdemain 5y ago
  Everywhere I have worked, code "review" was a cargo cult of people mechanically rubber-stamping each other's changes with zero context or consideration. And these weren't particularly dysfunctional companies!
  - watwut 5y ago
    I worked in a place where it was not like that. And it was dysfunctional. Instead, people nitpicked to death and tried to one-up each other with findings. There are loooong arguments over completely irrelevant details. There were multiple rounds of review, sometimes changing the code there and back again. People attempted to code into review comments. And the expectations changed every week, there was no stable standard. It was more about taking control and showing yourself more caring by finding increasingly insignificant things and then insisting on them.
    - legerdemain 5y ago
      Code reviews are a smell.

thriftwy 5y ago

I think it ended up highlighting the importance of small, incremental PRs and the dangers of 'code bombs'.

Chemaclass 5y ago
Yes, these are the main points :)

j1elo 5y ago

I'm not sure if I'll be alone here. For me, pair programming (in ye olde times, both physically sitting together) NEVER worked out, because my brain interprets sitting there and watching someone code just the same as getting confy in a sofa and watching a Bob Ross video. My brain tries to follow along, but I cannot help it, I feel so sleepy.

sodapopcan 5y ago
That's because you're not supposed to be watching, you're supposed to be actively involved in designing and writing the code whether you are at the keyboard or not. The navigator can also manage the todos, take notes, and look things up while the driver continues on the discussed implementation.

lngnmn2 5y ago

Code-reviews and pull requests must be super because they are asynchronous, so the person is spared from unnecessary emotional load and could choose the more productive state of the mind (an appropriate time slot). Everything asynchronous (in human written communication) is just better. We, by the way, are not evolved for being constantly in the midst of a crowd.

alkonaut 5y ago

> Spot bugs. Bugs and desired behavior should be covered by automated tests. The developer is the first responsible person for this topic. Spotting bugs in PRs literally means spotting what bug exists despite the tests. A lot of the time a bug is coming from weak specification or misunderstanding of the specification. If the developer (and therefore the code) assumes that all addresses must have a postal code then the fact that people might not have a postal code is a bug present in the code. It will fail under circumstances the developer obviously didn't think about. The most difficult job for the developer is finding the holes in the specification.

knocte 5y ago

I really like this article. I'm a huge fan of synchronous feedback (pair programming) and asynchronous feedback (merge/pull requests). In my career I've always been irritated by managers that think that pair-programming is wasting time (as in, less paralleization of work). The best way to describe this situation is with an image: https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8ee4 https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8... I also liked the part where he says "Code style shouldn’t be discussed in a PR", however having the infrastructure set up to be able to avoid this is kinda hard (but we're getting there, in my company). It depends on the language, but for F# we're adopting fantomas (for automatic formatting/indentation) and FSharpLint (which has different rules which check things that the prettifier tool cannot catch). PS(offtopic): BTW if you agree with the above and are looking for remote positions, ping me at my andres@nodeffect.com (we're always hiring).

vincentdnl 5y ago
Hey knocte, thanks for sharing my drawing! :)
- knocte 5y ago
  oh hi! hehe sure :)
randunel 5y ago
Your link returns a `404: Not Found`.
- knocte 5y ago
  Ooops, I've put it here: https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8ee4 https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8...
andreareina 5y ago
I'm getting a 404 on your link.

djmips 5y ago

For particular pull requests, I like to have the person responsible go over the PR in an organized fashion, top down where they explain why they solved the problem in this particular way, then go into what they've done and finally a guided tour of the code they've added. This would involve several people on the team and they have the opportunity to ask questions and interact. For how worthwhile that is, I'm surprised it's not brought up as well. I think pair programming and regular PRs are good too but sometimes a presentation style code review is great.

coolgoose 5y ago

I'm confused on why this even up to debate. Is like discussing about desert and literally talking about appels vs pears. Different tools for different things by far.

andrewingram 5y ago

None of those "fears" reflect why I tend to be resistant to pair programming: 1. I just can't keep up with Vim wizards, they dart around a file at the speed of thought and I can't keep track of what they're doing. 2. It's too much social stimulation, which I find incredibly exhausting. Whilst I don't enjoy people watching me as I work, it's not one of the root fears for me, because I don't see pair programming as being a watching vs doing equation.

Izkata 5y ago
> 1. I just can't keep up with Vim wizards, they dart around a file at the speed of thought and I can't keep track of what they're doing. My rule of thumb when there's this level of knowledge disparity is that the person who doesn't know what they're doing is the only one allowed to touch the keyboard. That way the knowledgeable person is forced to slow down and explain until the other person actually understands what they're intending.
- LR3sRdQ 5y ago
  This is a good rule.
ryanar 5y ago
Did you mean to say pair programming instead of code review? To address your two points, it is bad form for a person driving to move too quickly. If you are not explaining your thoughts and are moving so fast that your navigator can’t follow along you are no longer pair programming and have lost all benefit. Second, social stimulation can be an issue. But it is important to take lots of breaks, and to have time away from pairing to think and work on your own.
- andrewingram 5y ago
  oops yes, editing!
- barbs 5y ago
  > it is bad form for a person driving to move too quickly. If you are not explaining your thoughts and are moving so fast that your navigator can’t follow along you are no longer pair programming and have lost all benefit. That would make me uncomfortable as the programmer, since I'd want to code at my own pace. That said, I imagine I'd necessarily slow down if I needed to explain the code, to help pin down a bug or get feedback, for example. So I guess pair-programming would be useful sometimes. I wouldn't like it if I had to do it all the time, though.

unobatbayar 5y ago

"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks Jokes aside, pair programming is purely theoretical right? No one actually does it?

Chemaclass 5y ago
I practice pair-prog not every-time for everything, but every-week with different team members and for different topics. It's up to the context and the task. The goal is to think loud and work together.
sodapopcan 5y ago
No. My team pairs as default. Usually the only reason someone will solo is when one of the six of us is busy or out of office.
ipsi 5y ago
Eh? It's definitely done in practice, and at some places it's the default, done all the time.
CRConrad 5y ago
> Jokes aside, pair programming is purely theoretical right? No one actually does it? Holy crap, where do people even get these ideas from?

zegl 5y ago

I really liked this article. At Sturdy [1], we spent a lot of time thinking about this compromise between PRs and Pair Programming when designing our workflow. I've always felt that the PR code review happens too late, and that you might be tempted to ship code that isn't perfect, as you might have spent tens or hundreds of hours in the "wrong" direction without anyone noticing. But the PR might be the first time someone else on the teams sees the code, but since you've already made the investment in building the code, you might as well ship it. You might say that you'll come back and fix it later, but that rarely seems to happen. Pair Programming on the other hand, get's extremely tricky to coordinate. The entire team needs to synchronise their schedules to be able to effectively pair program, and even then, you only get a few hours of high quality programming time together each day. We've taken the real-time aspect of Pair Programming, and the "offline" aspect of Pull Requests (no voice/video chat required) and built it into the core workflow. On Sturdy, you start by creating a reviewable "Workspace", before you even begin coding. And after that point, you're "live streaming" your code up to the workspace as you're typing (through file system watchers)! Your team mates get an up-to-date status of what you're coding on, and can continuously give you feedback when it fits their schedule. 1: https://getsturdy.com https://getsturdy.com Disclaimer: Founder of Sturdy here

eweise 5y ago
What about a third option. Write a design doc so there's feedback about the approach before coding begins?
- zegl 5y ago
  Writing design docs are a great compliment, and I like how collaborative that process can be when you're doing it in Google Docs! Writing a detailed design document takes a lot of effort/time, with diminishing returns after the first few pages, as you'll likely end up discovering new edge-cases anyways when you start hacking away on the implementation.

bob229 5y ago

Stating the obvious

brightball 5y ago

I tend to encourage my developers to pair program as a necessary part of our cross training processes. It's a good way to get people more comfortable with it. Usually I find that even the most hesitant people will start to talk about the benefits of pairing after they've done it a couple of times, especially with a more senior member of the team. People take for granted how many little things they can learn from other people that they don't expect. I've learned more IDE tricks and command line tools from pairing than I ever did on my own.

arc-in-space 5y ago
>Usually I find that even the most hesitant people will start to talk about the benefits of pairing after they've done it a couple of times, especially with a more senior member of the team. Is it possible at least some of them wanted to avoid being seen as bad team players, especially if speaking out negatively could also be seen as conflicting with a senior? Do you catch the softball if it means a higher chance of holding on to your job for longer?
- brightball 5y ago
  Not really. At least on my teams where everybody has very open communication, people are more than willing to be critical. When you see the change from people adamantly not wanting to pair, then a couple of months later asking people to pair totally unprompted it's easier to read. The way I sell pairing is just this: 1. I want everybody to be able to take vacation without the phone ringing. 2. If there's a part of the system that only you are familiar with, your phone is probably going to ring when you're on vacation. 3. Have somebody else on the team do a couple of stories/tasks on that part of the system while you pair with them for cross training to ensure that your vacations are true vacations. Vacation Oriented Pairing :-) That may only work in an environment where we go out of our way to try to prevent people from overworking though. Might not work everywhere.

T3RMINATED 5y ago

Website blocked Not allowed to browse Music and Audio Streaming category

JediWing 5y ago

> If you still feel uncomfortable having another person next to you while you write code, it might be because you aren’t particularly happy with your own code, or the process that you follow in order to achieve some result. Or the process of constant all-day interaction with another person is just personally draining for you because you're introverted / have social anxiety, or because you have to juggle multiple responsibilities inside & outside of work and don't want the scheduling or social overhead to manage the back-and-forth, or for any of a plethora of reasons besides "something about your process is flawed". This sounds a lot like "if you have nothing to hide you don't need privacy" argument. Some people just hate pairing because it doesn't jibe with their personality or work style. Draft PRs + a culture of continuous reviews accomplishes much of this without taxing people who hate pairing.

gwn7 5y ago
> Or the process of constant all-day interaction with another person It doesn't have to be "constant" nor "all-day". The OP doesn't say anything like that. No straw mans please. > is just personally draining for you because you're introverted / have social anxiety I welcome different opinions on this but I personally think that this is something to be fixed, not to be accepted. I refuse to believe that introversion & social anxiety are unchangeable character traits (at least for most people). It is not ok to be introverted nor socially anxious. But if you to choose believe that it is, you won't be able to do anything about them. As a general rule of thumb the more extrovert a person is the higher possibility of their success in life because humans are social animals. This is known. (There are of course exceptions & outliers) > or because you have to juggle multiple responsibilities inside & outside of work and don't want the scheduling or social overhead to manage the back-and-forth Yeah, this is fair. If this is the kind of situation one is in, one probably shouldn't pair program unless the benefits clearly outweigh the costs. > or for any of a plethora of reasons besides "something about your process is flawed" I see your point but I think we also need to accept that the pair programming process of a lot of companies are indeed flawed. It may or may not always be the reason but it's not wise to outright dismiss it. > This sounds a lot like "if you have nothing to hide you don't need privacy" argument. Some people just hate pairing because it doesn't jibe with their personality or work style. I understand this. It is just that I don't want to work with that kind of people because I in fact think that it is not healthy. For me it is a red flag to lack the basic social skills such as sitting together in front of the computer and demonstrating part of your programming skills in a live manner. The only way I would accept to work with somebody like that would be if they were a 10x programmer of something like that. > Draft PRs + a culture of continuous reviews accomplishes much of this No, they don't. No process can ever have the bandwidth of face to face communication so it has some benefits that no other process can offer. In the end this is not a situation where we have to choose between PRs and pair programming. The article suggests that we can and should have both. The key thing is to find the right balance, as it always is. Note: I used to be the biggest introvert & socially anxious person.

agentultra 5y ago

> Pull Requests aren’t the best tool for everything A lot of teams I've worked with have had trouble with the listed problems. They're a sign that your team doesn't understand or hasn't defined the purpose of a code-review and how to conduct them. It's also indicative, if you have comments on architectural decisions in PRs, that you have broader communication issues within your organization. Another drawback of PRs: don't make it personal. A lot of folks have a hard time with this. A shared code-base doesn't belong to any one individual. So don't say things like, "You should do this," or ask, "Why did you choose to do it that way?" A constructive suggestion is about the code and is given in the direct, imperative tense: "If this function used a higher-order function parameter here it would map over the results and remove these two intermediate bound variables and make this function more general." You're not talking about the person or asking them to justify themselves. You're collaborating on the code. Offer constructive suggestions on improving the code. Keep in mind the style guide and the other suggestions by the OP.

coscreen 5y ago

Dragan Stepanovic did an interesting analysis [1] comparing lead and wait times times of async code reviews in contrast to pair programming. His conclusion: "The optimal size of a Pull Request is one line of code which is reviewed immediately", i.e. pair/mob programming. Disclaimer: I'm biased - founder of CoScreen [2] here, a pair/mob programming tool. [1] https://www.slideshare.net/kobac/async-code-reviews-are-killing-your-companys-throughput-248758692 https://www.slideshare.net/kobac/async-code-reviews-are-kill... [2] https://www.coscreen.co https://www.coscreen.co

LR3sRdQ 5y ago

I've done pair programming for a few years now. I've done mobbing, driver-navigator, ping-pong, demo-style, etc. What I've concluded is that the level to which one will like pairing is strong correlated with their personality. For me, pairing with someone that's at my skill level is a good time _assuming that we share most of the same core ideologies_. Pairing with someone that's at my skill level where it's a constant give and take is annoying, but still tolerable. Pairing this way saves a lot of time compared to fighting inside of a pull request (which can definitely happen). Pairing with someone that's far from my skill level, to the point where they're basically typing for you (apparently this is called _backseat navigator_, which is honestly a great name for it), is incredibly mentally taxing. Doing that for an entire day is really, really tough. Coordinating times is also an issue while pairing. Assuming core hours allow, I generally like starting my day between 11am-12pm and ending at 7-8pm. This basically doesn't work for people with families or early birds, but you don't know whether your pair is any of these going in. This is even worse if you're pairing with someone multiple time zones away. So pairing is almost always going to be a huge compromise against time preferences that can be avoided by relying on Slack/Teams and pull requests. Generally speaking, though, I much prefer writing code by myself, communicating through Slack, documenting like a madman, and doing code review through pull requests.

CRConrad 5y ago
> Coordinating times is also an issue while pairing. Assuming core hours allow, I generally like starting my day between 11am-12pm and ending at 7-8pm. [ ... ] This is even worse if you're pairing with someone multiple time zones away. Depends on which way the difference goes, doesn't it? If it happens to be two to four hours "the right way around", it would put you on track with someone observing "regular office hours" in their time zone.