Advice- Too many Programmers?

[axleAlex]

Hello CD,
I apoligize for the longer side of posts but it needs to be addressed to prevent drama amongst our team.

Our team has been around for 10 years now, and in the last two years has nearly doubled in size. We have appeared to be in a tough predicament, one involving too many programmers.

Let me start by mentioning that for Recycle Rush, we had nine programmers. Only one of them was a senior, taking us down to eight for this year. We enjoyed working on our scouting program, and more importantly our robot.

The issues arise now. We are presented with our largest incoming group, not all freshmen, even some sophomores and juniors. It appears that we might (no subteam desicions have been made yet), that we could have at least 7 new programmers, just shy of 1/3 of our incoming group. That could mean having 15 programmers.

Towards the end of last season, we ran out of things to do. This year could be a much more laid back year than previous as our scouting program is much closer to being done than expected.

We have had multiple ideas thrown out of how to address this situation:

1. Let everyone who wants to join programming join programming. This is what FIRST believes in, and what I believe in personally. When you start programming, you arent as good as you would be 3 months from now, (build season) and tryouts are for sports in my mind.
2. Have 'tryouts' of sorts to weed out the programmers, I strongly oppose as you should be able to pick out what you want to do, and we should not discriminate on the abilities of our new members.

This situation needs to be resolved, hopefully soon (we are supposed to start teaching programming) on October 8th. I do not want this situation to spiral into a 'select group' and as a result drama. FIRST is not for drama.

Any ideas? If you have any questions, feel free to PM me or reply below.
Thank you

[Sperkowsky]

Maybe you could give the programmers multiple jobs. Our team is very small so everyone is in multiple sub teams. There are always going to be those people who only want to program but I'm sure you can get some of them to help out in other areas.

[asid61]

Assign them to other jobs or research. Learning how to use new sensors or motion profiling, for example, takes up a lot of people.

[TogetherSword8]

What we started doing to give others programming experience was to duplicate projects, and form mini competitions. Those of you that are going to the Battle O' Baltimore may notice that 888 has registered two teams. Both teams have identical robots, the only difference is the people in charge of maintaining each one, and the programming. Each team has their own programmer, and each of them have their own ideas, that they developed independently with some guidance from myself (I have now graduated and am no longer with the team) and our mentors. After competition, the plan is for them to then come back together and discuss what went well and what did not.
With larger groups, if you have a lack of jobs, because of the openendedness of programming, I feel this system would be helpful, especially to give some prospective programmers ideas of alternate ways to perform the same task, which may also become useful in their later careers.

[DaRealSlimShady]

15 programmers is 15 too many.


#Mechanical4life

