Don't assume that many older teams have more programming expertise than the rookies. This will be a struggle for the whole FIRST community. However, we have some things to help us here.
1. A common platform spec, to make generic code independent of the robot.
http://spreadsheets.google.com/ccc?key=0AgYDudKXpgOzcFI5aW5EUVhnVVUxNUVuQTdZLWNIW Xc&hl=en
2. Canned moves, as you were saying. They can be stringed in a sequence with the error terminals. An alternative is wiring an enum array into a for loop, where a case structure executes the correct move (determined by the value of the enum).
3. Simple GUI interfaces: LabVIEW. Next year we will have LabVIEW 2009, with the addition of some nice features like
snippets.
4. Collaboration, communication, sharing of resources. I do LabVIEW and control system workshops in my area. I try to collaborate with people to make sure the community progresses as a whole.
The point is to start programmers out from a very high-level view in autonomous: I want the robot to do this, then this, then this, then this. If sonar value is less than 20in, then turn right. Otherwise, keep following the line. And so on.
Of everything on the robot, programming is the hardest to explain, and so it needs the biggest push. We're not coding machine language anymore. A well-documented VI can be understood by normal people, so long as they know that data flows along the wires, and a subVI won't execute until it gets data from all its wired inputs. Block diagrams are a pretty clear way of thinking.
I understand your concern. It's a little scary to think of 6 150lb robots moving around a field without direct human control, especially with little testing.
FIRST sometimes challenges us in ways that we think are unnecessary, and there are some challenges we'd like in FIRST that aren't yet present. One of the major selling points of this control system is that it makes it more feasible to do a comprehensive autonomous. Autonomous is underrepresented in FRC; in FLL, it's virtually all autonomous, and FTC gets 30s of autonomous per match. I believe the reason FIRST hasn't made autonomous a larger portion of the match is not that they think we're not capable, but that they want to draw in spectators, and make the game interesting. They're struggling to balance between popularity and technical prowess.
I certainly won't stop them from encouraging new teams, but I'm going to push for technical proficiency in all FIRST teams.
The biggest one is how to solve a problem. It's a process. You must single out the problem, clearly define a solution, and test that solution.
Similarly, with code, you must define what you want to accomplish and how you are going to accomplish it before you try to code the whole thing. Take a look at my Software Development Process.
sircedric4, I do think one of the problems you're running into is people not understanding the fun, importantness, or awesomeness of programming. Often it can be hard to convey, because people assume it's simply geeky. People have streams of thought, and so do robots. If they can describe each decision the robot will make, then that's half the programming. It's like giving someone a set of instructions, but that person only knows what it's been told, and what it is told by the sensors you put on the robot.