Cooperation in CS Education? 412
fwitness asks: "The college I currently attend, like most colleges, is on a form of 'Academic Honesty Policy'. It has been explained to me in various ways, but mostly it boils down to: If you catch someone's code out of the corner of you eye, that's cheating, and you need to come up with your own 'original' ideas. I'm a CS major, so I write a lot of code, and I imagine when I get in the work force, I'll be writing a lot more. The difference is, in the workplace, I'll be in a team of people. I won't have control and I'll have personnel and political issues to deal with in addition to my job. So far I've had one class that actually demonstrated this principle, and I'm pretty much finished all my CS courses. I know the college has to do this so they can somehow grade 'my' code and assess my performance. Isn't there a better way? A way that students can be taught to work as a team yet still be able to tell who is pulling their own weight and who is not?" I always enjoyed working in teams during my college education, yet found that projects, where you were allowed to work with others, were few and far between. Do you all feel that technical courses should show a bit more emphasis on working with others, or is this just one of life's lessons that you pick up as you go along?
My perspective as a current student (Score:2, Informative)
Teamwork is a really big deal (Score:3, Informative)
The more experience you can gain working as part of a team the better. Try spending time in fun projects sponored by you're local LUG, or the chess club or whatever. The other thing that will help a lot with this is sports, I played all kinds of team sports (hockey, football, rugby) when I was a kid and I think the experience really helped me with my proffessional development. The time I spent coaching a bantam (14 and 15 year olds) football team in high school was especially helpful when I became a team leader a few years ago.
In short, it wouldn't hurt to push for more team based assignments but just about any experience you can get working or playing with others can be helpful.
In ebgineering... (Score:2, Informative)
I also believe that you can never rely on a university to teach you anything about working a real job. Just talk to employers, they are always complaining about how students are underskilled. That is why they don't expect anything from you for the first year or so.
The only naswer I have seen that worked well was the co-op program. If you are at a school that has strong industrial ties then yo uare all set. Otherwise, you have to learn as you go when you get out.
Great programmers steal code (Score:4, Informative)
(Of course the distinction needs to be drawn between programming and 'true' CS/Information Theory etc, but you get the point)
The thing is, CS education treats programming too much like English - code may be 'speach', but it is not an essay. Yes, outright copying of code is still plagiarism, since you did not do your own work, but...
In the 'real world' you rarely find a situation when people solve the same problem in parallel.. So comparing implementations for 'originality' is not an issue. 'Parallel' problem solving should only be used in introductory courses. After you know the language/concept (around the upper 200 level classes) you should not have many 'solo' projects.
Instead, most projects should be solved by the group, and should be large enough to include a 'project management' component as part of the assignment. The problem should be too large for an individual to address in the time given - barring brilliance. Forced decomposition of the problem, division of the work into separate tasks, accountability on how well each part is done.. These are the things that will make for a successful team project.
Should cooperation be restricted? Not at all, but everyone should have their own area of responsibility.. You can have teams that compete, but better yet, involve the whole class and rotate responsibility.. Allow students to assign roles to themselves, and watch top coders, and star organizers emerge..
Idealistic? Sure.. Will some lazy bums slip through the cracks by riding on the coat-tails of their more talented and industrious peers? Of course.. All systems can be circumvented unless you want a full-time TA watching each student.
So what? These people will only do themselves a disservice in the 'real world' by demonstrating incompetence if they choose the wrong field - or, well, hey, what's wrong with coordinating and pilfering the efforts of others, as long as the job gets done?
If the coders can't make the pieces fit, but someone else can, that someone is a valuable asset to a company.
How many of the Linux developers out there have rewritten the kernel from scratch, just to add a feature? Everyone stands on the shoulders of those who came before.
Re:Well... (Score:2, Informative)
Having relatively recently graduated from college, I don't really see a way that this can be done. Most of my group experiences involved maybe half of the group caring about their grade, and the other half being ok with a C. You then end up with an extremely unbalanced work load as the ones who care the most do the most and produce the better product. Then they usually have to go around and fix up the people's work who really didn't care as much. All in all, it rarely leads to a produtive group and doesn't teach you much about the work force.
Oh boy can I tell you just graduated from college. What you just described is _exactly_ how it works in the real world.
Very, Very, Very rarely will you be fortunate enough to have an assignment to complete on your own. The vast majority of the time you will be working with a team. A team consisting of:
No this is not an exageration. This is how the real world works. The 10% of us who can pull our own weight often times pull the weight of the other 90%.
I've never had the pleasure of being on a team where a majority of the team members were usefull or productive. Perhaps I'm just really unlucky. If that is the case, I hope you end up working with a better calibre of folks than I have!
Take care,
Brian
100% Linux Web Hosting - 0% Windows [assortedinternet.com]
A couple methods I've experienced (Score:4, Informative)
For small projects, if you talk with anyone or get ideas from websites, etc, you have to cite your sources/collaborators. This doesn't mean wholesale copying of code from sourceforge or friends (as more than one student has discovered), but it at least lets the prof know if you had outside input.
For the team projects I've been on, there were a few methods used to get around some of the problems like slackers and code accountability:
- You pick your team members. If you know that someone is a slacker, you can try to avoid being on the same team.
- Projects involve numerous separate tasks. This helps in terms of delegating code to ALL the team members, so one or two people aren't stuck with all the programming.
- Team member evaluations. At the end of the project each team mate gives a grade to every other team mate (anonymously) for their code quality and project involvement. Each individual's grade is then composited from the Project Grade and each member grade. The assignment can get an A, but if you slack off, you can get a D or even F because your team mates graded you poorly.
Additionally, big projects are broken up into different stages, so you end up having a grade for each stage of the assignment, which is coupled with number 3 (above) to give an accurate reflection of the student's abilities.All in all, the system seems to work pretty well. The nice thing is, if it's a REALLY big project and your team has no hope of completing all the functionality, the prof can still evaluate your abilities based on what has been done.
Maybe not the best, but it worked for me :)
Re:Well... (Score:3, Informative)
You had me up to the bit I've bolded...since you are recently graduated, you clearly haven't yet realized that what you describe is EXACTLY how most teams work. It sounds to me like you have had some EXCELLENT real world experience and have learned a LOT about how the work force works. You labor under the misconception that graduation magically changes all those mediocre people into excellent. If you are extremely lucky, you will land in a team where everyone works their tail off and is dedicated to success rather than adequacy. Should this occur, hold onto the job for dear life.
Meanwhile, reflect on your experiences with teams in college. Learn how to motivate your peers. Let me know if you ever figure out how to turn a lump into a go-getter...