Advice- Too many Programmers?

[Lij2015]

I know this probably isn't what you want to hear, they'll leave on their own most likely if there really isn't anything to do if you keep them from disturbing stuff.

On another note, you can have the returners who know how to do it split off and do scouting and have a mentor teach the kids what to type(as far as robot code goes) while they alternate off or get more computers in the mix(if that's an option) and use it as training. If you don't have a mentor, you better get good at teaching them yourself!

I also want to counter the statement that you can never have too many, because in most cases unless you are a top caliber team that does everything they can and does tons of projects your programmers have a good bit of downtime.

[EricH]

Suggestion: Cross-train some of the programmers in electrical. That way, it's definitely the programming team's fault.


I'm on the mechanical side...

[Citrus Dad]

1) Build and expand your scouting system. We're still making ours better and it takes at least 3 programmers it not more. See our latest white paper here.

2) Build and run a webcast system. Teams are producing much better webcasts than FIRST is doing. We did 3 of them 2 years ago; we didn't get the opportunitiies this year. We do 2-3 offseason events as well, and FLL/FTC events can be webcasted. That can take 2-4 students.

[LCJ]

My suggestion is to run many more programming projects that are not necessarily for the robot.

Off the top of my head, the programmers on Team Appreciate work on the following:

Zero Robotics (3-8 people) - Robotics competition that involves programming a robot to compete in zero-g environments. This year's competition

