What do your programmer's do (besides the robot)

[Alex Webber]

Our team, 1810 has been very grateful to have had 10 programmers last year, with only one senior. We will have at least 13 programmers if the 2016 season started today.

As most teams have figured out, you don't need everyone working on the robot. Our team normally has 3-4 programmers working on the robot. What do the other ones do?

For Recycle Rush, we worked on our scouting program, this was a big project, and we got it working just in time for regionals. We were just woundering if any teams had any summer ideas, or build season ideas to program that are not the robot.

It would be nice if you could also tell me how many programmers your team has when you reply as well, to help give us a better idea of what would work and such.

Thanks, Alex

[xNovax]

I was the only student on the team that did programming this past season. Other than working on the robot code I worked on updating our scouting program. The program can be found here: Github

[GeeTwo]

As you have enough to do this, make certain that at least some of the programmers are embedded in the design team for every subsystem. This improves the chances that each subsystem can actually be programmed and has the necessary feedback sensors designed in rather than tacked on.

[jtrv]

Things we've started introducing lately:
(We had 4 programmers, 1 was in his first year of FRC but had a lot of experience in other programming areas, and 1 programming mentor who is a student from a local college)

-Look for ways to improve code layout / design / structure from year to year. Look at great things and awful things in each year's code and how things have progressed. Ways to improve and increase clarity is very important in a team as large as yours.
-The newest programmer overhauled the website and re-designed it from scratch (I believe he used some basic UI frameworks, but regardless, still a big project).
-Wiring (electrical & pneumatic)
-Helping with scouting. We haven't made our own electronic scouting program, and I'm not sure if we will in the near future. What I did do was create a program that simulated day 2 qualifications based on day 1 performances and day 2 schedules. Since our scouting team meets after day 1 and also right before alliance selection, having a good idea of what standings might look like on the day 1 meeting is a good idea. It obviously isn't perfect, but it gives insight on which teams could be in the top 8.
-Lots of work on control system development.
-We also procrastinate a lot.

[GeeTwo]

Originally Posted by jtrv

Things we've started introducing lately:
.. procrastinate a lot.

You might want to put off procrastination until next year.

[DonRotolo]

What do our programmers* do?
Bother the cat, mostly.


*No apostrophe, it is not possessive.

[GeeTwo]

Originally Posted by DonRotolo

What do our programmers* do?
Bother the cat, mostly.


*No apostrophe, it is not possessive.

Or perhaps it's the last word that's misspelled.

Our programmer's Dew keeps him (or her) awake to do more programming.

[Ichlieberoboter]

I was the head programmer on my team and also a chairmans presenter and I did some electrical. This isn't the best example cause we had a really small team but chairmans can always use help from my experience.

[MaGiC_PiKaChU]

we did the robot reveal video, and I also did electronics.

[hardcopi]

Ours come up with more and more disturbing plans to take over the world. We try to keep them busy.

Another good thing is documentation. We lost most of our programmers this year, but thanks to documentation (and the fact that they are teaching weekly classes to newbies until they leave for College) we are going to be ok.

FInd some reusable bits of code for them to improve upon. A favorite of our team is the joystick conditioning code.

[FlamingSpork]

Originally Posted by hardcopi

Ours come up with more and more disturbing plans to take over the world.

Always fun to plot, but when you actually try, you get a segmentation fault.

I'm working on coding a field management system for Maize Craze, and I so far have learned that any line of code can cause a segfault.

My team has also been working on learning how to make our code a tangled mess based on this: https://www.thc.org/root/phun/unmaintain.html

[GeeTwo]

This year we're requiring all of our programmers (and all of our controls people, and all of our mechanical people) to take a job on the business side of the house as well. "Business" includes just about everything that doesn't relate to the robot build, including Chairman's submission, outreach, web/social media, fund raising, scouting/match strategy (though not build strategy), spirit, safety, and probably a few more things I can't think of right now. The concept is to have separate meetings for "business" vs "technical". During the "off season", there should be a business vs technical breakdown approaching 1:1. During build season, this will probably be more like 5:1, or perhaps even worse.