Pair Programming Economics
wiki.c2.com
Pair Programming Economics
1–10 of 82 posts
Re: Pair Programming Economics
#2Some 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.
Re: Pair Programming Economics
#3Some 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.
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.
Re: Pair Programming Economics
#4I'm seeing an error when I try to view the site that looks like this:
"Trouble Encountered 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.
Re: Pair Programming Economics
#5Some 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.
Re: Pair Programming Economics
#6> 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.
Re: Pair Programming Economics
#7Some 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.
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.
Re: Pair Programming Economics
#8Pair 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.
Re: Pair Programming Economics
#9Pair 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"
Re: Pair Programming Economics
#10In my experience some people use "pair programming" to hide their insecurity and incompetence.