Team Website (2-5 people) - Building a professional website is a lot of work and there should be dedicated programmers that work on this. Building a clean, presentable website (like 254 or 148's) is a very useful skill to have after high school.

Scouting System (3-8 people) - We have tried making scouting apps to run on Androids, Apple products, and off of a laptop. There's a lot of work that can go into building a really good scouting system for your team.

Programming Helpers (any number) - These students learn how to code in a language that the team doesn't use so that they can help out newer teams in competition with their autonomous/drive code.

Hope the suggestions help!

[Arhowk]

My team's on the complete opposite end of the spectrum- I'm the only programmer (and the head electrical for that matter) with no programming mentor, but I'm just so bad at teaching kids that they get confused and decide to go to mechanical

Firstly, I think that you should start ALL students in robot programming for a few main reasons:

• It's the easiest programming in most of FRC. Teaching kids robot programming can help filter those who have interest in programming against those who just want to be around a computer, but also doesn't shy off the kids who really want to be programmers but don't want to get thrown into hardcore javascript day 1.
• It's the only thing needed by every team. Scouting is nice, website is nice, but you're going nowhere without a robot. If you teach kids web development and robot seperately and the robot programmers turn out to be mechanically focused than you have to teach the other programmers robot programming.
• It's hard to get this kind of experience outside of FRC. Anyone with a computer can build a website but the best kids can do for programming is just buying some $20 arduino kit. Managing code for a $5000 robot on a team of 20+ people is a tough experience to get elsewhere outside of an actual job.

Once you've filtered and sharpened a nice group of programmers (yes, every kid will try to enter as a programmer, its not as fun as they think) you can divide it elsewhere as other posters have said.

As to not be too off topic, "too many" shouldn't even be in your vocabulary! Just be sure to utilize them properly, don't just throw them in a room and tell them to code.

[teku14]

Originally Posted by Jared Russell

Between the code that runs on your robot, your driver station/dashboard, your website, your scouting system, automating your pit checklist, off-line tools for generating autonomous mode scripts, off-line tools for visualizing logged data, etc. etc... "there is not enough to do" is never an excuse for bored programmers.

Amen

[JustinCAD]

I feel that you can never have too many students join a subgroup such as Programming. Having multiple students wanting to do a certain task can open up many opportunities that wasn't possible with fewer people.

One idea that you could try and adapt to is to kind of create subgroups out of Programming. For example, one subgroup of Programming could work on ways to implement Java, while others can work on LabView, working together to have them work hand in hand. (For the note: I am not in programming, so I would not know whether Java and Labview are able to work hand in hand).

This being said, Programmers will always have work to do. Find/fix bugs, implement new styles of code, etc.

I wish you luck!

[MamaSpoldi]

Originally Posted by AlexanderTheOK

one little issue I've always had in the back of my mind, and in the back because my team has always been on the low end (2-5) of robot programmers is that these are 7 NEW programmers.

Autonomous scripting? Well first you need to know how to make a solid system that uses state machines (and obviously sensors) properly. That does actually take experience to do. It takes time on an actual robot. Again, not too much of an issue for teams that have lots of functional robots, lots of time, and not lots of programmers, but it could easily be a problem for a programming team of 15.

Now, while I imagine that if half of your fifteen are going into web development and making your scouting system, you get down to a manageable 7, where enough time and accessible hardware make it possible for programmers to gain that experience, but robot programming really takes contiguous programming experience.

I can see it being done, but it is a challenge.

Agreed! It is important to create a small pool of knowledgeable and experienced programmers to write and maintain the robot code with guidance from a programming mentor (in the best of circumstances). You can definitely have too many programmers to facilitate this and having everyone pitch in is generally counter-productive. Consistency and commitment of a few programmers are both key to having solid, maintainable code. This is even true if you are using some form of source code control (eg. SourceForge or GitHub), which should be used regardless of how small the number of programmers (even if it is just 1).

The idea of facilitating other programming projects such as development and maintenance of website and scouting apps are excellent ones, but do rely on either having students who are independent, experienced, and knowledgeable or having additional programming mentors who can organize and guide that development operation. Keep in mind that sometimes these "side" projects can be guided by adults who may not be able to make the level of commitment that is desirable for those directly involved with the robot programming. For example, a website development mentor would not be needed at competitions but would be very helpful in the off-season.

Originally Posted by JustinCAD

I feel that you can never have too many students join a subgroup such as Programming. Having multiple students wanting to do a certain task can open up many opportunities that wasn't possible with fewer people.

One idea that you could try and adapt to is to kind of create subgroups out of Programming. For example, one subgroup of Programming could work on ways to implement Java, while others can work on LabView, working together to have them work hand in hand. (For the note: I am not in programming, so I would not know whether Java and Labview are able to work hand in hand).

This being said, Programmers will always have work to do. Find/fix bugs, implement new styles of code, etc.

I disagree with your assessment. You can have too many programmers depending on your other resources.

Unfortunately just having work to do is not enough to make students productive in the programming arena. For example, a student who does not know anything about the code being developed cannot "find/fix bugs". Appropriate levels of knowledge, experience, and/or instruction are really necessary to make headway on most, if not all, programming projects. Although some may be happy to struggle to work on projects without knowledgeable guidance and possibly without a team-related goal, I suspect it would seem to others like you are just creating "make-work", ie. making up tasks to fill their time. This can often be much more frustrating than suggesting they work on other tasks that are needed by the team but that may not be programming. Just like everyone cannot be the driver (at the same time), everyone cannot be a programmer (at the same time).

A team needs to use their resources wisely. My experience is that a student will derive much more satisfaction from doing something useful and helpful if it is suggested in a respectful way; this is the goal of teamwork (another amazing aspect of FIRST). It makes sense to take on some additional students into the programming team with the goal of training them, but putting everyone to "work" programming is not always the best goal for the student or for the team.

[apache8080]

Originally Posted by AlexanderTheOK

one little issue I've always had in the back of my mind, and in the back because my team has always been on the low end (2-5) of robot programmers is that these are 7 NEW programmers.

Autonomous scripting? Well first you need to know how to make a solid system that uses state machines (and obviously sensors) properly. That does actually take experience to do. It takes time on an actual robot. Again, not too much of an issue for teams that have lots of functional robots, lots of time, and not lots of programmers, but it could easily be a problem for a programming team of 15.

Now, while I imagine that if half of your fifteen are going into web development and making your scouting system, you get down to a manageable 7, where enough time and accessible hardware make it possible for programmers to gain that experience, but robot programming really takes contiguous programming experience.

I can see it being done, but it is a challenge.

I disagree that Autonomous scripting requires a solid underlying system like state machines because WPILib has a lot of built in things to basic autonomous modes. If you have a group of programmers who are good beginners it would be good practice for them to script autonomous modes with the pre-built WPILib systems. In addition, I agree with Jared that there are other tools that they can be working on that can help with the development process. Last year on our team we had a group of new programmers working on testing smart dashboard widgets for selecting autonomous modes, vision features, driver aides, and visualization tools. They were able to learn a lot about WPILib.

[seg9585]

Keep in mind that not everyone on the programming team will actually be *coding*. Some will be working on logic flow and concept of operation, control documentation, configuration management, and autonomous mode planning. Others will be working advanced efforts such as custom game piece detection and interaction, robot autonomy (in both auto and teleop modes), etc.

Others will work on scouting apps and database design, website programming, etc.

We have about 30 students who want to join programming this year (surely this will weed out over time). Only a handful actually ever write actual low-level robot code.

[GeeTwo]

Originally Posted by seg9585

Keep in mind that not everyone on the programming team will actually be *coding*. Some will be working on logic flow and concept of operation, control documentation, configuration management, and autonomous mode planning. Others will be working advanced efforts such as custom game piece detection and interaction, robot autonomy (in both auto and teleop modes), etc. Others will work on scouting apps and database design, website programming, etc.

Unfortunately, our experience is that very few of our students are ready to do high level tasks before they are ready to do coding. Do you have tasks/training that prepares team members for design and documentation before they are ready for programming? That would be a game changer for us.

[indieFan]

One more suggestion: Have your knowledgeable students mentor other teams in the area, as well as your own. Not all teams are lucky enough to have mentoring in programming.

[JesseK]

My $0.02 - Cyber Competitions (red vs blue, white/grey/black hat, etc).

We have 130-ish 'programmers' in our overall program. Had to find something for them to do since they're all interested in applied STEM, but a few weeks of from-scratch robot just isn't enough
I'm not involved with that aspect of our program, but here's a link: https://www.uscyberpatriot.org/
edit - just noticed registrations are close - so you could sign up and start practicing for the exhibition rounds that may start just after FRC season ends.

Originally Posted by Jared Russell

Between the code that runs on your robot, your driver station/dashboard, your website, your scouting system, automating your pit checklist, off-line tools for generating autonomous mode scripts, off-line tools for visualizing logged data, etc. etc... "there is not enough to do" is never an excuse for bored programmers.

This x1000.

[Wendy Holladay]

this is why i think FRC was wrong to remove the website and animation awards. that is programming, yes it is.

talk to some of your programmers about working on the team website.

or have some develop animations for your chairman's awards.

[mjcoss]

Like others have said, it's all about managing multiple subteams. A few kids on the main robot, some on the driverstation, others on web, IT infrastructure, pit management, scouting app, database, inventory system for team's parts, heck even an attendance system, a student tracking system (who has had what training, done what service projects, etc.). Lots of stuff to do some mission critical, others not so much.

Some kids are not going to make it in the programming group, and should be redirected to other aspects of the team. Some are going to be great, but need to be shown how to collaborate. Others need unlearn some self taught bad habits. This is where the mentors come in. Keeping everyone engaged is a challenge.

We've around 100 team members, and maybe a dozen students interested in programming. I've got lots to keep them busy, and a few other adult mentors that can help. Should be an interesting year.