I’m breaking this into two answers each, one we use in FRC and one we use at work.
- How does your team effectively delegate the work between programmers? Do you have several programmers work on separate parts and then put them together or do you have everyone work on the same program?
FRC - we try to break it into logical groupings (usually by component) and then divide our team into groups that then pair program on the problem with the support of one mentor. We are fortunate to not only have a rather large programming team (looking at 12 students) but also having a fair number of mentors who, while not all terribly familiar with FRC are engineers.
Work - We tend to write user stories and then assign each story a developer. Where parts need to talk to each other we simply tell the developers that they must talk that out. We are also a highly distributed facility, last year I worked as part of a team that was spread out across most of the east coast as well as with another team with half the members in Colorado.
- How do you plan the code before you start programming (flowcharts, etc.)?
FRC - Simple planning meeting wherein we discuss what the robot needs to be able to do and write the user stories.
Work - Actually, identical process just replace robot with whatever project we’re working.
- What kinds of benchmarks do you use to keep the programming team on task throughout build season?
FRC - Every meeting the student sub groups need to answer “what did you do, what are you going to do, and what are your blockers?”
Work - Similar process, we also tend to use tools such as Jira and Pivotal Tracker to track who is doing what.
- What backup techniques does your team use to manage files effectively (cloud, etc.)?
FRC - SVN but we are in the process of switching to git.
Work - SVN/Git/HG and our in house servers for each of them. Each project has the choice to use whichever they want. I do not suggest this approach at all for companies. It works here for a couple reasons that are fairly unique to us. 1) we work in a huge variety of languages and problem spaces. 2) projects are prototypes with life spans measured in months to a year NOT in decades.
- Other tips, tricks, or suggestions?
I’m a fairly big fan of taking sticky notes on the walls with tasks. Three columns; To Do, Doing, Done. When someone takes ownership of a task (they start it) you move it from To Do into Doing and write their name on it. They are responsible for that task. When they move it to Done they can grab another task. The benefits of this, each developer knows what they are supposed to be doing. Each one can instantly see what other’s are working on. Each knows how much work is left. And they won’t come to you with “ok, what do I do next”… well, they might, but now you have a convenient board to point them to. Obviously you can prioritize or color code this board as you see fit.
Build code as building blocks and test the crap out of your blocks.
Modularize where logical but don’t over think it. Following great OOP principles is admirable but complexity is the enemy of reliability. It’s better to have code that is logical, readable and clean.
Comment stuff. Heck, keep a wiki somewhere that has testing procedures for each sub system. When you go to competition make a checklist based off this wiki so you can perform the tests each time you make a code change. Make a second checklist that can be performed as a preflight check. Make sure these lists catch your edge cases (limits or motion for example).
Sleep on problems. When I spin my wheels at work on a problem for more than an hour if I’m not making progress I switch to something else and don’t come back to it until the next day. Some days just aren’t good days and I leave work early. Sometimes I just take a walk around outside or read a book for 15 minutes. Point is, staring at a problem won’t make a good solution jump out at you.
Mountain Dew and Cheetos are NOT a valid dinner. If you insist on eating them constantly you better wash your hands because if everything ends up with a fine coating of Cheeto dust someone is going to be cleaning every surface with a toothbrush and it won’t be me… (mentors, I suggest you keep a handful of old toothbrushes handy for ‘cleaning detail’).