[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.

[AlexanderTheOK]

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.

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.

[Monochron]

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.

I think the important part of this advice that is often left out is that the real need here is for leaders to take on each of those tasks and help guide the other members through. Whether those leaders are adults or students can depend on mentor availability but you need people responsible for making those items happen.

Basically an important part of the solution to having too many students is to increase your number of leaders. Mentors, students, what have you.

[Ari423]

I would say it depends on the size of your team. If your team is 30 students, having 15 of them soley working on programming is excessive. Maybe you can impose a requirement to spend a certain number of hours working with another subteam before they can start programming. If your program is 60+ students I see no problem with having 15 programming students.

My team has also had this problem in the past few years. We are a team of about 15 total, and 5 of those students all wanted to program. This was clearly not the best use of their time for the team, so we asked those students to pick another subteam to assist before they were allowed to program. We lost one or two of the students, but in the end it was much more beneficial to the team to have the extra manpower building the robot.

[Greg McKaskle]

It is great to hear that lots of folks are interested in programming the robot. It is good that you are worried about this growth spurt since this is when things can change dramatically, for good or bad.

Since your programmingteam is less than doubling, I'd suggest the apprenticeship model. Let the programmers with most experience decide what they will work on, and each of them gets an apprentice to help/train. You may plan for a rotation opportunity at some point since they may find a better fit once they have a bit of runtime. You may also want to designate a technical lead to coordinate the activities of the team.

The more experienced guys will be asked to do something other than type/draw code. The new guys will learn how to code review and help someone else debug.

This is actually my favorite way to add programmers to a group at work, and it is beneficial to both parties.

Good luck.
Greg McKaskle

[marshall]

Find more mentors to help with organizing and running your programming students.

And before I get any "One does not simply find more mentors" memes... Ask the students in your group if any of their parents have a background in programming or IT or even organization/management. Get them involved. Ask your existing mentors to help with finding more mentors. Ask for help. Be open with your communication. Ask other students in the group to step up and lead development efforts.

Monochron hit the nail with his post. You need leaders to help spread out the opportunities you can make available to your new programmers. As Jared mentioned, there are a lot of cool things they can be doing.

[GeeTwo]

We have had about 5-9 programmers per year, but it seems that every year, one student does 75+% of the programming for the robot, and three do 99%. The other programmers never seem to "gel". My personal suspicion is related to time spent programming (whether learning, for other things, or on the robot) outside of regular build hours. Most individuals will never become an effective programmer if (s)he only puts in a few hours a week, a few months a year.

If this is clearly communicated up front, perhaps you will have fewer applicants, and among the ones you get will be the ones you need.

Originally Posted by aeastet

My plan for this up coming season is to break the programming group into a few groups. I will have a couple of teams that program the robot and a few that are working on the dashboard.

I'm not sure of our tasking/breakdown our first three years, but this is what we did last year; each person was lead on one or two sub-system, and they worked with a buddy or two to bounce ideas and help each other, plus mentors. At the end, our lead and deputy programmers (a senior and a junior) wound up doing most of the tasks assigned to everyone else. A third programmer, a freshman, got his stuff at least mostly done, but was busy as a driver by the time we were taking care of loose ends. The deputy and "third" have returned; the other programmers have not showed up to tryouts, so we will be taking another crop of new programmers. There have been at least two at tryouts who show promise.

Originally Posted by EmileH

I highly recommend [G]it[Hub] to help keep the organization of new and old code clean and organized.

+1 - It's a great "time machine" resource if you're coding by yourself. It (or something similar) is indispensable if you have two or more on your programming team.

[aeastet]

Our team this year is about 30. Of that I have 11 programmers. I am very excited to have a team with so many students that are interested in programming. I have been teaching programming classes all summer. I have the student broken into small groups and writing their own code. There are two to three students per computer. They are just now getting to the point where we will be putting their code on the robot and seeing what they learned all summer. They are excited and so am I.

My plan for this up coming season is to break the programming group into a few groups. I will have a couple of teams that program the robot and a few that are working on the dashboard. I will have them compete to see who can build the better code. The winning team will be in the pits for competitions. I hope to get better more engaged programmers, better programs, and more ideas this way. I am hoping that we can take the things that work the best from each team and make them into a super code of all of the ideas.

This is the first year I have had so many programmers so I will see how this model works.

[axleAlex]

Thank you everyone for your advice. To be clear, our team had 50 members last year. I will continue to develop a short presentation for our team next week before our new members start training and be a member of our team.

Thank you everyone!

[EmileH]

This year our team had 1 programmer, as in past years. My goal for this year is to get at least 2 new programmers to join, simply because I cannot put in the same time commitment this year as last year, for many reasons.

My suggestion (building on the other comments) would be to pair up the 7 new members with 7 of the more advanced/veteran students, and give each one of them a certain task.
The veteran partner would have the following responsibilities:
-Ensure their code is being implicated on the real robot (if applicable)
-train new member
-make contributions to the robot code
The new member would have these responsibilities:
-Learn how to program
-Make basic contributions to the robot code
-shadow the veteran member

For some tasks (dashboard, drive base code) two students is enough. For other tasks, like motion profiling or advanced PID control, multiple partner groups can be assigned to a task.

My question is: Do you use GitHub to collaborate between team members? If so, how are you using it? I highly recommend it to help keep the organization of new and old code clean and organized.

If not, I highly suggest you look into it. The quick version of it is that you have one master repository of the code that's currently on the robot. Then, each user has their own fork of the robot code. They make the changes in their forks, and when that user has tested their code on the robot, they simply make a "pull request" which basically asks the main repository organizer/programming lead to merge the forked code into the master. In most cases GitHub can take care of the merging for you (just hit the button) but in a select few cases you may need to manually add the requested code to the master (which is easy too).

HTH.