Pull Requests vs. Pair Programming

https://chemaclass.es/blog/pull-request-vs-pair-prog/

by Chemaclass • 5 years ago

87 144 5 years 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• 5 years 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• 5 years 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.

Chemaclass7• 5 years ago

Yes, that was what I meant. Thanks.

animal_spirits• 5 years ago

It [a pull request] is an "already change proposal [I have already worked on this change, here's the code] to be merged into the current system [someone please look it over]"

jstanley• 5 years ago

I think perhaps it should say "all-ready" rather than "already", in the sense that the "change proposal" is "all ready". Although it's still quite a clumsy sentence even then.

fouc• 5 years ago

it's missing a 'd'.. should be 'already changed proposal..'

gregmac• 5 years 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.

rpastuszak2• 5 years 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.

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!"

svieira• 5 years ago

Counterpoint: I've reviewed multi-thousand line PRs (with dozens of commits) ... those took me days of 8 hour review, with multiple issues found. (To be fair, when I first skimmed it, it looked great to me, but a deeper dive found lots of things that could be improved.) These kinds of large PRs was how the gentleman I worked with did pairing and it worked out pretty well (surprisingly, don't try this at home).

I suspect this is the exception that proves the rule, not really an alternative rule.

Cthulhu_2• 5 years 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.

Chemaclass7• 5 years 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 :)

Justsignedup• 5 years ago

I added linters and prettier. We don't have this discussion.

Anything that isn't important I prefix with nitpick and my team knows to ignore if they want to.

Actual feedback should be based on functionality.

Having said that, sometimes pair programming helps. It sucks when you're remote. And it really sucks when you have tiny tiny desks as is the new startup trend.

I honestly miss nice big cubicles. Say what you will, they served a great purpose. Every eng I knew with a nice big cubicle had a 2nd keyboard for the other person that sat in.

ngc248• 5 years 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.

True, Why is code being written without the architecture and initial design hashed out?

Do an initial high level design, discuss with your team, hash out any issues, then start with the implementation.

The PR code review should be a review of the implementation and not the design.

razeonex• 5 years 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• 5 years ago

agree)) same with me

M2Ys4U• 5 years 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!".

JasonCannon11• 5 years 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.

djrockstar1• 5 years ago

What's the distribution on that? One coder N navigators? Half coders half navigators?

rpmisms2• 5 years ago

That sounds awesome. I imagine being stuck doesn't happen often, so frustration would stay very low.

rixed5• 5 years ago

"your" guy?

