Your Team Sucks At Programming: Here's Why

Hi my name is Kim and I’ve been addicted to FRC for four years. Ultimately though, I’m a programmer (not a good one mind you), but I have some decent hot takes on why most teams are bad at programming.

(This post is in the style of @Katie_UPS’ post on scouting. Thanks Katie for the inspiration, and y’all should give it a read if you haven’t yet.)

  • You didn’t choose the right language.
    • C++ isn’t faster if you use it wrong.
    • LabVIEW isn’t automatically easier than the other two main languages because it’s graphical.
    • Your school probably has CompSci courses, try and use what they’re teaching to cut down on the amount of teaching students have to do. (Hint: it’s probably Java.)
    • Your team might have mentors who know a given language. That’s fine and dandy but that doesn’t mean they have time or the ecosystem knowledge to execute as well as students.
    • Python / Kotlin / C# / Ruby / etc. is a lovely language but that doesn’t mean going with an unsupported one is the right choice for your team. You should weigh the benefits and drawbacks very carefully.
  • You don’t know what you need.
    • Didn’t install the right vendor libraries to take advantage of motor controllers. (Don’t just drive Talon SRXes and Spark Maxes over PWM please…)
    • Didn’t use your sensors to the fullest of their potential. Learn about PIDF and control theory.
    • You shouldn’t be downloading The FRC Update Suite week 4. You should install it ASAP and keep it updated.
    • Keep your libraries and device firmware updated and check for updates! The FRC Update Suite upgrade was mandatory in 2019 after-bag but there will frequently be updates that make you do better (seen a lot with the NEOs this year.)
  • You tried to reinvent the wheel.
    • Shuffleboard and other dashboards are available, use them. Very few teams have a real need to write their own from the ground up.
    • Nobody is gonna use your hip new framework unless it adds something meaningful, so steal from the best (not just 254, sorry guys.)
  • You didn’t start early enough.
    • Programming isn’t a “wow I learned it super quick let’s go” thing, it’s bettered by practice. Coding a robot in the last half hour of build season isn’t great…
      • Additionally it hurts your drive team’s practice time but that’s another rant.
  • You didn’t do your research.
  • You lost your code and had no backup.
    • Try looking into version control systems.
    • This can be as complex as just doing a git push every meeting or as simple as saving a ZIP in more than one place.
    • Seriously, keep track of your code and where you put it.
  • Your code is unmaintainable and makes it really hard to debug.
    • Make meaningful comments from the get-go.
    • Try to not have thousand-line monstrosities, you should break that code up into manageable, maintainable pieces.
  • You didn’t see it as a means to an end.
    • What is the goal of programming for your team?
    • Has your team met those goals?
    • Does your teams programming efforts contribute to your goal?
    • What choices can be made in programming to better achieve those goals?

“But but but, 254 uses this structure we have to too!”

No you don’t. 254 structures their code the way they want to, that’s not how you should structure your code implicitly. Use a layout that makes sense for your team.

“So we should have no framework for our code and just shove it all into”

ABSOLUTELY NOT! It’s okay to have a less-rigid structure for your code but you should probably have some structure aiding in your ability to compete, maintain, and clean up code.

“We can’t start coding until we have a robot in hand though!”

Nope, you absolutely can. In fact, quite a few teams keep old robot chassis around to start testing drive code and prototype mechanisms as soon as possible. Probably a good idea if you can do so.

In short: Make smart decisions and remember that code on the robot is a means to an end - to help you do better on the field. Anything else is training and shouldn’t happen in the meat of the season. Be smart, crafty, and clever, but not on team time when it makes your code unmaintainable. Now that the summer is quickly approaching, it’s time for your team to do things right this time. The chance is in your hands.

Don’t let your season end prematurely of preventable mistakes.


I like the thought you put into this: the title looks like clickbait (which it is), but when you read what you assume is a post meant to herald the strength of a team’s programming subgroup, you realize that it’s actually a thinly-veiled guide/checklist to making the most out of the resources available to you from an FRC mentor with years of experience. Pretty neat. I especially like the point about not starting to learn/review programming early enough, something that’s often generalized to the team as a whole, and managing time and not procrastinating and definitely not building a bot until bag day (well, not anymore), leaving no time for testing (also mentioned). Your post is a great set of guidelines for teams that are looking to improve their bot.

  • I wish our school had programming courses, though more probably do. We are not up to speed
  • All these people in the know suggest unsupported languages. I know they mean best but it is confusing for people just learning.
  • Examples are either really simple or PhD level. The best way to learn is to see lots of code that is both pressing limits but understandable. Finding examples that are at your own level can be a challenge. Of course is it nice seeing the upper level code but if you can’t understand it well enough to use it then it doesn’t always prove useful.
  • Programmers could use a more active community, not just for answering questions but with coding events. Getting especially new students into the community is helpful to their development.

