Pull Requests vs. Pair Programming(chemaclass.es)
chemaclass.es
Pull Requests vs. Pair Programming
https://chemaclass.es/blog/pull-request-vs-pair-prog/
150 comments
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.
It's an absolute joy. Every one of my guys says it's much more enjoyable and productive than working solo.
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?
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?
We don't have that issue really. We do remote mob programming (all day long zoom call + https://mob.sh/ ) so we see everyone while we work.
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.
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.
Thanks for the response! I guess the big difference is being on camera. My team has been 100% remote of course since Mar’20, and split across SF and Toronto for the most part.
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 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.
I've done all day Zoom/VC mobs, and that sounds exhausting as hell to me. Different strokes and all, but programming this way really takes the fun out of it.
We solve this three ways. 1. We don't do a full 8 hour day, 2. We take breaks every hour, 3. we keep it entertaining by joking around with eachother while we work.
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.
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.
Yeah I find that I can remote pair for maybe 5-6 hours a day. Catching up on non pairing work things (email and slack and whatever) takes another hour or two, and I’m beat by 4 or 5.
What's the distribution on that? One coder N navigators? Half coders half navigators?
One person on keyboard, everyone else calling out code (we have 4 devs on the team currently). We switch positions every 15 minutes.
That sounds awesome. I imagine being stuck doesn't happen often, so frustration would stay very low.
Exactly. And when we do get stuck, we have everyone working on the problem together, so it doesn't happen for very long. The only time the team really got frustrated was due to a mysterious memory spike that pops up at the most inopportune of times, and we had to spend a long ass time investigating it (orders of my boss) so all work ground to a halt other than banging our heads trying to figure it out (to no avail).
Outside of that, things have been running smoothly.
(Also, we're hiring if you are a fullstack dev)
Outside of that, things have been running smoothly.
(Also, we're hiring if you are a fullstack dev)
Sadly, I'm fully remote and have no interest in moving to Seattle.
Sounds amazing, though, maybe I can get some of this implemented in my current position.
Sounds amazing, though, maybe I can get some of this implemented in my current position.
"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
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
Yeah, there’s nothing wrong with “my guys”, at least not with the possessive pronoun. You would say “my team”, “my employees”, “my direct reports”. You’d also say “my boss”, if that helps with your sense of internal conflict over this.
Haven't thought of "my boss". Sure it helps, thank you :)
Not an English native as well, but in my language it works in the same way. "My" is used to designate possession of the set, not of the individuals. I don't own "my friends" as a slave owner, they are "my friends" because that is my personal set of friends among all possible sets of people.
You're not wrong to wonder about this, and even if it's off topic, I appreciate your asking about it.
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.
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.
Is "guys" gender-neutral in some contexts? Maybe specific to some areas? It seems used by women for designating women at times.
“Guys” in my experience is just as gender-neutral as “teammates”, “people”, “folk”, etc. I’d address a group of all women as “guys”, e.g. “hey guys, you alright?” And if someone else used the word referring only to men I’d probably not clock that unless they clarified after
"I'm going to a club to watch some guys taking their clothes off". Gender neutral?
I mean, yeah, but its awkward and unnatural phrasing. Try "I'm going to a club to watch some folk taking their clothes off", or "I'm going to a club to watch some teammates taking their clothes off" as well and see how unwieldy and cumbersome they are.
>(I am sure unintentional) sexism in the phrase "my guys".
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 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.
Native English speaker here.
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.
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.
[deleted]
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.
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 wouldn’t want t program like that, but everyone is different and teams tend to hire for culture fit, and thus “thier style”
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.
What sort of problems do you find yourself using this for?
We do it for just about 100% of the time now. Only two exceptions: 1.) We have a second project we are ramping down on that only myself and 1 of my devs is trained on, so when we have to do anything with that he breaks off to do so. 2.) When bugs creep up that I can quickly solve, I'll do so as to allow my team to remain focused on our current system wide rewrite. Other then that, we do everything as a team.
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 ?
I guess this can work only on rather small teams though. What's the cardinality of that mob of yours ?
You are correct that we are a small team. I have 4 devs. We are hiring 2 more right now and the plan then would be to coordinate 2 mobs/teams. I generally believe a team should be between 3-5 people.
[deleted]
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.
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.
>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.
What is the second sentence saying? I can't parse it at all.
basically means a PR is when the feature is done. you're not asking for code ideas, you're proposing a finished change.
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.
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.
What are the benefits of a draft PR over publishing a feature branch that others can access?
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.
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.
Yes, that was what I meant. Thanks.
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]"
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.
it's missing a 'd'.. should be 'already changed proposal..'
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.
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.
> 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!"
+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!"
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.
I suspect this is the exception that proves the rule, not really an alternative rule.
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.
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 :)
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.
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.
>>> 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.
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.
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.
agree)) same with me
sort of like run time vs compile time
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.
"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.
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.
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.
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)
- "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)
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.
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.
> 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.
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.
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.
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.
To be honest you just seem to be coming up with impractical/unrealistic and idealistic counter arguments.
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.
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 mocking services impractical? You have to do it anyway for tests.
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.
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.
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.
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.
> 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.
That’s fair. I’m afraid a pair won’t stop talking and I won’t get a chance to think.
The whole point is to think loud together.
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.
some people's brains don't work in a way that "thinking out loud together" is an effective strategy.
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.
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.
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
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
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.
> 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.
> 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
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
When i've done pair programming, the goal was very much to produce code.
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.
Not the way it's been sold to me. The goal is precisely to produce code, more effectively than two devs would individually, because a concurrent second pair of eyes avoids blind alleys and problems that would otherwise take a handoff to spot, and handoffs are efficiency tarpits. Knowledge transfer is an unavoidable beneficial side-effect, but it's not the point.
The goal of pair-programming in XP is to produce better code, faster.
The idea that pair programming is mainly a teaching / learning mechanism is very widespread, but it's a profound misunderstanding.
The idea that pair programming is mainly a teaching / learning mechanism is very widespread, but it's a profound misunderstanding.
I don't honestly care tuppence for XP. It was an interesting revolutionary position in the mid 2000s, but an historical artifact now.
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.
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.
FWIW, although I only ever got to do very little pair programming (and it's long ago now), from all I heard about it (and the way it worked for us when we used it), I've got the same impression as regularfry and twic: It's at least as much about the actual code produced as any knowledge transfer.
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.
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.
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.
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.
We do mob programming at my company, but do so 100% remote. We do it via zoom for screen share, and use https://mob.sh/ for handling the quick code handoff between drivers.
> We designed on a whiteboard
I think this is where your impressive work is done, coding is just a chore, pair or not.
I think this is where your impressive work is done, coding is just a chore, pair or not.
I agree, I've commented this exact things on the Copilot discussions: that the actual programming isn't the hard part.
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.
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.
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"
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"
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.
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?
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?
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!
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.
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 are a smell.
Not wanting someone to review your code is a bigger smell, IMO.
Code reviews are one of the very few software practices that there's good evidence in favour of.
This is not necessarily in conflict with your statement.
This is not necessarily in conflict with your statement.
"Only children and fools speak in absolutes." -someone, somewhere, I don't remember.
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.
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.
Oops, and I thought civil engineering was messy. Time to switch back to civil engineering, at least it is, more civil than this.
I reckon if you have all senior developers, and design considerations are being dealt with / communicated about in other places (e.g. ahead of time, before the code is written). Then this is largely how things should go: a quick once over to try and spot obvious mistakes. I've worked in companies where code review was like this and it worked pretty well.
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.
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 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"
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.
I worry you missed the "documenting tacit knowledge is extremely difficult" part. Tacit knowledge is notoriously hard to document in a way that successfully transfers the knowledge from one person to another. Pair programming is at least an order of magnitude more effective, if not more.
If two people build a feature, two people are slowly forgetting how and why until they move on, and nobody else gets it at all. It is easier than documentation (which I agree is hard enough to more than double the dev time), but it only postponed the problem a little without solving it.
I think it ended up highlighting the importance of small, incremental PRs and the dangers of 'code bombs'.
Yes, these are the main points :)
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.
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.
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.
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.
> 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.
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.
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 [email protected] (we're always hiring).
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 [email protected] (we're always hiring).
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.
Your link returns a `404: Not Found`.
Ooops, I've put it here: https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8...
I'm getting a 404 on your link.
Oops, I've put it here: https://gist.github.com/knocte/5d189a822dd139ccdf30b3c633fc8...
Thanks for the heads up.
Thanks for the heads up.
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.
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.
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.
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.
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.
> 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.
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.
> > 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.
OK, but then that's not pair programming. It's you programming with someone watching.
> 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.
> That would make me uncomfortable as the programmer, since I'd want to code at my own pace.
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.
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.
oops yes, editing!
>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
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
> 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.
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.
This is a good rule.
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.
Different tools for different things by far.
"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?
Jokes aside, pair programming is purely theoretical right? No one actually does it?
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.
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.
> Jokes aside, pair programming is purely theoretical right? No one actually does it?
Holy crap, where do people even get these ideas from?
Holy crap, where do people even get these ideas from?
Eh? It's definitely done in practice, and at some places it's the default, done all the time.
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
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
What about a third option. Write a design doc so there's feedback about the approach before coding begins?
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.
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.
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.
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.
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.
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!
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.
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.
>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?
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?
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.
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 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.
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.
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.
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.
gwn7(1)
> 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.
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.
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
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
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.
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.
> 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.
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.
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!".