Ouch. I’m wounded.
In the spirit of trying to be productive, here’s my $0.04 (I had to adjust for inflation). It may look a lot like what’s already been said:
The core of asking what level of involvement is acceptable for a mentor to have is inherently a question of what the students will get out of it. Naturally, this means that one extreme (throwing the kids off the deep end) is just unproductive, since floundering is usually neither educational nor inspiring. That being said, the opposite is almost worse - when mentors take over the code and the students have little say in it, the students still don’t learn much and it’s not satisfying for them, even if the code is “better” by some metric. My experience with the whole mentor-written/designed/built bonanza is that it can vary a lot for teams - Team 100 prides itself on being a very student-oriented team, but we’ve also run into hangups where students didn’t have the experience they needed and didn’t feel comfortable asking for help. In the past year or so, student and mentor leadership has been working toward a culture change where we can call on mentors for help.
However, I think the core of keeping the right balance is a question of ownership. When a student can look at some part of a robot or its code and say, “I did that,” they’re much more likely to have enjoyed their time on the team and have gained something from working on it. Ownership doesn’t necessarily mean it was done alone - it’s just as satisfying to do something entirely yourself as it is to have help, either through tools written by or with the direct assistance of a mentor. At the heart, a student-written set of code would likely have some of the following properties:
- Student understanding of most algorithms and architecture used
- Sense of student pride and ownership over most or all of the code
- Confidence from students in modifying or writing new code
- Student involvement in the writing, testing, and structure of code
This is naturally a non-comprehensive and incomplete list. Note that these features are incredibly vague. Meeting what’s in the bullet points doesn’t mean that mentors can’t be involved in the coding process - far from it. However, I think it means that all mentors should know when is a good time to “back off” and respect students’ experience and ownership of a project. It will likely vary from team to team, and most teams probably wouldn’t make all the things in this bullet list (I can say right now that Team 100 doesn’t). However, at the end of the day, the “right amount” of mentor involvement is what gets you closer to either meeting those bullet points, or to meeting whatever the goals of the team are.
There is no “optimal” degree of mentor involvement. It’s a stupid question.
I’ve had students who were best served by doing the work on their own and coming back when they get stuck. I’ve had students who were best served by me sitting next to them and asking them guiding questions. I’ve had students who were best served by not looking at code at all because they wanted to focus on other things. Heck, I’ve had students where the best thing for them is to tell them they CAN’T do something.
The optimal degree of mentor involvement is entirely up to how the students learn and the mentor teaches. Sometimes the optimal level of involvement changes based on how those things interact. I have a certain way of communicating, a student has a certain of communicating. Sometimes these two things don’t line up and you have to adopt other approaches to effectively communicate.
The framing of the question had certain implications that mentors SHOULDN’T be doing certain things. The title betrays that thought process, there’s a very not subtle implication that we should be trying to “spot” mentor coded robots. And the entire post reeks of white glove mediocritism [1]. And then it goes to list what are effectively lines in the sand that we shouldn’t cross unless we want to be a “mentor coded robot” [2].
So what nuance do you want in this discussion? The OP comes from the wrong place, not my words, FIRST’s words. This is a MENTOR based program to inspire students to pursue STEM careers. Wanna take the mentors out? You’re in the wrong program.
[1] Which is what I’m going to start calling the idea that we need to drag down the best of us.
[2] implication of it’s bad… it’s not.
The quintessential (ideal) mentoring experience for the mechanical side goes something like:
“I show & teach by doing the first part, We do the 2nd part together, You do the 3rd & 4th parts while I watch”.
What’s hilarious to me is that if all 4 parts go on the robot, there is still a subset of people who would have a problem with that student experience.
The difference between that mechanical experience and code is … well, nothing.
It seems to me that the reason some teams have more mentor-built or mentor-coded items lies with how much the different mentors push their students. The mentors who push more owe it to their students to follow through and guide the students to success. There may be more “showing” than students “doing” in some cases because the mentor didn’t fully-understand the impact of what he or she told the student. What kind of mentor would I be if I told my students “Based upon my experience, you should do X,Y & Z complicated thing. Google it.” and left them to their own devices? In the “real world” that type of thing leads to failure most of the time. It’s also un-inspiring, would result in a terribly-performing robot (un-inspiring), and seems to be the antithesis of FIRST’s mentoring guidelines.
How hard should mentors be allowed to push their students in order for the team to gain a competitive advantage? The answer, IMO, is succinctly outlined in post #5 above.
From what I’ve observed, the teams demanding to have a “more level” playing field with less mentor involvement are usually those who don’t have mentors to push them or the mentors they do have are unable to follow through on how hard they push.
Sure there is. It may be team-context-dependent, but within the context of each team there’s certainly an optimization problem to be solved. Moreover, I think I’ll go out on a limb and suggest that there are likely commonalities between teams that make discussion of the issue quite fruitful.
You’re reading the OP in bad-faith, and I think you know it.
My philosophy is that my role as a mentor is to be trusted by my students, and, reciprocally, to trust my students.
But let me be clear - this trust I’m talking about isn’t a passive thing. I have to ask my students if they’re happy with their experience with me as a mentor. I have to spend a lot of time training my students in the preseason. I have to step back and give my students opportunities to fail. All of those things were hard for me to pull off last season, but I tried my best. And I like to think that I grew as a result - hopefully as much as my students did.
I personally agree with the other voices in this thread - the balance is incredibly situational. On 6844, there are some students where the balance is such where I need to be more active, and there are other students where I need to step back more - in the same meeting.
But can we please have a civil, thoughtful discussion here? The amount of invective on this thread is mind-boggling. I personally think that it’s both appropriate and constructive to discuss mentor/student dynamics in depth.
We design a new robot every year, but we can’t forget that we also design a new team every year as folks come and go.
No he’s not. Statements like this make that case by showing a premeditation of knowing the subject is going to not only cause controversy but that the person posting it clearly has an opinion and an agenda:
THIS POST IS FOR DISCUSSION AND NOT AN ACCUSATION NOR INTENDED TO BE POINTED TOWARDS ANY INDIVIDUAL OR TEAM
There’s a lot of talk on CD about mentor-built robots.
Mentor-coded robots are presumably harder to see
It feels weird to be putting this out on CD
I hope it doesn’t spark too much controversy
I’m not looking to set out some specific rules
I just want to see what everybody thinks
It’s pot stirring. Which is exactly what you accused me of doing presumably by comparing me to “edgy 4-channer” in your PM just moments ago.
This wasn’t posted in good faith and others have pointed it out already.
I think Andrew’s point is that it isn’t a blanket optimization for the whole team. Different KIDS need different mentorship. Not just overall teams needing different styles of mentorship.
It’s not even TEAM context dependent. It’s individual student/mentor interactions on a per problem space basis and can change drastically from moment to moment. It’s literally impossible to set up rules about it. Actually, Marshall might be a good person to ask about it, having interacted with many of the 900 students and watched the interactions between their mentors and them I’ve seen a wide range of levels of interaction varying based on the question and the student.
I’m reading with the context I have based on common practices in both the english language and discussion in this community as well as what I know of this student from interactions with their mentors. Words don’t exist in a vacuum, to claim otherwise is foolish. CD has played host to increasingly many “Mentor Built Robots” threads over the years. The naming similarities are either intentional or subconscious.
But since you want a nuanced discussion here:
OP - your core question is flawed, we have no reason to “notice” because that’s an internal thing to the team. Mentoring in general needs to be driven by student/mentor/problem interactions.
The more important question you SHOULD be asking is “how do we spot interactions which are counter the goals to our program” [1] For example - how do I, as a mentor, recognize that my particular style of communication is not effective with a student’s style of learning? What changes can I make? How does this change in the context of “what is best for the team” vs “what is best for the student”?
Instead of “Mentor Coded Robots, where’s the line” the question SHOULD be “how can mentors more effectively mentor students on software?”
[1] Notice, I said OUR. You can’t apply this question to other teams, you don’t have the proper context or history. Sorry, just because you saw a mentor do something doesn’t mean they do things all the time, there may have been things you didn’t see. [2]
[2] This is actually a common problem in FLL judging.
In my opinion, I don’t have much issue with mentors doing coding work like this as long as students are involved in the process and learning something. If a mentor decides to write code and distribute it, I can only hope that students on their team were able to see and understand how it was written and what it does. This way, the students gain a level of autonomy and don’t have to rely on the mentor being there if problems arise.
Maybe some teams need a code base from a mentor in order to start the process of knowledge being passed down by the students, or maybe something needs a quick fix during a competition. At the end of the day, as long as the students gain something positive, I’m happy.
I don’t understand why you’re constraining the problem so narrowly. There’s no need to be able to come up with a set of strict rules governing the thing in order for discussion of it to be worthwhile. Your take here reminds me of the fallacy of gray - in your zeal to emphasize how nuanced the situation is (I think most people here know it’s nuanced - obviously, I could be wrong) you exempt it from rational discussion entirely. I think this is a mistake.
As a mentor who has, in the past, essentially coded an entire robot for a team (in a situation where I still believe, in retrospect, that it was necessary), I simply do not agree with you that it is useless to frame the question in terms of “how much should the mentors do.” That is not the only angle from which one should look at the mentor-student dynamics, but it is an important one.
The OP read like “No offense, but…[sentence that offends].” Saying ‘this is not mentor shaming’ or ‘this isn’t intended to cause controversy’ does not make it so.
To broach this topic in a more diplomatic manor might be to ask: “How does mentor involvement in programming mesh with the high-level ideals of FIRST?” or “How does your team/mentors handle coding the robot to maximize FIRST goals?” Both of those introduces the same topic in a positive light, without implying that some level of involvement is too much or mentioning ‘mentor shaming’ or other negative subjects.
Yes, that does seem to be what OP is looking for.
Plot a function on the range of (0,1) [1] where the output is the appropriate percentage of mentor involvement. The variables include MentorCommunicationStyle, StudentLearningStyle, Problem, TimeAvailable, InspirationOfFailure[2], InspirationOfSuccess… and I’m sure I’m missing a few.
It’s a pretty crazy plot isn’t it?
That plot is worthless because the amount of effort to enumerate all the options and their impact. That’s your “optimal” line. It’s pointless. But that’s the answer to the OP’s questions. “Here look at this chart with a couple billion options and find your case”
I already suggested a more valuable discussion to have, how do we recognize and adapt mentor style and involvement. It’s a very related question but it moves the problem from “let’s draw lines in the sand” to “how can we inspire better”… Maybe I’m crazy for thinking one is worthwhile and the other is going to be washed away by the tide.
[1] I refuse to acknowledge white glove teams as acceptable in a Mentor based program. Don’t @ me.
[2] This could represent the cost of failure in inspiration, but it can also be a positive if the student in question learns that way.
Perhaps an analogy might help to demonstrate my point: how is the argument you’ve made here substantially different than, say, complaining about the existence of feminism because “there are so many other factors that we need to look at other than gender?”
That it is a complicated multidimensional problem-space does not itself mean that it is not fruitful to sometimes discuss one dimension in particular. That requires a more detailed argument than what you’re giving here.
That is more accurate than you believed. I’m complaining Feminism needs to exist because men are unwilling to look in the mirror and say “what can I do better?”
Inb4 someone quotes only a small fraction of this and jumps down my throat for complaining feminism exists…
keep frosty my friends 
One does not say “This is not X” and then proceed to lay out a series of statements that imply the opposite, if they do not want to say that X is true, especially on CD.
If you have to put “This is not X” in the post, you are at best acknowledging that you may be seen as doing X, and at worst trying a late cover-up. I suspect this time is closer to the first.
BUT…better than 90% of threads like this are, in fact, doing X.
I’m probably responding too late into this for it to be read by anyone that it may be useful to, and I may sound like a broken record, but I’m going to post anyway. I think there’s a subtle difference between what I’m saying and a lot of what I read, even if we’re in complete agreement.
I think when people bring up “mentor built” vs “student built” I think the heart of the matter is really what are the mentors responsible for and what are the students responsible. It still varies from team to team (and student to student), but I think this really addresses the issue.
My responsibilities as a “lead” mentor are:
- Make sure students are safe
- Make sure students want to contribute to the team
- Make sure students have an environment they can learn in
- a bunch of other stuff (help find sponsors, train students, work with the school district, etc)
- mentor the students through building a robot. Depending a lot on 2 + 3 above, this may involve anything from CAD, writing code, picking up tools, showing videos, walking through math at a whiteboard, teaching from powerpoints, walking students through how another team solved a problem, asking questions, sitting at a desk and doing my own work but being available for questions, etc. People get hung up a lot on this while ignoring 2 and 3.
Some other mentors might have very reduced responsibilities:
- Make sure students are safe
- help students build a robot
Ideally most or all mentors have 2-4 in the “lead” mentor responsibilities…but that’s just not going to happen for all mentors on all teams.
Student responsibilities vary greatly from student to student. Until they get to the point where they are wanting to contribute to the team, that is my focus as a mentor. Then, if they’re wanting to contribute to the team - the environment for them to learn from might be me stepping away and letting them run with it, or it might be me there solving the problem side by side. Sometimes depending on the problem it might even be me doing it entirely the first few times to show them.
TL;DR - when you hear mentor built vs student built, reframe to mentor responsibilities vs student responsibilities.
I cannot make this up.