Pull Requests vs. Pair Programming
chemaclass.es
chemaclass.es
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.
+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!"
I suspect this is the exception that proves the rule, not really an alternative rule.
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.
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.
> 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.
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.
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.
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.
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.
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.
With pair programming though, you're not coding at your own pace; you're solving a problem with a colleague and occasionally writing a bit of code. It should be mostly talk - and if there's a bit of grind work coming up, that's when you part ways.
> I wouldn't like it if I had to do it all the time, though.
Few people do, it costs a lot of energy to do social stuff - unless you're extroverted and energized by the social aspect of it.
> That would make me uncomfortable as the programmer, since I'd want to code at my own pace.
OK, but then that's not pair programming. It's you programming with someone watching.
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
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.
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.
> 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.
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
The idea that pair programming is mainly a teaching / learning mechanism is very widespread, but it's a profound misunderstanding.
I've never used pairing, nor seen it used, other than as a way of helping get someone up to speed on a task in an area or process unfamiliar to them.
Seems to me that it has suffered the same fate as so many other original "Agile" practices: The image of them nowadays is gravely distorted, sometimes to the extent of being a caricature, of what they originally meant.
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.
I think this is where your impressive work is done, coding is just a chore, pair or not.
Regardless, pairing helped us keep the code quality up and defects low, as well as making sure everything was properly tested and all corner cases were being dealt with. It of course also helped make sure we both understood every aspect of the code.
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"
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?
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.
Code reviews can be a good thing or bad thing, depending on what each party brings in and intends to get out of them. Painting them unequivocally as bad is rather silly.
This is not necessarily in conflict with your statement.
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.
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.
Disclaimer: Founder of Sturdy here
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.
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.
That’s fair. I’m afraid a pair won’t stop talking and I won’t get a chance to think.
some people's brains don't work in a way that "thinking out loud together" is an effective strategy.
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.
Jokes aside, pair programming is purely theoretical right? No one actually does it?
Holy crap, where do people even get these ideas from?
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.
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.
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).
Thanks for the heads up.
What is the second sentence saying? I can't parse it at all.
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.
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...
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.
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?
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.
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
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.
Different tools for different things by far.
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!".
It's an absolute joy. Every one of my guys says it's much more enjoyable and productive than working solo.
Outside of that, things have been running smoothly.
(Also, we're hiring if you are a fullstack dev)
Sounds amazing, though, maybe I can get some of this implemented in my current position.
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
As others explained, it is common usage in American English.
The bigger problem to many contemporary readers may be the (I am sure unintentional) sexism in the phrase "my guys".
Instead of "Every one of my guys says", another way to say it would be "Everyone on my team says". Or maybe even better, "My teammates all say".
Of course we have to keep in mind that these are all just late night off-the-cuff comments, so some gaffes may be expected and accepted.
Edit to address the thoughtful replies below: I think whether "guys" is gender neutral or not depends on the context and culture. Informally and in personal conversation, sure, if the "guys" in question don't mind it. Here on HN, doesn't matter too much. In formal writing or business communication, it would be something to avoid.
I generally try and be mindful of stuff like that, and were there any women on my team I wouldn't have used guys. Unfortunately covid plus unrelated personal issues caused the only woman on my team to have to resign last year. I do sincerely hope I can get some women to apply this hiring round, because diversity is important to me.
I would interpret some one saying "my guys" in this context as a sign of respect. It can be roughly understood to mean "my go-to guy." It has the connotation of a well established, high-trust, working relationship.
For example, if I needed to get my car serviced and someone was trying to pitch me different mechanics I would say, "I got a guy" to indicate that I already feel looked after.
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.
I guess this can work only on rather small teams though. What's the cardinality of that mob of yours ?
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?
The issue we do have is that sometimes myself and my other senior dev end up Navigating too much, leaving our more junior developers to not contribute as much. When I catch ourselves doing that I'll just ask the other sr dev to step back for a little bit and allow the others to step up.
We use Zoom for cross discipline meetings (and nearly everyone has camera on most of the time, though there’s no explicit rule) but discord+drovio for remote pairing. Discord has been nice for the ability to drop into another pair to ask for help, or for non devs to know who is pairing and drop in as well.
One other thing I’ve noticed is that some team members play music in their headphones while pairing/mobbing. While the others can’t hear it, it’s certainly not helping our communication or focus… and it certainly feels disrespectful to me.
We thought it was going to be exhausting like you said, and one of our guys even brought up that he was very introverted and didn't know if he would be able to do this. To our surprise, the days go by faster (not just because they are shorter), we get done with more work than we did before, and although yes we are tired after working all day, we all look forward to doing it again the next day.
It's true, mobbing isn't for everyone. But for us it couldn't have worked out better.
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.
"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.
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.
- "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)
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.
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.
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.
Does anyone really go to that much effort just so they can be offline?
Don't get me wrong, if I was going to a remote place without internet and needed to do some coding there, your suggestions make sense, even though I think there are pitfalls to that approach as then you're working off "static data/comments,etc" which might require further context or more recent context, which you'll need the Internet for.
How is having their source code impractical? You should have downloaded it anyway.
The only one that might seem extreme is downloading the SO dbs. I have done this because I stay offline so I can better focus. Not everyone (probably very few) will reach that point.
I think you're overblowing how recent the information you require is tbh. You can get a lot done with months old information.