Need your advice regarding pair/single programming approach
-
Give them a PC each you skinflint! What are you going to do, give one the keyboard and the other the mouse? :laugh:
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
It costs more when I let them do pair programming. :)
-
I started a new company, worked on my own for 6 months and saved enough to arrange infrastructure to start a team and hired two guys. Now, I want to seek your advice about putting them in pair or allow them to work individually? I think, as they have only one year of experience after graduating so, putting them in pair might lead to better quality of codes, on the other hand, by putting them on separate machines might increase productivity but may be less accurate. My personal opinion is to go for pair programming approach to ensure better quality code and when I am assured of their accuracy then allot them different machines with one trainee under each. If you have related experience please suggest me which is the better approach?
Do not pair....set them disjointedly but...beside one another. will increase their confidence..:rose:
Rating always..... WELCOME Be a good listener...Because Opprtunity Knock softly... Use http://www.google.com/transliterate/ for translator
-
If they really are newbies, I would pair program with them alternatively, and eventually let them pair program with trainees after that if you feel the urge. Have them pair program together right from the start seems a bit risky, and you will have to look over their shoulder anyway. Pair programming is usually made with a senior expert and someone else.
While I've never worked in a 'formal' pair programming environment, I agree with your view. Having two newbies work together seems like a recipe for disaster. Combining them with a more experienced engineer gains two benefits. The new programmer gets the benefit of experience, while the expert gets exposed to a less jaded viewpoint.
Software Zen:
delete this;
Fold With Us![^] -
If they really are newbies, I would pair program with them alternatively, and eventually let them pair program with trainees after that if you feel the urge. Have them pair program together right from the start seems a bit risky, and you will have to look over their shoulder anyway. Pair programming is usually made with a senior expert and someone else.
Rage wrote:
I would pair program with them alternatively, and eventually let them pair program with trainees after that if you feel the urge
This is a nice option. :D
Rage wrote:
you will have to look over their shoulder anyway
yes I have to check their code after they finish a module, can't take risk when it comes to quality of code.
-
DO NOT PAIR PROGRAM - IT IS THE WORK OF THE DEVIL!!! The one and only time I tried we almost came to blows - you need to be very careful when forcing people ot work this way: I've yet to see it done successfully.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
I didn't force them to this way I first asked them what would they prefer. Till now they are doing well. Hope nothing will burst in near future. If you are comfortable with it, Please let me know what went wrong when you tried the stuff. As I still have an option to revert to single programming, your opinion will matter. :)
-
Do not pair....set them disjointedly but...beside one another. will increase their confidence..:rose:
Rating always..... WELCOME Be a good listener...Because Opprtunity Knock softly... Use http://www.google.com/transliterate/ for translator
Did you experienced something similar/related. Please share it will be beneficial for us all.
-
While I've never worked in a 'formal' pair programming environment, I agree with your view. Having two newbies work together seems like a recipe for disaster. Combining them with a more experienced engineer gains two benefits. The new programmer gets the benefit of experience, while the expert gets exposed to a less jaded viewpoint.
Software Zen:
delete this;
Fold With Us![^] -
I didn't force them to this way I first asked them what would they prefer. Till now they are doing well. Hope nothing will burst in near future. If you are comfortable with it, Please let me know what went wrong when you tried the stuff. As I still have an option to revert to single programming, your opinion will matter. :)
You need to be very careful about how suited the 'pair' are to each other in terms of personality and character. If they clash it won't work or if one is a very dominant type and the other isn't. I've also seen 2 people who at first appeared well suited fall out over the most trivial of things and have to be split up. It is not a natural way to work: let them work as a team but not shoulder to shoulder. It's a fad and it doesn't work (IMHO). I first tried this 15 odd years ago before it was called pair programming.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
DO NOT PAIR PROGRAM - IT IS THE WORK OF THE DEVIL!!! The one and only time I tried we almost came to blows - you need to be very careful when forcing people ot work this way: I've yet to see it done successfully.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
digital man wrote:
I've yet to see it done successfully.
I've never had a problem with pair programming. As long as they do exactly what I say it will be fine - remember, pair programming means never knowing who to assign the blame to.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
-
digital man wrote:
I've yet to see it done successfully.
I've never had a problem with pair programming. As long as they do exactly what I say it will be fine - remember, pair programming means never knowing who to assign the blame to.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
Pete O'Hanlon wrote:
As long as they do exactly what I say it will be fine
and therein lies the heart of the problem... :)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I started a new company, worked on my own for 6 months and saved enough to arrange infrastructure to start a team and hired two guys. Now, I want to seek your advice about putting them in pair or allow them to work individually? I think, as they have only one year of experience after graduating so, putting them in pair might lead to better quality of codes, on the other hand, by putting them on separate machines might increase productivity but may be less accurate. My personal opinion is to go for pair programming approach to ensure better quality code and when I am assured of their accuracy then allot them different machines with one trainee under each. If you have related experience please suggest me which is the better approach?
-
Depending on their experience, get them reviewing each other's code occasionally.
Join the cool kids - Come fold with us[^]
This is an interesting alternate :)
-
You need to be very careful about how suited the 'pair' are to each other in terms of personality and character. If they clash it won't work or if one is a very dominant type and the other isn't. I've also seen 2 people who at first appeared well suited fall out over the most trivial of things and have to be split up. It is not a natural way to work: let them work as a team but not shoulder to shoulder. It's a fad and it doesn't work (IMHO). I first tried this 15 odd years ago before it was called pair programming.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
digital man wrote:
I first tried this 15 odd years ago before it was called pair programming.
:cool: Its simply great. Yes the point you raised is the biggest concern I have.
-
I started a new company, worked on my own for 6 months and saved enough to arrange infrastructure to start a team and hired two guys. Now, I want to seek your advice about putting them in pair or allow them to work individually? I think, as they have only one year of experience after graduating so, putting them in pair might lead to better quality of codes, on the other hand, by putting them on separate machines might increase productivity but may be less accurate. My personal opinion is to go for pair programming approach to ensure better quality code and when I am assured of their accuracy then allot them different machines with one trainee under each. If you have related experience please suggest me which is the better approach?
On a side note, the system analysis text book for the class I had this past summer called that "parallel programming". :sigh: There will soon be a crop of newbies claiming to be experts at parallel programming. :doh:
-
I started a new company, worked on my own for 6 months and saved enough to arrange infrastructure to start a team and hired two guys. Now, I want to seek your advice about putting them in pair or allow them to work individually? I think, as they have only one year of experience after graduating so, putting them in pair might lead to better quality of codes, on the other hand, by putting them on separate machines might increase productivity but may be less accurate. My personal opinion is to go for pair programming approach to ensure better quality code and when I am assured of their accuracy then allot them different machines with one trainee under each. If you have related experience please suggest me which is the better approach?
Congratulations on starting up your own company. If you remove the orange colour vertical stripes from the sides of your website, it would look better.
There are some really weird people on this planet - MIM.
-
I started a new company, worked on my own for 6 months and saved enough to arrange infrastructure to start a team and hired two guys. Now, I want to seek your advice about putting them in pair or allow them to work individually? I think, as they have only one year of experience after graduating so, putting them in pair might lead to better quality of codes, on the other hand, by putting them on separate machines might increase productivity but may be less accurate. My personal opinion is to go for pair programming approach to ensure better quality code and when I am assured of their accuracy then allot them different machines with one trainee under each. If you have related experience please suggest me which is the better approach?
Amar Chaudhary wrote:
putting them in pair might lead to better quality of codes, on the other hand, by putting them on separate machines might increase productivity
Your assumptions may or may not be true. If both of them are beginners, pair programming may not lead to big increases in code quality. On the other hand it may lead to better productivity because they are going to be less likely to goof around and spend their time in CP Lounge ( :-\ ). However, it really boils down to the fact that humans are complicated and unpredictable: some people will enjoy pair programming, be productive and deliver high quality code. Others will hate it, argue constantly and deliver nothing except bad vibes. The only way to find out how it ends up is to try it. If you can sell the idea to your employees up front that is a very good sign already. Good luck.
-
I started a new company, worked on my own for 6 months and saved enough to arrange infrastructure to start a team and hired two guys. Now, I want to seek your advice about putting them in pair or allow them to work individually? I think, as they have only one year of experience after graduating so, putting them in pair might lead to better quality of codes, on the other hand, by putting them on separate machines might increase productivity but may be less accurate. My personal opinion is to go for pair programming approach to ensure better quality code and when I am assured of their accuracy then allot them different machines with one trainee under each. If you have related experience please suggest me which is the better approach?
I quite enjoy working in pair with the other myself. --Carlo The Schizoid
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Congratulations on starting up your own company. If you remove the orange colour vertical stripes from the sides of your website, it would look better.
There are some really weird people on this planet - MIM.
Sure - we are working on new design. :)
-
I started a new company, worked on my own for 6 months and saved enough to arrange infrastructure to start a team and hired two guys. Now, I want to seek your advice about putting them in pair or allow them to work individually? I think, as they have only one year of experience after graduating so, putting them in pair might lead to better quality of codes, on the other hand, by putting them on separate machines might increase productivity but may be less accurate. My personal opinion is to go for pair programming approach to ensure better quality code and when I am assured of their accuracy then allot them different machines with one trainee under each. If you have related experience please suggest me which is the better approach?
Pair programming only works with people who can talk to and co-operate with each other. You can't know that if they're both new to the company, so start them off solo, but tell them that they will be paired soon. Then just watch how they get along and how they prepare for it -- a good indicator will be that they will pay more attention to commenting code if they know they will be paired, because they know it will save them time later (you're allowed to hint at that).
I wanna be a eunuchs developer! Pass me a bread knife!
-
Sure - we are working on new design. :)
Rajesh R Subramanian wrote:
If you remove the orange colour vertical stripes from the sides of your website, it would look better.
I couldn't be bothered to download and edit the page to look at it without the stripes, so I took a screenshot and resized it to skip the stripes. He's bang on. It looks a Hell of a lot better. Getting rid of those huge, winding paragraphs would help, too: HBCC-Tech specializes high quality, cost-effective software solutions. Our creative, dynamic, and passionate IT professionals aim at exceeding customer expectations with high quality, tailored solutions, structured project management, and effective communications throughout. The website has become a vital part of marketing strategies, where quality is an asset. HBCC-Tech provides customized solutions to suit your needs. User experience is paramount, so much emphasis is given to layout, intuitive navigation, reaction times, and ease of use. HBCC-Tech follows systematic yet flexible methodologies and software-development processes. Our focus is continuous process improvement, to provide state-of-the-art service and solutions.</p> <p>We service existing software applications, and develop new solutions to strengthen and support your business strategies, to help achieve the mission and vision of your business. In this fast paced globalised business world, a company can't afford errors in the website which is one of the most important medium to communicate with its customers. A minor error on website can adversely affect the image of the company in the eyes of its users In fact, get rid of the word "error" altogether -- talk about "monitoring" and "metrics". Notes: -- You started off with US spelling, then drifted. Choose one, and stick to it. If you can't get the little things right on your own site, no-one else will trust you to build theirs. -- Don't 'justify both"; leave a ragged right edge (it really does look and read a lot better that way). -- Put an extra non-breaking space after each terminator (full point, question mark, etc.); it lets people know in advance where the sentence ends, so they read it better (cadence, and whatnot -- don't worry about the details; just follow the tried and trusted methods). -- And, for Heaven's sake, remove all the "coming soon" notices and graphics. People don't buy stuff from Geocities sites!
I wanna be a eunuchs developer!
