<p>I might push back against the core idea here, and this gets to the idea of the central mission of the course of study.  Within my course, teamwork is not a primary goal upon which I will assess my students.  This is not to say that I don't value it.  I think that there is <em>great value</em> in paired programming, but I approach this only as a salesman, not as a taskmaster.</p>

<p>I get real buy-in.  On my most recent lab, >85% of my students have opted for two people, one-screen, driver/navigator paired programming.</p>

<p>That said, I never <em>require</em> paired (or group) programming.  I allow students to opt into paired programming if they wish to, and I sell it like crazy, but for some of those Lone Rangers, the idea of working with another person can be intensely frustrating.  Where this becomes a big problem is where they begin to hurt the education of their peers by simply doing the work themselves.  Some of these students may never really warm to the idea.  While I want to teach good team-working skills, I am unwilling to jeopardize the education of my middle- and low-flying students in order to force the high-fliers into an activity that they really don't want to engage in in the first place.</p>

<p>Even in this environment, there can still be group projects, but they would involve differentiated responsibilities:</p>

<blockquote>
  <p>Person A is responsible for parts 1, 2, and 3 of the project, while Person B is responsible for parts 4, 5, and 6.  Person C is responsible for QA.  Design your APIs together, and get them approved by me prior to the start of any actual coding.</p>
</blockquote>

CC BY-SA 3.0
2018-03-13T20:26:03.267Z
I agree that group/paired programming can be frustrating to stars, and I certainly don't wish to squelch their enthusiasm and creativity.  But I, as a teacher, am evaluated on, among other things, inclusion of group projects.  Indeed, student collaboration is one of the overarching goals of my district.  So it's THERE, whether I, or they, like it or not.  And mustn't we all, at some point, be able to work with others, even if it is frustrating, or slows us down?  How many Knuths are there in the world?  Who are ALLOWED/ENCOURAGED to work alone, because they are superstars?  Not many.
Java Jive
CC BY-SA 3.0
2018-03-13T20:26:33.320Z
That being said, I do think it is important that we (CS educators) allow superstars to define their own paths when appropriate.  I always have a couple, and they are a joy to watch.  Balance.  In everything.
Java Jive
CC BY-SA 3.0
2018-03-13T20:29:56.907Z
I agree with @JudyOakley here. Student's need more in their education than technology. The workplace demands it. So does being successful in many Colleges and certainly in Grad School. Your introverts aren't well served by letting them hide and your superstars aren't well served by letting them work in too narrow a range. Some education is hard. But _what_ is hard is different for everyone.
Buffy
CC BY-SA 3.0
2018-03-14T18:11:37.827Z
Since the original question was predicated on the assignment being a group project, this answer is not on topic.
Lee Mosher
CC BY-SA 3.0
2018-03-14T19:13:31.553Z
@LeeMosher Interesting point. Personally, I think that answers like this should be okay. In light of your observation, though, [I created a meta](https://cseducators.meta.stackexchange.com/questions/379/frame-challenging-questions-on-cseducators) to find out if the rest of the community feels the same way.
Ben I.
CC BY-SA 3.0
2018-03-15T02:47:28.350Z
@JudyOakley The core issue with (school) group projects that everyone overlooks is that you will _never_, in any other arena, face such a broad range of ability levels.  Lone-ranger programmers are often just skilled at what they're doing, and would rather not deal with people behind them in knowledge. (After all, not everyone is cut out to be a teacher.) These programmers tend to do well in classes, then go on to Google/Microsoft/Facebook where they work quite happily in teams with other skilled people.  Further, top companies usually have an "individual contributor" role made [cont'd]
apnorton
CC BY-SA 3.0
2018-03-15T02:47:33.330Z
... for highly-skilled programmers who would rather manage their own projects. I understand the desire to encourage teamwork in school, but I would strongly suggest allowing people to work independently if they feel that strongly about it.  Or, if absolutely required, let people choose their teammates, and the problem will sort itself out.
apnorton
CC BY-SA 3.0
2018-03-15T03:59:52.537Z
I'd like to point out that current thought among the companies that are hiring the "superstars" is that people who can code are a dime a dozen, and what they really need are people that can both understand the code _and communicate it_. Forcing high-fliers into group interaction is not crippling them (they will have plenty of other opportunities to expand their coding), it is an attempt to teach something they badly, badly need to learn.
Logan Pickup
CC BY-SA 3.0
2018-03-15T12:31:14.457Z
I was also the kind to do most of the work in a duo, while I was still explaining what I have done to the other. I like this idea. It's basically choosing on what you focus at the moment, teamworking or polishing technical skills. At the age of university, we're old enough to understand that team skill exists and must be polish but we can also have the right to polish further our expertise.
Walfrat
CC BY-SA 3.0
2018-03-15T12:34:27.360Z
@LoganPickup we could also need someone  who can code, manage his project, write the specification, communicate perfectly and live right next to the company without child or husband/wife. But this is of course happens pretty much never, you have to do with what you have, and that's why they're things like screening in interview, organization, coding standard, project manager, technical leader to help for that.
Walfrat
CC BY-SA 3.0
2018-03-15T14:32:14.610Z
@Walfrat Yes, companies would like a perfect employee; that's not my point. My point is that communication and collaboration skills are becoming _more_ valuable than coding skills, so long as you have at least _some_ coding skills. This is a hard requirement for any kind of agile development, for instance.
Logan Pickup
CC BY-SA 3.0
2018-03-13T20:09:03.447Z
2018-03-13T21:48:48.233Z
2018-03-13T21:48:48.233Z
Ben I.
<p>This is really a separate approach from my first answer, which has received some push-back.</p>

<p>It's worth noting that many of these loners are simply students who are substantially ahead of the curve.  One way to really want to engage such students in pair programming is to pair them with each other.  This will create something of a Dream Team.</p>

<p>Give them the assignment, but tell them that their goal is to produce the coolest thing that they can that utilizes the concepts that the lab is developing within the time before the lab is due.  Tell them you're excited to see what they can come up with, that you'll allow them to present their work to the group at large, and that if it's a cool enough idea, you may use it as a launching point for a future lab for later generations of students.</p>

<p>As an aside, there is no reason to restrict this approach to the high-fliers.  It can be reasonable to allow students to propose modifications to the labs if these modifications excite the students.  It involves more work on your end, but you'll get better output and (more importantly) more engagement and buy-in from your students overall.</p>

