Let me know if any of the following doesn’t make sense. I kind of just ramble and I’m bad at grammar.
I’d like to challenge what the student says about my first point.
To expand on my first point, our team employs heavy amounts of lecture training/machining practice/self-study in the off-season, hybrid prototyping where mentors work with the students, and leave them to make THEIR robot. We’ll assist when necessary of course. (Usually answering questions, holding something, and slow/ repetitive tasks that just need more hands as we historically are a ~10 person team.) This is where we define our team’s line for where our students are at. This line does move occasionally slightly based on time constraints.
In my experience, just having the student watching or just letting them figure it out is rarely the correct thing to do. I’ve found that just letting the student figure it out is very discouraging and they disengage immediately. Often times they don’t come back.
For example, imagine I told a brand new student who has gone through our training to “build me an elevator that achieves the following criteria” and “figure it out”. I guarantee that most students won’t have any progress after a few days. This isn’t because our training was bad. It’s simply too large of a step between having seen it and having them figure it out in its entirety. In this case, I would have failed to set them up for success.
Keep in mind that different people learn in different ways with varying amounts of motivation and grit. We as mentors should be willing to be proactive in finding out who needs help and investing time into each student as best we can with a mix of showing them what to do and giving specific challenges for them to figure out for furthering their knowledge.
It looks like they agree with the rest of my points. So I’ll stop there.
Now onto troubleshooting.
This generally starts during the testing of the robot. As failures appear, they get added to a list of situations to prepare for at a competition, but jerry-rigging implies it’s at a critical moment with not enough time so sometimes we do it for them. Mostly if it’s easy, the mentors will just tell them their options and together we execute. Other than that, the best we can do as a team is reflect and explain what we did so they are prepared for it next time.
Usually, when testing and there is a problem, we’ll have the kids tell us what they think is wrong first. This lets them practice these situations without the time pressure. As one can expect, no one is perfect so their first tries are usually wrong and we usually guide them through glaring issues that the mentors know are clearly wrong and easy to solve and teach.
If and when we the mentors are unsure what’s wrong, we take the time to troubleshoot with the students. For example, here are some common things on our list. (Not a programming mentor so I don’t really know what they do.)
Electrical
Single motor controller/motor issue → phoenix tuner/connect to spark
Power issues → wiggle every connector, hot glue, test cables
CAN issues → case by case kind of really depends on if it’s all red or else it’s really clear which part of the CAN is unhappy
Mechanical
Loose chain → zip tie tensioner/floating sprocket
The spare hex to line up bearings and parts for fast installs
The art of duct tape, electrical tape, and hot glue.
We actually practice and plan for certain parts of the robot for easy swaps.
And every robot has its own issues. For example, this year our team probably wasted 30 bucks on connectors in between every in-season competition for our CAN bus because many of them were crimped wrong or it just failed or our climber ripped it out. Clearly, the students now know exactly when we have a CAN and what to do about it because they did it almost every 10 minutes for about 15 days of meeting time. I did have to step in and make something that solved the climber issue to SHOW them as they weren’t sure of what to do even after providing examples and assistance. And yeah, I’m not proud of this 15-day response time, but both the mentors and the students learned a very important lesson those days. 
So 2 tactics,
- Walk them through an easy correction.
- Troubleshoot with them and learn together.
And a small note about communication.
In our training, I say one thing “If you’re not talking to someone or asking for help, you’ve already done it wrong”. We encourage the student to ask any questions and collaborate. However, like above the prerequisite is that they at least have a hypothesis of what’s not right or what they think could solve the problem.
Will add more later, class is kind of important to pay attention to. 