|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#31
|
||||
|
||||
|
Re: Getting Mentors out of Comfort zone
Oh, one other thing that helped a lot - get your mentors and student leads signed up on some kind of online collaboration tool. We used www.basecamp.com (which is free for teachers, and well worth the monthly rate for the rest of us). You would be surprised at the amount of organization & decision making that can be done outside of the meeting context when people are free to contribute on their own schedules.
|
|
#32
|
||||
|
||||
|
Re: Getting Mentors out of Comfort zone
One thing we've done in the past - having design discussions, strategy discussions, and prototyping as a group is awesome. It lets the mentors provide feedback based on their (hopefully) vast experience, and helps introduce newer students 539 more concepts. But in the end, a decision has to be made. If the mentors are dominating the decision making process, try getting them to step back. Get the team together after school before the mentors show up, make a bunch of decisions on what you want to build, and present it as a comprehensive design to the mentors. Show them you put in a lot of thought and that the team is United behind the design. And then ask them for help in achieving that design.
In my opinion, avoiding something just because the team has never done it before is silly. If there are other good reasons to avoid a particular design, then those reasons should be clearly listed for everyone to understand. |
|
#33
|
|||||||||||||
|
|||||||||||||
|
Re: Getting Mentors out of Comfort zone
They both found me, referred through other people. They were both actively seeking to mentor FIRST teams.
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
How did this work out? Were mentors actually willing to go to two different teams during build season? Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Thank you guys so much. My takeaways: More dedication from mentors
Finding new mentors:
|
|
#34
|
|||
|
|||
|
Re: Getting Mentors out of Comfort zone
Quote:
Quote:
|
|
#35
|
|||
|
|||
|
Re: Getting Mentors out of Comfort zone
So how was that experience? Since you were new, were you freaked out about mentoring a student? I've somewhat done this before, but I wonder if I need to be there with both the new mentor and the student to make the mentor feel comfortable.
|
|
#36
|
||||||
|
||||||
|
Re: Getting Mentors out of Comfort zone
Quote:
Quote:
Quote:
Quote:
Quote:
Things changed pretty quickly though. The excitement of competition, and the influence of a couple of *really* eager parents has given everyone a boost. They've been organizing meals for the team on their own lately, and it's awesome! The most important thing I can suggest is to keep parents in the loop about the team progress, and to treat them as team members. Host mandatory parent meetings. Send out a newsletter at least weekly. Get them signed up to Basecamp. Talk to the NEMO group for more ideas: http://www.firstnemo.org/ Quote:
Good luck! PM me if I can help further. |
|
#37
|
||||
|
||||
|
Re: Getting Mentors out of Comfort zone
I'm going to pull this thread back towards it's intended propose.
As a student from 2011-2014 on team 876; it was a real bummer when so many ideas of mine (and fellow teammates) got shot down, I always told myself that It would get better, as I got older that I would gain a higher degree of respect and recognition. While this was partially true, as in our mentor-centric team would actually hear my ideas out (and pay attention for that matter (2012 was a bad year)). My ideas never made it past the prototypes that I made. This was also true as far as programming went, every year- bare bones programming. Things eventually picked up in 2013-2014 as I stopped asking and just did. My point being that students really never had a large say in what the robot would end up being. We don't do CAD, we only have vague ideas on what the robot will be, it's mostly build on the fly. Our lead building mentor has yet to build us a bad robot, but things are mostly done his way (not entirely, but mostly). There are plenty of times I wanted to try swerve, mecanum or slide, but I got shot down because "that's not how we do things" or "there has never been a mecanum bot on Einstein". Now that I am a mentor I have caught myself exhibiting some of this "less desirable" behavior, don' t get me wrong, experience is good, but it is true that you learn more from failure than when you are handed success. I am now trying to port my projects over to students instead of trying to continue them myself (as much as I want to), and let them continue development of the ideas with my guiding input. When it gets down to it: The best way out of this, in my honest opinion, is for the students to approach said mentor(s) as a group, explain the situation, and offer ideas to fix the problem. The solution may just be as easy as bringing it out into the open. Past that, work on mechanism that you brought up during the build season and impalement them onto the bot after the season, or a programming method, etc. If it works better than the previous solution the mentor(s) may see that your reasoning was right in the first place and be more open to ideas. If it doesn't work better, you just learned what not to do in that situation, no harm done. I wish you luck, -Skye |
|
#38
|
|||
|
|||
|
Re: Getting Mentors out of Comfort zone
Quote:
I would say that if your new mentor is comfortable working with and communicating with teenagers, and humble enough to be able to say to a student "You know, I don't actually know the answer, let's find out together", then it should be fine. That's literally what we would do. We'd find stuff on wpilib or Google searches. Having experience with Java, I picked up on things a little quicker than he did and I was able to explain basic concepts as we went along. I don't think I was ever more than a step or two ahead of him but it was enough to get us both up to speed quickly. I count it as one of my "wins" that, on bag and tag day, at 11:30pm, we needed to test one last thing before we bagged the robot, and he was able to write the program we needed from scratch, under time pressure from everyone on the team. That was a proud moment for both of us! This setup also allowed the lead software mentor to focus his attention on several of the more experienced programmers, making his job easier too. A third mentor focused on other aspects of the code and worked directly with two students. I guess we essentially split the group so each mentor focused on 1-3 students for the entire time. I think this worked well. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|