25
$\begingroup$

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 and What advantages/disadvantages have you seen with Pair Programming in the classroom 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?, and Problematic student at a very high level, 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.

$\endgroup$
  • $\begingroup$ As a "lone ranger" myself -- though it's less that I don't want to and more that I'm just terrible at and not used to it -- this is incredibly useful. Thanks! $\endgroup$ – Fund Monica's Lawsuit Mar 14 '18 at 21:43
  • 2
    $\begingroup$ 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. $\endgroup$ – allo Mar 15 '18 at 10:02
37
$\begingroup$

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 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.

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.

$\endgroup$
  • 3
    $\begingroup$ 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. $\endgroup$ – Java Jive Mar 13 '18 at 21:00
  • 3
    $\begingroup$ 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. $\endgroup$ – Gypsy Spellweaver Mar 13 '18 at 21:00
  • 1
    $\begingroup$ 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. $\endgroup$ – Buffy Mar 13 '18 at 22:59
  • 3
    $\begingroup$ @Buffy That should be another answer, no? $\endgroup$ – Ben I. Mar 14 '18 at 0:40
  • 3
    $\begingroup$ @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. $\endgroup$ – Clay07g Mar 14 '18 at 16:10
11
$\begingroup$

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 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.

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.

$\endgroup$
  • 2
    $\begingroup$ 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. $\endgroup$ – Java Jive Mar 13 '18 at 20:26
  • $\begingroup$ 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. $\endgroup$ – Java Jive Mar 13 '18 at 20:26
  • 3
    $\begingroup$ 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. $\endgroup$ – Buffy Mar 13 '18 at 20:29
  • $\begingroup$ Since the original question was predicated on the assignment being a group project, this answer is not on topic. $\endgroup$ – Lee Mosher Mar 14 '18 at 18:11
  • 2
    $\begingroup$ @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] $\endgroup$ – apnorton Mar 15 '18 at 2:47
4
$\begingroup$

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.

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. – Logan Pickup
$\endgroup$
  • 3
    $\begingroup$ "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. $\endgroup$ – Logan Pickup Mar 15 '18 at 4:09
3
$\begingroup$

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.

$\endgroup$
  • 6
    $\begingroup$ This is a bit too much of the "stick" approach. Try the carrot. Dip it in sugar first. $\endgroup$ – Buffy Mar 13 '18 at 22:53
  • 6
    $\begingroup$ 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. $\endgroup$ – Chris Stratton Mar 14 '18 at 15:40
  • $\begingroup$ @ErikAlapää, your last sentence was unkind and has no place here. $\endgroup$ – Buffy Mar 15 '18 at 13:05
  • 1
    $\begingroup$ @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. $\endgroup$ – Erik Alapää Mar 15 '18 at 13:30
  • 1
    $\begingroup$ @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. $\endgroup$ – Java Jive Mar 15 '18 at 14:28
3
$\begingroup$

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."

$\endgroup$
  • 3
    $\begingroup$ "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. $\endgroup$ – Chris Stratton Mar 14 '18 at 15:46
  • $\begingroup$ 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). $\endgroup$ – Logan Pickup Mar 15 '18 at 4:06
3
$\begingroup$

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 @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.

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.

  1. 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.
$\endgroup$
  • $\begingroup$ 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 . $\endgroup$ – pojo-guy Mar 14 '18 at 12:08
  • $\begingroup$ These problems are not the same, not even on the same scale. They certainly don't have the same solution. $\endgroup$ – Buffy Mar 14 '18 at 12:53
  • $\begingroup$ @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. $\endgroup$ – pojo-guy Mar 14 '18 at 13:54
  • $\begingroup$ @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. $\endgroup$ – Ben I. Mar 14 '18 at 17:09
  • 1
    $\begingroup$ 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. $\endgroup$ – Ben I. Mar 15 '18 at 0:27
2
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – Java Jive Mar 13 '18 at 20:31
  • $\begingroup$ Might be time to look at the curriculum, then. Even IBM is agile now. $\endgroup$ – Buffy Mar 13 '18 at 23:00
  • $\begingroup$ “The process is like going over a waterfall“ — A miss quote of the original use of the term waterfall to refer to the method. $\endgroup$ – ctrl-alt-delor Mar 13 '18 at 23:40
  • $\begingroup$ @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. $\endgroup$ – Java Jive Mar 14 '18 at 1:34
  • $\begingroup$ 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. $\endgroup$ – pojo-guy Mar 14 '18 at 23:41
2
$\begingroup$

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 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, 2) 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 @pojo-guy's answer). The key here is not individually, but valuable for the team and synchronizing.

$\endgroup$
  • $\begingroup$ This is an excellent answer. Thank you for citing your sources. $\endgroup$ – Ben I. Jul 19 '18 at 16:00
  • $\begingroup$ 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". $\endgroup$ – pojo-guy Jul 21 '18 at 14:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.