[apalrd]

Coming from another programmer:

1. I was technically a lead programmer this year. Because I was the only programmer. Last year there were three. We spent so much time trying to synchronize copies and versions that we got almost nothing done, and the lead mentor (who works as a programmer) wrote all of the code in competition, some of it between matches. This was the first year in a very, very long time (ever?) the Killer Bees had a student programming leader, something I am very proud of. It was helpful to our team, since our coach could go out and watch matches instead of write code. Writing all of the code does not necessarily mean you hog the code. If you are a good programmer, your code is readable, and are dedicated to the team, it is possible to do all or most of the coding. It might actually be easier to do it this way, then you don't have to deal with versioning and who has the latest copy of what file and interfaces and whatnot.

1b. We do not run for any positions on the bees. All of the sub-teams are led by mentors, and we (students) choose a sub team to work with. The drivers are selected by the mentors as a whole, based on dedication and other factors. Anyone in the pit crew, comp team, and Chairmans team can be considered a leader, as they are the highest in their field and were selected for higher responsibility positions.

2. Teaching is hard. I know. I taught programming to FLL students once. In their NXT-G language, which is quite hard to use BTW. If you can teach concepts instead of syntax, it is much easier. In LabVIEW especially, you can generally find the block you need, so you don't have to explain what each block does or what calls it contains, you know. You can focus on thinking like a programmer, designing the code, and how the algorithm works, then talk about language specifics.

2b. When someone makes a mistake, help them solve it. Many new programmers create lots of IF statements, usually many more then necessary. You can teach them that there is a different way. Example: Last year we had a 4-wheel independent steer. The first time we drove it, it had two pairs of two pods, each with a steering motor and pot. We, the programmers, decided the best way was to have several cases based on how far the pods were to each side, and set the motors accordingly. Jim, lead mentor/programmer, taught us about P and PID control. We looked at it, and couldn't figure out how it would work. Then it did. And we realized that there was a better way to do it then having a whole bunch of case statements. So, instead of just freaking out, help them and make sure they don't ever do it again.

3. About the junior vs senior thing. We don't consider based on junior/senior, we consider leadership positions based on experience, and a little bit more to upperclassmen (not freshmen especially). If "he" is a better leader, whether or not he is a better programmer, he should get the position (likewise for you).

4. Original question: What makes a good leader?
a. ability to get things done. Very important in robotics.
b. good to work with. Important when working with a team.
c. dedicated to team. Comes to as many meetings as possible, does whatever he/she can to help team.

5. Spaghetti code is not good.
5a. In LabVIEW, we have a magic button "Create SubVI" which takes selected code and sends it into a subVI, equivalent to a function. Awesome little button. We also have a magic button "clean up diagram". It re-arranges everything to be neat and tidy. Also an awesome little button. (We've also got Clean Up Wire, cool icons for our SubVI's, and threading)
5b. You get none of this in C++, but sending things into functions when possible and partitioning code into seperate modules and classes helps A LOT. Best of all, if you partitioned things correctly, then the "teleop" call will just pass input data to the rest of your code. In Autonomous, you can call the same functions you called in teleop and it will do the same thing. Especially helpful with your PID controllers and other complex modules.