Post #120,569
10/8/03 11:19:22 PM
|
Pair programming for coding newbies?
I'm teaching a Programming Fundamentals course next term and I was considering trying some small team exercises where students work together on problems. My thought was to divide them up into two-person teams and use VNC to let them work in the same IDE together. (I realize this isn't "real" pair programming, ala XP, but they're beginners.)
I think this might give them a little more confidence, let them teach each other the material while learning it more deeply themselves and give them a taste of teamwork.
So, good idea, bad idea? Thoughts?
...Bueller?
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,579
10/9/03 2:12:58 AM
|
Could be interesting.
But I think you'd need to police it, especially if they're not on the same PC.
What I found works for pair programming:
* 1 PC, two programmers.
* The person who isn't on the keyboard needs a pad and pencil.
* Similar skill levels helps.
* For actual programming, the person least familiar with the code should be on the keyboard.
* For learning to program, I'd put the person least familiar with the language on the keyboard.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #120,599
10/9/03 8:46:30 AM
|
Good points
>* For actual programming, the person least familiar with the code should be on the keyboard.
Why is this?
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,605
10/9/03 9:26:47 AM
|
Like Alex says below
Watching something happen is not the same as working the grey matter to figure things out. You retain far more just by typing it in than by watching. That's why frequently if you take notes you find you don't need them when you'e done, but if you don't take them, then you need them. ===
Implicitly condoning stupidity since 2001.
|
Post #120,613
10/9/03 10:45:37 AM
|
Got it
I've been talking to the instructors who usually teach this class and they've told me that the main hump for newbies to get past is to just jump in and start coding, not worrying if it works right the first time.
I thought that it would help if they didn't feel like they were going into this all by themselves. In addition, by having students take turns coaching each other on the material, I can give them all a chance to get a better handle on the concepts.
I got the idea from a course I'm taking where the instructor encourages this kind of behavior, even to the point of having an online discussion board where students can share tips and tricks and ask questions if they get stuck on homework or projects. (He monitors the board so that students aren't just passing the answers around.) It works very well for me and I find I like the open community feel.
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,703
10/9/03 11:27:17 PM
|
Separation of thinking and typing.
Ideally, you want one person thinking about the algorithm and the other person thinking about how to code. In practice, there is considerable overlap, of course, but if the person not on the keyboard is the most familiar with how the code in question already works, he is forced to communicate this to the person driving. This puts the programming->coding communication out in the open where both heads can think about it.
It's also damn hard to do right. :-) But making the effort is usually good enough.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #120,592
10/9/03 7:14:37 AM
|
I found PP a skill that's hard for me.
I find it very hard to in non-equal teams. I suspect that pairing quick learners with quick learners and slow ones with slow ones is the key to success. Hence, don't do it till you or your students learn who is who in the class.
--
OK, George W. is deceptive to be sure. Dissembling, too. And let's not forget deceitful. He is lacking veracity and frankness, and void of sooth, though seemingly sincere in his proclivity for pretense. But he did not lie.
[link|http://www.jointhebushwhackers.com/not_a_liar.cfm|Brian Wimer]
|
Post #120,595
10/9/03 7:28:56 AM
|
Bingo.
The slower student will just "coast" and learn very little. Watching something happen is not the same as working the grey matter to figure things out.
Alex
"Don't let it end like this. Tell them I said something." -- last words of Pancho Villa (1877-1923)
|
Post #120,600
10/9/03 8:49:40 AM
|
Agreed
I don't think I'll introduce it until after the first week. I also want them to get used to working with others and sharing knowledge.
I don't want this to be an excuse for the slow ones to just coast so I have to make sure that there's good coaching going on.
They'll also have individual assignments that they'll be responsible for completing on their own.
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,598
10/9/03 8:37:55 AM
|
Re: Pair programming for coding newbies?
I've used pair programming when teaching Java and C++ and it worked well. Are the students going to be next to each other even though they are on separate machines? I think it is essential that they be close enough to /talk/ with each other easily.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #120,601
10/9/03 8:50:12 AM
|
They'll be next to each other
Or at least very near each other. The hard drives are removable as well, so I can team up students who don't normally sit next to each other.
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,666
10/9/03 6:16:12 PM
|
Another idiotic software idea
If I were a top-notch programmer, the very last thing I'd want was someone bugging me of reformatting my code.
Programming at its best is a solitary endeavor.
-drl
|
Post #120,667
10/9/03 6:23:50 PM
|
Beg to disagree...
Coding is best when solitary.
Programming, the design and development of the interfaces and data structures, works best when shared among a competent team. There has to be agreement as to how things get done with a minimum of compromise*. Once everybody knows what is to be done, go whereever you want and do it. Preferably alone...
*Compromise guarantees that nobody gets exactly what they want.
|
Post #120,681
10/9/03 8:51:53 PM
|
With one minor difference in my case
I'd like to get my students used to working with other programmers, since in real life you may code on your own but you're usually part of a team.
Also I'd like to reduce the 'fear factor' of staring at a blank text editor window wondering where to begin.
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,685
10/9/03 9:31:02 PM
|
Where to begin?
Much of programming is just mechanics of various idioms - so teach them idioms.
Plus - good programmers are likely to be self-motivated. If you give them touchy-feely instruction they will resent it and more, they will see right through the BS. I always taught for the best students and hoped they'd pull the rest up a level - and it worked.
-drl
|
Post #120,701
10/9/03 10:51:34 PM
|
Details?
What's your approach for newbies?
What kind of academic setting was this?
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,704
10/9/03 11:29:08 PM
|
Re: Details?
I taught calculus and linear algebra to 1st and 2nd year engineering students at Ga. Tech - that's how I paid for school :) Because everyone had to take core math classes at a non-trivial level, the sections were huge - a 5 hour class consisted of a professor lecturing 3 hrs a week to 200 or so students, while 5 or so teaching assistants would conduct the other 2 hrs as problem solving, test discussion etc. Since what we did was more or less up to us as long as we covered the appropriate sections of the book, I used at least half the time explaining the ideas in practical terms and illustrating with zillions of examples, particularly from physics which gave them a head start on the core physics courses to come the next year. I made them do hundreds of problems which made a lot of extra work for me, but it was well worth it because my students were *good*. We almost always topped the list of TA sections. I never coddled them but my door was always open. I explicitly used Feynman's advice to aim at the best students - when you do this a weird "symbiosis" takes over, the mental climate of the class gets more charged, and the middle students do better - so the main things were lots of mechanical work - idioms - practical explanations, and aiming at the top students.
In the context of programming - if it's a beginning class then what they most need to master is the mechanics of making programs - understanding what a compiler does, what a linker does, generalities of machine architecture etc. Then throw algorithms at them and have them implement them in the language of choice. If they are comp-sci majors they can handle C as a first language - like cranking out multiple integrals and eigenvectors, the very process of working with C will provide a firm basis for higher level work. "Pair programming", "XP" and all that BS at an early stage sounds too much like "new math". If you had time to prepare (this can't be overstressed in teaching - preparation is everything) you could work out a step by step program for writing a complete, non-trivial application, say, a Rolodex, a comp-sci calculator, etc.
In short - in the early stages, play God, be God, live God. They want to be instructed. The NEED to be instructed.
-drl
|
Post #120,799
10/10/03 1:18:59 PM
|
Good points, thanks
I'm not trying to teach XP at this point, just brainstorming about new ways to approach an introduction to programming.
Westwood is not a traditional college, but a technical/vocational school that offers four year degrees as well as associate certificates. Therefore, our student demographic consists mainly of folks who would not do well in a traditional university setting. Therefore, while we certainly use most of the usual teaching techniques, we also try to think about creative ways to present the material to our students.
So, we keep lecturing to a minimum, hands-on practice to a maximum. The reason I was thinking about pairing students up was two-fold:
- Our class sizes are usually fairly small, from 9 to twenty students, so the team work would be manageable from my perspective.
- One of the common issues we face is where students get stuck right at the beginning, either with little idea how to proceed or so anxious that the code they write or algorithms they design won't be 'perfect' the first time out of the gate that they get incredibly frustrated. (We've occasionally had one or two students burst into tears when the compilers reported errors in their code.)
My thought was that pairing them up would take some of the pressure off them as individuals and create a situation where each member could encourage and motivate the other.
But like I said, it was just a thought. I'm not married to it.
-Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,844
10/10/03 6:17:38 PM
|
How about teaching them how to template?
I rarely start a new program from absolute scratch. Instead, I have a "template" which is the bare bones of a working program which I copy and then proceed to modify. I found this very necessary when writing programs for Windows 3, as there was maybe 150 lines of overhead that every program had.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #120,867
10/10/03 7:47:57 PM
|
Good idea
We'll be using Visual C++ 6 in class so we'll be starting with a built-in template but it's a useful skill nonetheless.
It also helps you get past the "blank screen" syndrome if you can start writing some things right away.
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,733
10/10/03 7:53:11 AM
|
Ok, to extend my point
I think that it may do your students some good to distinguish between the formative and executive phases of building a program.
I would consider the formative phase the part where you figure out what the program is supposed to do, how it is supposed to do it, and what tradeoffs there are to play with.
This generally exposes the hardware constraints, the major functional elements to be dealt with, and the interfaces between them.
In my experience, this is the phase that is generally shared between members of the group. It may be that there is just a driver guy, a firmware guy, and an app guy, so there are clear boundaries. Even in this case, each guy should understand how the interfaces work at least a level down on the other side of "his" interface. For example, the driver guy should understand at least one level deep how the firmware and the app work as it connects to the driver. This, I think, is harder for many to share because it is two minds viewing the same problem differently. It is a concept that is probably worth getting across to the students.
The coding or executive aspect is easier to show, but is really the lesser part of the actual program. Some will be more verbose than others. Some will be prodigal with resources. Some will degrade performance to save resources. You can lead by example and demonstrate good coding practices, but they will learn in real world mode by doing maintenance and enhancements of existing programs. That's where you learn idiom and technique. One section of code works well but needs to be extended to do something else; you learn what makes this good code. Another section of code really sucks and has to be replaced; you learn what makes it bad code. This is pretty much the way I learned. In the end though, coding is just something you do the way you like to do it.
To my mind, the classroom exercises are simply to teach basic technique and give experience with the tools. The rest comes as you grow. You have to be able to learn and adapt or your're just not going to make it. Which borders on tautology.
Apologies for rambling on,
Hugh
|
Post #120,801
10/10/03 1:24:14 PM
|
My thoughts as well
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,748
10/10/03 8:48:46 AM
|
Consider it as parallel processing
You can repeat the activity to learn (code something twice, accuiring experience with time) or you can have another person doing it in parallel to you, so you benefit from his/her mistakes.
--
OK, George W. is deceptive to be sure. Dissembling, too. And let's not forget deceitful. He is lacking veracity and frankness, and void of sooth, though seemingly sincere in his proclivity for pretense. But he did not lie.
[link|http://www.jointhebushwhackers.com/not_a_liar.cfm|Brian Wimer]
|
Post #120,800
10/10/03 1:23:08 PM
|
That was my thought as well
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #120,886
10/11/03 1:12:59 AM
|
Re: Another idiotic software idea
If I were a top-notch programmer, the very last thing I'd want was someone bugging me of reformatting my code.
Me too! Fortunately, pair programming is not like that at all. When I work along, I am a pretty good programmer. But I always produce better code when I pair.
There's an interesting rhythm when pairing. When I have the keyboard, I'm very focused on solving the problem that's before me, getting the syntax right, getting loop conditions correct, all the nitty gritty details of the problem at hand. At a certain point I have to stop and look forward and start plannning where the software needs to go. If I were alone, I would kick back a bit and start planning my next coding burst. But when I am pairing, my partner has been doing that already. He's been watching the code and making suggestions, but because he has not invested as much mental energy in the details, he can use his spare brain power for some longer range planning. When I slow down, he is ready for a turn at driving (i.e. having the keyboard). We switch and while he drives, it's my turn to take the longer view.
So, my solo programming sessions are a pattern of quick bursts of coding spaced by periods of reflection. But a pair programming session is more consistent, with the pairs switching between long-range and short-range planning as they go.
It takes practice to be a good pair programmer. The first time you try it, it will probably feel awkward. But give it some practice and its quite possible you will enjoy it more than you would expect up front.
Well, anyways, that's my experience.
Anybody live near Cincinnati that would like to pair with me?
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #120,889
10/11/03 1:50:24 AM
|
Re: Another idiotic software idea
Well, we had pair chemistry lab back in the day, and my pair had quite a pair, so I was OK with that :) At first I hated the idea and then it grew on me ...
-drl
|
Post #120,894
10/11/03 4:31:03 AM
|
Speed and pair programming.
No not *that* kind of "speed"! I've found that two programmers pairing can go noticeably quicker than two programmers working independantly in parallel.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #120,948
10/11/03 7:52:40 PM
|
Re: Another idiotic software idea
I really enjoy pair programming, too. In my experience, one of the most annoying parts of programming is making tactical mistakes in the implementation. This is the level that's a little higher than the level of syntax correctness, but lower level than overall system design. When you are hacking, you need to devote fairly close attention to getting the code right, with the result that sometimes you can write some really inelegant and ugly code that is still technically correct. And since you paid so much attention to it, you can't see that it's ugly until a few days have passed and your mind is no longer focused on it-- at which point it's usually acquired enough dependencies to make fixing it anoying. Having a partner watching the code take shape means that he can point out these errors just as they are happening, so that you can correct them before they accumulate a set of dependencies that will slow fixing it.
Refactoring and test sets let you fix these kinds of errors faster, but pair programming means that you frequently don't make them in the first place.
|
