For Mentors Only: Inspiring Youth

[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

[KenWittlief]

Originally Posted by Stuart

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.
...
...
the problem become is that you have 2 very smart very confidant people, argueing about their own personal abilitys.

yes, there it is: ego. One person who keeps tripping over his own ego, or two people whos egos are so big they keep crashing into each other.

Engineering and science is not about being smart. You dont get paid based on your IQ, or how many things you have memorized, or what you can invent on your feet.

You get paid for results. Sometimes the super bright young engineer gets so caught up in recognition and credit for his work, whether or not he will get a bonus or a raise, that they go off the deep end, quit their job in the middle of the project and go where someone will recognize what a 'genuis they are'. The run off to someone who will stroke their ego.

Then who finishes the work that was left behind? Usually its your engineer with an average IQ who comes to work everyday, follows a logical proceedure, and doesnt worry about whos getting all the glory. In other words, the guy without the ego problem. The guy with his eyes on the whole project. The guy who understands than when his task is done there are twenty other people downstream whos tasks are just beginning.

With engineering, the thing is, there is no right answer. There is not even a best answer. There are always many ways to design and build and test a system. In the end it doenst matter whos idea was the most clever or creative. What matters is who got the project done, on time, on budget, with few bugs and errors in the final product.

The end user (the drivers in our case) are not going to know if the code in the RC is brilliantly written, clever and concise, all they will know is "when I push the joystick the robot goes forward...."

and the dead-honest truth is, thats all the end user really cares about.

[Daniel_LaFleur]

The end user (the drivers in our case) are not going to know if the code in the RC is brilliantly written, clever and concise, all they will know is "when I push the joystick the robot goes forward...."

and the dead-honest truth is, thats all the end user really cares about.

Ken is so on target here.

The end user does not care who finished the project. He does not care what problems you had to overcome. He does not care how much work went into designing / testing / building whatever widget you designed / tested / built.

All they care about is that it does what you say it does, in a fashion that is easy to use and reliable. Lets face it, in the real world very few are interested in the design problems that went into your MP3 player....all they care is that it works out-of-the-box and all the time.

[dhitchco]

In the process of trying to inspire youth as well as inspiring fellow mentors, I am reminded of one thing:

In corporate life, it's a careful balancing act:
Product Quality
Product Cost
Product Schedule

You can have supurb-quality products that are "late to market" and cost too much and will FAIL

You can also have products that ship to meet the schedule (e.g. the holiday rush) but that have terrible quality and safety issues.

So, I find inspiration in students and mentors when you can look YOURSELF in the mirror and say "I did it all....quality, cost, and on time"

You have noone to impress but yourself........isn't it called "self-engraciating"?

[Taylor]

It is a delicate balancing act - when do we allow the students to try something we know will fail, but the experience will make them better. Especially this close to the end of the build, we as mentors are taking a more aggressive approach to putting forth our ideas. Not because of ego, not because of pride, but because time is an (the) issue and, at this point, our greatest foe.
I am in a unique position in that I am sponsoring a second-year team, but this is my first year with FIRST. I was able to attend the IRI in 2005, so I have a taste of what a FIRST competition is. However, as a teacher new to the school system and new to the programs, my knowledge of robotics is rather limited, so I try to apply common sense as a problem solver as I can. I know that I have learned ten times more from the students as they have from me. But the one thing I do believe I understand is the FIRST philosophy - gracious professionalism, co-opetition, celebrations of group successes and failures ("failures are a great thing, especially when they happen early" - Andy Baker), etc.
Before the school year started, I sat down with the returning team members and asked what they wanted out of this year. Their #1 concern was that the 2005 robot was completely student-designed and student-built, and they'd like that to continue. We as mentors are exactly that - the proverbial "guide to the side" rather than "sage on the stage". We must understand that FIRST is about recognizing innovations in science and technology from the youth. We've had our glory days, now it's our opportunity to pass on the values, virtues, and legacies on to the next generation of problem solvers. I think that some of the ego issues come about when individuals lose sight of the fact that FIRST teams are exactly that - teams. As I peruse CD forums, there are countless references to team 71 in 1999 or 230 in 2002 or 45 in 1776. I have yet to come across anything that said "remember that one blonde kid from 234 in 2000 and how great his design was?"
The purpose of FIRST is not to win awards or championships or become a hall-of-fame team. These are fringe benefits to a strong work ethic, positive attitude, and fun environment. Life's a journey, not a destination.
I want to add that I am cognizant of the fact that I am a newcomer to FIRST, that I undoubtedly do not and cannot see all that FIRST is, was, should be or will become, and in the grand scheme, my opinion is negligible. But I do know that I have the charge of growing a young team into one that is respected, well-liked, and successful (and hopefully has working robots). By sharing my thoughts with the CD community, I hope to gain a greater knowledge of my role, of FIRST as an institution, and feedback and friendships from trusted and renowned authorities on the subjects at hand.