Fog Creek Software
Discussion Board




There's too much fear

I read over the Pairing thread[1], and the overwhelming opinion is that pairing sucks and everybody would hate their life if they had to do it.

I've done pair programming since before I knew what it was. I've also been in the "no way I would do that full time!" mode. Now that I've done it a lot, it's hard to imagine wanting to completely eliminate it. We don't do it full time, but it's rather valuable for knowledge sharing. It does help productivity, believe it or not.

So I think what's going on here is that these people are afraid of things they've never done. Here are some possibilities I've thought of. I could be right or wrong. How about the people who've done pair programming jump in and tell me what you think. I'm not saying that people with these fears are bad people or bad developers; I'm just trying to identify the fears themselves. (Nearly all of these could describe me at one point or another.)

1. They're afraid to spend significant time with other people. Coding is a loner activity, and it attracts a lot of people who like to spend significant time by themselves.

2. They're afraid not to be in control. They figure if they're not in front of the keyboard, they won't have enough control over the code.

3. They're afraid to justify their code. Most places don't do code reviews, and those that do tend to have an adversarial atmosphere around them instead of a way of educating and sharing.

4. They're afraid not to own the code. When you develop it yourself, you feel like it's "yours". If you pair, you don't own anything.

5. They're afraid to justify their design decisions. Coding generally involves some macro design decisions, like when to throw out existing code or when to refactor it; when to write just enough to make it work, and when to design in future compatibility you know you're going to need.

6. There's too much vested into "winning". A lot of developers feel like they have to win arguments, and if you're pairing, that might lead to a lot of discussion and arguments, which you may not "win".

Can anybody think of anything I've missed?

Now, more importantly: how can we as developers overcome these fears to become better?

[1]
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=47155

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, May 31, 2003

It's like sex.  If you're with someone good, it's an enjoyable experience.  Otherwise you just can't wait for it to be over.  If you're with a mature programmer, it can be good.  The rest of the time you have to deal with some snot nosed punk that thinks it's a competition.

victim, jr.
Saturday, May 31, 2003

For once, I can't add anything to what's been posted on the main thread topic. Brad and Victim Jr, you've both hit the nail squarely on the head.

I will add one side note, though.

Programmers are a pathologically skeptical bunch, and the more experienced a programmer is, the more he will tend to disparage overhyped "new" trends. XP and anything associated with XP, such as pair programming, meet these criteria.

One thing that the experienced tend to get sick and tired of is the "new is the only one true way" mentality of this industry.

So we're hearing programmers (typically consultants with something to sell) prattle about the joys XP as though anything written without XP techniques is dog sh*t and anyone not doing XP is a cro-magnon.  It's as though anything predating today's notion of best practices is crap.


The other thing that the experienced get tired of very quickly is the recycling of very old ideas in new forms that are taken by newbs as the holy grail and a modern epiphan. Mistaking an old idea for revolutionary is stupid. People should read their history.


The idea of working professionally with peers had been pervasive in the sciences and in engineering for decades. The computer field started the vogue for socially dysfunctional "precious snowflake" rejects holed up with their precious work.  So pair programming, in a sense, is a return to the sort of professional interaction that other technical occupations have always employed. 

Bored Bystander
Saturday, May 31, 2003

Actually It is not neccessary that people be good just at the same skill level, otherwise your coding with an anchor, or (if youre the anchor) you nod off within 5 minutes

Daniel Shchyokin
Saturday, May 31, 2003

BB, your penultimate paragraph is right on.  I have been around long enough to see a lot of ideas get recycled, often with a new name but touted as the newest thing in SW development.  Most of XP falls into this category.

I am having a harder time figuring out your last paragraph.  Pair programming is the one feature of XP where I don't know of anything comparable preexisting.  Can you give examples of something equivalent in other engineering fields?  Certainly there is collaboration, but what would be comparable to sitting at the same terminal and making joint decisions about each line of code?

mackinac
Saturday, May 31, 2003

Beware the Usenet effect.

In general, human nature will always create overly negative impressions on discussion forums. Why? Because people rarely feel the need to post "I've done [x] and I like it" out of the blue. Negative emotions are generally stronger and easier to articulate, so they're articulated more.

In fact, think about software management in general - how often do you read stories like "we brought our enterprise project in on time and under budget"? Unless it's an exceptional success, people don't write about it, and people don't want to read about it.

