So, Team 4334 is going through some shake-ups this year, and one thing I was wondering is how you guys set up your programming sub-team? How did you handle multiple people working together? Any tips are useful.
From our team documentation:
- Split the subteam into singles, pairs, or small groups to work on specific subsystem, command, and utility code. Ideally, individuals will stay with the same sections of the code base throughout development as much as possible. This is often a small subteam, but splitting into “groups” maximizes the amount of programming time each student has.
- Be flexible with assigning “groups” and tasks so that less experienced students continue to learn without being overwhelmed.
- Oversee and coordinate version management of the code base via Git, ensuring that all “groups” are able to access the latest code written by their team members
- Maintain integration within and between subteams when designing the code base:
[LIST]- Bring the full programming subteam together at the beginning and end of each subteam meeting to develop an overall design plan for the code base and ensure full subteam understanding of all parts of the code
- Coordinate with mechanical and electrical leads to remain up-to-date on the latest design plans, including taking field trips to the shop so that the entire subteam has a solid understanding of what they are programming
- Communicate with the rest of the team at wrap-up meetings to promote basic understanding of accomplishments and adherence to deadlines
[/LIST]
We program in command-based java, so…
With Git, of course! There’s always something from GitHub in the virtual Kit of Parts, but even a standard free account is enough for many teams.
The programming mentor and/or student lead will lay out and name the subsystems and commands, and a programmer (and possibly a helper/learner) will be assigned to each subsystem and usually its related commands. IIRC, each programmer has a separate branch (sometimes 2 or 3 if they’re working multiple pieces of code simultaneously) to do interim commits and unit testing before merging into master.
On 687, we have a pretty big programming team (16 people!) and we don’t even have freshmen yet.
We have 3 programming leads, and we’re running 4 projects right now. I’m working on path following, we have a team working on vision, a team working on state space control, and a pair working on code for our offseason robot. I’ve found that groups of 3 or 4 tend to work best with a robot, with people taking turns on the laptop. (Normally 1 lead + 2/3 others)
I try to explain the code we’re working with at the start of a meeting so everyone knows what we’re doing, and I sometimes stay hands off the laptop to involve the underclassmen more.
What is this organized programming of which you speak?
The best practice for your team depends on many, many factors.
- How many experienced programmers do you have?
- How many inexperienced programmers do you have?
- How many programming mentors do you have? What are their experience levels?
- What language are you using?
- What goals do you have for your programmers? Are you trying to be a control systems leader, or just get the minimum viable code onto the field?
- What is your student training system like?
- What outside exposure to programming do your kids have? (for example, AP Computer Science)
- What resources does your team provide? Where are students able to write code? Can everyone write code at meetings, or will some have to write code at home?
Can you provide more information for us?
I do not recommend blindly copying the structure of another team.
Thanks for clearing that up.
We currently have a pretty new team (experienced mentors, new team).
Last year, the team I’m currently working with decided to switch to LabVIEW and use the Command and Control architecture. This architecture allowed them to use standard Version Control Systems (Git in our case) to pull their changes together (because we wound up with a 1:1 mapping of programmers to subsystems, merging was a piece of cake as the only VI (LabVIEW’s closest equivalent to a function) they all touched was Teleop (note: as much as I like Git and LabVIEW, I think they need to get it together and make better support for each other . . . ).
I’ve worked with teams that split by subsystems, and with teams that had the main programming mentor and the two programmers basically buddy coding (the mentor doesn’t touch the computer in this case) the whole bot - personally, I feel like this gave a better opportunity for direct interactions and showing how to use standard architectures to make life a lot easier. I also realize that not all teams have a setup where they can dedicate a whole mentor (that knows both the programming language the team is using and the FRC architecture/libs well enough to be a guide) or if they do most teams will have more students than that involved.
I think pair programming is one of the best ways to teach a new programmer the basics and let them build up, once they get to the the technical level where you can say “we need a function/VI that does x” and they can do it on their own, shift to the next student (and or have them start buddy coding with a newer student).
You definitely need someone keeping an eye on the overall architecture (needs to be someone there all the time that can understand and/or problem solve when pitfalls are encountered).
By height.