Quote:
Originally Posted by Infinity2718
I would reword this a little bit, its more of a process. Instead of taking appropriate risks, engineering is about identifying risks and mitigating them. Once the criteria are defined, such as a strategy in FRC, ideas are created for solving them. Those ideas should have their risks identified and them gone through the engineering process to eliminate or reduce. If they can't be eliminated analytically, they need to be tested conservatively and eliminated that way. So from a technical standpoint, its not about taking risks, but more about identifying them (which is the hardest part) and reducing them. Without the initial engineering, many prototypes are setup for failure and go through the shotgun approach with hope of finding a solution. With time in FRC and available people, sometimes the analysis gets short changed, but people can be amazed at how much time can be saved with some basic physics calculations. I don't think any ideas are bad, but they must be sorted through to get to the best solution.
|
Emphasis mine. These two stood out to me. If I have a student that has some crazy, insane idea or otherwise has objections- I don't want to let that derail the team and our process, but I also don't want to tell them "no that's a dumb idea", because that doesn't help anyone either. I want to run through the analysis with them- let them
prove to themselves what the "right" answer is, and point to objective metrics of why thing A is being done.
Quote:
Originally Posted by marshall
A couple of years ago I had one particular student that I could not reach. He was very determined to do things his way after having come from another FRC team that was run very differently than ours and having participated in FRC from a very young age. He was determined to turn our team into his team and have everything his way... In the end, I let him take parts of the process into his own hands and it did not lead to success that year for us. It taught him a lesson that I don't think he would have learned had I put my foot down and said 'no' to him along the way.
To be clear, I'm not sure it was valuable for the entire team. I think it did more harm to the team than good to that one student. It has helped to make me a better mentor for seeing that though. Remember students, your mentors aren't perfect, we are human too.
|
I think lessons in humility can be taught in ways that impact the overall team less. Smaller exercises in failure rather than large ones. A failed prototype followed by an engineering analysis of that failure might do it, or an detailed analysis of the idea in question compared to other ones. I would hesitate as much as possible from letting other students down to teach one student, but that's a difficult call to make, especially with different personalities involved.
Quote:
Originally Posted by Clem1640
Failure can be a great and valuable learning experience, but this requires a few crucial mindsets and capabilities:
1) Introspection. You must firmly believe that your failure was due to factors (at least in significant part) under your control. Therefore, by doing something different, you might succeed. If you assign your failures to outside agents, then you really cannot productively learn from them.
2) Critical Analysis. Understanding the factors behind your failures, your shortfalls, your strengths, weaknesses, opportunities and threats. Understand how you might succeed and what changes you might make to your habits / processes to improve your prospects to succeed.
3) The will (and the physical/financial/temporal capability) to change what you do and the way you do it (your processes) in order to succeed.
4) The ability to inspire your team to make the necessary process changes that are needed for success.
|
This +1000