Personally, I don't have a problem with XP - for those that have followed my "too much process can kill a project" rants, you'll realize I tend to prefer an XP style anyway. I'm itchy about Pairing - I do believe that in the right circumstances it would work very well; I fear that the average manager won't understand the concept of "in the right circumstances" and it would become a 24/7 mandate, regardless of compatibility. As I indicated in another thread, I think the potential destructiveness of abuse of XP concepts far outweigh the potential benefits.

As for the list above, #1 is the only one that really applies to me, but I'm flexible. As for code reviews, I welcome them - I would dearly love to have a group of peers go over my code; I'm sure I would learn new things and it would be pretty fun.

Philo

Philo
Saturday, May 31, 2003

mackinac - I don't know about programming; I suspect the single keyboard has been the barrier to entry, but in other fields there's been pairing for centuries. Chemistry, physics, biology, etc - people have been working together.

Another support for the pairing concept - have you ever taken a lab course with a lab partner? Notice how much easier labs are with a peer than by yourself?

Philo

Philo
Saturday, May 31, 2003

I like pair programming.  I was paired voluntarily with another programmer about a year ago and we shared the same keyboard, monitor, computer etc.  We sat next to each other all day and yet we never tired of each other.  If I couldn't think of an idea then she thought of it.  And if she was stumped then I would normally be able to help her out.  So if either of us was on a roll coding then the other would just watch, observe, think and wait and we would normally talk the troublesome spots over.  Of course she took smoke breaks a lot and was considerate and would stay away from me while her smoke "smell" wore off.  Anyway we normally solved many times more coding problems than we did by ourselves and we had many good laughs.  Now maybe this was a freak accident that two people of relatively the same experience level could get along so well and get so much work done, but I think you have to try it before you can judge it.  Then again maybe I'm a strange type of programmer, more open than the average.

Another $0.02 to the coffee fund? (Lotto fund?)  I vote Beer and Brats fund!!

Programmer in Wisconsin
Saturday, May 31, 2003

Mackinac:  I just meant that in other engineering and technical fields, collaboration is common and it's an expected norm. Peers are allowed to know what others are doing and it's expected that it's a team effort in all respects. In software development, it's very often the case that a significant piece of code (significant in terms of its importance to revenue or a larger goal) is 'owned' by just one person most trusted to make it happen. And equally common is that literally nobody around that one person knows even the first thing about what that person has done, only the overall function that the software performs. This can be the case even though there may be a "group" assembled around the project - only one person really understands what's going on, and everyone else is in a non critical supporting role.

My attitude is that allowing exclusive ownership of a significant piece of code by one person is a "sin" against good business principles. If one person can hold a business hostage, then it's not much of a business. And this happens all the time, and in companies in which the owners puff their chests in pride at their "team". One certain employee leaves and you'd have immediate chaos.

And - sometimes, such projects are even entrusted to a person "not" really trusted by anyone, but to whom it falls to do the work because nobody around them is allowed to have a clue or is of demonstrably lesser skill. I've been amazed by the number of projects in this industry that are locked up by individuals that I wouldn't allow in my house and around whom the general concensus is that they are not to be trusted.
To get back to the main point of the thread: pair programming is probably a better thing than  the practice of solo programmers appointed to go it alone indefinitely. However, everyone's tolerance for working in tandem ought to be respected.

Bored Bystander
Saturday, May 31, 2003

I have never worked on a project using pair programming in the manner promoted by XP.  I am also one of those who would not want to be assigned to a project using it.

The notion that we can't know whether or not we would like pair programming without trying it is a statement that is true, but lacking in practical usefulness.  Those of us with finite lifetimes can't try every methodology that comes along.  We have to extrapolate past experience and make reasonable choices about what new methods to try.

Brad, you left one important "fear" off your list. The fear that managers will implement XP, it will be an slight improvement over their existing but really bad practices, and then it will be yet another excuse to avoid implementing the kind of best practices that have been known about, at least to developers,  for years but too often ignored by management.

mackinac
Saturday, May 31, 2003

Should artists "pair paint"?

just some dude
Saturday, May 31, 2003

>>> Mackinac:  I just meant that in other engineering and technical fields, collaboration is common and it's an expected norm. Peers are allowed to know what others are doing and it's expected that it's a team effort in all respects.  <<<

