What do your programmers do when programming has finished?

Hello, programmer from Team 2408, the Shrapnel Sergeants here to ask you guys a question. What do you guys (programmers specifically) do when your job has been completed? What can we do in the community or at meetings to keep our robotics related activity high? Any suggestion is appreciated, thanks.

I always have my programming team learn something new. Maybe a new sensors that can help in future yrs.

Programmers are always busy :wink:

What is this “finished” of which you speak? :wink:

There are a lot of things to do even if your robot is out of the competition (and it appears you’ve qualified for Championships, so there’s also anything you need to tweak for that).

If you aren’t using a proper revision control system, this would be a good time to start.

Learn how to use new sensors (ultrasonics, encoders, vision, infrared, something else).

Develop niftier autonomous modes.

Improve your ability with more advanced programming techniques. (Look for papers in CDMedia by Chris Hibner for some good examples.)

Code an electronic scouting system.

Write an app to use in outreach.

Write an app to download information from the FMS twitter feed and do something useful (or just interesting) with it.

Develop an electronic inventory system for your team’s workshop that you can use to keep track of when you’re out of a part and automate your bill of materials for next year. (Possibly a bit of a stretch.)

Learn a little more about electrical or mechanical (as applicable). This can prove useful when you need to figure out how to control a mechanism they’re making.

Use your imagination. There’s an infinite amount of work available if you just look for something.

Seek and destroy bugs in your code again. There’s always at least one, sometimes buried very deep.

Failing that, come up with new automodes.

Convince the mechanicals and electricals to learn how to use a diagnostic screen (which you’ve coded) so that you can prove that it’s NOT a code problem even more easily.

Enjoy the time you have until someone comes and says the inevitable phrase “Hey Joel, is it possible to…”

We just usually help out with the web team or make html games to put on our website :smiley:


I am the lead programmer of my team, however nobody works on JUST programming, or JUST electrical, or JUST mechanical. especially because in order to troubleshoot my software, i end up troubleshooting electrical a lot too.

we are all well-rounded individuals.

For the past two years we (1912) have competed in the Zero Robotics SPHERES tournament. It’s programmed in C with virtual satellites. As an offseason event, SPHERES is a great experience, especially in training younger students. This was actually my first exposure to programming in general.
here is a link to their website:

It might also be useful to invest some time into learning other coding languages, too… there are always opportunities to help other teams at tournaments. Also, it comes in handy if your alliance members use other languages and are making changes to their code in order to make a specific strategy work.

We had a pretty small group of people who actually showed up on a regular basis, so when I wasn’t programming I was probably helping out the mechanical folks. When I wasn’t needed there I’d be working out bugs or just improving the code as much as I could.

We have been working our programmers to DEATH improving our Auto routines. If you’re “done” then I assume you have a number of reliable auto routines that you can pick from to coordinate with your alliance partners as well?
I would HOPE so. :stuck_out_tongue:

Or maybe something to where the drivers can change certain values for autonomous on the dashboard right before the match based on your alliance partner’s preferences.
Especially useful if a programmer is on your driver team.

That’s a great list. I planning on working on a lot of them hopefully during the off season for both my “old” team (3928) and my new team (2167). Also, there is always work to be done on building and maintaining team’s web presences.

I finished my program week 5 of build season. It was functional and did it’s job. My mentor always says “great, now here’s more things to do” and hands me a list. Today I woke up with a text message from my mentor saying “I’ve emailed you things you need to have done for Terra Houte” There are at least 5 things he’s given me to do. Long story short, one can always improve code, make it cleaner, run faster. A programmers job is never done, unless, of course, it is the “dead zone.” That is the week before competition and inorder to change the code on the robot, 2 students and a mentor must be aware of what is being changed.

Me too, but none of us are even named Joel. It’s weird.

What is “finished”? Can’t make your shooting more accurate? Automate more actions? Drivetrain perfect? Totally optimized? Totally documented? Commented and simple to change? Never have any issues/bugs? Are you using every second on that autonomous period? Does your drive team have any other ideas? Is there more training you can do, of your own programmers or in helping other teams? Any old or off-season bots you can work on bettering? Any new controls you’re interested in (this is a major hobby or our team)?

There’s always more to do! There are ancillary activities you can do as well, but all our sub-teams find it valuable to continue looking for ways to improve our current season goals/performance (unless training gaps are dire). I guarantee you’ll be blown away with some of what they come up with–as long as they save the old code versions!

Yah, there’s no such thing as done. Either look through the code and see how you can improve it (keeping the original as a backup, of course) or learn something new! Like TheSoftwareGuy said, knowing how the electronics works is a big help for a programmer. But if you’re sure you are done, minesweeper is a great way to kill time. :wink:

You are never done programming, and that’s what makes it fun.

Develop better sensor feedback and debug output.

This is engineering. Nothing is ever done. It might be “good enough”, it might be at a state where “I think this’ll work”, but it’s never done! Even in the off season, we’re making changes and reprogramming things.

Heck, just last week we sat down and did a code review (the programming team presented the code to the main programming mentor, myself, and the programming teacher at the school, who is taking the year off from the team). During the review, we changed a few things that needed changing, discovered the cause (and the fix) of the only real issue we had noticed in the robot’s performance, and created a list of stuff that should be done for the code. And this is after having a very successful regional up in Duluth a few weeks ago (placing 4th)!