Our team has had trouble teaching over the years especially after switching to python. I’m wondering how other teams teach to improve our teams teaching without a software mentor(as we don’t have one) anything helps thanks.
3 Likes
There is definitely a steep learning curve for code, especially if you’re a beginner. It can be really hard to teach people if they aren’t committed. Learning the programming language can be done with plenty of resources and YouTube tutorials, but robot code is the challenging part. The best way I learnt this is just by getting a lot of experience with trial and error. And that’s one thing we plan to include for our following year: give the new students projects to do and try to get them to solve it on their own. Projects like purposely adding bugs in the code, and have the students try to figure out the solution. Our team has 2 programming mentors, but you guys could definitely do this on your own.
Another thing we are doingthis year, to help keep things organized, is creating a document with a step by step instructions for learning. Something like 1. Learn Python basics, 2. Learn OOP with Python, 3. Learn robot components, etc. This gives a clear way for you to keep track of what stage students are, and help students know what they could do to learn, if they wish to learn on their own.
1 Like
Genuinely wondering, why did you decide to switch to python? And did you switch from Java or another language?
2 Likes
This may be a bit long since I have a lot to say on the topic. But, the tldr is that Python is a much more well-suited language than Java for the nature of FRC.
Let me preface this by saying that I’m a big fan of Java, I think that it’s a really useful language once you get past its quirks and general verbosity. But, all that said, I’m pretty sure that Java was chosen as the de facto language for FRC solely because of AP CSA since it really doesn’t make sense to use it as a robotics language. The big draw of Java is the JVM and cross-platform compatibility, but that is useless when every frc program is run on the same platform, all the JVM really does in this case is add unnecessary bloat.
Furthermore, the explicitness, and often daunting syntax, of Java really doesn’t help it in this regard either. FRC is already a time crunch and team’s generally underestimate the amount of time needed to create a robot, so programming is even more of a time crunch. So having to explicitly type and lay out the privacy of every variable and excessively long import statements don’t really help out much with short development times and really only adds extra stress. As much flack as dynamic typing gets, it is still really useful when you are trying to write up a quick script before competition, and honestly just setting you’re type checker to strict fixes 99% of the issues with dynamic typing.
Comparing Python to Java. It’s just a way, way better language to develop time-constrained robotics programs in. It’s already commonly used on raspberry pi’s, so anyone with prior robotics-programming related experience will probably know a thing or two about the language. Also, since robotpy wraps around the C libraries, performance time really isn’t as big a deal as people make it out to be.
Package management and load times are also much better on python than java, even with base pip, and virtual environments and newer tools like uv make stuff so much more straightforward. Also the command-line repl prompt is amazing for ensuring parts of your code works while working on it allowing you to be even more efficient while scripting.
Also zooming out from just robots for a second. Python is also way more useful than Java for other stuff in FRC, especially scouting. There’s a reason why Python is the most popular language in data science. Having the ability to open up a Jupyter Notebook and immediately jump to data visualization with very little relative effort is amazing and having programmers who can do that and code a robot while only needing to know one language is even more so and makes the overall team much more flexible.
Again sorry if this was a bit long. I also want to reiterate that this isn’t an attack against Java, I think it’s an amazing and useful language, just not for the current environment of FRC.
And with that, thank you all for listening to my ted talk.
5 Likes
Our team also has no software mentors, and hasn’t for a good while. So here’s our approach:
Unfortunately there has to be that one person to do all the work like learn themselves with no help, then be expected to make a curriculum from the most common knowledge thing like creating private or public variables, all the way to how to integrate your finished code onto the electronics. Unfortunately that had to be me to do so. Because our programming team is so small I had no other choice but to make one since we can’t spend our time in season teaching the rookies.
Is a lesson/curriculum plan better than manual? Not in my opinion but that’s all we can do until programming gets bigger.
We use java, so unfortunately it would be no help if I gave you that curriculum. Wish you the best of luck though!
1 Like
While I do get what you are saying in regards to time-constraints on writing code, and how Python is better suited when you look at compile time and learning curve, I do need to bring up the point as to how much more supported Java is to Python. Not only are many vendor libraries not supported in Python, but even WPIlib is not fully integrated yet. In my mind this makes Java a much more valuable language in FRC, even with the pitfalls of compile time and the difficult learning curve.
1 Like
This year we tried to focus on the new programmers in our department much more than what we did in the past. I created a slide show that explains in detail the inner workings of Java, and creates a fun environment to learn the language. I also, as @Akshaj_K suggested, created something like a quiz/test, in order to help the new students learn through projects. However you teach, I would definitely recommend giving personal projects to each new student so that they can learn how to program, research, and troubleshoot.
3 Likes
I’ve got a quick question for this thread:
If you had to quantify the percentage of your time for teaching the core of the language (functions, conditionals, etc) instead of WPILib code (commands, subsystems, etc), what would that number look like (any have you found success with that strategy)?
If you spend a lot of time teaching the language, what robot-specific code do you spend less time on or omit altogether? Conversely, if you spend a lot of time focusing on WPILib and the more niche genre of hardware programming, what language features (if any) do you omit?
I imagine that this is very heavily dependent on the previous knowledge of students, so let’s say this question refers to brand-new programmers.
1 Like
Disagree. Our team has been trying to get vision systems to work for a while now, and we are switching from python to java this year because auto align will not work as well as we want it to because python is too slow. I agree with the rest of your post though, and python is better in many ways than java for frc. But for using complex vision systems and auto alignment, python simply cannot keep up.
Teaching code effectively, especially to have rookies write subsystem code within 3–4 months, can be a challenging task. I’ve found that the most successful approach relies on two key principles.
First, it’s essential to let the rookies face challenges independently, particularly when working in pairs or small groups. Allowing them to troubleshoot and solve problems on their own builds confidence and problem-solving skills.
Second, provide clear, specific goals, whether through structured projects or targeted reviews of learning materials. This creates a clear benchmark for progress and gives them a focused path toward mastery.
Personally, I learned from just observing the trained programmers and asking questions, but the biggest “jump” is by having experience don’t he robot.
2 Likes
Our off season time is low compared to other teams, so we highly recommend our new students to learn a language on their own. We try to use more of our time getting students hands on experience, rather than give them a lecture about a programming language, which could easily be learnt at a student’s own time. I in fact only knew the basics of Python and haven’t touched OOP at all, but just getting experience with the robot code was enough to essentially teach me all about it. The experience mixed with Google searches from time to time is where most of my language for Python comes from. Similarly, I learnt most of Java just by reading other people’s code.
2 Likes
sounds like this ship has sailed but … while Python is indeed slow in some ways, “too slow for vision” seems not true? are you trying to run everything on the RoboRio?
1 Like
That’s definitely a valid point. Not having access to stuff like advantage kit and other Java tools is a big drawback.
But looking back at our season. I don’t think there’s ever really been a point where that ever held us back competitively. On the contrary, I think the benefits that python brings helped us a lot this year (captaining an alliance at worlds isn’t too bad for our first year 
)
But as with everything in life. There’s pros and cons to each language and it’s really up to the individual team to determine which language is more valuable for them.
3 Likes
so inspiring
Arguably…we have JAVA in classes. We still have issues with getting coders. We have been sending students to Kettering every summer. Not practical…however…we have been doing it for a few years now. Still not ideal or financially feasible…or cost effective.
We use limelights, and vision does work, python’s just not fast enough for the more complex stuff we want to do, like full auto align. We used python with vision this year, it just wasn’t able to do as much as we wanted to do. Python is fine in general, there is just a point at which it starts to limit robot capability, so switching to Java can become necessary.
mmmm, I mean, you gotta make your own choices, but like I said, I think you may be misinformed about the causes of whatever performance issue you’re thinking of.
2 Likes
If your team can swing it, I’d encourage your veteran students to make an explicit goal to focus away from coding and more toward documenting, process setting, and training.
What you lose it technical capability from an experienced student doing chunks of work quickly, you gain in mentor value. What they lose in time to develop further technical skills, they more than gain in soft skills and good communication strategies. We try to emphasize a “mini-mentor” approach to our seniors, and the ones who really make an effort here really benefit long term.
A local team (SteelRidge) apparently ran a number of years (up til 2025) without a code mentor, with their students building the curriculum for training additional students. It was actually so good it inspired our team to do a full overhaul of our process to steal their ideas.
Talking with other local teams and borrowing what they do is absolutely a viable strategy, and one they’ll likely be happy to help with.
If it’s helpful, here’s our (relatively early stage) curriculum and documentation inspired by working with them.
https://stormbots.github.io/KnowledgeBase/
Our goal here is very much provide a pathway from knowing nothing to “coding X thing” without having to slog through unrelated concepts. The WPILib docs are awesome, but that’s the biggest pain point we’ve seen when our students are trying to self educate.
Building on that roadmap is the core we stole from Steelridge: Having a small list of action items to demonstrate a minimal level of mastery on each topic. The combination should give us a pretty flexible curriculum with clear documentation written for the knowledge level of a student, regardless of how they ended up there. And if they want something specific, they can work backward to get the prerequisites.
3 Likes
That’s interesting 
. We also used vision with limelights and were able to get auto align working. We just used PID to auto align, so what is your team using for “full” auto align that isn’t able to work with Python.
Thank you all for the ideas. I will definitely use this to help me. Also I probably should have noted though that I’m the only person on my team now that really knows software but all advice is very nice to have thx
2 Likes