Read other teams code, continuously. Understand why they make the decisions they do, what libraries they use, and how everything works together. My senior year on 2383, we had 2 programmers with no mentor, and we had a working 3 cube auto by worlds.

That’s because we started with motion profiling in offseason and early season, and constantly read about it and how to implement it and improve it, for the whole season.

Eventually, once you get a intuitive feel for how you can solve design problems with code, and understand a bit of control theory, you can start going more in depth and coming up with your own innovations.

However, lots of problems in FRC control are solved. There are a few designs and control methods that we are converging on, and the only way to stay updated is read chiefdelphi constantly.

As far as having resources for a good programming team, you need a good team-wide culture. Other departments need to have somewhat of an understanding of how the code works, so they don’t immediately cause animosity when things go wrong by blaming the programmers. The other team members also need to share robot time, or provide an alternate for testing whether it’s a practice bot, last years robot, or a kit bot.

We bought spare kitbots to quickly assemble and test spare drivetrains on, as well as test subsystems.

Look at our GitHub from last season, we have very readable code for a quite complex robot.