For Mentors Only: Inspiring Youth

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

[kaszeta]

Originally Posted by KenWittlief

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.

I've had the same experience with our team's students: they want to jump in immediately and do everything (and have it work right the first time). Every year it's a long effort teaching them the virtues of incremental development.

Typical conversation:

Student: Why are we testing trig functions on the bench? Why don't we just write the code and run it on the bot?

Mentor: Because if we test the trig functions (and the gyro, and the camera, and ...) here, we'll know the math is right, so when the bot spirals around randomly instead of doing the right thing, we will have a much better idea of what went wrong.

Student: But I want to run the bot now.... I have my completely untested follow-the-camera-with-PID-control-gyro-and-accelerometer-code that I want to try out.

Mentor: You must first learn patience...

Student (impatiently): How long is that going to take?

However, it's working now. All the nuts and bolts of the programming have been tested (gyro code, PID feedback, improved camera tracking, holonomic drive), and now that it's working really well, they are now seeing how the design process is supposed to work.

[Warren Boudreau]

Location: In the queue, about a minute before a match....

Mentor: Okay, where's your check list?
Student: We don't need one. It's all under control. (Thumbs up, wink)

Location: Going back to the pit, after the match.....

Mentor: What happened?
Student: Uhhhhhh, we forgot to close the pneumatics valve.
Mentor: Here's a sheet of paper. Make a check list now.

This really happened. Too many times.

[KenWittlief]

Originally Posted by Warren Boudreau

...
Mentor: What happened?
Student: Uhhhhhh, we forgot to close the pneumatics valve.
...

take two: forgot to set the "left/right side of field" switch (makes for an entertaining auton period when the bot goes the wrong way).

take three: forgot to line the robot up (aim) for auton mode

take four: the auton-disable switch was set to disable

[phrontist]

Me: Lets give up on the binary counter chips, interrupts will do the job just fine!

Mentor: Yeah, but those chips are so cool and so is the multiplexing code!

Me: Yes, but interrupts will work, lets just implement it that way and move on...

Mentor: You know what else is cool?

This sword cuts both ways. I don't see it as a mentor/student thing, but rather a personal bias issue. I've seen many professionals succumb to perfectionism many a time, and it's not always a bad thing.

[Mike Shaul]

I would have to agree with the sentiment that you can't allow things to just magically appear for the students, if they don't do it, we CAN'T do it for them.

Once they realize that they are on the hook to deliver and that they will have to explain to the rest of the team why they aren't done their motivation seems to increase dramatically... however, it seems to be a struggle at the beginning of every year.

Ah the gentle art of mentoring. My advice, let them fail.
You gotta suffer if you wanna sing the Blues. We all learn to walk, talk etc. Learning anything is by a trial and error process. I've seen a very experienced team spend 4 hours trying to 'trouble shoot' a 'software' problem, when the RC had a big red trouble light on the 5v supply circuit. (the problem was a shorted sensor. As a mentor, I simply asked them "Well, what does that light mean?" (everyone assured me the light was on as a result of a software problem.)

Eventually they came around to my point of view, but I pretty much let em thrash for about another hour, before they exhuasted themselves and came to the brilliant conclusion that maybe I was right.

Some people (and I include myself) can repeatedly shoot themselves in the foot, and then reload and shoot some more. The mentor's role is then to say sympathetically,
"If you shoot yourself in both feet, your limp will be less noticeable."

If you (as a mentor) are struggling with a problem, don't hesitate to get help from your fellow mentors. Many the time, a fresh pair of eyes can spot the problem that you can't. I've been on both sides of that situation.

Last piece of advice - adjust the trajectory by slight mid-course corrections, instead of waiting to the last possible minute and using up all your reaction mass.
(Sorry for that last bit, too many years working at NASA.)

[phrontist]

Originally Posted by Dr.Bot

If you (as a mentor) are struggling with a problem, don't hesitate to get help from your fellow mentors. Many the time, a fresh pair of eyes can spot the problem that you can't. I've been on both sides of that situation.

Why not have a student be that second pair of eyes?

[Stuart]

well as some one who was on a robotics team(I was that student who found all the flaws to your designs then solved them, and said that that alternitive would be "easy to do") and who now is mentoring one(im a college student on a team with no engineers and only 1 real coach Im as close to a mentor as you can get) I kinda have an intresting perspective on this

most of the students your working with are smart . . very smart, they have probly been smarter than their teachers for some time now, and have probly never come across a problem that they could not solve. you may call this arrogence but I say its only that if they cant back it up, and most of them can.

most mentors have gone through college, they have a job in industry and are doing pretty good . . they also are probly smarter then their colleges/bosses, and can usuly solve a problem before it becomes one(admit it youve done this).


the problem become is that you have 2 very smart very confidant people, argueing about their own personal abilitys. and thats what both students and mentors need to realise, that when you argue with each other your really arguing with yourself from 10 years in the feature or past. and your both probly right. the solution to this is respect, for the student remember that your mentor does have experiance behind them and that "getting it working" is a great place to start from, you can then add onall your little whisslebobs after that. and the mentors nead to remember that that student your talking to can do what they say they can, and that paper with fancy writeing/ paper with big numbers doesnt neccicarly make you always right.


and thats my take on it