I spent the first fifteen months of my current job on a 100% pair programming team before transferring to a more traditional scrum-based team.
Some observations: team cohesion on the pp team was much higher, code quality was higher. Flexibility, not surprisingly was lower: we had a very fixed schedule: "Stand up" at 8.06 (despite the name, it was unrelated to the scrum event, instead it was more time for sharing news and interesting things before the workday started), team stand up immediately following (this was closer but not quite the same as the scrum stand up), then breaking into pairs and working until noon, then an hour for lunch, then working 1-4 then an hour for individual work like training, administrative junk etc. Remote work was not typical although there were two or three remote team members who lived elsewhere and tele-paired three weeks out of four.
I'm hard of hearing so this was a somewhat draining experience for me thus my switch to my current team. Here, team members typically work remotely 1–2 days per week (largely a consequence of corporate policies which have fewer desks than employees). Each team has 2–3 offshore teams that we work with. It seems like we spend an inordinate amount of time in meetings (my calendar has 11 hours blocked off for meetings in a "normal" week and more is not uncommon). There's a tendency for information to only be passed on orally which isn't great with my hearing loss.
It's not strictly a comparison of PP vs non-PP but overall, I would return to the PP team without hesitation.
Agreed. This has been my experience as well. I've mostly pair programmed over the last 15 years. Very similar schedule. Same pros & cons. There's a counter intuitive key element to Pair Programming - you're slowing down in order to go faster. You make fewer mistakes and correct them an order of magnitude faster when you do. You spend less time "thrashing" on something. You're less likely to loose the better part of an hour going down an implementation rabbit hole. Once you let get of the illusion that you can be better long term "by just going off and cranking this out on my own" (e.g. cowboy coding / hacking / JANGIT - Just Add New Garbage Ignore Testing), then the value of pairing really shines. 18 months into a project, you're looking at something that is still high quality, still manageable, and you still actually want to work on because you're proud of what you and your team have done.
Other than "code quality was higher", I don't see anything else directly related to pair programming in your observations. Seems more about team culture and organization.
I have some hearing loss as well, and this clearly would kill it for me, even if I thought it was a good idea otherwise. I actually walked through the programming floor of what might be the largest pair-programming operation in the US and was shocked to see (and hear!) that it was concrete floors and ceilings with no sound treatment. Awful.
My suspicion is that the jawboning about pair programming has more to do with the fact that it's a legal way to weed out older programmers than for any real economic benefits. We're more likely to have hearing loss, and will seem like poorer programmers in a pairing situation. Plus, we're overall less likely to put up with trendy bullshit like PP.
- hard for remote teams. Only good if everyone on the team can easily pair up.
- only good if everyone follows a strict schedule
- only good if everyone understands the problem and solution space equally. If one of us needs to go into a cave for an hr to read documentation or experiment, it all falls apart.
- very mentally intense. You're always on. Can only keep it up for a few hrs without some massive mental drainage.
Overall I like PP for small problems to help teach someone. I dislike it for day-to-day.
I find it really hard to try things I'm not sure will work, or noodle around, or feel my way toward a solution, when someone's watching. Just incredibly uncomfortable. Since those sorts of things are where a lot of my value comes from, count me out on PP. It's fine in very small doses for specific purposes when both people want it and are already comfortable working together but I'd go fucking crazy being forced to do it every day on a schedule.
I like PP when I am working on an established code base making changes. If I'm working on a PoC or something, I spend more time with pencil and paper up front than I do at a keyboard, so PP is out.
> only good if everyone understands the problem and solution space equally
That's a goal of pairing up. Together you'll get it better than you would have separately, if for no other reason than the one person who already knows it has to be able to explain it. And as a bonus, now that knowledge belongs to two people instead of being siloed with one of them.
> A pair works at the speed of its slowest member, so it take at least 8 hours for them to finish the "easy" coding.
Not necessarily. I pair with a guy who's probably 10 times as productive as I am(I really try, but I understand that I'm relatively slow), and he'll ask me to pair with him because I might come up with an idea for something that even he is stuck on. I often do, despite the fact that I'm much slower than he is at implementing things.
So while I do think that it can often be the case that a pair will only work as fast as its slowest member, most likely when tackling a large problem or even doing something tedious, that doesn't mean that there aren't times where a more productive member can value from pairing with a less productive member.
EDIT: This is entirely from my point of view, so it's possible that this person I mentioned feels differently. However, even if they were frustrated by my slow performance, I don't think they'd inquire my assistance on problems if they thought they wouldn't benefit from it.
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 do it a different way wherein one person writes the failing test, then their pair writes the implementation to get the test to pass along with the next failing test. Rinse, repeat.
I generally find the axiom "If you want to go fast, go alone. If you want to go far, go together." applicable to this context.
----
Benefits of pair programming (IMHO):
* It eliminates the need for code review (most of the time) since another dev is providing input as you write.
* Pairing senior and junior developers is an excellent way to build the abilities and confidence of the latter.
* Pairing decreases siloing of knowledge and one individual's "ownership" of a particular feature or system. You much less frequently see things like "Oh, you have a question about our Widget Framework? Go ask Sally, she's the only one who touches that part of the code."
* You're less likely to implement hacky solutions just to get something to work because someone else is working alongside you. (At least, I am.)
* It's easier to find and fix bugs (in my personal experience) when you have two sets of eyes on the code.
* You have to slow down and explain your ideas before immediately jumping in and implementing them. I generally find that reaching consensus with my pair about the strategy to solve a problem helps surface edge cases I might not have thought of alone.
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 this lower quality pair goes significantly slower and the result may need some code review/cleanup cycles, but it's a worthwhile investment.
Paring with Ping Pong TDD works really well. Improves paring with frequent driver/navigator switches and improves TDD by having the navigator thinking ahead. Been doing it almost exclusively for 14 years.
Hiring for pairing is important. It's not for everyone, although not everyone has been in an environment where it's done well. I make sure to let people know they will be pairing full time on my teams and ask if they are comfortable with that. Also won't hire anyone that would be significantly slow to work with (can't touch type, slow thought process)
Some people hate pair programming. I happen to be one of them. It kills my personal job enjoyment/satisfaction and if I was coerced into pair programming too often, I would find a job elsewhere.
So, the cost of losing one or both of the programmers in the process must be considered too.
True. It's also true a lot of people hate solo programming, and do not want a non pair programming job.
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.
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 when they're working on something challenging and/or interesting?
I can't imagine not wanting a second opinion from time to time, and I've certainly missed having one sometimes when I've been working solo on something and there was no-one else to talk about it with. But personally, I also can't imagine being comfortable in a full-time pair programming culture with necessarily restricted schedules and limited solo time. Sometimes, I just want to do some research or think through some ideas or play with quick and dirty prototypes for a while, even if I might be very interested in discussing my results or initial conclusions with other interested developers afterwards.
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. 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.
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
Just to be clear, I'm talking about two (or more) developers, gathering together to solve a problem collaboratively, with the end result that the code to do so is written or at least the significant questions have been answered and what remains is little more than a mechanical exercise. But I'm talking about that happening spontaneously, and not necessarily starting from a complete blank slate, being done on a specific schedule or according to any specific process or using any specific tools, or being required as formal policy.
Next time on Hacker News: an article about the economics of strong typing, with someone threatening to quit if they have to use a strong typing system, demanding that be factored into the economics as well.
Perhaps true, but not really the point the authors were looking at.
If you look at @programminggeek's point without passive-aggressive exaggeration and then at the wiki, you'll see that it's specifically called out as a potential problem.
Sadly, it's dismissed out of hand as a "people problem" and "irrelevant". It really deserves more attention.
First of all, if you're looking for programmers to maintain a VB6 app, you really should factor into the economics of that endeavor the fact that most people don't want to code in VB6.
Second, no matter how potentially beneficial the pair programming approach is, there is a question of psychology in play. There are people who are introverted enough that the constant company required for pair programming will wear them down and cause them to quit or change teams. Dismissing it as a "people issue" and misrepresenting it as being unable or unwilling to be a team player is an oversimplification.
I don’t know if I would say I “hate” it, but the one time I tried it (at the behest of my then-employer), I and the rest of my team found it to be unworkably impractical. We had half as many computers as we had programmers, so we each shared a workstation. However, each of us had our own individual e-mail addresses, so we’d have to take turns checking and reading e-mail while the other one sort of looked away. When we started using something new (I think it was Apache Struts back then), we’d have to take turns reading the documentation - we even tried putting two different copies up side by side so we could scroll individually (but we still had to take turns moving the mouse). Beyond that, everything seemed to take way longer than it might have taken individually because neither of the people in the pair would be comfortable doing anything experimental unless they could quickly explain it to the other, so there was a lot of time spent talking about whether some approach or other might work instead of just trying it to see what happened.
There are so many anti-patterns here it's painful...
If you're pairing, don't read your e-mail. Even if you're just in a solo work session, don't read your e-mail. It's incredibly disruptive and constant inbox checking will drop your productivity like a rock.
It's okay to pair with multiple workstations (or a single workstation set up for multi-user mode, that's the dream I guess). Looking away from the "main screen" to check docs (or VCS, or the build, etc.) is perfectly fine, just don't get drawn in so deep that you forget about your partner. And certainly don't use that as an excuse to check your e-mail or slack!
One strategy to apply is "show, don't tell". If you have a hard time explaining what you're going to try to do, just do it, the code will probably be clearer than your explanation alone. If it's not, use the conversation to drive the uncovering of assumptions, which can then be encoded in the source.
Remember that pairing isn't simply two people, one keyboard. There are defined roles: the driver and the navigator. The driver handles mechanics, the navigator observes and questions assumptions. Then switch roles. The driver should fearlessly try the experimental things. If the navigator wants to experiment, ask to drive.
Pair programming can be fantastic in short burst. The other day me and a coworker were working through a difficult solution and having another set of eyes was needed.
Maybe its just because I get along with my coworkers, but when working on something difficult we naturally collaborate and end up in an unofficial "pair programming session"
Over the last few years I’ve come to this exact realization as well. I used to think about it as a couple devs sharing a keyboard for interminable stretches and it made my skin crawl. Watching someone “drive” fumbling for buttons in the IDE and not using shortcuts makes me want to shoulder them out of the way and take over.
However, for short bursts (10minutes to max about 90) that are focused on a particular goal makes me feel both re-invigorated and more satisfied with the completeness of the ideas.
The re-invigoratation (for me) comes from not having to run my brain at 100% for the duration. In auto racing terms, my partner and I can take turns drafting off each other’s thoughts, increasing our mental efficiency.
When differences arise I love hearing their thoughts and finding ways to merge the best of both ideas- or completely tossing my own because theirs are better. I’ve heard it (no clue where or from whom) described as idea sex. I’m very okay with my ideas being promiscuous and having lots of better little idea babies.
I still haven’t figured out how to keep my skin from crawling watching people fumble around their UIs though...
I have worked in 100% pair programming environments for 5 years now, across 2 different employers. I feel like what you’ve just discribed is a good example of the beniefts of pair programming along with the downsides of not doing it all the time.
Your skin crawling while your pair is fumbling for buttons in the IDE is likely displayed by you physically as well, maybe holding your breath or twitching your hands towards the keyboard, your pair is probably then also thinking “what are they thinking but not saying, have I just done something really stupid” which leaves everybody feeling very uncomfortable, and is unproductive. However if people are comfortable with each other and importantly, open to being shown something new, the whole situation is fixed with a simple “hey, did you know there is a shortcut for that”. Over the weeks simple interactions like that add up to mean the whole team is using all of the keyboard shortcuts. The same is true of software patterns and useful library functions, they spread like gossip in the group because everyone is excited to show the next person.
I totally understand that pair programming isn’t for everybody in fact I think it is only for a specific type of person and group. Pair programming only works in groups where each member has high levels of empathy and trust is high within the group. Everybody on this thread that turned down pair programming jobs because they thought it sounded awful were definitely right to do so. But for some it can be an extreamly productive and fun way of working and learning at the same time.
isn't how pair programming emerged ? a natural realization that teaming up helps searching through space at high speed, keep motivation up, anxiety low.
my favorite time in college was the one time I met a similarly minded guy, we cracked through problems with such a positive energy. It was like a biking race, I'd find an idea, then get stuck, he'd try something, so on and so forth.
- Pair programming works better remotely than people say, in my experience.
- It is a great way to share unwritten/unspoken information and best practices.
- PP is excellent for team cohesion and allowing engineers to get to know each other and their strengths.
- Not every engineering problem warrants PP.
- Some problems are better solved by one person as it can take too much time to get the other person up to speed with the issue.
- Pair programming often leads to better code, but you have to balance that with the overall reduced amount of work being done at once. If two people are working on one issue, you have to balance the benefit of that versus two people working on two problems.
- I'm more effective when I can focus, and sometimes I need to spend an hour deep-thinking about a subject and perhaps pseudocoding something. Pair programming with someone remotely and having long periods of silence would be... weird.
- People seem to view PP as a measure of success. The more a team is pairing, the more success being experienced. Right?
- If someone isn't into pair programming often, that's seen as a negative.
- 95% of people who pair remotely need better microphones or accoustic environments. I wish remote companies would ship their employees a pair of AirPods, a Yeti mic, and some acoustic foam squares.
- Pairing is more consistently useful for reviewing large code changes where it can be difficult for a reviewer to reason about the work that was done. Going through it with the author and doing a screen share can make all the difference.
My conclusion is that pair programming can be good for some things, but I would consider it a red flag if a company highly emphasizes pair programming or coerces people to do it. Treating pair programming like a panacea dismisses the fact that people of different personality types have been writing perfectly good software without pairing since time immemorial, and that there are other ways to improve code and product quality. What I think can be nearly as effective as pair programming is getting code reviewed early and often. I'm not the best at this yet, but I've noticed that life is just better when I don't do a ton of work and wait for it to be reviewed when it's "done".
There is a construction site in front of my office. When I walk close by, I always see a guy working and another one standing next to him apparently checking if he is doing correctly the job. Wondering if this is the equivalent of pair programming in the construction industry.
Anyway, I've done some pair programming when I was younger, and I like helping some new folks with a 1-hour pair programming sometimes, but I don't think I could stand having someone pairing with me all day. Furthermore, there are other ways to keep code quality high (code reviews, tests and so on).
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.
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..
I'm pretty sure it's not that nobody bothers, it's just that there is well over a decade of research and literature strongly suggesting that it's either (a) impossible to do this kind of direct productivity measurement accurately, or (b) gives the wrong idea, creating wrong incentives that generally fail to improve outcomes (or worse, that the measuring directly hinders many positive outcomes.)
Outcomes are hard to measure, so we measure productivity instead. At least that's how it goes in my organization (and it does not turn out well, as suggested by the literature.)
Edit: but we are for the most part not developing software as our core competency in this company, so it turns out that fixing this is a pretty low priority...
I think PP is great; however, I do not like to use it as an educational practice. Why boils down to two ideas - a) you are not hired in teams, so you cannot rely on classmates; and b) we've made students so scared to help each through fear of academic integrity and copyright violations that we had to create a special activity centered around looking at someone else's code.
The first idea is rather obvious - the teams you build while learning may be enjoyable but that does not directly translate to hireability. PP Exercises are still scored primarily through correctness over contribution, so a slacking student can do less and potentially learn less without fear of too much penalty to their course grade.
The second idea is more an opinion about the state of CS ed. In an English class, if I wrote something that wasn't good, I could rely on peers to help. If I need help on my weight lifting form, I can show my form to others for advice. In CS, how dare you show your code to anyone because Copy and Paste are so easily done. I've literally had students swear off StackOverflow and helping peers for fear of being labelled a cheater. PP to me seems like its trying to solve that fear rather than deal with the cause of the fear.
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.
This sentence from the blog is key, "Caveat: Pair programming is a learned skill. It takes time and work to do it well."
Pair programming sounds great and all but if even one person from the "pair" is not good at it, everything falls apart. Also, the pair's chemistry has to be on point like Jeff Dean and Sanjay from Google :p
Pair Programming is a complete crock of shit. If you hire someone to do a job, either they can do their job, or they cannot. If you cannot trust someone to perform and deliver work up to a certain standard, do not hire them. Is there any other industry where you hire two people to do one job?!
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.
I'm one of the right people, I love pairing and have been doing it for a decade full time. That being said, I'm also very much aware 80% of developers will never want to do it, and that's okay. Even though it's a skill to learn, and I'd guess a good many of those 80% would come to enjoy it with more practice, it's ok to not like it.
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.
My experience pair (and mob) programming for the past months has been very positive, both with in loco and remote peers (sometimes mixed). New hires feel they get a lot of context faster, and experienced peers feel it improves quality, as it forces code to be understandable.
I believe it's instrumental that the entire team is at peace w/ some working agreements to make it work:
- Splitting work between pilot/guide(s) (otherwise, it turns into a monologue)
- Rotating roles often
- No pressure to stay or having to leave for a while
- Have adequate installations (quiet space, standup desks, large screens, 40"+ displays if possible, ambient sound for remotes to join in the session)
What's worse is that it didn't used to. The current version is a rewrite, based on a wiki-interop framework (developed by the original wiki's creator, so it's not a hostile takeover, but rather an attempt to do stuff that wasn't possible originally).
For no apparent reason. Five years ago it was part of the world-wide web and open to mashups and automation, now everyone needs a custom deobfuscator (albeit a simple one).
The SPA rewrite of wiki was an extremely bizarre move and I'm still not sure why they did it. (For those who aren't aware, this site is the wiki - the original one, and was mindblowing in the 2000s.)
> The underlying assumption is actually, For any two programmers, no matter how good he or she is, if we get them to sit together, the value of their work will be greater than if they sit apart.
Yes, an ASSUMPTION. Not proven. Not studied. An assumption.
> There's an implicit assumption there that all bugs take the same amount of time to fix.
No there isn't.
> Now, I'm about to make a crucial assumption: that Alice and Bob's "difficult tasks" are disjoint, such that what's difficult for Alice is not necessarily difficult for Bob and vice-versa.
... Followed by some anecdata to validate the assumption, followed by "calculations" using hand-wavey numbers.
The rest of the article is similarly filled with hand waving, assumptions, strawmen, and outright fabrications. If you have a valid point, use valid reasoning to argue it.
While it's easy to through around words like anecdata and poke at this article for not having hard data, I simply don't think you'll be satisfied because measuring productivity and value delivered are incredibly hard to quantify. I think this article is wholly reasonable in it's approach as attempting to show with some back-of-the-envelope math and some hand wavy explanation that it is, in fact, possible for the economics of pair programming to work. Having another person try and explain the many complicating factors is exactly what I need someone to have if I want to convince my organization that it is perfectly reasonable to try and no you're productivity won't be cut in half.
I did pair programming at two different companies full-time, one was over 200 people and that was one of the most productive companies I've ever worked at, hands down. That is also highly anecdotal, but I know it's true because I did it for 5 years and also have seen what it looks like without it for at least as many. It doesn't work for everyone. Some organizations just attract better people and that is a confounding factor. Remote pairing is hard. All these things are true, but if I want to try it at my next company, as I'm doing right now, I need articles like this to prove I'm not crazy, and yes, it's worth trying if you have problems with communication, or want to train young developers, or learn something new, or reduce bug rework from poor code reviews. It's a very useful method of developing software and I'm happy this guy made an attempt to quantify it, however poorly, because software is just a hard thing to quantify.
My experience with pair programming in ML modeling:
- ML involves making lot of assumptions. That created some fatigue in me, and it helped to have someone giving out their thoughts actively. Even when not aligned on a common view point, simply going by one's approach first based on ease-of-implementation sounds practical. we could try other ideas always right..
- Creating bugs became more apparent. i.e., every software bug is someone's creation, and pair programmer would actively think about what's going on, makes the code less buggy
- Software architectures and designs are easy to justify at the end, because you've one more already on board, at least to some extent. If the person isn't aligned with the other's thinking, its very easy to pin point the item. Usual management style is, someone with different eyes (managers, tech leads) review once its gotten to some place.
- What was mild inconvenience was: my pair programmer was Vim guy, I'd like sublime text. Our style of thinking was also different. It made few things better, but ultimately you are asking someone to push their approach onto you. Some adjustment needed.. but okay. I'd prefer reading papers in depth before finding a common theme to implement, they'd prefer jumping into code, and then tweaking and hacking. My motivation/internal agenda is to write novel work, they'd want to simply get best numbers out. Aligning on something at this high level I thought has pros and cons..
- Overall, pair programming really helped me see myself. Its like getting active feedback, but not in the formal feedbacks designed in companies. If both like to some extent doing it together, its a good way to grow as a person and engineer.
- In workplaces there persons would not say I don't like pair programming with this person, unless do/die situation, at least in small companies. This pushes everyone to learn some people skills to see how things are going on.. I felt some discomfort at this aspect, but okay.
- I always had some insecurity about whether I am good enough for my goals or current project. I admired how many things are done by my pair programmer, and that made me feel whether they like working with me. It was always running on the back of my head. I think this dragged my personal contributions..
I'd always suggest someone try pair programming, see how it goes.
Some observations: team cohesion on the pp team was much higher, code quality was higher. Flexibility, not surprisingly was lower: we had a very fixed schedule: "Stand up" at 8.06 (despite the name, it was unrelated to the scrum event, instead it was more time for sharing news and interesting things before the workday started), team stand up immediately following (this was closer but not quite the same as the scrum stand up), then breaking into pairs and working until noon, then an hour for lunch, then working 1-4 then an hour for individual work like training, administrative junk etc. Remote work was not typical although there were two or three remote team members who lived elsewhere and tele-paired three weeks out of four.
I'm hard of hearing so this was a somewhat draining experience for me thus my switch to my current team. Here, team members typically work remotely 1–2 days per week (largely a consequence of corporate policies which have fewer desks than employees). Each team has 2–3 offshore teams that we work with. It seems like we spend an inordinate amount of time in meetings (my calendar has 11 hours blocked off for meetings in a "normal" week and more is not uncommon). There's a tendency for information to only be passed on orally which isn't great with my hearing loss.
It's not strictly a comparison of PP vs non-PP but overall, I would return to the PP team without hesitation.