CC BY-SA 3.0
2018-03-13T21:00:07.280Z
you are right on the money, and in a good classroom environment, these things will happen organically.  In my current project, which initiated this question, I've had two groups go "Dream Team" on me and implement far and above their specifications.  This has, in turn, fueled other teams to want to "get finished so we can try to do that".  It's awesome and amazing.  I don't know if I could formalize it in the future...but I can maintain a classroom that fosters openness and curiosity so that students feel free to do such.
Java Jive
CC BY-SA 3.0
2018-03-13T21:00:36.800Z
Of the two you have this feels like the better of the two. As a former *high-flyer* I'd find this a challenge to be met.
Gypsy Spellweaver
CC BY-SA 3.0
2018-03-13T22:59:28.260Z
I would still try something different. Homogeneity doesn't let them grow. One option is to make your superstars tutors or teaching assistants. If your project has roles, give them a non-programming role, since they won't learn much from just programming if they already excel there. Or a tester role. Or a tool builder role. But best if they can also learn to work with others. As a tool builder the rest of the team becomes their customer, similar for tester. They have to interact, but can't just take over.
Buffy
CC BY-SA 3.0
2018-03-14T00:40:57.023Z
@Buffy That should be another answer, no?
Ben I.
CC BY-SA 3.0
2018-03-14T16:10:11.457Z
@Buffy I disagree. Most companies set up homogeneity in order to complete the most complex projects. Pairing the high fliers is realistic and will help them grow, technical-skill-wise (AKA the point of the class). You're severely underestimating the skill-ceiling of programming. No human has ever reached a point where they are unable to continue learning programming. There are plenty of other classes to teach the skills you are suggesting, and practice them.
Clay07g
CC BY-SA 3.0
2018-03-15T03:55:01.787Z
As a computer science student, I have no interest in sinking countless hours into a lab class (which at my university are usually worth 1-2 credits despite always having a heavy workload). Should I be put into a class like this, I would do my best to sandbag and fake incompetence so that I don't get put on such a "dream team" and get a C- in the class for not exceeding expectations enough.
Plasma
CC BY-SA 3.0
2018-03-13T20:40:01.760Z
2018-03-13T20:40:01.760Z
Ben I.
<p>Most of what I was going to say was covered by @Buffy. Also I have not tried this in the classroom yet. It is some ideas that I had, based on my industry experience. Pick and choose what seems right, and test it.</p>
<h1>Do it agile one requirement at a time.</h1>
<ul>
<li><p>You can write the unit tests for them, and release one test at a time. Some automated system, that releases the next test when a test passes.</p>
</li>
<li><p>Use revision control, tell them that they must check in regularly, at least after each test passes. Ensure that they can only check-in code form within the lab. Create an auto grader that checks out there code one revision at a time, and runs the units tests. Check that they don't do to much per commit. Be careful as if they are doing it correct, with well written code, you can get emergent behaviour, and several tests will suddenly pass (Maybe 3 then 1 then 10 then all).</p>
</li>
<li><p>Get the high performer writing automated tests.</p>
</li>
</ul>
<hr />
<p>Ideas added by others:</p>
<ul>
<li>“Get the high performer writing automated tests.” - or other tooling. Writing tooling that saves time for other contributors is a nice skill to have, it suits lone rangers well (since the tooling is often smaller in scope and suitable for a single person), and naturally forces personal interaction - their peers have now become their clients. – <a href="https://cseducators.stackexchange.com/users/4656/logan-pickup">Logan Pickup</a></li>
</ul>

CC BY-SA 3.0
2018-03-15T04:09:22.303Z
"Get the high performer writing automated tests." - or other tooling. Writing tooling that saves time for other contributors is a nice skill to have, it suits lone rangers well (since the tooling is often smaller in scope and suitable for a single person), and naturally forces personal interaction - their peers have now become their _clients_.
Logan Pickup
CC BY-SA 3.0
2018-03-13T23:54:16.753Z
2018-03-15T10:00:19.913Z
2020-06-18T08:36:57.023Z
ctrl-alt-delor
<p>Since I first considered posting this question, the situation played out in my classroom, and here's how I handled it.  I had three students who had a history of <em>"Lone-Rangerism"</em> (last semester). I assigned the group project and warned the entire class that no one could go rogue. I observed each group frequently, circulating the room every 5-10 minutes, paying special attention to those groups who had a former <em>Lone Ranger</em> on their team, making sure that their project wasn't suddenly "done" from importing code the <em>LR</em> did at home.  I also set a timer and made each team change "drivers" every 30 minutes so that the <em>Lone Ranger</em> couldn't take over and do all the work. So far, so good.</p>

CC BY-SA 3.0
2018-03-13T22:53:57.727Z
This is a bit too much of the "stick" approach. Try the carrot. Dip it in sugar first.
Buffy
CC BY-SA 3.0
2018-03-14T15:40:44.580Z
Intentionally restricting the work of the most productive team members is only likely to drive them to drop the class.  *Functional* engineering organizations fully use the capability of all of their members -  once you create a system that *by design* does not, you model a dysfunctional organization with an official path where little happens, an unofficial one where all the real work gets done, and a huge tension in between.
Chris Stratton
CC BY-SA 3.0
2018-03-15T13:05:48.093Z
@ErikAlapää, your last sentence was unkind and has no place here.
Buffy
CC BY-SA 3.0
2018-03-15T13:30:19.820Z
@Buffy, why don't we let Judy Oakly decide for herself if she was offended? Perhaps I was too harsh, I just think university should be a safe haven from aggressive leaders. I pay by taking student loans, I get to learn in my way.
Erik Alapää
CC BY-SA 3.0
2018-03-15T13:50:22.527Z
@Erik, I wasn't offended, just a bit surprised that someone who didn't know me at all would say that. I was going to let it slide, but now that you have addressed me directly, here I am. For one thing I teach high school, not university. My students are usually 15-year-old boys, who still need a lot of guidance. I'm sure you can relate. And I have a tendency to come across harder than I am. My students tell me I'm the best teacher they ever had, because I value relationships and strive to be open and allow extreme flexibility in the classroom.  Continued...
Java Jive
CC BY-SA 3.0
2018-03-15T13:53:53.697Z
@Erik, what I wrote about monitoring the students to avoid LR syndrome was for 90% of them who NEEDED that sort of supervision. Yes, they had gone rogue in a previous semester, but they wrote CRAPPY code! That was why they needed the team! The other 10% were indeed stars, so I left them alone and voila, a couple of Dream Teams emerged who did amazing and wonderful things.  My original question was not intended to look for ways to squelch superstars, but how to manage those who don't need to go rogue, just yet, for various reasons.  I think if you re-read it you will see that.
Java Jive
CC BY-SA 3.0
2018-03-15T14:01:26.490Z
@JudyOakley You are probably a better teacher than I ever was, I have done some teaching as a high school temp and as a math PhD student many years ago. I also teach some in my current work. I just wanted to state that university is all about freedom and knowledge, and, to a lesser extent, high school also is.
Erik Alapää
CC BY-SA 3.0
2018-03-15T14:04:33.853Z
I think it makes a *huge* difference that this is at the high-school level vs. university, and your actions make more sense in that context.  I would be extremely adverse to the behavior in this answer in a university setting.
Ironcache
CC BY-SA 3.0
2018-03-15T14:28:57.367Z
@Erik and Iron, I will make myself more clear in future questions where the context of HS vs. Univ. matters.  Thank you both for your comments.
Java Jive
CC BY-SA 3.0
2018-03-13T19:40:37.127Z
2018-03-13T19:40:37.127Z
Java Jive
<p>My answer is "play it by ear", and don't expect to make any progress.</p>

<p><strong>Example 1: myself</strong>
I was one of those LR students decades ago. Grades and peer approval had no meaning to me. There were no levers for a teacher to pull to get me involved. I pulled in C grades, yet scored 100% on the standardized provincial physics exam in 12th grade.</p>