Screensteps has lots of information, but also frustrates me greatly.


Hopefully the FRC Docs project will remove some of the frustration. It’s currently maintained by WPILib, so I assume it’ll be the official source for this information at some point.

Edit: Oops, didn’t see that you were already linked to it. I’ll leave this up for other people, though.


I second this. I’m not a programmer, but we built a wooden board with a bunch of talons, motors, a PDP, a RoboRio, and a bunch of things we could include on a robot. The programmers use this for writing the code even before the chassis is done, and then once we have a functional robot, they tune it to work with the actual bot. It’s really helpful, and it gives newer students a way to get familiar with the things on the robot


We used Python for 3 years. We had 2 excellent coders who had been using it since they were in middle school, so we went with it.

A parent who was a COBOL programmer by day tried to force them to use Java. They learned it, as well as C++, showed off their skills with some projects and then announced they were going back to Python.

Graduation left us without a single coder. LabView seemed like a logical place to start. A team was assembled but they didn’t seem to be going anywhere. Finally, in November of last fall they announced they wanted to learn Java and were adamant they could do it. I was nervous, but I went along with it, having few other options. They managed to learn Java within 2 months and one student is very proficient.

Sometimes, you gotta let your students do their thing. Just make sure they have a safety net to land on if something goes wrong.


This is an excellent idea, I think I’ll suggest it to our team!

And you can start design of the code while the mechanical design team is still doodling – as long as your team began with good strategy sessions and you know WHAT it is the robot is supposed to be able to do. If you stub out or at least document what the commands do before you know what the robot will look like, it’s easier to focus on the what than the how. It also makes the decisions about which sensor(s) to advocate for easier and better.

For projects about the size of a robot, I have often found it effective to design top-down even if the actual coding is done bottom-up.


There is a very active programming channel(s) on the FRC Discord server.


rip #programming


Seconding the FRC Discord. It kind of gets a bad reputation around here for what it was when it started, but it’s been very helpful for me over the past few years.


It’s great for our programmers. We have the wooden board mounted vertically and we put wheels on it so we can move it around our shop if need be

We actually had the problem that most of the code structure was finished before the parts were built. This led to lots of rushed tuning and not a lot of driver’s practice. And of course just because it works in theory doesn’t mean it works on the actually robot

1 Like

I read the title and was thinking “I know we’re bad don’t remind me please :(” But I was actually very surprised to see we do many of these things already. There hasn’t been a computer science class at my school historically, but they’re trying to add one and if they do I will likely take it. We’ve also been very good this year about starting early, keeping everything updated, and using source control so we don’t lose all our code. I like the lack of auto this year since it really gave us time to focus on the code itself and adding stuff like vision. Our code is by no means perfect, and probably undocumented and frankly kind of ugly (it’s written by high schoolers what do you expect lol) but we’ve been pretty proactive; having almost all the major subsystems coded before they were even assembled. Thank you for the insights though; there’s definitely a lot of things we can improve on- most specifically it being hard to debug.


If you’re already doing some of these things, then the road to doing more things more correctly is an easier one, and far more incremental. The post is deliberately clickbaity in title, like others have called out, but ultimately it’s a self-awareness check. You don’t know how bad you are until you see someone far better than you, and even knowing where to look for those people can be challenging sometimes. Those moments can be humbling and instructional (it’s happened to mre many times as a mentor, by students no less.)


7 posts were split to a new topic: RoboRIO as a computer

For people looking to get started programming this is one of the best tutorials I have seen so far.

I have started having some of my students work through it.

Thanks to team 3255 for putting it together.


And my programming mantra…
Why do something from scratch when it is likely someone better than you already created the code you need and has been gracious enough to share it with everyone!


I’ve worked with two different teams that did this. Both found that the programming platforms were very helpful in keeping the programmers moving forward without needing as much access to the actual robot. We used a 12 V laptop charger to power them. The programmers could stuff one of these setups in their backpack and do homework after the team meetings.

The software mentor at the second team bought some small, inexpensive DC panel meters and connected them to the output of the motor controller on the programming platform. It was able to indicate the polarity and magnitude of the motor controller’s output voltage, eliminating the need to install a motor.

1 Like