Why don't more kids program?

I’ve never had any formal training in programming, but I’m pretty good as getting sample code, modifying it and making it do what I want. In practice, it generally means using google a lot and ending up living on stack overflow for a few days.

For VEX IQ, we still use robotC Graphical. One of my middle school IQ teams scored a 22 at WORLDS with their programming, which was tied for 6th if you’re just looking at programming scores. If you take the time to read though all the commands and make sure your kids can use them, then they can do almost everything they want to do.

In my camp last week, I had some students paired together that went to worlds but hadn’t done programming as they weren’t the “programmer.” They will be in fifth grade next year. In a half hour they had written a program that would score 40 points in Squared Away. I helped them through the first couple of iterations and they had a couple of questions as they went along, but they were pretty comfortable with it after going through it a couple of times, and I don’t think they would need much help at all if the program got erased and they had to redo it. (If only the USB port were more reliable…)

I’ve done a little with VCS, but using the sample programs it makes it pretty easy to figure out what you want to do. Use the templates, plug in what you need, give it a whirl. It can be insanely tedious, but it’s not that hard.

So I’m curious, why don’t more kids code their bot???


The job of programmer already sounds pretty daunting, so it will be natural for some kids to not want to try programming.


Just curious - what about the job of programmer sounds pretty daunting?

I only had 1 kid out of 5 on my team last year who wanted to program at the start of the season, but managed to convince 2 more during the season.

1 Like

Also to add to the stress of having the name of programmer, on some teams a lot of pressure can be put on you to make a robot work even if it is a mechanical issue. A lot of guys expect programming to be like magic and poof its done and fully functioning but in reality it takes time to program a bot to perfection.


I also don’t understand this. For a basic VRC V5 robot you just need (in addition to the comp. Template) 4 lines to set up the drive commands, a few callback functions for different tasks, and a few if statements to control lifts and stuff. It would be optional to add some touchscreen controls, but those aren’t needed. I think it’s mostly the autonomous part that scares people. It’s really just a matter of visualizing what you want the robot to do, tell the wheels to drive and turn how you think they should, then just test it on a feild to make the numbers accurate.


I think a lot of kids just don’t care for it. There are plenty of programs designed to expose students to programming.


Talking from my experience and some friends, when you first look at starting programming it seems really complicated and some people just don’t want to put in the effort. Also sometimes kids will start and then get frustrated and quit because they just have no clue where to start.


I agree that autonomous definitely seems daunting. If you don’t have tasks set up, you could have a fifty line auton that does four things. I think this makes people kind of scared.

Also, last year, we had a problem with our wheels in that one side would go faster than the other. For a while, I, the programmer, was blamed for it, even though it was a mechanical issue. This also puts a lot of pressure on kids.

I think the amount of timing it takes to get things perfect can be what makes kids not want to dive into it. I went through about 60-70 versions of my auton before I got it to the point I was happy with it. The sheer amount of time it takes can also be frightening.

Finally, there is always the terrible possibility of something going very wrong. In ITZ, I was up until 4:00 AM at Worlds reprogramming everything because somebody managed to corrupt the files for RobotC. It is much less likely for the robot to explode than the files to be erased or similarly messed up.

Those are just my experiences as a student programming.


A big part about why a lot of people don’t want to program is the time and research involved going into more advanced programming such as instead of using timing you use the circumference of the wheel and degrees to tell distance and other more complex tasks like pid’s which take days of tuning and troubleshooting which i can definitely see why coding is scary to people who haven’t done it before.


honestly the reason there aren’t as many autons as there should be is that tinkering with parts is a lot more fun for most people then typing lines of code.


Programming is often dependent on proper build, which can be very time-consuming, which is frustrating for young students.

Keeping the build simple can help. For example, simple tutorial code which shows the use of a single sensor has often been effective in getting the kids I work with interested in moving further. But then, if there aren’t “intermediate” instructions that bridge to the next step, students don’t move forward.

