I got inspired to write a post about this because of a post on Chief Delphi, and I think it is very important for all FRC students to understand why the idea of competency shouldn't be applied to FIRST Robotics.
The Journey vs. the Destination
I dislike the word incompetent. I also dislike the word competent. The main reason for these feelings is that competency is a destination. FIRST is a journey. I have never met someone who participated in FIRST or VEX who knew everything, student or mentor. In fact, I have never met a human who knew everything. What makes FIRST powerful is that everyone, regardless of where they started, can improve.
By assigning competency to success in FIRST, this idea of progress is removed. Competency is a binary concept, you either competent or not. It can be very easy to say "I am incompetent, so it is not worth trying to improve." On the other hand, it can be very easy to say "I am competent, so it is not worth trying to improve." Both of these mindsets are pitfalls that can very easily cause people to not improve. By placing success in FIRST not based on improvement but rather on competency, everyone constantly strives to make themselves better.
Stagnant Team Development
There are several points of view on this issue from my team, so I want to preface this section by saying that everything I write is from my own point of view, and does not represent the view of my team.
The competency mindset plays a huge risk to both individual students and teams as a whole. This is a story about why competency is a bad measurement, based off of the experience of my team. My team switched from LabVIEW to Java in 2008. That same year, we moved from Mercurial to Git version control. We figured out how Command Subsystem format worked, and we stuck with it. Our 2018 code looks fairly similar, with the main difference being using CAN Motor Controllers (but not actually using them for what they are designed for). 2018 was my freshman season on FIRST, and I as an "incompetent" freshman decided to not question why things had stayed the same. That year we had an unreliable, unsophisticated robot.
How did we end up with basically the same code? It is simple: our team thought we had become "competent" with knowledge after the 2008 migration. We didn't innovate because there was no reason to. This was our 23rd season as a team, we should've blown the competition out of the water from a software perspective, but instead we were somewhere between the one half and bottom one third of robots in terms of software at competition.
The off-season between 2018 and 2019, I saw a presentation from Austin Schuh from 971 at a competition in Davis, and even though I didn't understand the math behind what he was doing, I learned something even more important: they got where they are because they were never content with their robot code. I later saw this same trait in other world-class teams, such as 254.
My team fell into the pitfall of being content with our robot code and failing to innovate. In 2018, there was no closed-loop feedback on our robot, because in 2008 we did not have closed-loop feedback. In addition:
We didn't have a working autonomous because innovation wasn't worth the time.
We didn't have a PID-based elevator because innovation wasn't worth the time.
We didn't have a better debugger because innovation wasn't worth the time.
We didn't make full use of our Talon SRX because innovation wasn't worth the time.
We didn't innovate because innovation wasn't worth the time, so we were left behind.
Why wasn't innovation worth the time? It wasn't worth the time because we thought we were competent. I am not going to lie, before I saw 971, I truly thought we were competent. It was so easy to blame the success of 254, 971 and other teams that are within half an hour of our school because they had better mentors. We didn't think about the fact that most of their mentors lived or worked very close to us geographically. It was only after seeing that presentation that I realized the problem was that we thought we were competent.
2019 was one of the biggest year-over-year improvements for software in my team's history, and it was because we decided that innovation was worth the time, because we weren't competent. If there is one thing that I wish I could make sure never happened on my team for the rest of time, it is us feeling that we, as a team, are competent. We are not, and will not, ever be competent, since being competent doesn't exist. If we treat success like a destination, we will fall further behind and have to work harder to resume making our robot code better.
We need to treat it like a journey.
What Makes an Effective FIRST Student?
Now that my mini-rant about team competency is done, I will address the idea of competency as it pertains to students.
In my experience, people who are effective in FRC focus on continual improvement in the same way that students should.
Take Risks, Welcome Failure
When I walked into my first work session, I had no idea what I was doing. I thought I wanted to do IT, because I knew I liked computers, but I never thought I could be one of the people who programmed the big, scary robots. On the second day of Build Season, I thought I would try programming, and I quickly realized that I liked it. However, since I was very new to programming and very shy, I was afraid to take risks. This is part of why I didn't question how we did things on the team, because I was the rookie. I didn't know what I was doing. This fear was my biggest regret of freshman year. I ended up taking an overly-simple project for the start of the Build Season and ended up being miserable for the whole Build Season, because I was afraid to take risks.
For most of my life, I thought that failure of a project was a failure of myself, and that asking for questions was admitting failure. Changing this mindset was by far the most difficult thing for me on FRC, more than anything I have ever had to program, presentation I have had to give, or problem I have had to solve. As a result of this mindset, I rejected failure because I thought it would reflect poorly on me. If I had welcomed failure, asked mentors for help, and quickly reevaluated my plan, I would've gotten where I am now a lot faster. Most of the things that I learned on FRC came after I changed my mindset, because I couldn't learn with my previous mindset. So I encourage everyone, please take risks, ask for help, and welcome failure, and you will be miles better off than anyone who hasn't.
There are no failures, only lessons - John V-Neun
Ask Questions, Learn From Others
This goes with what the previous section was about. Asking questions and learning from others means that you can think about problems in new ways as well as learn from others. There is no such thing as a dumb question, and lots of information is freely available online.
Almost everything I have learned in FRC came from asking questions, learning from other people (such as off-site presentations), and hands-on work. In order to learn as much as you can, you should try to do all three.
A very good way to learn more is by asking on ChiefDelphi. The OP of the Chief Delphi thread that inspired this is a perfect example of how asking questions can lead to learning. My first post was not until my sophomore year, and I still feel very reluctant to post, so amazing job to OP on taking the initiative.
The other good option is to follow online resources. When I was in eighth grade, I started a VRC team at my middle school. Even though we had some adults with VRC experience, it still was very difficult and confusing to find information about how to do things in VRC. One local team had information about how to do a variety of tasks with VEX Robotics on their blog, which was the inspiration for my blog about FRC. I still refer to that blog constantly even in FRC, because the information is super helpful.
If you want resources, I have a list of some of my favorites below, which can help you find lots of information that you may need:
https://docs.wpilib.org (for some reason, this doesn't render as a card)
In addition, this blog has some tips from an FRC student that hopefully can help other students and teams, so I recommend you check out some of my posts.
Learning From Veterans
Learning from veterans can be a very valuable tool. It helps you quickly learn about the more advanced things that are going on. In my experience, most veterans, especially ones that play a leadership role, are more than happy to pair program with you. When you work with them, feel free to ask lots of questions.
The one warning that I have with this is that when there is a high-stress environment, it sometimes can be better to ask later. This usually takes place right before a deadline or when a problem does not have an easy resolution. If you think that now may not be a good time to ask questions, the best course of action is just to look at what is going on and occasionally ask if you can help. The veteran or another person will most likely be happy to explain the process later on and explain what the problem was. In my experience, most people in FRC love sharing what they did and teaching others, but robotics can also be very stressful at times, and it sometimes can be easier to work in a quiet environment.
If you want to learn more but it is not a good time, mentors can be an awesome resource to help you out. Mentors tend to be better about explaining what they are doing in stressful situations than students are, and at least on my team, usually are more available to explain what is going on.
The last thing that I want to address in this section is to remember what it was like being a rookie once you are a veteran. I often forget what it was like myself, but I think it works a lot better if you try to create a more positive environment for rookies. The idea of remembering what it was like to be a rookie is what drove our effort to rethink training. If you are a rookie now and you feel comfortable, talking to a veteran or mentor about the problems you are currently facing or experiencing can help make the experience better for you and other rookies.
Show Up, Show Enthusiasm
The last major tool to increase your STEM skills in FRC is to show up and be enthusiastic. Every FRC team needs more people who show up, and the people who show up and are excited about FIRST tend to be the best suited for personal growth and playing a bigger role on the team. It depends on the team, but on my team, we have sophomores who play a more important role than seniors because the sophomores show up and are exited to be at robotics.
It is also refreshing for us veterans to have people who are enthusiastic about robotics. So many people see robotics as an obligation or are forced to participate by their parents, so I am much more likely to want to teach someone who shows interest.
Competence as an Excuse
There are some people, like OP, who try to work hard to become competent, and have a genuine interest in improving their skills. Other people use incompetence as an excuse. Out of everyone that I have met as part of FRC, I respect the rookies that challenge themselves, even if it isn't successful, the most and I get very frustrated when a very capable student (especially those who are involved with team leadership) don't do a basic task because "they are incompetent." If someone assigns you a task, especially if you are not a rookie, saying that you are incompetent can cause you to be seen as lazy.
This excuse is part of why I hate the word competence.
If you want to be successful, challenge yourself.
If you want to be successful, ask questions.
If you want to be successful, take every opportunity you can to learn.
If you want to be successful, don't use incompetence as an excuse.
The better option would be to say you would love to, and then ask a mentor or another student for help. I can tell that OP falls into the first category, and I know that myself, along with almost everyone else in FRC, want more people in FRC who try to challenge themselves rather than make excuses.
My greatest regret in FRC was not being more open to asking questions and accepting failure. If there is anything that any student can do to excel in FIRST to ask questions and accept failure. One of the first steps is asking questions on Chief Delphi. I didn't even make an account until my second year of FRC. I don't believe in competency as a concept, but by continually working to improve yourself, you will get more out of FRC than many other students.
Looking for Presentations?
One of the most valuable learning tools in FRC is going to presentations by other teams. While frequency varies by region, you should try to attend presentations to learn from better teams how to be better.
These presentations are also available online, but I have found it much more interesting and education to attend in person, so you should try to attend an in person one if possible. One of the best decisions that I made in FRC was getting a group of people to drive four hours to go to the presentations from Citrus Circuits because it completely changed how we did code, even though we weren't attending the competition they are at.
If you are in Northern California, I recommend these events:
- WRRF Workshops (Santa Clara)
- Spartan Series (Mountain View)
- Capitol City Classic (Sacramento/Davis area)
In addition, there are many presentations at the FIRST Championships in both Houston and Detroit, which are well worth the time if your team qualifies for Champs.
Most of these workshops share their videos online, so even if you are not in Northern California, you can take a look online.