71–80 of 82 posts
Pair programming can be very useful when you're training someone new or starting up a new project and want to spitball ideas. I was offered a position with full-time remote pair programming. That sounds like a nightmare to me and opted out of that one.
I said no to an opening like that as well. I have no problem doing it from time to time, doing it every day sounds like a total nightmare
Earlier quoted context omitted.
My other point is that pair programming is a learned skill. If you just put two unprepared programmers by a computer, you'll most likely end up with two annoyed programmers, and not great code. This is a popular argument among pair programming enthusiasts, which suggests there may be some merit to it. How do we reconcile it with another popular argument, that many programmers will naturally pair up on an ad-hoc basis…
> How do we reconcile it with another popular argument... I don't think I've heard this argument, and I haven't observed programmer behavior in the wild :) I'm happy working solo 1 day a week or so, to do things maybe only I care about, or explore/learn things. Pair programming certainly isn't for everyone, but don't knock it until you've done it for a few weeks, hopefully with some good pros! I've never learned so m…
I don't doubt that you can learn a great deal and obtain other benefits as a result of pair programming. I'm just questioning whether making it a formal, quasi-full-time arrangement is necessarily better than the ad-hoc version I see happening all the time for similar reasons and with similar benefits.
Being forced to pair program all the time blows (IMHO). It's just too rigid. I was recently paired with another guy way below my ability. Great for him, not so great for me. PP is amazing when you and a co-worker decide to pair because it's the perfect approach for a problem you're trying to solve, or because one of you needs help figuring something out.
Better yet tell him to just stay home and get the job done right.
I work at a company that does full-time pair programming whenever possible. There can be drawbacks for sure, but overall, I love it. However, one caveat is that our hiring process places emphasis on finding people that are collaborative and easy to work with as opposed to know-it-all "rockstar" developers. We also do test-driven development, so in addition to the most common pattern (driver / navigator) we sometimes…
I've seen the following from pairing Junior and Senior engineers: * Really talented junior engineers blossom extremely quickly. They will easily be a multiple better after a year vs not pairing. * Middle of the road junior engineers can be stunted and continually depend on the decisions / skill of the more senior pair. Pairing them more frequently with same level or lower helps. Sometimes this doesn't happen because…
Even if it was scientifically the fastest and best way to program (engineer productivity is unmeasurable so we'll never know) there's still a huge number of developers who will hate it for a number of reasons. They are all valid and no one should be forced to do things they hate if they can add similar value some other way.
Now there are certainly times when it is very valuable to do collaborate, such as rubber duck debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging or mentoring or simply doing a 'desk check'. But these are the exceptions, not the rule. Having someone breathing down your neck or be a back seat driver all day is at best a waste of productivity, forcing the driver to think at the pace of the observer, and at worst, a complete waste of time and effort.
- 2 seniors tackle hard problems
- 1 senior and 1 junior is good for teaching the junior
- 2 juniors together is a recipe for disaster.
I imagine this could be chain-gang hell for introverts. I've always wondered if the people who move into decision-making spots are extroverts, who then go on to make decisions affecting introverts, like open-plan seating.
It definitely is. What happened is software paid so well that people who can talk more than think, which is the vast majority of people, crowded it out.
1 Manager 1 Scrum Master 1 Team Leader 2 Regulars 1 Expert
TL;DR Experts quit max after one year and teams are left with 3 regulars dying inside to keep stuff working.
ps. When mentioned that we have too many middle managers - instant push back - coz they all cover each other, fearing someone will fire them if not. Worst part is those people have zero technical knowledge and make stupid decisions based on things they have seen on PowerPoint presentation. Last such a stupid idea was to move our platform from stable AWS environment to crappy/buggy Azure ecosystem. (simply because one of managers most likely got paid under the desk to push company into this direction). After losing over 1Million Euro on Azure we scrapped this idea..
Earlier quoted context omitted.
> How do we reconcile it with another popular argument... I don't think I've heard this argument, and I haven't observed programmer behavior in the wild :) I'm happy working solo 1 day a week or so, to do things maybe only I care about, or explore/learn things. Pair programming certainly isn't for everyone, but don't knock it until you've done it for a few weeks, hopefully with some good pros! I've never learned so m…
I've literally never worked for any employer in any development role where spontaneous pairing or larger group collaborations didn't happen often. It's just human nature. I see others commenting in this very discussion with similar anecdotal experience, so apparently I'm not just completely weird in this respect. I don't doubt that you can learn a great deal and obtain other benefits as a result of pair programming.…
Sure, people help each other in various ways in most places. But that's the solo programmer on a task asking someone else for help. Two people work on a something together, from start to finish, is a quite different thing