What dev department is staffed well enough to do this, I want to join them.
So far every dev job I have had, has had only half the people they need and refuse to hire more.
Discussion on:
View:
Show:
In 1975 I completed a 4 month full time structured COBOL program course. Peter Gambel and myself were picked up by the BTR computer department. As they were 1 desk short in the developers section we both ended up sitting at one desk. We work on 3 projects together. Coding sheets and punch cards in those days.
As we had come off the same training course we thought identically in terms of naming conventions, top-down programming design, sub-routine coding, line numbering, etc.
The great experience still remains with me.
Debugging sure was a breeze when we checked out each others work.
Get it a try it might just surprise you
Donavan McDonough
As we had come off the same training course we thought identically in terms of naming conventions, top-down programming design, sub-routine coding, line numbering, etc.
The great experience still remains with me.
Debugging sure was a breeze when we checked out each others work.
Get it a try it might just surprise you
Donavan McDonough
were they?
Don't try and take the credit, pair programming is new, it says so on the label.
Don't try and take the credit, pair programming is new, it says so on the label.
That's around the time I started programming (yep, COBOL, and "stuctured" when that was the hot tech), and with moving between desk and card punch machine and dropping off the decks to be read into the computer, and waiting for the printouts - yeah, it could have worked ... then.
Nowadays, although I am more of a web admin than a programmer, I usually have a dozen windows or more on 2 monitors going, and when I am not checking on processes, debugging crashes, fine-tuning monitoring tools settings, installing updates, starting/stopping services, and even dabbling in my "hobby" of writing ksh utilities to help with the foregoing, then I use the "spare" time (yeah, right) to catch up on emails, respond to chats, and catch up with endless online learning - share what, exactly?
Also, I see the hard-core programming types in other cubes at times, and they seem to keep multiple monitors, and even PC's, going just by themselves, so I have trouble visualizing them sharing their hardware.
However, online collaborative work modes with screen sharing, code check-out/check-in, and other such techniques make more sense as a 'virtual' method of doing something similar.
Something weird about this notion...
Nowadays, although I am more of a web admin than a programmer, I usually have a dozen windows or more on 2 monitors going, and when I am not checking on processes, debugging crashes, fine-tuning monitoring tools settings, installing updates, starting/stopping services, and even dabbling in my "hobby" of writing ksh utilities to help with the foregoing, then I use the "spare" time (yeah, right) to catch up on emails, respond to chats, and catch up with endless online learning - share what, exactly?
Also, I see the hard-core programming types in other cubes at times, and they seem to keep multiple monitors, and even PC's, going just by themselves, so I have trouble visualizing them sharing their hardware.
However, online collaborative work modes with screen sharing, code check-out/check-in, and other such techniques make more sense as a 'virtual' method of doing something similar.
Something weird about this notion...
Some programmers I've worked with have drove me mental with their approach. Nothing wrong with either of us, just think very differently. At best leaves one or the other nodding, and making the tea.
One of Murphy's many laws is that putting 2 people together in an office gives you a 90% chance of a personality conflict. (I think it jumps to >99% when we're talking about the same cube.) That's just how it is. It can take months, maybe years to put together a cohesive pair that doesn't want to kill each other. About the time you find that perfect match, one of them gets a job offer and all your effort is shot. It's one of those things that is great when all the stars align and the universe is in harmony. Unfortunately it doesn't happen very often and trying to force it doesn't really work out all that well.
From another perspective, our positions are individually scrutinized and negotiated with the customer. Might as well ask for the moon as ask for 2 people to do what they perceive as one job.
From another perspective, our positions are individually scrutinized and negotiated with the customer. Might as well ask for the moon as ask for 2 people to do what they perceive as one job.
To get the most out of it you need to pick the right project, basic enhancement stuff for instance, it's a waste of a programmer and a half.
You also need to work on your pairings. We all have our own ways of thinking about a problem, I've seen two people arrive at the same solution with radically different approaches, and two people achieve equally acceptable but different solutions.
As Slayer says though, the time and motion, bean counter types have a real problem with this concept. Get gung ho with it, and all they see is chance to cut staff in half, and we all know that as well. We do tech because we like it, not becasue we are too stoopid to figure out standard corporate SOP.
Choose your targets wisely. It needs to be a reasonable block of work, either adding a new feature in one place, or enabling a new one across the piece.
There needs to be several potential solutions or none. If there's "only one way" to do it no point in having two people doing it.
The pairs need to see the value of it, bouncing ideas off each other spotting holes, disseminating domain or technical knowledge.
Other options are available, group design, peer review, hot housing.
They are all tools in the box, use the right one at the right time. Anyone who sells any of them as a silver bullet, has simply got bored with offloading bridges to greedy idiots.
You also need to work on your pairings. We all have our own ways of thinking about a problem, I've seen two people arrive at the same solution with radically different approaches, and two people achieve equally acceptable but different solutions.
As Slayer says though, the time and motion, bean counter types have a real problem with this concept. Get gung ho with it, and all they see is chance to cut staff in half, and we all know that as well. We do tech because we like it, not becasue we are too stoopid to figure out standard corporate SOP.
Choose your targets wisely. It needs to be a reasonable block of work, either adding a new feature in one place, or enabling a new one across the piece.
There needs to be several potential solutions or none. If there's "only one way" to do it no point in having two people doing it.
The pairs need to see the value of it, bouncing ideas off each other spotting holes, disseminating domain or technical knowledge.
Other options are available, group design, peer review, hot housing.
They are all tools in the box, use the right one at the right time. Anyone who sells any of them as a silver bullet, has simply got bored with offloading bridges to greedy idiots.
We use the same driver, navigator or "right seat ride" concept during training or to resolve issues and troubleshooting. As with most of the comments I see here. Most IT groups are not really designed for this mentality. It is let's get as much productivity out of each individual as we can and therefore the the whole team by default. I have observed that the pairing technique does work marvelously when in a training environment or case by case basis for support issues.
I wouldn't mind seeing a study to verify if the pairing technique makes a productivity impact. After all two sets of eyes are better than one. Pairing does bring up unique issues of the usual problems that companies deal with: work schedules, personaity conflicts, skill sets, work area footprints, equal opportunity, gender preferences etc etc etc.....
I wouldn't mind seeing a study to verify if the pairing technique makes a productivity impact. After all two sets of eyes are better than one. Pairing does bring up unique issues of the usual problems that companies deal with: work schedules, personaity conflicts, skill sets, work area footprints, equal opportunity, gender preferences etc etc etc.....
The sort of numbers that would satisfy the time and motion boys are the same ones they use in the equation 1 man for two weeks = 2 men for one week, which as we all know is complete drivel even discounting the knowledge and skill levels of the developers.
Now if you looked at the numbers around the lifetime of a piece of software, including training, coping with staff rollover, key person dependencies etc, I'm morally certain pairs is a good move. Can't prove it, though and it doesn't matter anyway, because the time and motion boys don't look past the this deadline.
Now if you looked at the numbers around the lifetime of a piece of software, including training, coping with staff rollover, key person dependencies etc, I'm morally certain pairs is a good move. Can't prove it, though and it doesn't matter anyway, because the time and motion boys don't look past the this deadline.
It has been a bit over six years since I began developing software and web applications for a living rather than a hobby, and since I graduated from university. The only experience I have had with this has come within the past 12 months out of that entire time, and have noticed that it can become a debate of various issues such as best practices.
The main benefit I have noticed from it so far is the ability to learn from each other when using this sort of technique, such as when a developer is being cross skilled in a new language. It can also be generally great at breaking through mental barriers when I am, or my peers are stuck trying to solve a problem as the process of describing the problem can even allow you to figure out the solution yourself.
My preferred method is to independently work on code and peer review the changes each of us have committed when merging into the chosen repository, and use this technique only when trying to increase the general knowledge of the team as a whole, pushing through any barriers and reducing any points of failure which may exist (when only one person knows how to look after or do something).
The main benefit I have noticed from it so far is the ability to learn from each other when using this sort of technique, such as when a developer is being cross skilled in a new language. It can also be generally great at breaking through mental barriers when I am, or my peers are stuck trying to solve a problem as the process of describing the problem can even allow you to figure out the solution yourself.
My preferred method is to independently work on code and peer review the changes each of us have committed when merging into the chosen repository, and use this technique only when trying to increase the general knowledge of the team as a whole, pushing through any barriers and reducing any points of failure which may exist (when only one person knows how to look after or do something).
Being a contractor, I have been paired with a contractor from another firm. I spent more time training than writing code, then basically put my foot down. I believe in cross training when a full time employee, or training a member of the company I am working for. As a contractor, I believe that's why I was brought in on a project for my knowledge and more than a bit against training another agencies developer.
The situation I've found that seems to work best is to pair 1 sr. developer as a navigator to (no more than) 3 jr "drivers". The drivers get experience and training, and the navigator checks for bugs, conventions, and goldbergs.
High productivity, low error rate, happy developers, and upper management feels comfortable.
High productivity, low error rate, happy developers, and upper management feels comfortable.
I think pairing is a good practice especially promiscuous pairing where you pair with totally different people. You learn more that way or contribute more.
The issue I have with it is that sometimes I just want to have my space to myself- you know. So I am in favour of it but NOT all the time like full time. Remote pairing is good too. I have practised it. Flawed Internet access is probably the only inhibiting factor in this case.
The issue I have with it is that sometimes I just want to have my space to myself- you know. So I am in favour of it but NOT all the time like full time. Remote pairing is good too. I have practised it. Flawed Internet access is probably the only inhibiting factor in this case.
Yes, And then there is the college effect where the group doormat does the work while the other sits on the duff doing nothing except potentially taking credit. I've worked at places where not only is the programming half staffed, but half of the half is either doing nothing or 'management'. What ever happened to having a good work ethic and actually rewarding people? Oh yeah. EoE and other maxims like this that are worthless because the idea is mentioned and someone blindly goes with it.
Any expectations of a company that all their programmers should work in pairs does not take into account differences in temperament and personality type. A person who is an introvert, such as I am, would never be able to work that closely with another programmer. It is a certain recipe for stress disorders, and would put somebody in the hospital within weeks. (I once had a supervisor who caused me so much stress I ended up in the hospital. And I am a very easy-going guy).
On the other hand I could see it working for programmers who are gregarious, and who need discipline to focus on their work. But I don't understand why these people would ever become programmers in the first place...
On the other hand I could see it working for programmers who are gregarious, and who need discipline to focus on their work. But I don't understand why these people would ever become programmers in the first place...
but the whole point of effective pair programming is two can do the task nearly as fast as one, with the bonus of two people comprehending the code, and just as important how it ended up like that.
Working with another programmer, is not working for a supervisor, even or perhaps especially, ones who at least believe they can program.
Your last paragraph is simply insulting, introverted != competent.
Working with another programmer, is not working for a supervisor, even or perhaps especially, ones who at least believe they can program.
Your last paragraph is simply insulting, introverted != competent.
from what I have seen. But, no, I do not think that is an absolute qualification - just a tendency that goes with the degree of mental focus and concentration often needed (at least with my style of programming back when I did that more exclusively).
I have just seen a reference in another discussion to a study of what accounts for good vs poor programming results, and a hugely predictive factor was the degree to which programmers were NOT forced into "social" working situations, but could have their own space - pay and experience mattered far less.
Someone where I work brought this up in reference to our workplace's growing use of open workspaces - pick your chair and work table spot for the day, and plug your headset into the IP phone, and set up your notebook and keyboard/mouse from your overnight equipment locker. This is beyond pairing - more like "herding" (cats no less).
Many of us in IT are cringing at the prospect, and desperately trying to qualify for the exemptions (or looking for other jobs). I am working mostly from home, and it is not fully set up at our worksite yet, but "The Doom" is approaching
.
I had the experience of working with a colleague in one of those settings at another site, and it was terrible ... for me. She was a very soft-spoken Indian, and her table-mates of the day often drowned her out when we were trying to collaborate via phone.
It seems some work situations/modes/personalities simply will not fit this model.
YMMV
I have just seen a reference in another discussion to a study of what accounts for good vs poor programming results, and a hugely predictive factor was the degree to which programmers were NOT forced into "social" working situations, but could have their own space - pay and experience mattered far less.
Someone where I work brought this up in reference to our workplace's growing use of open workspaces - pick your chair and work table spot for the day, and plug your headset into the IP phone, and set up your notebook and keyboard/mouse from your overnight equipment locker. This is beyond pairing - more like "herding" (cats no less).
Many of us in IT are cringing at the prospect, and desperately trying to qualify for the exemptions (or looking for other jobs). I am working mostly from home, and it is not fully set up at our worksite yet, but "The Doom" is approaching
. I had the experience of working with a colleague in one of those settings at another site, and it was terrible ... for me. She was a very soft-spoken Indian, and her table-mates of the day often drowned her out when we were trying to collaborate via phone.
It seems some work situations/modes/personalities simply will not fit this model.
YMMV
Throwing random individuals together to make a pair is going to even less successful than trying to build real teams that way. An ineffective pair is going to be less productive than one individual never mind two.
Programmers tend to be introverted on average, say compared to sales types, but in most cases they don't have a problem discussing programming with anyone. If fact trying to shup them up about it, is a bigger issue.
Programmers tend to be introverted on average, say compared to sales types, but in most cases they don't have a problem discussing programming with anyone. If fact trying to shup them up about it, is a bigger issue.
Right - collaborating does take that discussion, although it can be via IM chats for physically separated folks (more accurate sometimes, if not screen-sharing), but I was referring more to my employer's cat-herding plan ("cat houses"? ;-} ), with lots of people in close proximity.
Had pairs working together in late 80's doing agile programming - they reviewed each others code so they could discuss differences in coding style and content and ensure compatibility. I found a lot of bugs were avoided as differences in interpretation were clarified. It also led to high productivity due to competition between the programmers to produce high quality code quickly - neither wanted to be picked up for buggy code.
I'd find it very difficult to work with someone constantly looking over my shoulder.
While there are and should be training aspects around pair programing, it should not feel like you are being criticised, if it does you are paired up with the wrong person.
For the design and planning phase, the more eyes to search for flaws and suggest ideas the better. When it comes to actually writing code...well, to put it nicely, most developers tend to be rather "confident" in our ability and who among us doesn't believe in our heart of hearts that our approach is best?
While the knowledge sharing inherent in paired programming is positive, in practice, it's difficult to imagine a bigger barrier to progress than two developers sitting at a monitor and haggling endlessly over some trivial aspect of code.
More importantly, pair programming should never be substituted for a good peer review and testing policy which I suspect it sometimes might be.
While the knowledge sharing inherent in paired programming is positive, in practice, it's difficult to imagine a bigger barrier to progress than two developers sitting at a monitor and haggling endlessly over some trivial aspect of code.
More importantly, pair programming should never be substituted for a good peer review and testing policy which I suspect it sometimes might be.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