Might be just me, or might be because English is not my native language, but the use of possessive to designate people who work with you (albeit in a position that feels like it's inferior on some org chart) always sounds patronizing to me. Does it really not in English ?

Not against you personally, I just could not keep this feeling within for longer.

/out-of-topic

makeitdouble• 5 years 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.

ehnto• 5 years ago

What sort of problems do you find yourself using this for?

rixed5• 5 years ago

I, for one, would like to work on a team where everyone is working at the same thing, as opposed to everyone working in isolation on its own slice of the problem before figuring out how to assemble the slices eventually.

I guess this can work only on rather small teams though. What's the cardinality of that mob of yours ?

ohwaitnvm3• 5 years ago

I’ve been pairing at all but one of my jobs in the last ten years, and love it, but I found mobbing to almost always be a driver, a half engaged navigator, and a third basically napping or distracted by a smartphone.

The devs in question were experienced in pairing and happy to do it, but I pretty much always found adding more than a second head was effectively net neutral if not negative.

So I’d love to learn how to make mobbing better for the rare times it comes up. What do you have to change or be more disciplined about to make mobbing a net gain?

jseban• 5 years ago

Yeah you can never get away from the fact that programming is best done in isolated concentration, and then occasionally gathering in a group to share insights/gather feedback. Just like academia and every other field that requires concentration and deep thought. If pairing would be effective, why don't people do this in other knowledge jobs, it's incredibly frustrating, exhausting and wasteful, just another attempt to dumb down programming to assembly line factory work. The little knowledge sharing that you get is much better shared in different ways.

I prefer to pair up when there's a decision that needs to be made, or when stuck. This can be much better to work on by two people, to get a second opinion or a fresh pair of eyes. But as soon as this is resolved and the path forward is clear, I immediately stop pairing and go back to work individually, because it's much better.

ZhangSWEFAANG• 5 years ago

sort of like run time vs compile time

drenvuk4• 5 years 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.

samwestdev• 5 years ago

lmao you mad?

drenvuk4• 5 years ago

A bit, yes.

dgb23• 5 years 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.

rixed5• 5 years 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• 5 years 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.

_hu6p2• 5 years ago

If you need the internet to program you're similarly useless.

This seriously depends on the complexity of the task, the software you're using, how good your memory is and how confident you're in what you write.

Let's say you're using an API of a third party solution... you need Internet.

Let's say you're using a new framework/plugin you need to read documentation for it (and yes, you can download it, but then you incur the risk of it being outdated or missing something...).

There's so many other instances where you need the Internet if you want to end up writing good code. There's also instances you don't... but yeah in the long run you do need the Internet / live documentation / ability to search for bugs, problems and troubleshoot with "latest" information available as oppose to the 10month dusty documentation PDF you got sitting on your machine.

drenvuk4• 5 years ago

1. Of course you need the internet if you're hitting an api but the docs will get you to the point you can test it yourself without internet access by mocking their services.

2. If you're using a new framework or plugin you should have the source available in addition to the documentation. That should tell you all you need. 10 month "dusty" documentation means you're working with unstable code. If you don't have the source to inspect then you have other issues, the first being the proprietary code inflicted mess that you have to deal with.

3. You can download the stackoverflow databases of the topics you deem important and search through them.

My bet is that you haven't really even tried.

gleenn• 5 years 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.

JasonCannon11• 5 years 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_seaberg3• 5 years 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.

Chemaclass7• 5 years ago

The whole point is to think loud together.

JediWing2• 5 years 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.

98lenvi• 5 years 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

Existenceblinks3• 5 years 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• 5 years 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

twic2• 5 years ago

When i've done pair programming, the goal was very much to produce code.

dkersten2• 5 years ago

I had a very positive experience with pair programming on a project for about ten months. We (myself and one other guy) definitely did serious work. We built and delivered a complex piece of well tested software that is now running on aeroplanes (non safety-critical software). It was also a distributed system, adding to the complexity, where some parts run on AWS and some on the planes, communicating over satellite internet (which may or may not be available).

We did it because we decided it would be the most effective way to work. There were only two of us on the project, so it was very important that both of us understood all aspects of the design and code. It was important to us that we spot issues early and that our test cases were comprehensive (we also used generative property-based testing to find actual bugs, which included simulating network errors, crashes etc).

We designed on a whiteboard, then we would pair to implement it. We worked remotely about 50% of the time (using ScreenHero to do remote pair programming. I miss ScreenHero). Yes, the goal was to share thought processes, but it was also to produce high quality code, spot errors, come up with edge cases and tests. And to document everything.

Personally, it was one of the most successful projects I ever worked on. The pair programming was exhausting, but very effective.

Existenceblinks3• 5 years ago

I'll add more funny story to my own comment above.

My boss usually pings me to do pair programing with him when:

- He wanted to write some half-thought codes he also wants me as co-author to it (literally 2 names on git commit)

- He wanted to do some dangerous things on production DB, he wanted me to be his witness, in case something went wrong, I would also share some guilt

It's really funny I would call this "pair responsibility"

legerdemain3• 5 years 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.

rixed5• 5 years 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?

legerdemain3• 5 years 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!

TameAntelope3• 5 years ago

Pair programming is a way of transferring tacit knowledge that's literally an order of magnitude more effective than trying to document that tacit knowledge, mostly because documenting tacit knowledge is extremely difficult.

But ultimately it's a culture thing -- if you're hired into a culture that values pair programming, you're hurting your team by not also valuing pair programming, and vice versa (you can't make a bunch of introverts enjoy spending hours with someone giving them guidance over their shoulder).