For example, you could show a student a program where pushing a bumper sensor turns off a motor. Some students would mentally make the jump to, “I could build a robot that drives into the wall and stops when it hits the wall,” but some wouldn’t, and would need explicit directions to do so.

The highly talented students get a lot of attention. They’re the type who would say, “I built the Clawbot using instructions, and now I can build a 4-bar lift looking at a CAD rendering or photo, and I can modify someone’s PID code and make it keep my lift from sagging.” Not everyone has that level of talent, and with coding, it’s especially difficult, because often the code of bots in videos is unavailble for perusal. Past a certain level of difficulty, students give up.

I often teach arithmetic to (junior) college students, and I’ve been tasked with the job of getting a significant number of students who can’t manipulate fractions, decimals, and percents to mastering college-level math, like statistics or even Calculus. The only way to do this is by leading with 1000 small steps, with many tasks of gradually increasing difficulty.

If there were a 100 projects with step-by-step build instructions and accompanying worked-out code, that could be quite effective. I started a project like this over 10 years ago, but updates software/hardware quickly render tutorials like these obsolete. If the project doesn’t work exactly as the tutorial states, or if the kit doesn’t contain all the parts in the tutorial, the student gets frustrated and gives up. Even my college engineering club almost gave up on this Arduino tutorial because the menus on the software we had downloaded didn’t match the tutorial (we went back and downloaded the ancient version, which matched the instructions).

Intermediate steps are key to learning for students of intermediate (rather than stellar) ability.


< soapbox >

But trying to understand the basics will make it much less daunting…

And if your builders understood programming this would have never been an issue. They would have understood that the command is exactly the same for both motors. In fact, that is typically the default position with going forward. The best way to dispel magic is to understand how it’s done!

Yes, but why not show them in a way that is actually interesting in a format they already enjoy. Using SCRATCH to move the cat is… OK… But having the robot actually respond is much more exciting.

I agree… Better teaching is necessary…

I don’t want to sound too insensitive, but what an amazing learning experience that was for you. You probably got more real world skills out that that than the rest of your team. I’d hire you over them.

Using circumference… Why? That’s not advanced programming, that’s making something a bit more complicated than it needs to be. You open up the motor on the V5, move the bot forward, then look at the number of rotations. It’s… easy…

With the built in PID, while it isn’t as good as tuning it yourself, it’s still pretty darn good and will suffice 95% of the time.

Typing??? Ctrl+C and Ctrl+V… That’s all I do. :slight_smile:

I agree 100%… However a good coder will be a better builder as they will have in mind where they are going to go with the bot after it is completed. By keeping coding in mind throughout the process the bot will be easier to code and will preform better.

< /soapbox >


This also, to me, begs the question of “why do teams separate the roles of ‘builder’ and ‘programmer’ (and even ‘driver’)?” The hardware and software need to work together and the driver should be able to understand (and influence) both.

It seems like many teams view programming as some sort of magik - black voodoo that causes significant problems or some elixir that overcomes physical flaws. As we all know, there is no magic, just time spent understanding something.

In Turning Point, I was dismayed when observing at our first competition that more than half the teams didn’t even program a simple auton that would “drive straight” and toggle the bottom flag or push over a cap. One could imagine a basic auton this year that would simply score the preloaded cube in the scoring zone.


I wholeheartedly agree. Our first year (I’m a coach/mentor), we did not have autonomous. I think it seemed like something really challenging. Once we learned how to do it, it wasn’t nearly as hard or as scary as we thought! One piece of advice I give new teams is to have a goal of at least MOVING in autonomous. In most games, there are ways to score a minimal amount that are not complicated at all. And lots of times, that can win autonomous.


As I reread your post more carefully, a couple things popped out:

You’re a capable “troubleshooter” and self-learner. Not all coaches/students have that ability.

In this scenario, you had a decent amount of time to spend with what sounds like a relatively small group of students. You have time to listen to and answer questions.

