
Pair Programming Economics - guilhermekbsa
https://wiki.c2.com/?PairProgrammingEconomics
======
dhosek
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.

~~~
downerending
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.

~~~
riffraff
Is PP "trendy"?

The "extreme programming explained" book that (afaik) popularized it came out
more than 20 years ago.

~~~
downerending
It was trendy then, and it's trendy now. It's a recurring fashion. Penetration
in the real world is almost zero, and for good reason.

------
Justsignedup
Personally, I dislike 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.

~~~
karatestomp
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.

~~~
throwaway55554
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.

------
ravenstine
> 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.

~~~
heisenbit
And you will be better in the future paying interest for years.

He is forced to stretch himself and expressing ideas and concept one level
clearer than otherwise. This helps him to move on another level skillwise.

------
bakedbeanz
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.

~~~
hendershot
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.

~~~
JackMorgan
I completely agree, with the right people, pairing to train is 10x faster. For
the wrong people, it's 10x slower.

------
quaffapint
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.

~~~
hising
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

~~~
wolco
It could work out if you split the work. You work in the am I'll take the pm.
Half days.. not bad.

------
programminggeek
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.

~~~
BurningFrog
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.

~~~
Silhouette
_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.

~~~
BurningFrog
> _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 much about programming as during my first ~6 months
working together with people and learning their wisdom and tricks.

You're right that the restricted schedules are a downside.

~~~
Silhouette
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.

~~~
BurningFrog
We may just mean different things by pairing.

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

~~~
Silhouette
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.

------
tentboy
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"

~~~
manyxcxi
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...

~~~
aarongraham
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.

------
ravenstine
My experience pair programming:

\- 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".

------
ggregoire
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).

------
m463
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.

~~~
pts_
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.

~~~
pojzon
I've also noticed this. It became so bad in my current company we have teams
which consist of:

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..

------
pjc50
Like a lot of discussions of programmer productivity, it's hard to measure, so
nobody bothers and we talk around the issue without any hard numbers.

~~~
yebyen
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.)

[https://martinfowler.com/bliki/CannotMeasureProductivity.htm...](https://martinfowler.com/bliki/CannotMeasureProductivity.html)

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...

------
muffelsong
In my experience some people use "pair programming" to hide their insecurity
and incompetence.

~~~
swagtricker
Absolutely true. In my experience, some people use "bashing pair programming"
to hide their insecurity and incompetence.

------
tsumnia
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.

------
potta_coffee
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.

~~~
wolco
You are doing it wrong. You need to drop to his level in order for harmony to
exist. He can't just jump to yours.

Better yet tell him to just stay home and get the job done right.

------
zadkey
I'm seeing an error when I try to view the site that looks like this:

"Trouble Encountered
[https://c2.com/wiki/remodel/pages/PairProgrammingEconomics](https://c2.com/wiki/remodel/pages/PairProgrammingEconomics)
can't fetch document

See github"

I'm guessing the site is overwhelmed with more traffic than it can handle.

------
mkchoi212
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

------
antonyme
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](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.

------
JackMorgan
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.

------
hcarvalhoalves
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)

\- Naturally leads to egoless programming

------
5cott0
The economics of pair programming is twice the price for half the
productivity.

~~~
house9-2
It depends on how you measure 'productivity' I guess.

~~~
wolco
You know things like finishing work.

Pair programming is about the relationship first. Code second. Overall system
quality last.

------
jownwayne
Through a lot of experimentation I found that pair programming _can_ help in
many cases: onboarding, code reviews, design & architecture and others
([https://www.togetherwecode.com/articles/seven-ways-
explore-p...](https://www.togetherwecode.com/articles/seven-ways-explore-
power-pair-programming/)).

It doesn't always work for me, but I found that it offers a surprising amount
of benefits.

------
dang
Many previous threads going back 12 years, for the curious:

[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=comments%3E3%20%22Pair%20Programming%22&sort=byDate&type=story&storyText=none)

------
lotwxyz
This is a wiki that only serves user-agents that are capable of executing
JavaScript. Weird.

~~~
notriddle
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).

------
redis_mlc
For those who don't see the value in pair coding, there is an alternative with
less overhead - code review.

Just emphasize to everybody to keep it friendly, and make an effort to +1 ASAP
every time.

------
gentleman11
What is that website by the way? There is a lot of good content on it but it’s
quite unusual. It’s becoming a go-to of mine

~~~
kryptiskt
It's the first wiki. Made by Ward Cunningham who was one the original agile
people.

------
NicoJuicy
In pairs:

\- 2 seniors tackle hard problems

\- 1 senior and 1 junior is good for teaching the junior

\- 2 juniors together is a recipe for disaster.

------
kstenerud
> 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.

~~~
gleenn
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.

------
lala26in
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.

