171–180 of 308 posts
Earlier quoted context omitted.
Pairing is a decision made between two devs, not as a team or company, imo.
I've never seen or even heard of a place where pairing is optional. I've only ever seen it compulsory or forbidden.
Earlier quoted context omitted.
The only way I've seen this kind of situation come about is if pairing isn't forced. "Forced" means leadership encouraging at every opportunity, ham-handedly, without considering context. If there isn't an extreme investment by leadership, badly-executed pairing will ensue, form what I've seen.
Pairing is a decision made between two devs, not as a team or company, imo.
Earlier quoted context omitted.
I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.
I despise code reviews, because the criticism is shallow, and offered too late, after the work has been done. I want the review in real time, and at a greater depth of insight. This is what pairing provides.
At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved.
I also found it a great way to catch subtle bugs or difficult to follow logic. But it does require actually having and taking the time to carefully review things, rather than giving them a passing glance.
Pair programming generates visceral responses due to it being introduced as if it were fact, which for me always triggers my spidey senses. People who didn't like it were told "you're doing it wrong" or "you didn't give it a proper chance". Dismissing criticisms out of hand only furthers distrust, regardless of the actual value of the idea. I played along and paired for awhile, but now steadfastly refuse to pair, eve…
I’ve always encourage pair programming solely as a team cross training exercise and only for short stints. Aka - Bob built a system using tooling that is new to our team and unknown to anyone else. Bob needs to pair with Fred for a couple of hours so more than just Bob will have hands on experience with the tech. That’s my only requirement because in my experience it’s better than documentation and it’s a requirement…
Earlier quoted context omitted.
I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.
...although some people might argue that you could get the same value from a rubber duck ( https://en.wikipedia.org/wiki/Rubber_duck_debugging )
Rubber ducking is great for forcing yourself to articulate your train of thought, spelling out your assumptions, and proof-reading your own logic.
Code reviews are great for catching errors you glaze over because you're too familiar with what you think you wrote to see what's actually written. It's also a great way to onboard people and enforce code standards and best practices.
Even when you're in a more senior position code reviews can often teach you new things, when you interact with systems the reviewer knows better and they happen to know a better approach.
Earlier quoted context omitted.
I don't agree. I wrote a top-level comment about my (positive) experience pairing, but I'll state it again here because its relevant to your comment: I was on a team with one other guy working on a complex distributed-systems project. We were both principle engineers at the company. We delivered the project in under a year and as far as I'm aware from talking with former colleagues, the code is still in production wi…
I just can't fathom that. How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work. Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or…
This is a very common misconception. Both of you are "working", only one of you is typing. I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. Both people are doing these things, except you're both doing them on the same task. That means that the task is often done faster, but much more importantly, its done better and the wins really rack up in the long run: you get knowledge sharing for free, you make less mistakes, better designs, write more robust software, better tests (because you have a second person to make sure they're good), have two people working on documentation etc. We ship more complex projects, with fewer errors, better documentation in less time.
> I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work.
How much of your programming is actually typing into a text editor? Maybe I'm working on different types of code as you, but for me, design/planning and problem solving is takes up about 80% of my "programming time". As I said above, not only is this faster with two brains working on it, but the results are better too.
> Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
Sure. The difference is that you're doing it all the time. Which has the benefits I mentioned above, at the cost of.. its a mentally exhausting way to work.
The project I worked on with pair programming was a large complex distributed system to deliver large amounts of data to fleets of airplanes over satellite internet (among other means), with guaranteed delivery SLA's. It took two of us 11 months from start to deployment. I've worked on simpler projects without pair programming that took longer. I don't work there anymore, but last I checked, it was still running in production without problems. I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.
You can't operate indefinitely this way as an introvert, it's physically impossible. Extroverts simply can't comprehend how impossible this level of interaction on a daily basis is for an introvert. Programming is an inherently internal process which is introversion, and naturally draws people that lean more towards introversion to this field. I'm not dismissing the benefits of pairing, but to do it while completely ignoring the needs of the target audience (predominately introverts) is ludicrous and of course this burns people out.
Introverts, to varying degrees, expend energy in the presence of other people. They have to be alone to recharge. There is often a misunderstanding that introverts are just shy, this is a fundamental misunderstanding. Shyness often accompanies introversion but they are fundamentally different aspects.
Extroverts are the opposite, they gain energy when interacting with others. Most people are some form of omnivert, certain interactions can drain them and other interactions can give them energy.
No matter how beneficial pairing is it will fail if it doesn't learn to adapt more to the needs of the core user: introverts.
Earlier quoted context omitted.
I despise code reviews, because the criticism is shallow, and offered too late, after the work has been done. I want the review in real time, and at a greater depth of insight. This is what pairing provides.
Shallow and too late criticism sounds like a problem with how the reviews are handled. At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved. I also found it a great way to catch subtl…
The emotional labour involved in managing colleagues (especially those who are less experienced) all day every day is so intense I could barely function outside of work. Steering people towards solutions when they were hung up on irrelevant stuff, explaining things to people who were themselves exhausted in the same way I was, remaining engaged when my screen share was hijacked yet again by someone who "just" wanted to show me something.
I have no idea how the author lasted so long. It took me less than 100 days of pairing (partly through a northern English winter) to quit.
Added to the above, the 'standard' Zoom caveats apply, too: https://www.bbc.com/worklife/article/20200421-why-zoom-video...
Earlier quoted context omitted.
Pairing is a decision made between two devs, not as a team or company, imo.
I've never seen or even heard of a place where pairing is optional. I've only ever seen it compulsory or forbidden.