I agree that competitive environments discourage collaboration, and I find that decreases the quality of the learning experience. However, I've now run a total of 11 three-week sessions with intermediate programmers in which we have dropped students due to inactivity or due to not meeting weekly checkpoints, but for the most part managed to have an *incredible* amount of collaboration between our participants. Every one of our students spends at least a couple hours a week helping the other students, all in a completely open environment where they can overhear one another's conversations. We don't require this collaboration, we only tell them it's allowed and encouraged.
What makes it so that an environment in which you can expect a third or more of the folks who start the course to be "weeded out" by the end of the course NOT become a competitive pressure cooker? I think it's the structure that does it.
Here are some the things we do that I think allow us to make cuts without hurting our learning environment:
- We give each student a LOT of support. We have several mentors and two instructors in each session, so that the Student::Mentor ratio is basically 3:1 or less. Each student can expect to have at least a couple hours a week of one on one collaboration with a mentor/instructor.
- We allow the students to propose their own assignments based on a theme, which means that they can choose something they at least *think* will be successful.
- We don't do one pass over assignments. Students send in their work and then fellow students and mentors review it and make suggestions, then they resubmit. Then instructors look it over, give further feedback and instructions, and then they resubmit again. We repeat the process as much as necessary to get the student to pass the assignment with sufficient quality.
- We provide all of our exercises and lay out all of the requirements for the course up front, preventing the student from running into nasty surprises mid-session that would knock them out.
- We release all of our materials so that prospective students can review them to see if the course would be a good fit for them.
- We carefully design exercises so that they can be worked on in the open without any spoilers, which means that unless they're physically doing the work for another student, it's impossible for our students to "cheat" by helping one another. In fact, collaboration around the dependencies and common issues between their projects is actively encouraged.
These things combined have made it possible to make a course that says "Yes, we do fail people who don't meet the expectations", but at the same time says "If you feel like this is something you'll be capable of doing, you'll have endless support from us to make it happen"
The trouble with this model, and the main reason why I'm taking this course, is because I fear it'll break down hard with novices and advanced beginners. There is a wide space between a simple study group and what we're currently doing, and I don't think this sort of environment we created would be suitable for new programmers without sufficient tweaking.
I want to be able to find a way to make sure we're spending our very limited resources wisely on the students who are "willing to put in the effort" without shutting out those who are trying in earnest but not being well served by our teaching style.