Contains our goals, curriculum design guidelines, and learning outcomes.
Contains our varsity letter requirements.
What non-software team members should know about the software team.
Contains the software team style guide.
Since 3512 was founded, the software team has enjoyed a certain level of autonomy. With that, we've been free to establish our own internal leadership structure. Rather than a typical top-down leadership structure, we operate more like a "software committee". Everyone is equal and contributes to the code base on their own volition with mentors performing quality control. There is a software lead who handles meetings and shields the members from administrative stuff, but the title doesn't imply any superiority or power over the other members.
This works best when everyone is equal in skill level, so the mentors work hard to promote learning among rookies to raise their level of competency to that of their peers. We encourage collaboration with the other students to aid in this process.
Pursuant to the goals listed here, the mentors teach rookies the basics of writing software and enough of the tools to make them productive contributors. The veterans already know how to write software, so the mentors can focus on actually teaching them software engineering. Ideally, the students contribute during the design process and are able to justify their design decisions.
The students learn the subject matter most efficiently with mentor guidance, so the mentors are fundamentally in a partnership with the students. While the students should do the work, the mentors should use their experience to inform the students of available tools and potential pitfalls so an informed design decision is made. In this sense, the mentors are primarily in an advisory role.
Furthermore, mentors should always provide an unbiased analysis. Transparency helps build trust, and specific solutions always have drawbacks. The mentor should be honest about them so the students develop a level-headed view of the world.
However, the mentors also possess the long-term vision for the team and should push the boundaries of the team's accomplishments each year to achieve it. To do this, the mentors may implement tricky bits of framework code, but the students should still understand what has been written and should be walked through it step-by-step if necessary. Remember that FIRST is a mentor-based program, but it is for the students; giving them a sense of accomplishment and ownership keeps them engaged and returning each year.
I like to take the "add tools to the toolbox" approach with my software team. We try some random alternative to improve on previous architecture, and a student or two takes that on as an R&D project. They usually stabilize and end up on the robot by the time competition occurs. We've done probably four different approaches to state machines at this point, and our controls solutions have evolved a lot. Prefer evolution over revolution.
My time as a student in FRC was basically one giant R&D experience for me. By always being on the cutting edge of 3512, I learned a lot along the way (successes and failures included). This exercise in independent learning made a big impact on my future, and I want to give students here the same opportunity.
Even in college, hands-on engineering projects like FRC are rare. I was on an FSAE team at UCSC. We didn't receive any support from the engineering department (and not for lack of trying) because they are more focused on research. Students should make the most of their FRC experience while they can.
I tell college students this often: "Don't let schooling interfere with your education.". Seek out projects that you're interested in and learn everything you can. It opens a lot of avenues for you later.