Before I begin, I would just like to give some context as to who I am, and why I am posting this. I was the lead programmer for Team 694, and I’ll be graduating this year. I was really worried about how our team would fair after quarantine as not many students had programming experience, but I was pleasantly surprised when we managed to get a classroom of ~50 kids to all break up into groups and work on subsystems.
If you were to open our Conveyor Subsystem, or Climber Subsystem, you would get to see the author tags of everyone who helped collaborate on that one part of the robot. The level of collaboration that I saw was incredible. We ended up completing a 5 Ball Auton on our 4th day of testing, which not a single senior programmer/mentor even touched. We won 3 Innovation in Control Awards, which despite being a very niche award, became a source of pride within the software department.
But how was this possible, and how can you do the same? While it might be difficult to capture lightning in a bottle twice, I’ll try to list out a few things I found that helped us succeed, which hopefully you’ll find helpful as well.
- Prioritize Newbie Education
The hardest part about robot education is finding the right people. We had spent a lot of time creating a very inclusive curriculum for new members. We were not focused on finding the “smartest ones” or the “best programmers,” but just created an environment for people to stay after school, learn robot programming, or just do homework if they needed to. While many of them were not super involved, it created a low-stress environment that allowed those who were dedicated to really shine.
It’s the most difficult part, but if you manage to pull it off, you will reap the rewards of it very quickly.
- Lead Programmers, try not to write any robot code.
While this might seem counterintuitive if you are about to graduate or are a mentor, try to be as hands-off as possible when it comes to writing code. You will graduate, and your knowledge may not pass down as well as you think it will, so give your underclassmen a chance to show off. While it might make you pull your hair out trying to explain advanced concepts to underclassmen, just doing it for them robs them of a chance to learn.
- Organize, organize, and organize
Just because you shouldn’t be programming, does not mean you shouldn’t be involved in the process of programming. As the lead programmer, be critical of pull requests and encourage teammates to write the best code they possibly can. Organize code reviews. My team HATES code reviews, but I make them do it anyway because it catches everyone up to speed with what our robot can do, and it helps catch little errors we find.
Make sure you familiarize yourself with the subsystem/command programming model and make sure people stick to it. Life is easier for everyone when the entire robot is programmed in such a modular way. Even though I might have sent a PR back like 5 times in a row in order to fit some arbitrary “command-based model,” they thanked me later when our autons just fit together like lego bricks.
- Consider writing your own team library?
This one might be for the bigger teams, but my team had a lot of success with our own library called StuyLib. It was full of classes I had written in previous years and mainly helped us with things like, writing code that was gamepad independent, having all our constants on SmartDashboard in an easy way, ramp our driver inputs for smooth driving, read from the limelight, or just fun ways of processing sensor data. All these things were a lot of fun for me to write, but they helped make the lives of the underclassmen easier, so they could focus on programming the robot instead of writing wrapper java classes.
It also allowed some of our students to work on a side project without affecting our main code base. One of our students was really interested in writing an Interpolator Class that would let us shoot from anywhere. So he decided to write it in StuyLib, allowing him to then import it into the robot code and use it very easily.
WPILib does do a lot of things for you, and it always feels bad when they implement a feature you worked really hard on, but there are always other fun things to implement for your team. Just be sure to document and keep your code open-source, nobody likes private repos, especially in FIRST.
But as FIRST continues to grow, and computer science becomes more and more popular, the issue of how to collaborate effectively will become even more important. These tips are in no way complete, as they were just what popped into my head while writing, so if you have any more tips, be sure to drop them in this thread.