I’m entering the sort of mid-level mentor stage, after five years of experience. I am no longer completely new to the subject, but I’ve been around long enough to have learned a couple of things. So, here’s my perspective on the subject.
I gave up on trying to teach programming to kids that have zero programming experience. If they don’t know what a variable is, or a method/procedure/subroutine, I tell them they need to take some sort of class from somewhere else before they can be part of the programming team. That may seem a bit harsh, but my experience is that I just don’t have the time to devote to the very basic tasks. Whether or not your team can afford to do introductory programming instruction will depend on your specific circumstances. How many mentors? How much time? During what part of the season, etc?
So, for kids who at least know the basics, I start with exercises that have immediate impact, a sort of “hello Robot”, approach. I walk them through setting up a robot project using the FRC libraries, and then explain that the good folks at WPI have created libraries for the most common objects that we will use. I start with motors. Write a program that tells a motor to turn on and off. We have a test bench that we created that has a variety of motors and sensors, wired up to a Roborio, so I have the students write a program that will turn on one of those motors and make it spin. If you don’t have such a bench, but you have last year’s robot rolling about, have them write and deploy a piece of code that will turn on the motors and go forward for one second.
After that, I add extra pieces, one at a time. Now spin the motor, or go forward, when the joystick is pressed. Now, read the encoders and stop when you get a certain distance.
If using a real robot, and your team has been around a while, your drive code might have some “fancy” stuff, like gyroscopic control for straight driving. Strip that stuff out, so that it’s down to the core driving feature when teaching new programmers.
Above all, all of that theory stuff about what makes “good code” is not something you start with for a new programmer, or even an experienced programmer who is new to FRC. Start with practical, hands on, immediate feedback exercises as much as possible. After 35 years of professional programming, that’s still the way I learn any new programming language, operating system, library, or whatever else I’m doing. Figure out the “hello world” program, and add to it. Once I get to the point where I’m confident I can use the tool, then and only then do I actually start thinking about design considerations. These kids won’t have that level of experience, so it will take them longer to get past the basics. (I don’t know how many times I’ve had to explain, patiently, the reason they are getting the null pointer exception. “There’s a difference between declaring an object, and actually creating an instance of the object.”)