• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Trainees working in pairs - good solution?

 
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I run an internal 3-day intro to Java course where I work for a variety of people (developers, technical people, web people, scientists). I am just in the process of re-working this course considerably to introduce OO much earlier rather than ploughing straight into all the syntax.

Anyway, I want to get more of a team atmosphere going this time, and we're going to be sitting around designing our application together on paper etc before we start coding.

The way we are set up here is that trainees each have their own PC in the lab to work on. But I can't decide whether to:

1) Do it the usual way and each trainee sits at their own PC and does their own version of the application

2) pair trainees up at each machine and make them work together on one application

3) make project teams of 3 or 4 people to work partly at their own PC's but all contribute to one application at the end

At the moment I'm liking option 2 because I think it will help them learn, and will also make it easier for me than helping individual people all working on separate versions of a a project. However, how do I sell it to them...is it even a good idea?

any experiences/comments?
 
cowbird
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have some experience in extreme programming Java projects, and 'pair programming' could be a good idea in some cases...

In XP the pair switches the keyboard often (every 20 minutes) so both members stay focused. The one typing concentrates on the code he's writing, the other one helps him with that lines of code, but also thinks about how that little part fits into the whole. The advantage is that you make less errors (even typo's, they're immediately cought by the non-typing pair-member) and that you learn faster. Mostly, one of the two pair-members knows (a little) more about the particular piece the pair is writing, and he explains this to his pair while coding.

I don't know the last advantage will come out in a beginner's Java course, because both pair-members are not familiar with Java, but with a mixed (different levels of experience) group, it's definately a great advantage. A disadvantage in your case could be that 'lazy' students rely on their pair and don't type or think much, and don't learn much in that way. And that's hard to check as a teacher... There will also be a lot of noise in your classrroom, because a pair should constantly be talking to eachother.

Maybe your third option is better for a beginner's course. If you make teams of 3-4 individual programmers, they also need to communicate a lot, but each member gets responsability for his own piece of the app. So every student needs to write the code for his part on his own. This way of working also forces your students to agree on the general design as a team, design common interfaces and they'll encounter some of the problems of working together on a Java project, just as in real life... So maybe option 3 would be better than the second for a beginner's course!

You could also bring the pair programming into option 3, and tell the students that when coding a difficult piece (or something they're totally unfamilir with, they can ask a team member to pair program for a while...

When I teach UML, I make teams of 3-4 students to 'design' some application, they learn a lot from and about working together and it's the closest you'll get to the real life thing IMHO.

Let us know how it goes ! Good luck !

[ December 23, 2004: Message edited by: Jef Cumps ]
[ December 23, 2004: Message edited by: Jef Cumps ]
 
Ben Wood
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Jef, this is valuable input. One thing I wanted to avoid this time is allowing people who just aren't getting it from being left behind simply because they are sitting quietly at the back. I thought making them work together would keep the pace of the group up as a whole because they can help each other; this would help both them and me.

The team idea is good. I suppose they could decide amongst themselves who will implement which code. I'll give that some thought, as before your post I was leaning towards the working in pairs idea.

I have decided to use a CRC card approach to the design stage before they get coding. That way they should understand the classes they need to write. As a user of XP techniques, do you have any experience of using CRC cards in a teaching environment?

Previous delegates thought the course was OK (training is only a very small part of my job, so I'm by no means a pro!), but had much mroe trouble understanding the concepts than they did learning the language syntax. I thought CRC would be a good way to explain OO design.
 
Jef Cumps
cowbird
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I recognize the problem about understanding the OO stuff in a course. When I give a 5-day long UML course, I'm supposed to spend 1 day on OO and 4 on UML. What I do with a not-OO-experienced group is one full day OO prinicples and exercices, and then LOTS of OO design and practices in the UML part, maybe even 1/3th of the time. People without OO experience really need al lot of time and exercices to make the 'switch' and start thinkikng in objects, especially when they were programming structurally before...

I never used the CRC cards in a course, but did use them in a project once. I think they can be very valuable in your course! They'll ease the design and splitting up the work. And they stimulate some good OO principles like giving a class the right (and not too much) repsonsability and stimulate refactoring...
 
reply
    Bookmark Topic Watch Topic
  • New Topic