BB, this is an interesting point, but I just don't see that collaboration in other technical fields is at all comparable to pair programming as advocated by XP.

I can see that collaboration in software development could be a good thing.  Practices such as design and code reviews are a sort of partial collaboration.  But this sort of collaboration, and the collaboration that goes on in other technical fields that I am aware of, has an interaction period of  hours, days or even weeks.  Pair programming has an interaction period of minutes, or even seconds.  I can see that that could work out for certain types of debugging or maybe developing simple functions, but not for major software development projects.

In these discussions I do try to be careful to use "pair programming" in the sense advocated by XP.  In fact, I usually checkout the http://www.extremeprogramming.org web site to be sure of the details.    One of my coworkers really likes the idea of PP, but to him that just means two people working on the same project so one can go ask the other questions if they run into problems.

mackinac
Saturday, May 31, 2003

[pair programming, in a sense, is a return to the sort of professional interaction that other technical occupations have always employed.]

I don't agree with this, Bored. I think collaborating, interacting and communicating are a good idea, and there isn't nearly enough of it in any of the places I have worked as a programmer. But sitting together at the same keyboard every day is something entirely different.
I have some idea of how scientists work -- yes there is communication and discussion of ideas. But you also spend many hours alone reading your field's publications, analyzing your data, etc. Time alone is absolutely essential for creative and/or intellectual work.
Certain people can tolerate hours of solitary concentration, while others can't. Maybe pair programming is really for those who can't.
On the other hand, I would like it once in a while. Making it a mandatory policy is a very bad idea.
This has nothing to do with fear, since I can explain everything I write. Sometimes the explanation might be "well I was in a big hurry," or "I didn't know any better at the time." But usually I have a good reason.

The Real PC
Saturday, May 31, 2003

Okay Philo, lets see this site.. Post the URL
I will give you an honest evaluation of the site, including the code.

  - Kent

Kent Design4Effect
Saturday, May 31, 2003


I have done a fair amount of pair programming, but it generally turns out to be more of me mentoring less experienced developers.  While this may provide some long term benefits by downloading knowledge to them, it definitely tends to slow me down.

That said, I have had invaluable experiences when paired with the correct person.  However, in the situations where it works extraordinarily well, we did ignore some of the more annoying things like the 'one keyboard' rule.

In the strictest sense, you could say that if you aren't doing the one keyboard thing, you aren't pair programming.  However, I would argue that if you have two developers sitting next to each other with two separate terminals, you can still achieve or surpass the expected performance of one keyboard.  The really vital thing is establishing and maintaining the needed communications between the developers.  I have actually managed pair programming sessions with co-workers over 800 km away with real success.

Having said all that, it certainly isn't something new, and it is definitely not going to be advantageous for everyone.  In mismatched pairs, it can have its uses if you can affort the time to mentor but should otherwise be avoided.  If you get the right match, you will be amazed at how quickly the job is finished.

!
Saturday, May 31, 2003

Kent - not my site to post publicly, but I'm emailing you the url...

Philo

Philo
Saturday, May 31, 2003

I think a lot of this discussion about the alleged merits of pair programming reflects, yet again, the youth and immaturity of programming as a profession.

The type of sharing involved in pair programming is the type of sharing that occurs in factories, where people are sorting tomatoes or spraying cars.

Brad Wilson alleges there's something wrong with good software engineers wanting to do their own work, to take pride in it and also to be reluctant to share the fruits of that work without fair reason.

There's nothing wrong with that. It's normal, and good practice.

If any immature practitioners in law, or writing, or journalism, or any of the other established professions, tried to tell those practitioners to sit side by side and do lots of their work together, they would be told where to go.

From everything I've seen, the most fervent advocates of pair programming are the less able; the people whose builds take eight hours because they can't optimise their architectures; whose products can't be installed without lengthy hand holding sessions; and who never design anything genuinely new, interesting or impressive.

Not bored
Saturday, May 31, 2003

not bored:

It's been said repeatedly that great intellectual achievements don't come from committees. However, most commercial software development *isn't* rocket science.

I don't exactly agree that advocates of pair programming are the lamest programmers. I tend to take the simplest explanation of things. Pair programming will *probably* tend to reduce the quantity of arcane tricks that are played in code and will create redundancy in the organization - IE, more than one person will know how stuff works. If that places a ceiling on the achievement of someone who writes code that can't be understood by others, then I think that most biz owners will say "so be it".

