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.

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