For Mentors Only: Inspiring Youth

[Rick TYler]

Sometimes, I think a small rubber mallet would be just the thing...

Mentor: Why don't you program 127 speed as a special case -- your driving code takes too long to return to stop when the user just lets go of the joystick.

Student: NO! If I write the code to handle all cases properly, it should handle that, too.

Mentor: The acceleration curves look good, except when the driver wants to stop dead. Why not program 127 as a special case?

Student: NO SPECIAL CASES! That's a hack. I want to do it right.

Mentor: We have to ship the robot in two weeks. Don't you think you should just call this a win and program the aiming algorithm? I think three weeks on the driving code is enough.

Student: NO! I know what's wrong -- just one more change!

Mentor: Just program 127 as a special case, and let's hook up the camera.

Student: NO! I know I can do it!

etc.

Kind of makes me think I should take up bull riding instead.

Any other instructional student/mentor interactions?

[RogerR]

Originally Posted by Rick TYler

Sometimes, I think a small rubber mallet would be just the thing...

you mean "motivation"? we have one of those. we also have two larger ones called "inspiration" and "respect".

here on 1369, we mentors have been using The George Wallace Method (named after it's creator, George Wallace); simply put, you use frequent, random beatings and verbal abuse to keep students in line.*






*just kidding. we don't beat the students to keep them in line. we just beat them for fun.

[Dan Richardson]

Originally Posted by RogerR

you mean "motivation"? we have one of those. we also have two larger ones called "inspiration" and "respect".

here on 1369, we mentors have been using The George Wallace Method (named after it's creator, George Wallace); simply put, you use frequent, random beatings and verbal abuse to keep students in line.*




*just kidding. we don't beat the students to keep them in line. we just beat them for fun.

I know that method all to well, especially because when its George Wallace sometimes it applys to fellow mentors as well. heh just kidding hope he doesn't hurt me

[Eldarion]

Originally Posted by Rick TYler

Sometimes, I think a small rubber mallet would be just the thing...

Mentor: Why don't you program 127 speed as a special case -- your driving code takes too long to return to stop when the user just lets go of the joystick.

Student: NO! If I write the code to handle all cases properly, it should handle that, too.

Mentor: The acceleration curves look good, except when the driver wants to stop dead. Why not program 127 as a special case?

Student: NO SPECIAL CASES! That's a hack. I want to do it right.

Mentor: We have to ship the robot in two weeks. Don't you think you should just call this a win and program the aiming algorithm? I think three weeks on the driving code is enough.

Student: NO! I know what's wrong -- just one more change!

Mentor: Just program 127 as a special case, and let's hook up the camera.

Student: NO! I know I can do it!

etc.

Kind of makes me think I should take up bull riding instead.

Any other instructional student/mentor interactions?

I know this is supposed to be for mentors only, but I have to say this sounds a lot like a typical conversation with myself!

[kaye]

I am a rookie mentor, but I will say one thing: SPIRIT.

Ain't no way to get this job done - not to mention have ANY fun at all - if people don't pull together. The FIRST manuals on building the robot are exhaustive, but there ought to be a Project Management pack to help inspire and organize the team crews and balance the flow of ego. It's almost as though if you are not actively involved in building the bot, you rate, well, less.

Yes, I know. It's First ROBOTICS, not FIRST, um, T-Shirt. Still, a quick look at Autodesk Streamline shows you how the hierarchy of a project flattens out--the sum is greater than its parts, etc. That's what I think we need to remind ourselves.

Team leaders and mentors have to work to get this message across. I think that you gotta do EVERYTHING to maintain a team atmosphere. Make sure that you start right away with sprit-building stuff like choosing a team name, logo design, getting t-shirts and logo-stickers and slogans onto anything that moves. Make NOISE. Choose a theme song. Be nuts!

Your project manager has to be an absolute MANIAC for teamwork. He has to make EVERYONE feel valued, right down to the kid who letters the safety signs. An "I can do it myself" Type-A personality may get the job done, but he/she will alienate most of the team before the first week is out.

I'd be glad to hear what y'all think.

[ForgottenSalad]

Mentor: We have to ship the robot in two weeks. Don't you think you should just call this a win and program the aiming algorithm? I think three weeks on the driving code is enough.

Student: NO! I know what's wrong -- just one more change!

I've been all too guilty of that one plenty of times. Heh. It's interesting to see it from a mentor's point of vew... Good idea for a thread.

(I know this thread's for mentors only but eh...)

[sanddrag]

I tell them "Sure, I'll take the blame if we don't get it done or it doesn't work. But that doesn't mean I'll do anything about it."

Is that inspiring?

But seriously, I tel students I'll help them but I won't do it for them. And anything I do, I make sur they know what is going on. Because I don't want us getting into the mindset that every time they need something I show up and it magically appears. They actualyl need to know that there are parts suppliers and shipping companies between the web page and me, and that there are hours of machining between inventor models and actual parts. If mentors do too much, they start believing all their designs come with an automatic/instantaneous "export to reality" function, which they most certainly do not.

[Al Skierkiewicz]

Rick,
Each case is different but in a situation like this, it might be best to comprimise. i.e. "We need to get going on the shooter program and we are coming down to ship. How about you work on this problem until 7:00 and then just insert the 127 so the drivers can practice. We can come back to it we have time before ship. Then get the shooter done and we'll see how it goes from there."

[meaubry]

Great topic as this does get to be a difficult balancing act.

This 6 week project is all about deadlines and compromises. Try to be firm with the planned deadlines for major tasks and play it by ear for the lesser ones, as the dependencies quickly determine what can and can't be done.

Do the "must haves' first, then focus on the "nice to haves".

Make the point to the students that if they don't all work together AND to the plan, the robot will NOT get completed with enough time to test that it works (really important to do this before it goes in the box).

I purposely didn't refer to the programming issue because I look at programming the same way as I look at making parts - it ALL has the same deadline and MUST be included in the project planning. There are lots of times I would love to keep working on a mechanism until it was perfect - but if it is not an absolute critical piece, we do the best we can and move on. I suppose knowing how to convince a student to "move on" is what the real problem is in your example.

When deciding to make something "perfect, but late" or "sufficient, and on time" - take sufficient and on time, there is time for improvement later.

[Rich Kressly]

There have been some excellent documents floating around (check white papers) and also at least one championship presentation on the topic of project management. In a perfect world all teams would have some sort of decision making / timeline "system".

That being said, this is less than a perfect world and many decisions for every FIRST team will be judgment calls during the brief build season. If there is a priority list with time limits set during brainstorming that could help. Mentors will almost always have to step in and keep everyone focused on the big picture while they also inspire the learning process. I'm a big fan of Al's approach, which validates the student's desire and moves the project along at the same time.

During my six years in FIRST, I've had several opportunities each season to address groups of students and individuals about project management, timelines, and decisions. I always try to be empathetic, but I'm also always as real as I can be about deadlines and the big picture. Mentoring and teaching can take place in all kinds of ways. What one student needs is not what another student needs. Sometimes a very gifted and intelligent student simply needs to learn that it's time for the project to progress and it is not their decision. Other times it may be appropriate for mentors to allow someone to "run with a ball" and go a little past the team deadline.

In all cases though, it's about respect, responsibility, learning, the big picture, and the final product. No one is perfect and I'm the first one to admit as a teacher that I make mistakes with students every day. In the end, the best we can hope for is that we (mentors and students) learn from our mistakes and grow as people through the process.

Namaste...

[KenWittlief]

Some of my favorite Mentor/Student conversations:

[Student, 1 minute before a match] I want to make a small change to the code, its only one line
[mentor] we cant change the code now, there is no time to test it before the next match
[student] we dont need to test it - its only one line - I KNOW it will work


[student] My code is not running right, there must be something wrong with the robot controller!" (I call this CS101 syndrome: "My ten line program is giving me the wrong answer, there must be something wrong with the VAX / Mainframe / PC / microprocessor.....")

CS101 version 2.0 [Student] the RC in the robot is blown out, the robot is completely dead!
[mentor] what was the last thing done to the robot?
[student] I made some changes to my SW, recompiled and downloaded, and now the RC hardware has failed.
[mentor] did you try downloading your old code again?
[student] what good will that do? the RC is bad!

the core all these situations is ego. Im not picking on students, because ego is a problem for all new engineers. We have to learn to detach our ego from our work (projects) and accept that we must follow the whole engineering design cycle:

define WHY a new system is needed
define WHAT the new system must do
define HOW the new system will do those things
build a prototype
test the system to ensure it does the WHAT
give the system to the customer (user) to make sure its what they want.

The temptation to jump into a project at one point, and fly by the seat of your pants is overwhelming. For most new engineers, once you have done than, and gotten burned by your own ego, then you really understand the whole design cycle, and why each part is absolutely necessary.

[petek]

I have a pet motto I keep trying to remind myself which I think is relevant:

Better is the enemy of good enough.

I bet a lot of us (mentors and students) got into this line of work first because we wondered how things work, and stayed in it because we thought "I can make that work better". Thus starts a life-long battle between perfection and time. So far, time is ahead.

[BandChick]

The one thing we've been focused on is prioritizing and time management. It's worked for the most part, but there are always kinks that need to be worked out. Speaking of, 1089 found and developed a great project management script for our team. It's called Dot Project, and it allows you to set up projects with timelined deadlines, assign individuals to a project, track the progress of the project etc.

You can find the software here: http://www.dotproject.net/demo/
Here's the tutorial on how to use it, as well: http://psdam.mit.edu/rise/tutorials/...anagement.html

I sympathize with your post, Rick, I'm sure most mentors do. Just remember, even if they do it the long way, at least they're learning!

[John Neun]

Originally Posted by petek

I have a pet motto I keep trying to remind myself which I think is relevant:

Better is the enemy of good enough.

I bet a lot of us (mentors and students) got into this line of work first because we wondered how things work, and stayed in it because we thought "I can make that work better". Thus starts a life-long battle between perfection and time. So far, time is ahead.

"Better is the enemy of Good Enough." I must confess, I have never heard that before, but it is something we should have posted where all can see it. Good one!

Sometimes even the most capable students can't live up to their own estimations of their capabilities. I am of course guilty of this, too, but as we get older and experience more failures, our assessment of our own skills becomes more realistic, or at least more humble. I wish I had the blissful self-confidence of some of our students, even if it is a little delusional. It's all part of the process.

[Peter Matteson]

Originally Posted by petek

I have a pet motto I keep trying to remind myself which I think is relevant:

Better is the enemy of good enough.

I bet a lot of us (mentors and students) got into this line of work first because we wondered how things work, and stayed in it because we thought "I can make that work better". Thus starts a life-long battle between perfection and time. So far, time is ahead.

In my office we call that "analysis paralysis". In addition to using the quote above. Sometimes you can get so focused opn a problem you can't see it clearly anymore. At that point a good engineer will ask for assistance from someone whom is outside the situation and can look at it more objectively.

Sometimes our paradigms blind us from seeing the alternate solution because it is outside our understanding. That is why we never saw the solution that now seems so obviously simple.