Quote:
|
Originally Posted by Cory
This thread could go on for ten pages and I guarentee the only thing that will be agreed on is "to each their own"
|
That’s exactly what I wanted to bring up. I pointed it out before, but I feel that I need to reemphasize it. Each team has it’s own priorities. The way your team is run depends on these priorities. If you’re not sure what your team is all about, I suggest sitting everyone down in a meeting and trying to figure it out.
Everyone is arguing and showing why what they think might be “better”, but few are seeing that everyone has different perspectives. There are merits to more or less mentor involement, but each team has to chose which they want to take advantage of. One team may feel that winning at the expense of not giving students as much hands on experience is worth it. Another may feel that it doesn’t even matter if they make it to competition as long as the students got to do everything.
Quote:
|
Originally Posted by Sanddrag
But the mentors already know everything. The point is not always to get the robot done fastest, it is for you students to learn something.
|
Quote:
|
Originally Posted by GeorgeTheEng
Personally, I sometimes find mentors are too limited in thier decisions. Engineers tend to stick with "well, we know how to do this so we'll keep doing it this way". Students, esp when they come and go tend to bring creativity and different approaches that us old curmudgeon sometime lack.
|
I’ve found that inexperienced people are the most creative. They don’t have the background that they need to get the job done, so they have to make it up as they go along. If someone tells you how to crack open a walnut, you’ll keep using what they teach you. If you figure it out on your own, you may have a new, better method. If you want your students to learn and be creative, you might have to let them flop around and make mistakes. While throwing knowledge at newbies might be more efficient, it hinders creativity.
You could also see this the other way around. Fostering creativity might not be as important as completing the project in the allotted 6 weeks. They can still learn after everything is finished. Learning through observation has it merits. FIRST allows students to see how real world engineering works. If they don’t learn that much about the technical details right now, they’ll be going to college anyway.
Quote:
|
Originally Posted by Alexander McGee
I think that the real problem here is everyone's definition of "performance". So what if the robot doesn't match up to the other ones? So what if there is something that was designed/built/engineered better than yours? Does this not inspire our students? Does it not make them want to do better the next year?
|
Just because a robot doesn’t perform that great doesn’t mean that people won’t learn or won’t be inspired. Our 2004 drivetrain was horrible (my apologies to Scott). In 2005, we analyzed it and figured out all the problems with it and fixed them in the new design. There were simple solutions to each problem individually, but it was decided that the drivetrain would be completely overhauled instead. Various ideas were borrowed from other teams (mostly the higher ranked ones). It worked better than we intended. A few parents pointed out that the evolution from the 2004 to the 2005 drivetrain was incredible. There are only a few minor issues with it that need to be worked out. Had the 2004 drivetrain worked reasonably well, it may have been decided to just tweak it. We would not have looked to other teams, and would not have learned some new techniques that were used in building/designing the new drivetrain.
Of course, some might feel that consistent “failure” would discourage people. Why would they keep coming back if they know they are going to fail? As the 2004 drivetrain started to show its wear and tear in its poor performance, a lot of team members started to get discouraged. I couldn’t believe how many people were just moping around despite the fact that we still had a decent chance. If these failures happen at inopportune times, people might start leaving.
Quote:
|
Originally Posted by Adrienne E.
A reoccurring debate on our team has always been, if there are no high school students interested in doing a task (wiring, programming, chairmans, animation, or anything on the team) then what?
|
On 1351, if nobody wants to do it, it doesn’t get done. We’ve had to abandon a few projects because nobody wanted to do them. The people (students) that were qualified to do it were busy with other things and nobody else wanted to learn. It seems harsh, but it’s all about teamwork. Someone always steps up to take care of mission critical projects even if they don’t like it, because they know it needs to be done. Life isn’t always fair; if you want to help the team succeed, you might have to do something you don’t really want to.
However, by setting students up like this, they may shy away from engineering. If they have bad experiences about it before they go to college and get stuck with whatever degree they spent the last 4 years on, they might do something else. By doing the “dirty work” for them, they’ll be able to have the full experience because the team is able to advance. Instead of seeing the bad side of engineering, they’ll see the good side and hopefully stick with it.
Quote:
|
Originally Posted by Steve W
A proper balance of mentors, engineers and students is one were they are all learning from each other, all being inspired and most important, that they are all having fun.
|
Quote:
|
Originally Posted by techtiger1
The robots without mentors would be boring and the kids would have no one to look up to and no one to guide them in building it. I know that on 1251 without our engineering and various other mentors we would not be able to make our robots and things we deisgn a reality.
|
Quote:
|
Originally Posted by Philip W.
Just because a robot is 100% student-built, doesn't mean mentors and engineers still can't help. We must remember that mentors should only be teaching. If mentors keep to teaching students the design process and how to use a machine and etc., and ensure the students are productive...
|
It seems that most people are sitting here. This is the safe spot. You get the best of both worlds. However, as I’ve been trying to point out, you don’t get to reap the full benefits of either extreme. If your team thinks that you need to be 100% student run, you get all the benefits that come with it. The same goes for a 100% mentor run team. If your team thinks that they can live in the middle, then so be it.
Just remember that you have to chose what is in your team’s best interests. If you haven’t done so aleady, get your team together and discuss what you want to get out of FIRST. Doing so will be good for more than just deciding on mentors, but also how you want to run your team in general. If your team has a direction and purpose, I think that you’ll be more successful. Success of course being defined however you want. Now go! Call everyone and set up a meeting.
Quote:
|
Originally Posted by mechanicalbrain
Also this thread will stay alive longer if we don't directly refer to others post.
|
Oops, sorry. But I think I needed to in order to prove my point.