My guess is that pair programming is intended to reduce the amount of code that only one person can understand, and is intended to diffuse some of the knowledge - probably most urgently for the sake of maintenance, which is often as large a burden as initial development.

If there are hot buttons I've seen with technical management that happen to intersect the areas that pair programming and XP address, these are it.

Bored Bystander
Saturday, May 31, 2003

"Brad Wilson alleges there's something wrong with good software engineers wanting to do their own work, to take pride in it and also to be reluctant to share the fruits of that work without fair reason."

I never said that.

However, the way some people act -- when they're paid to be part of a team -- is a tad bit pathological. If you want to be a solo inventor, then by all means, go off and do something by yourself.

As an employer, I'm more concerned with what's best for the team and the company than I am about placating someone's need to "own" something outright. Employees don't get paid to do whatever makes them happy; they get paid to do what they're told. Their choice is not "get paid while I do what I want, or get paid while I do what you want", it's "get paid while I do what you want, or leave the company".

Do you disagree?

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, June 01, 2003

"The type of sharing involved in pair programming is the type of sharing that occurs in factories, where people are sorting tomatoes or spraying cars."

Where the hell does that come from.  Bwoyh, you ever worked in a factory?  There's no sharing in a factory.  You sit at your station and turn your screw, insert your coils, perform your tests.  All by yourself, hoping a machine doesn't come along and replace your job.  My first 5 years as an engineer was making machines to replace these peoples' jobs.  It aint a pretty sight.  What used to take a line of 10 workers, knifing coils, trimming pots (resistors), is now done by 1 machine in about 10 seconds.  But that's old news, really old news... so 80's.

Engineering on steroids - that's when a hardware and software engineer get together a pair program.  The best of both worlds all rolled up into code genius.  Or a test engineer and a design engineer.  When that rarity get together, new benchmarks get set and performance soars.  This is a recent case in our small company, and while its not within my realm yet, I look on with envy.  When a whiteboard session of specialists find their groove and start nailing a problem that appeared unbounded, but by the end is a design - I love it.  Gotta get me summa that...

Nat Ersoz
Sunday, June 01, 2003

Brad, I know you're being dramatic, but I agree that that's the general idea.

As a contractor, I never entertained any illusions that I owned the code in the physical or trade secret sense - I was simply happy to have produced it.

I have code right now that's doing some amazing work. Most people using it have never heard of me. That's okay - I'm simply happy to know that I wrote it.

It seems like there are two (among many, of course) psychologies at play - some people have a need to possess their creation, like "losing control" of it somehow lessens them. Others seem to be happy simply working for a paycheck, and being comfortable in the knowledge that their worth is recognized with the paycheck and by those that know they are the authors.

Regarding pair programming - I believe the benefits:
1) Properly implemented, a pair will definitely be more efficient than a single programmer
2) The code produced will be of higher quality
3) Less likelihood for "little personal touches"
4) Redundancy. (increases the Bus Number)

vs. the costs:
1) Nobody seems to be sure if a pair is more efficient than two programmers. If not, then pair programming is a cost in manhours
2) Increased management effort in selling the idea, then managing the pairs
3) Some cowboys will fight pairing, which is wasted effort ( = lost $$$)

Philo

Philo
Sunday, June 01, 2003

"Employees don't get paid to do whatever makes them happy; they get paid to do what they're told"

It only makes sense if what you are 'told' is sensible.

Some big assumptions there.

Realist
Sunday, June 01, 2003

Brad, it doesn't matter whether I disagree with you. If you want to hire code-monkeys, go right ahead.

If you want to argue pair-programming is better, make it clear you are arguing from the employer's perspective.

Nat, my comaprison of pair programming with sorting tomatoes was meant in the sense that both minimise the contribution of the individual, treating peope as interchangeable workers.

Not bored
Sunday, June 01, 2003

Philo, there's no independent evidence that pairing produces better code. I think this especially applies once you start considering high quality, as opposed to junior, programmers.

Second, I like and enjoy what I do and take pride in it. It's regarded as highly valuable. I do claim ownership of that work, in the creative sense ( moral in legal terms) and the financial sense.

Not bored
Sunday, June 01, 2003

[Employees don't get paid to do whatever makes them happy; they get paid to do what they're told.]

