Quote:
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.
Quote:
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.