Mentor coded robots

FIRST General Forum
#41

This is where 4607 is now. Rewind to 2013-2015 we struggled to find our way in how the team should operate. In 2016 we had our breakout season (in my eyes) because we shifted how the team operated. We had a leadership team of six students and three coaches (coaches are different than our mentors as they are more administrative). We brought on a new coach that shaped up our Business, Marketing, Media, and Chairman’s side of things. Lo and behold, this area of our team succeeded our wildest imaginations (RCA in our 4th season).

Because of this success, we went a stretch further in 2017 with our engineering side of things, but we didn’t fully engage the way we did with the Business side. It ended up being a trainwreck half way through the build season and we went back to the playbook and reset things for 2018 (our team was nearly 60% new students and mentors). We ‘embedded’ mentors in all aspects of the design, engineering, and programming sides of the team. It was a resounding success as the team built a very robust, very easy-to-maintain-robot, and the programming took off once we had the right components (anyone want to purchase some GEMs?). We again won a RCA, the robot qualified for our State Tournament in it’s own right (first time since 2014), and made it to finals on Curie. Now - we could not have done this without our new programming mentor that really brought our programming department up to snuff - all the while on an unsupported language (Python). He has been instrumental in the success of our robot on the programming side of things. Without him, we would have a good robot that made it to champs via our RCA.

Along with all of this, we had a number of mentors very well versed in FMEA that proved to be one of the greatest assets for our team. I would like to think that even though we weren’t the first to pioneer the FMEA process, we definitely defined how it should be run on a FRC team.

From 2013-16 I would be proud to have won a ‘white glove’ award. However, I was also very blind to the ideals of mentorship on a FRC team. Now we are very proud of our policy of embedding mentors into the process and the growth of our students in their own right.

tldr; Get mentors involved in all aspects of the team.

#42

This isn’t rarely discussed. This has been discussed hundreds of times. The same people that come down on the side of “mentors do too much” will come down on the same side in this case.

Of course you’re starting from some faulty assumptions. Just because a robot looks incredible doesn’t mean that mentors had something to do with it. And a poorly coded robot doesn’t mean mentors didn’t write every last bit of code.

But it all goes back to - what’s right for your team. If the team members are happy and learning, you’ve found a decent balance.

#43

Additionally, mentors should be involved in all aspects of the team just to make sure things are handled in a mature professional way. For example - if a student got a little upset and tried to delete all the team’s code, the mentors should have a way to prevent this and mitigate damage. That student may also need to no longer be on the team.

#44

As I read through this thread, I was hoping some people would pick up on this question. I think it is a good way start a conversation to learn what is going on out there, what is working, and why. I was a bit disappointed not to see it but having read a number of these sorts of threads, it was not surprising. Sorry if more it was there than I picked up on, after a bit I did start reading rather quickly.

While I am not with a top performing team now (both are showing improvement, maybe some day), I will share a summary of my experience.

In my 8 seasons of programming mentoring, I have varied from writing quite a bit of code to writing no code. Each case was based on 1 or both of these factors:

  1. the best way to teach the programmer(s) a new concept(s).
  2. the immediate needs of the team. This comes in a couple flavors.

  • a crisis that the programmer(s) do not have the skill or time to handle (always loop back to teach afterward).

  • capacity issues (e.g. only one student programmer that also has other responsibilities).

My ideal is to run or assist students at running off season programming classes and to write just a little code in season but mostly guide and advise. I want to write a little code because it forces me to stay in regular contact with the code. I have other mentoring areas too that could take all my time if I let them.

Are you sure about this? I have found that good leadership often comes down to being able to ask the right question.

Steve

#45

One thing I wonder, If you are using a library written by others, does it matter who wrote the library? Where does the robot builder fall into this. On the hardware side: Should we be dishing teams how use COTS gearboxes?

#46

This thread is not mentor shaming. The OP went to great lengths to make clear that it was not mentor shaming. It is entirely reasonable to discuss what the “optimal” degree of mentor involvement in a given aspect of FRC is. Is this team-specific and hard to generalize about? Sure, and the discussion should reflect that.

But it is puerile and betrays a certain fragility of ego to attempt to stamp out a discussion like this because of the whiff of “anti-mentor sentiment.” A lot of you should be ashamed.

#47

Ouch. I’m wounded.

#48

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.

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