Honestly, being an introvert here is a hinderance to growth; it's vastly superior to run through a problem as a pair when someone has better knowledge about that problem than you do.

corpMaverick• 5 years ago

I had to google this one. "Tacit knowledge is the intelligence we have that is gained through the personal and professional experience you've learned both in your current role and previous jobs. It's the knowledge that's difficult to explain and challenging to document"

erik_seaberg3• 5 years ago

Pairing for knowledge raises the bus number from one to two, which doesn’t help for that long in the current market for devs. Documentation is what endures.

thriftwy• 5 years ago

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

Chemaclass7• 5 years ago

Yes, these are the main points :)

j1elo• 5 years 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.

sodapopcan4• 5 years 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• 5 years 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• 5 years 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.

knocte4• 5 years 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/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).

randunel• 5 years ago

Your link returns a `404: Not Found`.

knocte4• 5 years ago

Ooops, I've put it here: https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8...

andreareina• 5 years ago

I'm getting a 404 on your link.

knocte4• 5 years ago

Oops, I've put it here: https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8...

Thanks for the heads up.

andrewingram3• 5 years ago

I feel like if I ever succeed in getting a manager to realise that a team of 3 engineers doesn't mean you can/should do 3 pieces of work in parallel, I'll have achieved a great thing.

vincentdnl• 5 years ago

Hey knocte, thanks for sharing my drawing! :)

knocte4• 5 years ago

oh hi! hehe sure :)

djmips• 5 years 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.

andrewingram3• 5 years 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.

ryanar• 5 years 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.

andrewingram3• 5 years ago

oops yes, editing!

barbs• 5 years 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.

rpastuszak2• 5 years ago

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.

Precisely, pair programming is mostly about reducing the feedback loop and leveraging different modes of thinking (low- vs. high-level, driver vs. navigator[1]). I think this is just one of the things that are a bit hard for people without pairing (or XP) experience to grok.

How this looks in practice: https://sonnet.io/posts/snakes/

[1] https://martinfowler.com/articles/on-pair-programming.html

Izkata• 5 years 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.

LR3sRdQ3• 5 years ago

This is a good rule.

coolgoose• 5 years 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.

unobatbayar• 5 years 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?

sodapopcan4• 5 years 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.

Chemaclass7• 5 years 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.

ipsi• 5 years ago

Eh? It's definitely done in practice, and at some places it's the default, done all the time.

CRConrad4• 5 years ago

Jokes aside, pair programming is purely theoretical right? No one actually does it?

Holy crap, where do people even get these ideas from?

zegl2• 5 years 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

Disclaimer: Founder of Sturdy here

eweise• 5 years ago

What about a third option. Write a design doc so there's feedback about the approach before coding begins?

zegl2• 5 years 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.

brigandish3• 5 years 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.

sodapopcan4• 5 years 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.

brigandish3• 5 years 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.

brightball2• 5 years 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• 5 years 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?

brightball2• 5 years 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.

JediWing2• 5 years 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.

underbluewaters• 5 years ago

Programming is one of the few professions where one can be very successful as an introvert, working in a manner that is compatible with my personality type. I think it's great that there are other methodologies for people with different preferences but I hope pair programming doesn't start to be seen as a "best practice" that is forced on all teams without acknowledging these personality differences.

CRConrad4• 5 years ago

In a way I think it is a "best practice": It's a pretty central part of "Extreme Programming", which was one of the early sparks that ignited the whole "Agile" movement. And from what little I've gotten to do it, it really is an effective way to code, so I'm all for it... But yeah, I'm probably pretty extrovert, so easy for me to say.

I don't know how, exactly, but it seems to me finding some way to get this to work also for the more introvert among us should be a pretty high priority on the methodology front.

agentultra• 5 years 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• 5 years 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-kill...

[2] https://www.coscreen.co

LR3sRdQ3• 5 years 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.

CRConrad4• 5 years 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.

Pull Requests vs. Pair Programming

Related Stories