<p>I recently found out that I am (by this year's standards) autistic, in addition to being ahead of the curve by a significant amount.  I either ended up doing all of the work for "team" projects,  or got shuffled to the side because I had no interest in the drama that went with dealing with people. No amount of teacher intervention or classroom technique changed that. </p>

<p><strong>Example 2: My daughter</strong>
My daughter was part of a group assignment in her media class. When one of her team mates started texting her inappropriately, she and her team mate were informed that she was doing her assignment solo. The teacher was puzzled by the sudden unilateral change, but he wisely chose to trust that this was necessary.</p>

<p><strong>Edit: I missed the point</strong>
Based on comments (thanks @Buffy) I realized I totally failed to make my point. The two real-life scenarios I describe are personal experience, and are not extreme. My own autism has not stopped me from having successful careers, and would have remained undiagnosed until my passing had I not had other health issues in which it was found.</p>

<p>Without the background information I provided here that was not available 4 decades ago, my high school teachers saw me as having "advanced academics" and "poor social skills" etc, and "would do the task over night to bring it back to the first group meeting, completed".</p>

<p>At that time, autism wasn't even on the books as a legal diagnosis.  It was years before it was recognized as being biological in origin. Today, I understand that the point of the tasks was the group experience rather than the task itself. But without that explicit explanation, I was physiologically not capable of realizing the task was not the important part of the assignment. Furthermore, had I been told that the "group" was the important part, I would have simply shut off rather than participate.</p>

<p>While not all kids with poor social skills are autistic, when I see the combination of poor social skills and advanced academics, I raise the question because of my own experience.</p>

<p>Likewise, without the background information, my daughter's teacher's perception would have been that an advanced student suddenly went rogue without explanation. The texts were mistake of the young man's that both found terribly embarrassing, and neither were prepared to talk about with a teacher. He (the teacher) may still be under the impression that she got tired of being slowed down by a novice.</p>

<p>As a teacher you don't have all of the information, and all you can do is the best with what you have.</p>

<p><strong>Edit 2: What can you do??</strong></p>

<p>As suggested by @beni , I have some suggestions that might help.</p>

<p>I find it almost as ironic that I am making recommendations centered on "soft" skills as I do that in my volunteer time I manage a team of (mostly) adolescents in the high pressure and close quarters of live webcasting.</p>

<ol>
<li><strong>Understand that part of learning to work in a group is learning when to leave the group unilaterally.</strong> In my daughter's case, she learned that sexual harassment is not an acceptable part of team work, and it is perfectly okay to walk away from a team where it is happening. Recognize that interpersonal conflicts that are irreconcilable do happen between high school students, they need to try to handle some things on their own, and you will not always know about those issues.</li>
<li><strong>Recognize that there is no cure-all solution.</strong> Setting an advanced student with <em>good</em> social skills (like my daughter) up as a team lead or teachers assistant can work well, but setting up and advanced student with no interest in socialization (like myself) in that role would precipitate a shutdown or walk out if you were lucky.</li>
<li><strong>Recognize that some tech companies are now specifically seeking programmers on the autism spectrum</strong> , precisely because they can solve certain classes of problems better than teams of neurotypical programmers. Being unable to work in a group is not necessarily a handicap. (<a href="https://www.windowscentral.com/microsofts-autism-hiring-program-seeks-bring-diverse-talent-redmond" rel="nofollow noreferrer">https://www.windowscentral.com/microsofts-autism-hiring-program-seeks-bring-diverse-talent-redmond</a>)</li>
<li><strong>If your problem students share the characteristic of being hyperfocused and task-centric, put them together.</strong> They may go home and bring the task back completed for the first official meeting, but being similarly focused they are likely to strike a synergy and do it together (that would be me!). At the very least, they will have a chance to review each other's solutions and time to expand. Being task centered, they may not socialize much outside of the task, but they can develop a feedback loop of excitement as they expand and improve the solution.</li>
<li><strong>Don't treat students you don't understand as damaged goods.</strong> I have a gentleman on my webcast team whose teacher tries to meet him half-way by treating him like an infant. This kid (middle school) has earned sufficient respect as a camera tech (following directions) and a technical director (giving orders) during live webcasts that when he gives directions everyone on the team pays attention, including people twice his age or more. His teacher has nothing but frustration with him ... doh!</li>
<li><strong>Engage their interests with specialization.</strong> If I chose to do something in school, it was out of synergy with my own interest. I could do relativity physics in my head, but wouldn't do homework. In one class I got a final grade of 10%, because I scored 100% on the final exam that was worth 10% of the class grade.</li>
</ol>

<p>Another member of my webcast team is autistic to a higher degree than I am, but this kid (not old enough to drive) gets himself up every Sunday and rides his bike to church so he can do his part on the team as title artist. It suits him because he sits in a quiet corner away from the rest of the team and can focus on his artwork. He's started to earn respect from his peers because when he's not there they have to do that job. Modern software development requires a broad range of specializations - take advantage of it.</p>

<ol start="7">
<li><strong>Make use of remote team management tools and practices.</strong> Today, in industry, many software project teams never meet in person. My own team includes people from all over the USA, Brazil, and India. On some of my most productive days I never actually leave my bedroom. Teamwork does not require face to face time.</li>
</ol>

CC BY-SA 3.0
2018-03-14T12:08:49.823Z
Learn to live with it. You can't teach a one legged person to run 100 meters, although they can still become an athlete. You can't force a student who has no interest in being part of a group into having interest in a group activity. And you can't force people with a bad history together to work in close quarters .
pojo-guy
CC BY-SA 3.0
2018-03-14T12:53:40.193Z
These problems are not the same, not even on the same scale. They certainly don't have the same solution.
Buffy
CC BY-SA 3.0
2018-03-14T13:54:00.710Z
@Buffy how do you know unless you ask? In my case, autism wasn't even a legal diagnosis at the time, and in my daughter's case the teacher had no inkling of why she suddenly went LR.
pojo-guy
CC BY-SA 3.0
2018-03-14T17:09:04.463Z
@pojo-guy I see better where you're coming from. OP has indicated in a comment that she is also evaluated on student teamwork. Obviously, there are a lot of headwinds, but if you were the teacher in that position, how would you attempt to approach students such as yourself? We don't need to achieve total success in one project. Baby steps can still be important in the development of a student. But how would you encourage such baby steps in ways that don't dehumanize or invalidate the student? In some ways, you may be the best person here to answer this question so far.
Ben I.
CC BY-SA 3.0
2018-03-15T00:13:42.027Z
@BenI. Evaluating the teacher on my ability to work in a group would have been exactly analogous to evaluating the track coach on his ability to take a one legged student and get him to sprint 100 yards, except the missing leg was more visible. I know it's how some super-social bureaucrat who wouldn't know a copybook from a class decided to evaluate teachers, but it's unreasonable and unrelated to either the teacher's skill or the student's learning.
pojo-guy
CC BY-SA 3.0
2018-03-15T00:27:38.290Z
I'm a wee bit in love with this answer now. Thanks so much for sharing your perspective here. The answer may not have a ton of upvotes, but you've given at least one classroom teacher a lot to think about here.
Ben I.
CC BY-SA 3.0
2018-03-14T11:46:49.957Z
2018-03-15T00:16:44.637Z
2018-03-15T00:16:44.637Z
pojo-guy
<p>As suggested in a comment, I'll add the following. </p>

<p>The purpose of an education goes beyond the learning of narrow technical skills. If you graduate with that, but nothing else you probably don't have a very bright future other than via some serendipity. There are <em>rare</em> exceptions of course, but for every "creator of a major OS who has people issues" there are likely thousands of others who are isolated in their lives and unemployable. </p>

<p>Both the Prima-Donas and the total introverts (even the autistic) need to have a way to grow personally as well as professionally during their school years and CS instructors can't just leave it to someone else. Your job is to educate your students, not just present them with technical details. Part of the education of any professional today is learning how to work well in team situations. That is the purpose of student teams. It is not (NOT) the more efficient production of some software. </p>

<p>So, you need a way to give the social outliers a way to learn those skills, even if their natural tendencies lie elsewhere, and even if they don't do as well at socialization than at tech. They have to start and they have to advance. </p>

<p>Furthermore, pairing like with like is sub-optimal: Homogeneity doesn't let them grow. If your superstars only work with other superstars they won't really learn much and might fight like cats and cats. At the other end of the scale (the extreme introverts) I predict long, unproductive, silences. People need to learn to work with people not like themselves - variety is the chocolate-of-life. Both of those traits limit the individual and both can be overcome. One of the best public speakers I know and an inventor of an important programming language is extremely introverted. He taught himself to overcome his "handicap" by playing a role when needed, not by changing his personality. My personal case is different. I am, by nature, very introverted, but have actually changed my personality and few, other than my spouse, recognize that introversion. I did it by forcing myself out into the open and then deciding that the consequences weren't as dire as I'd expected. Your personality isn't deterministic of what you can do, just how hard it is to do some things. But teachers need to help students, especially young students, deal with this. </p>

<p>That said, in a team, it is possible that different people take different roles. It is best if you can find a way for them to switch roles (and in pair programming it is essential that they do so), but it may not always be possible or worth the disruption. </p>

<p>One option is to make your superstars tutors or teaching-assistants. If your project has roles, give them a non-programming role, since they won't learn much from just programming if they already excel there. Or give them a tester role. Or a tool builder role. But best if they can also learn to work with others. As a tool builder the rest of the team becomes their customer, similar for tester. They have to interact, but can't just take over. Their role may not require intense interaction with everyone else, but it does require some. Roles like this also confer responsibility on the individual while permitting them to do their own thing up to a point. </p>

<p>Teach the whole person, not just the geek. Expect that they are all different, with different strengths and weaknesses. Your job isn't to "fill them up", but to <a href="https://rads.stackoverflow.com/amzn/click/1579220541" rel="nofollow noreferrer">"change their brains."</a> </p>

CC BY-SA 3.0
2018-03-14T15:46:33.033Z
"make your superstars tutors or teaching-assistants" indeed.  By entirely relieving them of responsibility for the *resulting code*, and making their assignment instead the progress of their classmates, you can create a positive environment.  In contrast, a situation where they are responsible for the technical outcome, but restricted from achieving that in the most direct manner, is inevitably going to result in tension.
Chris Stratton
CC BY-SA 3.0
2018-03-15T04:06:23.233Z
You can also have a project planning session, where the students themselves are given the chance to assign their own roles. Having someone responsible for unit tests, code review, interface definition, etc. it also valuable in a mixed group (as well as high-level positions like tutor for the high-fliers).
Logan Pickup
CC BY-SA 3.0
2018-03-14T13:15:59.623Z
2018-03-14T13:15:59.623Z
Buffy
<p>The key to this is to use a carrot and not a stick. Even better, build the carrot into the project process itself, so that the incentives for the superstar are to do the right thing. Of course you should always try to align the incentives with the desired outcome, but here it needs special care. It is applicable even if you <em>don't</em> have a Lone Ranger too. </p>

<p>Your objective, in the project is not, I assume, code at the expense of all else. Learning is the objective, not code. This is different from the workplace. Here the #1 goal is not working code, but learning. Even well structured code is valued above working code in education, and the structure will likely lead to correctness of the code in any case. </p>

<p>First, in your project description, say something about the learning. And divide up the grade for the project into parts, heavily advantaging process and good behavior: team-work. One way to achieve that is to have the students give reviews of their peers at the end of the project (and to advertise this at the start). You also need to give explicit grades for cooperation and teamwork. </p>

<p>One possible way to get feedback and give students a way to feel proud of their contributions is like this. Give every student three, say, "chits." These can be index cards signed by both yourself and the student. Each student is permitted to give a chit to another student based on their helpfulness. The receiver also signs the chit, say on the back. At the end of the project collect the chits and reward people based on how many they have from other students. </p>

<p>Another method, if teams have about five students or so, is to require each student to fill out a form on which they list the three, say, students who were most helpful and contributed the most to the project. They also need to write a line or two of explanation for each "vote". Note that they don't evaluate every student, just the ones they think should be rewarded. </p>

<p>If teams are always just two students, then each can be required to write a bit about their partner's chief contribution and their own. Again, you aren't asking for negatives and are less likely to get them in most cases anyway. </p>

<p>These peer-review techniques should be introduced before the project starts, so students know what is going on. I have learned interesting things about some students this way when I'd have overlooked positive contributions of someone. </p>

<p>Another help is to teach a development process along with the project and insist that it is used. An Agile process is especially helpful here since you can act as the team's "customer" and only give them enough "stories" (work to do) for a single period, rather than the project as a whole. You can even warn them that the direction of the project (the requirements) may change over the course of the project. There is no incentive to program speculatively in this sort of environment. </p>

<p>Each day, you need a set of index cards, each describing some feature of the project to implement that day. Pass them out to the team(s) and hold a short question/answer session to clarify what is on the cards but not to make a complete specification. </p>

<p>If you want to really make it work, have them write unit tests for the things they build, so that they know when it "works" according to the tests. Expect questions throughout the session, since the specification is only in your head. </p>

<p>If there are several cards for each day, then pairs (paired programming) can switch roles at the completion of each card. Even better is to have them switch for each test. Student A writes a test and passes the keyboard to B who makes it pass. B then writes a test and passes the keyboard back to A. The one not typing (the navigator) isn't expected to sit silently, but to offer suggestions throughout. Your superstar may wind up teaching some others a bit about the technology this way. </p>

CC BY-SA 3.0
2018-03-13T20:31:39.090Z
Our curriculum is so old it still teaches the waterfall process.  And since it is still there, it can still be on the final exam, which I don't write.  But I could still contrast with Agile...thanks for the idea.
Java Jive
CC BY-SA 3.0
2018-03-13T23:00:23.663Z
Might be time to look at the curriculum, then. Even IBM is agile now.
Buffy
CC BY-SA 3.0
2018-03-13T23:40:56.557Z
“The process is like going over a waterfall“ — A miss quote of the original use of the term waterfall to refer to the method.
ctrl-alt-delor
CC BY-SA 3.0
2018-03-14T01:34:50.840Z
@Buffy I am bound to the curriculum until it is officially modified by the state.  We are still using Visual Studios 2010.  But I can certainly augment as I see fit.
Java Jive
CC BY-SA 3.0
2018-03-14T23:41:06.613Z
Many companies still (mis)use waterfall. It has the advantage that it ensures there is a high level vision, but the disadvantage that managers have got their hands on it and ruined it like they are trying to do to agile.
pojo-guy
CC BY-SA 3.0
2018-03-15T00:21:04.213Z
Original waterfall was actually "agile". The intent (before MBA's got their hands on it) was an illustration that the sooner you fix errors, the less they cost to fix. Code well, know where you plan to go, and fix issues early - pretty much the definition of Agile.
pojo-guy
CC BY-SA 3.0
2018-03-15T00:25:06.723Z
@pojo-guy, sorry, but that is a misrepresentation of agile process. Agility is about responding to change, not about getting it all absolutely correct at the start (which is impossible in a changing world). You are confusing/obfuscating the issues, rather than offering useful commentary.
Buffy
CC BY-SA 3.0
2018-03-15T00:25:50.603Z
Waterfall, as intended, was also about responding quickly to change.
pojo-guy
CC BY-SA 3.0
2018-03-15T00:30:16.313Z
No, it was not. The sorts of things you do in waterfall, even iterative waterfall (which came later) make responding to change expensive by enabling early commitment. You are twisting words.
Buffy
CC BY-SA 3.0
2018-03-15T00:35:20.120Z
I can agree to disagree - as you pointed out, this side discussion is really out of scope for this question.
pojo-guy
CC BY-SA 3.0
2018-03-13T20:16:38.787Z
2018-03-13T22:21:52.277Z
2018-03-13T22:21:52.277Z
Buffy
<p>A suggestion would be to include in the project grade a component that evaluates collaboration and make it so a group with a lone ranger fails the project or is assigned a barely passing grade. Make this explicit the moment the project is proposed, emphasize it during its execution and explain how they will be evaluated in this regard. For instance, the University of New Orleans published a <a href="http://www.uno.edu/general-education/collaboration-rubric.aspx" rel="nofollow noreferrer">collaboration rubric</a> that can be readily used by the instructor (or students) to evaluate the collaboration abilities of a student. </p>

<p>If possible, ask students themselves to evaluate the how well their partners collaborate. There is some scientific evidence (<a href="https://www.sciencedirect.com/science/article/pii/S1096751611000492" rel="nofollow noreferrer">1</a>, <a href="https://www.tandfonline.com/doi/abs/10.1080/135625100114885" rel="nofollow noreferrer">2</a>) that peer assessment activities can be beneficial to grade individually according to participation in group projects. These papers also contain rubrics that could be adapted to your context.</p>

<p>It is important to communicate to students that collaboration means doing what is best for the team, not doing tasks physically together. If the objective of the team is learning, completing a project alone without any input from the other members is not what is best for the team, so it is not good collaboration. However, completing, individually, a task that is valuable for the team and synchronizing its execution with the rest of the work is good for the team, so it is good collaboration (as pointed out by @pojo-guy's answer). The key here is not <em>individually</em>, but <em>valuable for the team</em> and <em>synchronizing</em>.</p>

CC BY-SA 4.0
2018-07-19T16:00:45.837Z
This is an excellent answer. Thank you for citing your sources.
Ben I.
CC BY-SA 4.0
2018-07-21T14:14:28.450Z
I like the way you were able to phrase the concept that 'collaboration means doing what is best for the team, not doing tasks physically together".
pojo-guy
CC BY-SA 4.0
2018-07-19T15:03:22.843Z
2018-07-19T15:03:22.843Z
igordsm
<p>We all have them - students who want to write all the code themselves, who don't want to be part of a group project.  They have poor social skills, or they don't know anyone else in the class, or they don't trust others, or they think other people "slow them down".  So they go home after a group project is assigned, write all the code themselves, and bring it back to the first group meeting, completed.</p>

<p>A typical situation is a group project done in a class or lab period over several days. The instructor or a lab assistant is present to watch over the students and give advice as needed. Different strategies might be needed if the project is done outside the view of faculty on the students' own time. </p>

<p>This could also differentiate depending on whether the situation is the first occurrence (you are surprised by it), or if you are familiar with the <em>Lone Ranger</em> and know he or she has a history of going rogue.</p>

<p>What are your practical ideas for preventing a student from taking over a group project, or dealing with it after it has occurred?</p>

<hr>

<p>Of note from other posts:</p>

<p>Reading the answers to <a href="https://cseducators.stackexchange.com/q/3248/104">Techniques for encouraging pair programming</a> and <a href="https://cseducators.stackexchange.com/q/1383/4338">What advantages/disadvantages have you seen with Pair Programming in the classroom</a> offers insight into the problem of encouraging students to actually "work" together, which can be part of the problem here. The real issue, however, isn't that the other students aren't willing to do the work, rather that the <em>Lone Ranger</em> just does all the work, usually before work begins, without the others even having the opportunity to work.</p>

<p>Two other questions, <a href="https://cseducators.stackexchange.com/q/3/4338">Is it possible to ensure division of labor on a group assignment?</a>, and <a href="https://cseducators.stackexchange.com/q/430/4338">Problematic student at a very high level</a>, help with creating the environment and assignments to enable group work, and determining <em>if</em> someone has gone rogue and done all the work. Neither deals with preventing the <em>Lone Ranger</em> from repeating once the problem has been identified.</p>

CC BY-SA 3.0
2018-03-15T10:02:39.597Z
Working in a team does not necessarily mean working as close together as when team programming. Somebody who likes to work on his own for some reason (and CS people will often need to work alone later) can do so and still be a productive member of the team, just by contributing parts which can be done solo. There are different personality types and different learning types and both have categories for "lone rangers". It is no good idea to force them too much to work in a way which is less efficient for them, if it is not absolutely needed.
allo
<best-practice><secondary-education><project><classroom-management>
How do you deal with Lone Rangers in group projects?
# How do you deal with Lone Rangers in group projects?

(Asked by: username_0 on 2018-03-13)

We all have them - students who want to write all the code themselves, who don't want to be part of a group project. They have poor social skills, or they don't know anyone else in the class, or they don't trust others, or they think other people "slow them down". So they go home after a group project is assigned, write all the code themselves, and bring it back to the first group meeting, completed.

A typical situation is a group project done in a class or lab period over several days. The instructor or a lab assistant is present to watch over the students and give advice as needed. Different strategies might be needed if the project is done outside the view of faculty on the students' own time.

This could also differentiate depending on whether the situation is the first occurrence (you are surprised by it), or if you are familiar with the *Lone Ranger* and know he or she has a history of going rogue.

What are your practical ideas for preventing a student from taking over a group project, or dealing with it after it has occurred?

---

Of note from other posts:

Reading the answers to [Techniques for encouraging pair programming](https://cseducators.stackexchange.com/q/3248/104) and [What advantages/disadvantages have you seen with Pair Programming in the classroom](https://cseducators.stackexchange.com/q/1383/4338) offers insight into the problem of encouraging students to actually "work" together, which can be part of the problem here. The real issue, however, isn't that the other students aren't willing to do the work, rather that the *Lone Ranger* just does all the work, usually before work begins, without the others even having the opportunity to work.

Two other questions, [Is it possible to ensure division of labor on a group assignment?](https://cseducators.stackexchange.com/q/3/4338), and [Problematic student at a very high level](https://cseducators.stackexchange.com/q/430/4338), help with creating the environment and assignments to enable group work, and determining *if* someone has gone rogue and done all the work. Neither deals with preventing the *Lone Ranger* from repeating once the problem has been identified.

**Tags:** best-practice, secondary-education, project, classroom-management

> **Comments:**
> **username_1**: Working in a team does not necessarily mean working as close together as when team programming. Somebody who likes to work on his own for some reason (and CS people will often need to work alone later) can do so and still be a productive member of the team, just by contributing parts which can be done solo. There are different personality types and different learning types and both have categories for "lone rangers". It is no good idea to force them too much to work in a way which is less efficient for them, if it is not absolutely needed.  

---

## 8 answers

### Answer by username_2 on 2018-03-13. Score: 38

This is really a separate approach from my first answer, which has received some push-back.

It's worth noting that many of these loners are simply students who are substantially ahead of the curve. One way to really want to engage such students in pair programming is to pair them with each other. This will create something of a Dream Team.

Give them the assignment, but tell them that their goal is to produce the coolest thing that they can that utilizes the concepts that the lab is developing within the time before the lab is due. Tell them you're excited to see what they can come up with, that you'll username_1w them to present their work to the group at large, and that if it's a cool enough idea, you may use it as a launching point for a future lab for later generations of students.

As an aside, there is no reason to restrict this approach to the high-fliers. It can be reasonable to username_1w students to propose modifications to the labs if these modifications excite the students. It involves more work on your end, but you'll get better output and (more importantly) more engagement and buy-in from your students overall.

> **Comments:**
> **username_0**: you are right on the money, and in a good classroom environment, these things will happen organically.  In my current project, which initiated this question, I've had two groups go "Dream Team" on me and implement far and above their specifications.  This has, in turn, fueled other teams to want to "get finished so we can try to do that".  It's awesome and amazing.  I don't know if I could formalize it in the future...but I can maintain a classroom that fosters openness and curiosity so that students feel free to do such.  
> **username_8**: Of the two you have this feels like the better of the two. As a former *high-flyer* I'd find this a challenge to be met.  
> **username_3**: I would still try something different. Homogeneity doesn't let them grow. One option is to make your superstars tutors or teaching assistants. If your project has roles, give them a non-programming role, since they won't learn much from just programming if they already excel there. Or a tester role. Or a tool builder role. But best if they can also learn to work with others. As a tool builder the rest of the team becomes their customer, similar for tester. They have to interact, but can't just take over.  
> **username_2**: @username_3 That should be another answer, no?  
> **username_9**: @username_3 I disagree. Most companies set up homogeneity in order to complete the most complex projects. Pairing the high fliers is realistic and will help them grow, technical-skill-wise (AKA the point of the class). You're severely underestimating the skill-ceiling of programming. No human has ever reached a point where they are unable to continue learning programming. There are plenty of other classes to teach the skills you are suggesting, and practice them.  
> **username_10**: As a computer science student, I have no interest in sinking countless hours into a lab class (which at my university are usually worth 1-2 credits despite always having a heavy workload). Should I be put into a class like this, I would do my best to sandbag and fake incompetence so that I don't get put on such a "dream team" and get a C- in the class for not exceeding expectations enough.  

---

### Answer by username_2 on 2018-03-13. Score: 11

I might push back against the core idea here, and this gets to the idea of the central mission of the course of study. Within my course, teamwork is not a primary goal upon which I will assess my students. This is not to say that I don't value it. I think that there is *great value* in paired programming, but I approach this only as a salesman, not as a taskmaster.

I get real buy-in. On my most recent lab, >85% of my students have opted for two people, one-screen, driver/navigator paired programming.

That said, I never *require* paired (or group) programming. I username_1w students to opt into paired programming if they wish to, and I sell it like crazy, but for some of those Lone Rangers, the idea of working with another person can be intensely frustrating. Where this becomes a big problem is where they begin to hurt the education of their peers by simply doing the work themselves. Some of these students may never really warm to the idea. While I want to teach good team-working skills, I am unwilling to jeopardize the education of my middle- and low-flying students in order to force the high-fliers into an activity that they really don't want to engage in in the first place.

Even in this environment, there can still be group projects, but they would involve differentiated responsibilities:

> Person A is responsible for parts 1, 2, and 3 of the project, while Person B is responsible for parts 4, 5, and 6. Person C is responsible for QA. Design your APIs together, and get them approved by me prior to the start of any actual coding.

> **Comments:**
> **username_0**: I agree that group/paired programming can be frustrating to stars, and I certainly don't wish to squelch their enthusiasm and creativity.  But I, as a teacher, am evaluated on, among other things, inclusion of group projects.  Indeed, student collaboration is one of the overarching goals of my district.  So it's THERE, whether I, or they, like it or not.  And mustn't we all, at some point, be able to work with others, even if it is frustrating, or slows us down?  How many Knuths are there in the world?  Who are ALLOWED/ENCOURAGED to work alone, because they are superstars?  Not many.  
> **username_0**: That being said, I do think it is important that we (CS educators) username_1w superstars to define their own paths when appropriate.  I always have a couple, and they are a joy to watch.  Balance.  In everything.  
> **username_3**: I agree with @JudyOakley here. Student's need more in their education than technology. The workplace demands it. So does being successful in many Colleges and certainly in Grad School. Your introverts aren't well served by letting them hide and your superstars aren't well served by letting them work in too narrow a range. Some education is hard. But _what_ is hard is different for everyone.  
> **username_4**: Since the original question was predicated on the assignment being a group project, this answer is not on topic.  
> **username_2**: @LeeMosher Interesting point. Personally, I think that answers like this should be okay. In light of your observation, though, [I created a meta](https://cseducators.meta.stackexchange.com/questions/379/frame-challenging-questions-on-cseducators) to find out if the rest of the community feels the same way.  
> **username_5**: @JudyOakley The core issue with (school) group projects that everyone overlooks is that you will _never_, in any other arena, face such a broad range of ability levels.  Lone-ranger programmers are often just skilled at what they're doing, and would rather not deal with people behind them in knowledge. (After all, not everyone is cut out to be a teacher.) These programmers tend to do well in classes, then go on to Google/Microsoft/Facebook where they work quite happily in teams with other skilled people.  Further, top companies usually have an "individual contributor" role made [cont'd]  
> **username_5**: ... for highly-skilled programmers who would rather manage their own projects. I understand the desire to encourage teamwork in school, but I would strongly suggest username_1wing people to work independently if they feel that strongly about it.  Or, if absolutely required, let people choose their teammates, and the problem will sort itself out.  
> **username_6**: I'd like to point out that current thought among the companies that are hiring the "superstars" is that people who can code are a dime a dozen, and what they really need are people that can both understand the code _and communicate it_. Forcing high-fliers into group interaction is not crippling them (they will have plenty of other opportunities to expand their coding), it is an attempt to teach something they badly, badly need to learn.  
> **username_7**: I was also the kind to do most of the work in a duo, while I was still explaining what I have done to the other. I like this idea. It's basically choosing on what you focus at the moment, teamworking or polishing technical skills. At the age of university, we're old enough to understand that team skill exists and must be polish but we can also have the right to polish further our expertise.  
> **username_7**: @LoganPickup we could also need someone  who can code, manage his project, write the specification, communicate perfectly and live right next to the company without child or husband/wife. But this is of course happens pretty much never, you have to do with what you have, and that's why they're things like screening in interview, organization, coding standard, project manager, technical leader to help for that.  
> **username_6**: @username_7 Yes, companies would like a perfect employee; that's not my point. My point is that communication and collaboration skills are becoming _more_ valuable than coding skills, so long as you have at least _some_ coding skills. This is a hard requirement for any kind of agile development, for instance.  

---

### Answer by username_11 on 2018-03-13. Score: 4

Most of what I was going to say was covered by @username_3. Also I have not tried this in the classroom yet. It is some ideas that I had, based on my industry experience. Pick and choose what seems right, and test it.

# Do it agile one requirement at a time.

* You can write the unit tests for them, and release one test at a time. Some automated system, that releases the next test when a test passes.
* Use revision control, tell them that they must check in regularly, at least after each test passes. Ensure that they can only check-in code form within the lab. Create an auto grader that checks out there code one revision at a time, and runs the units tests. Check that they don't do to much per commit. Be careful as if they are doing it correct, with well written code, you can get emergent behaviour, and several tests will suddenly pass (Maybe 3 then 1 then 10 then all).
* Get the high performer writing automated tests.

---

Ideas added by others:

* “Get the high performer writing automated tests.” - or other tooling. Writing tooling that saves time for other contributors is a nice skill to have, it suits lone rangers well (since the tooling is often smaller in scope and suitable for a single person), and naturally forces personal interaction - their peers have now become their clients. – [username_6](https://cseducators.stackexchange.com/users/4656/logan-pickup)

> **Comments:**
> **username_6**: "Get the high performer writing automated tests." - or other tooling. Writing tooling that saves time for other contributors is a nice skill to have, it suits lone rangers well (since the tooling is often smaller in scope and suitable for a single person), and naturally forces personal interaction - their peers have now become their _clients_.  

---

### Answer by username_0 on 2018-03-13. Score: 3

Since I first considered posting this question, the situation played out in my classroom, and here's how I handled it. I had three students who had a history of *"Lone-Rangerism"* (last semester). I assigned the group project and warned the entire class that no one could go rogue. I observed each group frequently, circulating the room every 5-10 minutes, paying special attention to those groups who had a former *Lone Ranger* on their team, making sure that their project wasn't suddenly "done" from importing code the *LR* did at home. I also set a timer and made each team change "drivers" every 30 minutes so that the *Lone Ranger* couldn't take over and do all the work. So far, so good.

> **Comments:**
> **username_3**: This is a bit too much of the "stick" approach. Try the carrot. Dip it in sugar first.  
> **username_12**: Intentionally restricting the work of the most productive team members is only likely to drive them to drop the class.  *Functional* engineering organizations fully use the capability of all of their members -  once you create a system that *by design* does not, you model a dysfunctional organization with an official path where little happens, an unofficial one where all the real work gets done, and a huge tension in between.  
> **username_3**: @ErikAlapää, your last sentence was unkind and has no place here.  
> **username_13**: @username_3, why don't we let Judy Oakly decide for herself if she was offended? Perhaps I was too harsh, I just think university should be a safe haven from aggressive leaders. I pay by taking student loans, I get to learn in my way.  
> **username_0**: @Erik, I wasn't offended, just a bit surprised that someone who didn't know me at all would say that. I was going to let it slide, but now that you have addressed me directly, here I am. For one thing I teach high school, not university. My students are usually 15-year-old boys, who still need a lot of guidance. I'm sure you can relate. And I have a tendency to come across harder than I am. My students tell me I'm the best teacher they ever had, because I value relationships and strive to be open and username_1w extreme flexibility in the classroom.  Continued...  
> **username_0**: @Erik, what I wrote about monitoring the students to avoid LR syndrome was for 90% of them who NEEDED that sort of supervision. Yes, they had gone rogue in a previous semester, but they wrote CRAPPY code! That was why they needed the team! The other 10% were indeed stars, so I left them alone and voila, a couple of Dream Teams emerged who did amazing and wonderful things.  My original question was not intended to look for ways to squelch superstars, but how to manage those who don't need to go rogue, just yet, for various reasons.  I think if you re-read it you will see that.  
> **username_13**: @JudyOakley You are probably a better teacher than I ever was, I have done some teaching as a high school temp and as a math PhD student many years ago. I also teach some in my current work. I just wanted to state that university is all about freedom and knowledge, and, to a lesser extent, high school also is.  
> **username_14**: I think it makes a *huge* difference that this is at the high-school level vs. university, and your actions make more sense in that context.  I would be extremely adverse to the behavior in this answer in a university setting.  
> **username_0**: @Erik and Iron, I will make myself more clear in future questions where the context of HS vs. Univ. matters.  Thank you both for your comments.  

---

### Answer by username_15 on 2018-03-14. Score: 3

My answer is "play it by ear", and don't expect to make any progress.

**Example 1: myself**
I was one of those LR students decades ago. Grades and peer approval had no meaning to me. There were no levers for a teacher to pull to get me involved. I pulled in C grades, yet scored 100% on the standardized provincial physics exam in 12th grade.

I recently found out that I am (by this year's standards) autistic, in addition to being ahead of the curve by a significant amount. I either ended up doing all of the work for "team" projects, or got shuffled to the side because I had no interest in the drama that went with dealing with people. No amount of teacher intervention or classroom technique changed that.

**Example 2: My daughter**
My daughter was part of a group assignment in her media class. When one of her team mates started texting her inappropriately, she and her team mate were informed that she was doing her assignment solo. The teacher was puzzled by the sudden unilateral change, but he wisely chose to trust that this was necessary.

**Edit: I missed the point**
Based on comments (thanks @username_3) I realized I totally failed to make my point. The two real-life scenarios I describe are personal experience, and are not extreme. My own autism has not stopped me from having successful careers, and would have remained undiagnosed until my passing had I not had other health issues in which it was found.

Without the background information I provided here that was not available 4 decades ago, my high school teachers saw me as having "advanced academics" and "poor social skills" etc, and "would do the task over night to bring it back to the first group meeting, completed".

At that time, autism wasn't even on the books as a legal diagnosis. It was years before it was recognized as being biological in origin. Today, I understand that the point of the tasks was the group experience rather than the task itself. But without that explicit explanation, I was physiologically not capable of realizing the task was not the important part of the assignment. Furthermore, had I been told that the "group" was the important part, I would have simply shut off rather than participate.

While not all kids with poor social skills are autistic, when I see the combination of poor social skills and advanced academics, I raise the question because of my own experience.

Likewise, without the background information, my daughter's teacher's perception would have been that an advanced student suddenly went rogue without explanation. The texts were mistake of the young man's that both found terribly embarrassing, and neither were prepared to talk about with a teacher. He (the teacher) may still be under the impression that she got tired of being slowed down by a novice.

As a teacher you don't have all of the information, and all you can do is the best with what you have.

**Edit 2: What can you do??**

As suggested by @beni , I have some suggestions that might help.

I find it almost as ironic that I am making recommendations centered on "soft" skills as I do that in my volunteer time I manage a team of (mostly) adolescents in the high pressure and close quarters of live webcasting.

1. **Understand that part of learning to work in a group is learning when to leave the group unilaterally.** In my daughter's case, she learned that sexual harassment is not an acceptable part of team work, and it is perfectly okay to walk away from a team where it is happening. Recognize that interpersonal conflicts that are irreconcilable do happen between high school students, they need to try to handle some things on their own, and you will not always know about those issues.
2. **Recognize that there is no cure-all solution.** Setting an advanced student with *good* social skills (like my daughter) up as a team lead or teachers assistant can work well, but setting up and advanced student with no interest in socialization (like myself) in that role would precipitate a shutdown or walk out if you were lucky.
3. **Recognize that some tech companies are now specifically seeking programmers on the autism spectrum** , precisely because they can solve certain classes of problems better than teams of neurotypical programmers. Being unable to work in a group is not necessarily a handicap. (<https://www.windowscentral.com/microsofts-autism-hiring-program-seeks-bring-diverse-talent-redmond>)
4. **If your problem students share the characteristic of being hyperfocused and task-centric, put them together.** They may go home and bring the task back completed for the first official meeting, but being similarly focused they are likely to strike a synergy and do it together (that would be me!). At the very least, they will have a chance to review each other's solutions and time to expand. Being task centered, they may not socialize much outside of the task, but they can develop a feedback loop of excitement as they expand and improve the solution.
5. **Don't treat students you don't understand as damaged goods.** I have a gentleman on my webcast team whose teacher tries to meet him half-way by treating him like an infant. This kid (middle school) has earned sufficient respect as a camera tech (following directions) and a technical director (giving orders) during live webcasts that when he gives directions everyone on the team pays attention, including people twice his age or more. His teacher has nothing but frustration with him ... doh!
6. **Engage their interests with specialization.** If I chose to do something in school, it was out of synergy with my own interest. I could do relativity physics in my head, but wouldn't do homework. In one class I got a final grade of 10%, because I scored 100% on the final exam that was worth 10% of the class grade.

Another member of my webcast team is autistic to a higher degree than I am, but this kid (not old enough to drive) gets himself up every Sunday and rides his bike to church so he can do his part on the team as title artist. It suits him because he sits in a quiet corner away from the rest of the team and can focus on his artwork. He's started to earn respect from his peers because when he's not there they have to do that job. Modern software development requires a broad range of specializations - take advantage of it.

7. **Make use of remote team management tools and practices.** Today, in industry, many software project teams never meet in person. My own team includes people from all over the USA, Brazil, and India. On some of my most productive days I never actually leave my bedroom. Teamwork does not require face to face time.

> **Comments:**
> **username_15**: Learn to live with it. You can't teach a one legged person to run 100 meters, although they can still become an athlete. You can't force a student who has no interest in being part of a group into having interest in a group activity. And you can't force people with a bad history together to work in close quarters .  
> **username_3**: These problems are not the same, not even on the same scale. They certainly don't have the same solution.  
> **username_15**: @username_3 how do you know unless you ask? In my case, autism wasn't even a legal diagnosis at the time, and in my daughter's case the teacher had no inkling of why she suddenly went LR.  
> **username_2**: @username_15 I see better where you're coming from. OP has indicated in a comment that she is also evaluated on student teamwork. Obviously, there are a lot of headwinds, but if you were the teacher in that position, how would you attempt to approach students such as yourself? We don't need to achieve total success in one project. Baby steps can still be important in the development of a student. But how would you encourage such baby steps in ways that don't dehumanize or invalidate the student? In some ways, you may be the best person here to answer this question so far.  
> **username_15**: @BenI. Evaluating the teacher on my ability to work in a group would have been exactly analogous to evaluating the track coach on his ability to take a one legged student and get him to sprint 100 yards, except the missing leg was more visible. I know it's how some super-social bureaucrat who wouldn't know a copybook from a class decided to evaluate teachers, but it's unreasonable and unrelated to either the teacher's skill or the student's learning.  
> **username_2**: I'm a wee bit in love with this answer now. Thanks so much for sharing your perspective here. The answer may not have a ton of upvotes, but you've given at least one classroom teacher a lot to think about here.  

---

### Answer by username_3 on 2018-03-14. Score: 3

As suggested in a comment, I'll add the following.

The purpose of an education goes beyond the learning of narrow technical skills. If you graduate with that, but nothing else you probably don't have a very bright future other than via some serendipity. There are *rare* exceptions of course, but for every "creator of a major OS who has people issues" there are likely thousands of others who are isolated in their lives and unemployable.

Both the Prima-Donas and the total introverts (even the autistic) need to have a way to grow personally as well as professionally during their school years and CS instructors can't just leave it to someone else. Your job is to educate your students, not just present them with technical details. Part of the education of any professional today is learning how to work well in team situations. That is the purpose of student teams. It is not (NOT) the more efficient production of some software.

So, you need a way to give the social outliers a way to learn those skills, even if their natural tendencies lie elsewhere, and even if they don't do as well at socialization than at tech. They have to start and they have to advance.

Furthermore, pairing like with like is sub-optimal: Homogeneity doesn't let them grow. If your superstars only work with other superstars they won't really learn much and might fight like cats and cats. At the other end of the scale (the extreme introverts) I predict long, unproductive, silences. People need to learn to work with people not like themselves - variety is the chocolate-of-life. Both of those traits limit the individual and both can be overcome. One of the best public speakers I know and an inventor of an important programming language is extremely introverted. He taught himself to overcome his "handicap" by playing a role when needed, not by changing his personality. My personal case is different. I am, by nature, very introverted, but have actually changed my personality and few, other than my spouse, recognize that introversion. I did it by forcing myself out into the open and then deciding that the consequences weren't as dire as I'd expected. Your personality isn't deterministic of what you can do, just how hard it is to do some things. But teachers need to help students, especially young students, deal with this.

That said, in a team, it is possible that different people take different roles. It is best if you can find a way for them to switch roles (and in pair programming it is essential that they do so), but it may not always be possible or worth the disruption.

One option is to make your superstars tutors or teaching-assistants. If your project has roles, give them a non-programming role, since they won't learn much from just programming if they already excel there. Or give them a tester role. Or a tool builder role. But best if they can also learn to work with others. As a tool builder the rest of the team becomes their customer, similar for tester. They have to interact, but can't just take over. Their role may not require intense interaction with everyone else, but it does require some. Roles like this also confer responsibility on the individual while permitting them to do their own thing up to a point.

Teach the whole person, not just the geek. Expect that they are all different, with different strengths and weaknesses. Your job isn't to "fill them up", but to ["change their brains."](https://rads.stackoverflow.com/amzn/click/1579220541)

> **Comments:**
> **username_12**: "make your superstars tutors or teaching-assistants" indeed.  By entirely relieving them of responsibility for the *resulting code*, and making their assignment instead the progress of their classmates, you can create a positive environment.  In contrast, a situation where they are responsible for the technical outcome, but restricted from achieving that in the most direct manner, is inevitably going to result in tension.  
> **username_6**: You can also have a project planning session, where the students themselves are given the chance to assign their own roles. Having someone responsible for unit tests, code review, interface definition, etc. it also valuable in a mixed group (as well as high-level positions like tutor for the high-fliers).  

---

### Answer by username_3 on 2018-03-13. Score: 2

The key to this is to use a carrot and not a stick. Even better, build the carrot into the project process itself, so that the incentives for the superstar are to do the right thing. Of course you should always try to align the incentives with the desired outcome, but here it needs special care. It is applicable even if you *don't* have a Lone Ranger too.

Your objective, in the project is not, I assume, code at the expense of all else. Learning is the objective, not code. This is different from the workplace. Here the #1 goal is not working code, but learning. Even well structured code is valued above working code in education, and the structure will likely lead to correctness of the code in any case.

First, in your project description, say something about the learning. And divide up the grade for the project into parts, heavily advantaging process and good behavior: team-work. One way to achieve that is to have the students give reviews of their peers at the end of the project (and to advertise this at the start). You also need to give explicit grades for cooperation and teamwork.

One possible way to get feedback and give students a way to feel proud of their contributions is like this. Give every student three, say, "chits." These can be index cards signed by both yourself and the student. Each student is permitted to give a chit to another student based on their helpfulness. The receiver also signs the chit, say on the back. At the end of the project collect the chits and reward people based on how many they have from other students.

Another method, if teams have about five students or so, is to require each student to fill out a form on which they list the three, say, students who were most helpful and contributed the most to the project. They also need to write a line or two of explanation for each "vote". Note that they don't evaluate every student, just the ones they think should be rewarded.

If teams are always just two students, then each can be required to write a bit about their partner's chief contribution and their own. Again, you aren't asking for negatives and are less likely to get them in most cases anyway.

These peer-review techniques should be introduced before the project starts, so students know what is going on. I have learned interesting things about some students this way when I'd have overlooked positive contributions of someone.

Another help is to teach a development process along with the project and insist that it is used. An Agile process is especially helpful here since you can act as the team's "customer" and only give them enough "stories" (work to do) for a single period, rather than the project as a whole. You can even warn them that the direction of the project (the requirements) may change over the course of the project. There is no incentive to program speculatively in this sort of environment.

Each day, you need a set of index cards, each describing some feature of the project to implement that day. Pass them out to the team(s) and hold a short question/answer session to clarify what is on the cards but not to make a complete specification.

If you want to really make it work, have them write unit tests for the things they build, so that they know when it "works" according to the tests. Expect questions throughout the session, since the specification is only in your head.

If there are several cards for each day, then pairs (paired programming) can switch roles at the completion of each card. Even better is to have them switch for each test. Student A writes a test and passes the keyboard to B who makes it pass. B then writes a test and passes the keyboard back to A. The one not typing (the navigator) isn't expected to sit silently, but to offer suggestions throughout. Your superstar may wind up teaching some others a bit about the technology this way.

> **Comments:**
> **username_0**: Our curriculum is so old it still teaches the waterfall process.  And since it is still there, it can still be on the final exam, which I don't write.  But I could still contrast with Agile...thanks for the idea.  
> **username_3**: Might be time to look at the curriculum, then. Even IBM is agile now.  
> **username_11**: “The process is like going over a waterfall“ — A miss quote of the original use of the term waterfall to refer to the method.  
> **username_0**: @username_3 I am bound to the curriculum until it is officially modified by the state.  We are still using Visual Studios 2010.  But I can certainly augment as I see fit.  
> **username_15**: Many companies still (mis)use waterfall. It has the advantage that it ensures there is a high level vision, but the disadvantage that managers have got their hands on it and ruined it like they are trying to do to agile.  
> **username_15**: Original waterfall was actually "agile". The intent (before MBA's got their hands on it) was an illustration that the sooner you fix errors, the less they cost to fix. Code well, know where you plan to go, and fix issues early - pretty much the definition of Agile.  
> **username_3**: @username_15, sorry, but that is a misrepresentation of agile process. Agility is about responding to change, not about getting it all absolutely correct at the start (which is impossible in a changing world). You are confusing/obfuscating the issues, rather than offering useful commentary.  
> **username_15**: Waterfall, as intended, was also about responding quickly to change.  
> **username_3**: No, it was not. The sorts of things you do in waterfall, even iterative waterfall (which came later) make responding to change expensive by enabling early commitment. You are twisting words.  
> **username_15**: I can agree to disagree - as you pointed out, this side discussion is really out of scope for this question.  

---

### Answer by username_16 on 2018-07-19. Score: 2

A suggestion would be to include in the project grade a component that evaluates collaboration and make it so a group with a lone ranger fails the project or is assigned a barely passing grade. Make this explicit the moment the project is proposed, emphasize it during its execution and explain how they will be evaluated in this regard. For instance, the University of New Orleans published a [collaboration rubric](http://www.uno.edu/general-education/collaboration-rubric.aspx) that can be readily used by the instructor (or students) to evaluate the collaboration abilities of a student.

If possible, ask students themselves to evaluate the how well their partners collaborate. There is some scientific evidence ([1](https://www.sciencedirect.com/science/article/pii/S1096751611000492), [2](https://www.tandfonline.com/doi/abs/10.1080/135625100114885)) that peer assessment activities can be beneficial to grade individually according to participation in group projects. These papers also contain rubrics that could be adapted to your context.

It is important to communicate to students that collaboration means doing what is best for the team, not doing tasks physically together. If the objective of the team is learning, completing a project alone without any input from the other members is not what is best for the team, so it is not good collaboration. However, completing, individually, a task that is valuable for the team and synchronizing its execution with the rest of the work is good for the team, so it is good collaboration (as pointed out by @username_15's answer). The key here is not *individually*, but *valuable for the team* and *synchronizing*.

> **Comments:**
> **username_2**: This is an excellent answer. Thank you for citing your sources.  
> **username_15**: I like the way you were able to phrase the concept that 'collaboration means doing what is best for the team, not doing tasks physically together".  

---