Yes, but if what they're told doesn't make them happy, they should leave. If you make your employees unhappy, they will leave (or if they are financially unable to leave they will stay on as prisoners).
Making your employees happy (except, of course, for the ones you want to get rid of) is good for the company, and making them unhappy is bad for the company. If pair programming is going to make the more creative and independent employees unhappy, then of course your company will be a haven for mediocre conformists.
Maybe pair programming is not as evil as I suspect it is. Maybe it will do for software development what the assembly line did for car production. But in that case, it's time for many of us to change careers.

The Real PC
Sunday, June 01, 2003

Not Bored - have you ever done *anything* as a team? Labwork, writing, coding, designing, crossword puzzles, etc?

There's a synergy that just happens when two people work closely together on a task that defintely moves things faster than one person working and produces better results. I suspect it's a result of the fact that everyone thinks differently, so having two pairs of eyes on a problem always seems to do more than 2x the analysis.

As programmers, we always make assumptions while coding. Someone sitting next to you while you're working who understands the code is going to question those assumptions.

Philo

Philo
Sunday, June 01, 2003

"Brad, it doesn't matter whether I disagree with you. If you want to hire code-monkeys, go right ahead."

That's a LOT of anger, just over someone who said that maybe there's some fear associated with why people don't want to pair program, and that employers should consider what's best for the employer. I feel pity for you. :(

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, June 01, 2003

BW: >>> Employees don't get paid to do whatever makes them happy; they get paid to do what they're told. Their choice is not "get paid while I do what I want, or get paid while I do what you want", it's "get paid while I do what you want, or leave the company". <<<

It is somewhat embarassing to admit it, but as an employee I have to often operated in the "do what I am told" mode.  At the same time I notice a few employees going off and doing something because it interests them, but no one told them to do it.

At some point I noticed that those employees who kind of did what they wanted ended up inventing improved processes, or were the ones who won the employee of the year award for the new business area they developed.

It is true that these people didn't just spend their time with random web surfing.  Although, in some cases even web surfing can be helpful.  On one project I spent some time looking at communications analyzers on eBay and ended up buying one.  No one told me to do that, but we wouldn't have been able to meet some of the project requirements without it.

mackinac
Sunday, June 01, 2003

I'd never join a shop that practiced pair programming.  I've had one too many sessions with no-social-skills-snotty-nosed-punk-ass geeks...  My personal well being/job satisfaction standards wouldn't allow me to risk the chance that I'd be paired with one of these people.

victim, jr.
Sunday, June 01, 2003

I find it funny how so many people judge others without even having the slightest clue in the world as to what they are like.  Making generalizations about things like, "I don't want to be stuck with a know-it-all punk", is absurd and demonstrates your own fears and weaknesses.  Why don't you help the "punk" and point him in the right direction instead of being a jerk geek and just saying, I don't want to work with him/her.  In fact you can go back to masturbating now, since that all you probably do outside of work.

I also find it amusing that the people with big heads think someone else is "below" them.  Here let me hand you a pin so you can let the hot air out.  Don't strike a match.

The fact is anyone can write code.  Anyone.  And given that they are of a state of mind which is focused on the problem, they will be able to write code that will solve the problem.  How dare any of you think that you are a "coding god".  How dare any of you forget that when you were starting out someone gave you a chance to code, alone or with someone.  The attitude of "I can code and only I know what I am doing" is sickening and is demonstrated by everyone on this board.  Anyone with a little motivation can do what you people do.  Anyone.  Stuck up snobs.  Pigs.

Pigs
Sunday, June 01, 2003

I'm sure you are wrong, Pigs.
I have always been sort of idealistic and believed anyone can learn to do anything, if they want to. But my observations over the years have shown that many, even most, people have a very small supply of motivation or discipline when it comes to things requiring mental effort. Even if all are able, most could never get interested enough to try. That goes for any kind of math, science, or literary/scholarly work. And I no longer believe that all are able.
Coding requires mental effort. If you do it without mental effort, you either have a special kind of intelligence, or you are doing very simple work. It requires as much mental effort as anything I have ever done, and I am very far from being stupid.
I'm sure there are lots of managers who think coding is on the level of clerical work, and that programmers should have little tiny manageable egos. While I believe that no one, however smart, should feel or act superior because of their skills or intelligence, it's stupid to pretend that the person who barely got through high school is on the same intellectual level as the person with college degrees in technical, scientific, or professional fields.
A really good programmer must be the kind of person who can learn a new technology within a couple of days on their own, just by reading and experimenting. Most of the people I know, who are not programmers, could not do this if their life depended on it. They couldn't do it if you gave them years instead of days. They would rather be thrown in jail than learn programming.

The Real PC
Sunday, June 01, 2003

sure, anybody can program... they can learn it in 6 months at the local tech center.

Look, I wasn't saying these people weren't smart, just that they sucked to be around.  At this point in my career I can afford to be choosy about what I do, when I do it, & who I do it with. 

"In fact you can go back to masturbating now, since that all you probably do outside of work."

well, I'm constantly working on something, so that leaves me with little time to do other things.  Plus it's enjoyable...

victim, jr.
Sunday, June 01, 2003

[sure, anybody can program... they can learn it in 6 months at the local tech center.]

Is there any proof of this?
The people who learn in 6 months were interested to begin with, and may have had previous experience. But how good are they after the 6 month course? And can you take a person with no interest or ability and teach them in 6 months?

We know that just about everyone can learn to read and write, although previously it was only the highly educated elite who could.
However, most people read and write very badly. The same would probably be true of programming if they started teaching it to everyone in grade school.

I would like to see the work of a person with no interest or experience who learned programming in one 6 month course. Maybe it would be like reading a book written by someone who had one 6 month course in literacy.

The Real PC
Sunday, June 01, 2003

I have no proof of it, in fact, that was meant as sarcasm...

victim, jr.
Sunday, June 01, 2003

Oh ok, I thought it was you who said:

[The fact is anyone can write code.  Anyone.]

That statement is so absolute, and I have to question it. It's like saying anyone can represent themself in court, or anyone can diagnose diseases, repair their own car, or cook. Sure anyone can learn how to cook, but how many are good at it? Anyone can learn to fix their own car, but most would rather pay an expert. Anyone can play the piano -- the question is whether anyone wants to hear it, and then whether anyone wants to pay to hear it.

It's stupid to say anyone can write code. Anyone can do practically anything, given unlmited time.

So I think "Pig's" statement is kind of ridiculous. Probably just an expression of anger.

The Real PC
Sunday, June 01, 2003

"Should artists "pair paint"? "

Ever talk to an artist about how many canvases they go through? As a wild guess, their marketable success rate is probably what, 5-20%?

So if you're saying that programmers should spend 75% of their time writing stuff they throw away, then yeah, pairing isn't for you.  ;-)

