Mentor coded robots

FIRST General Forum
#49

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.

#50

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.

#51

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.

#52

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.

#53

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.

#54

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.

#55

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.

#56

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.

#57

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.

#58

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.

#59

Yes, that does seem to be what OP is looking for.

#60

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.

#61

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.

#62

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…

#63

keep frosty my friends :slight_smile:

#64

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.

#65

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:

  1. Make sure students are safe
  2. Make sure students want to contribute to the team
  3. Make sure students have an environment they can learn in
  4. a bunch of other stuff (help find sponsors, train students, work with the school district, etc)
  5. 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:

  1. Make sure students are safe
  2. 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.

#66

I cannot make this up.

#67

The OP didn’t imply that, unless you chose to read that into it. I don’t think the OP was particularly well-constructed, but it wasn’t posed as a normative statement about what mentors ought to do. If the OP’s intent was to shame mentors who “do too much,” then the fact that everyone responded this way was more efficacious at spreading that sentiment than the OP ever would have been on its own. I’m a programming mentor who has done quite a bit of “hands-on” coding for my teams in the past, and I didn’t feel impugned by the OP.

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.

The first case is a really important tool for being able to discuss fraught subjects productively, though, and I really don’t think it’s a good idea as a community to become hostile to it.

If you can’t see the difference between “the OP should not cause a reasonable person to feel shame” and “some people should be ashamed for the way they have responded to this thread,” I’m afraid that we might have trouble communicating further. These aren’t contradictory in any way, they’re totally different things.

#68

The OP is aware of previous Mentor Built™ discussions, and is thus aware that the title Mentor Built™ is reserved for teams on which the speaker believes the mentors are building too much of the robot. The term is most commonly used to deride high performing teams.

The OP then asks members of the forum to draw a line (well with 13 questions its more of a hyperplane) in the sand between robots where one specific aspect of the robot is Mentor Built™ and robots where that aspect is not, and lazily re-brands it “Mentor Coded.”

The OP makes no attempt to separate the obviously derived new term from the originals derisive context, thus it is entirely reasonable for readers to assume that the OP has no intent of doing so.

When so many people “misinterpret” the OP, it’s the OPs fault, and they are either incredibly bad at communicating, or are just lazily covering their butts.

Since the OP recently graduated, and I know most mentors attempt to teach their students to communicate effectively, I’m betting on option two.