The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Gabriel
Software Surgeon
Originally posted by Mike Isano:
And if I'm the one who is doing the "watching" after a while my mind starts to drift away.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Originally posted by Gabriel Claramunt:
Well, I guess some people like it, others don't. If it doesn't work for you, don't do it. "People over process"![]()
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Thanks,<br /> <br />Paul Croarkin<br />SCEA 5, SCWCD, SCJP
Gabriel
Software Surgeon
Originally posted by Gabriel Claramunt:
I'm referring to XP, where every practice relies heavily in the others.
Pair programming in XP allows the non-driving pair to do design and perform code/unit tests review "on the spot", so in XP there's no need of design or reviews, and the pairs can work directly from the user story. If you take the out the pairs, you'll need to compensate or you have a higher risk of lower quality code, design, and unit tests (a problem if you're doing militant refactoring). Collective code ownership will suffer also, because the knowledge about the code is not acquired during pairing (and lower quality unit tests will compound the problem).
(for a more "evil" view on the issue, you can see The Case Against Extreme Programing: A Self-Referential Safety Net)
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Mike Isano:
XP endorses pair programming. I absolutely HATE .... Does anyone else feel this way?
Originally posted by Guy Allard:
Mike - If it works, use it. If it does not work, do not use it.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Mike Isano:
The idea behind pair prog is that your friend will be constantly reviewing your code, giving ideas, etc. But really it just makes me feel like i'm being watched. And if I'm the one who is doing the "watching" after a while my mind starts to drift away.
Originally posted by Paul Carter:
Pair programming would absolutely drive me nuts!
Programming is a difficult task which requires concentration and freedom from distractions.
The only thing I can think of that would be less helpful than having another programmer sitting next to me while I work
would be to also be working in one of those idiotic bullpens that some people are so crazy about.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Have you tried it with someone who is good at it?
Studies show that Pair Programming actually helps people to get less easily distracted, and to get back into flow faster once they got distracted.
But that's not Pair Programming. Pair Programming is about sitting *together* in front of a computer, and *collaborating* on getting a task done.
would be to also be working in one of those idiotic bullpens that some people are so crazy about.
Originally posted by Damon Black:
I even find myself avoiding needed refactorings or explorations because of the additional headache of having to negotiate with your pair partner to do so.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Damon Black:
When I code by myself I can usually get myself in stretches of intense concentration, where I'm 'thinking in code'. Everything makes sense and I'm able to keep all the dynamics of whatever module I'm working on in my head at once. I NEVER get to that state of mind pair programming. Even with the best of them.
--------------------------------------------------------------------------------
Studies show that Pair Programming actually helps people to get less easily distracted, and to get back into flow faster once they got distracted.
--------------------------------------------------------------------------------
Studies may show this for some people. For me it's been exactly the opposite.
I do agree there are some tasks that benefit from this approach. I especially think that when you're going to be making architectural decisions that affect many areas of code, working with other people is essential.
But the thing I can't seem to do (and I acknowledge this is likely just a personal weakness) is 'think along' with someone else.
I even find myself avoiding needed refactorings or explorations because of the additional headache of having to negotiate with your pair partner to do so.
This is what I'm currently working in. Combined with pair programmer, it provides the added din of distraction that makes it virtually impossible for me to get anything done. It's like working in a grade school cafeteria.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
For example, one thing we did was installing small bells on each table that you could ring when it got too loud in the room - just as a reminder to your colleagues to tone down their voice.
Originally posted by Ilja Preuss:
Damon, this is an interesting report. I'm curious - please allow me to inquire a little bit...
What do you think is it about pair programming that holds you from "thinking in code"?
One more question: when you pair program, how much of the time do you find yourself being the driver (the one typing at the keyboard)?
Can you say what lets you get distracted easier when pair programming?
It's natural that there is kind of a buzz in the team room...
Originally posted by Ernest Friedman-Hill:
That sounds like a wonderful idea -- I'll try that the next time the opportunity presents itself. Far less disruptive than saying "Shhh" or "Quiet down please!", and at least potentially anonymous, too.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
Originally posted by Damon Black:
No problem. I should have plenty of time since I was 'let go' today for my inability to bend my 'people' to their 'process'.
I think I'm in a different place in my brain when I'm programming. And it's nowhere near the place where I deal with interpersonal communication. Each time my partner says something, sighs a little loud, or even fidgets in their chair, my attention is diverted away from the kind of thinking I need to do when programming.
--------------------------------------------------------------------------------
One more question: when you pair program, how much of the time do you find yourself being the driver (the one typing at the keyboard)?
--------------------------------------------------------------------------------
Not much. I know it's what needs to happen for engaged pairing - and I've really tried to do it. But as tedious and frustrating as it is to watch someone else program, it's even worse trying to program and not being able to maintain a consistent train of thought.
It's not that I'm more easily distracted, the problem is that there's much more distraction. I'm actually probably a little more easily distracted programming by myself, my thinking tends to be more relaxed and creative.
But I deliberately work (when given the choice) in an environment where I can remain free of unwelcome distractions. The problem with pairing is that the distractions are so much more frequent and intrusive.
I liked your idea about the bells and passed it along to our team, before I got fired that is.
The 'not-noise' is the real distraction of the bullpen stuff. It's tough NOT to listen to another human voice, especially if the voice might have important information for you. Someone might be just be clearing their throat, or making a joke, but you have to listen for a second to discern that, and as I've said, that's a jarring shift in perspectives for me.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
it doesn't sound like there was a lot of effort to try to work on your problems...
That's strange, because when pair programming, you should constantly be communicating with each other, anyway.
I assume you didn't have a coach that helped you with the adoption of pair programming?
Did the team already do pair programming when you joined?
I think the trick you need to learn for pair programming is "thinking out loud".
That's interesting. Every single developer I know is more creative when working in a pair - simply because of the stimulation by thoughts from a second brain. Being relaxed is a prerequisite, of course, and that might take some work to accomplish.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Cameron McKenzie:
As a lead developer, or heaven forbid, a project manager, I have seen much greater productivity out of my fellow developers when doing pair programming, even when they don't like it. My personal experience is that it works, and it makes developers more productive.
-Cameron McKenzie
Originally posted by Ilja Preuss:
Anyway, if we ever meet, I would be highly interested in trying some pair programming with you, just to see what happens. I'm sure we both would learn something from the experience...
Originally posted by Stefan Bell:
As a lead developer and technical architect, I have experienced mixed results. Some of our most productive and talented programmers have not faired well in PP. I know what Ilja will say, but we tried different partners, coaching, basically everything and it just didn't improve. The others and particularly the junior developers thrived in it.
My two cents.
Originally posted by Ilja Preuss:
...I also wonder whether the team did iteration retrospectives where such issues where discussed openly.
Originally posted by Gaurav Faujdar:
I feel that pair programming is about discussing and solving your problem together rather than only sitting together on a computer, where one person is typing away and the other is plainly watching.
Of course, once you have a algorithm for you problem there is hardly any point sitting together
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Saranyan Narayanan:
If there is one of the engineers in the pair who needs to lead all the time because of experience , it is hand holding not pair programming![]()
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Hedley Finger:
When you are really hot, in the zone, going with the flow, to have a partner interject to suggest another (not necessarily better) way of doing it completely derails the train of thought.
How do people on this topic who claim to be successfully using pair programming deal with the distraction factor?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Saranyan Narayanan:
If there is one of the engineers in the pair who needs to lead all the time because of experience , it is hand holding not pair programming![]()
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
It is my experience that pair programming leads to a different kind of flow. In that kind of flow, you are really working as one pair, thinking together, not as two separate developers. You are in a continuous exchange of thoughts, taking suggestions from your partner as stimulation instead of interjection.
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
|