A good number of situations involve a coach/teacher who doesn’t have one or both of those things: 1) ability and 2) time. Some at-home teams are coached by a parent who not only doesn’t know how to program, but also no ability of how to troubleshoot or solve a technical problem. I get lots of calls from friends who say, “My computer is broke, can you fix it?” I ask, “What is it doing or not doing properly?” and they can’t tell me. They can’t google the solution because they can’t describe it. And they’re coaching robotics teams. Another scenario is the classroom with 35 students, 1 teacher, and a 45 minute class period. Try to work on-on-one in that situation, and it’s a disaster.

So short summary of my long, roundabout answer is, “More kids don’t program, because there aren’t more teachers who are capable or have the right environment to properly teach them.”


That is truly unfortunate - but, no doubt true. However, there are things that I can’t do as a coach (for example, I can’t CAD - tried to teach myself but it just tied my brain into knots). I did have two graduating students on my team that did have the ability. I had them teach a couple of the younger kids. As mentors and coaches, we don’t need to know everything. We just need to learn to leverage the collective capability on our teams. I’ll argue that having one person do everything for all teams is not leveraging that capability. Plus, as the saying goes - you learn more when you teach - and that goes for the kids, too. Your crack programmers can teach some other team members.


I second this.

One of the big things myself and a friend of mine attribute our success in mentoring to is being able to leverage the capabilities of skills of others, as well as even reach out to other people who know more than us.

I explain to the parents of my kids and people who ask me all the time how I do it (even though I’ve been doing this for over a decade), that most of it is just knowing how to use my resources.

I mean yeah I’ve got the background and building and programming, but I also know that I’ve gotta reach out to the people who know more than sometimes. I also try and make it a point to be a source for coaches, parents, and mentors to reach out to me for help as well, because I’ve seen those coaches with no support system with their teams.


I’m actually amazed at how well the students can teach each other. Since they are closer in age, they speak the same language and are really effective in communicating. Sometimes as a much older coach, the connection is not there - especially since I’m not an educator. I probably tend to hover a little too much and “do” more than “teach.”


In my experience as a coach/mentor I think there are several things that contribute to it. These are in no particular order:

The first issue is, only 1 student can type at a time. So they are writing the code and anyone else interested in programming is just watching. It can be split up, but it’s still one typing and one watching. Without a SMART board or some way to get the laptop screen up on a wall, having all the students on the team watching is a recipe for distraction, goofing off, etc.

I have no professional experience in writing code, but it feels like each programmer has a “style” similar to writing prose. Having multiple styles in one program seems confusing.

Despite my frequent explanations to the contrary, the students seem to universally believe that they HAVE to have the robot assembled before they can start programming. I’ve explained to the programmers over and over, no, you can tell the builders where to plug in each motor, but it seems to fall on deaf ears. This then results in a time crunch to get the programming done.

Our organization is run as a club, there is not classroom/lesson time, so all the learning is hands on. Learning programming that way is frustrating, I think, because when it doesn’t work it’s not easy to see why.

Having only one robot. Either programmers are testing or drivers are practicing driving. Both can’t happen at the same time. This again puts a lot of focus/pressure on the programmer.

The iterative nature of write/test/analyze/repeat is not appealing to many students, especially when, as I said above, the nature of what’s going wrong is difficult to identify.


One of the first things I’ve done is create coding “style” guidelines so that everyone writes code in the same manner. Easier to debug, fewer errors, easier for everyone to get involved and follow along. Easy enough to implement, and it doesnt take an exorbitant amount of technical know-how.

I do this professionally, and we reduce a lot of issues this way. It also encourages communication and collaboration among your teams.

Now that we have options like PROS, VEXCode, RMS with RMBuild, live sharing and editing options such as VSCode Live share and Atom’s Teletype are available for students now, to foster even more working together.

VEX as a platform drives home the nature of iteration. If that write/test/analyze/repeat isn’t appealing for programming, it’s not going to be much more appealing for a physical robot when they have to diagnose issues.