Philo

Philo
Sunday, June 01, 2003

Brilliant logic Philo.

And people wonder why software has bugs.....

punter
Sunday, June 01, 2003

[ their marketable success rate is probably what, 5-20%?]

check their ROI, business guiness

just some dude
Sunday, June 01, 2003

or even better, their ROA

just some 3l33t biz'nass dude
Sunday, June 01, 2003

Did anyone else not get that I was trying to make the point that painting is not even analogous to software development, so the question "should artists pair paint?" is not a valid rebuttal to pair programming?

Philo

Philo
Sunday, June 01, 2003

check the "hackers & painters" thread, and try to keep up.

http://www.paulgraham.com/hp.html

just some dude
Sunday, June 01, 2003

I've read the article, but I don't choose to debate with you - you seem more interested in "winning" than in reaching any kind of rapport on the subject. Take care, and watch the blood pressure.

Philo

Philo
Sunday, June 01, 2003

I'm sorry philo.  Hey, do you want to get together & do some pair programming with me?

just some dude
Monday, June 02, 2003

Brad, there was no anger in my commending you to proceed with your interests.

It was simply a statement that you seem to have strong intents that will obviously not my changed by my opinion, so your rhetorical question as to whether I agreed with you was deceitful. Nothing more.

Not bored
Monday, June 02, 2003

Philo and Brad, you guys should relax and learn to respect other people's work and points of view.

.
Monday, June 02, 2003

Philo, you asked if I had ever done anything as part of a team. The answer is that, yes, I've done many things that way, at uni, at work and in military service. To participate in the activity of, say, a highly trained military unit as it engages a target is a fascinating experience.

However pair programming does not strike me as the same sort of thing, at all.

Not bored
Monday, June 02, 2003

*  Recent Topics

*  Fog Creek Home