Should a programmer be a driver too?

[FoleyEngineer]

What's your opinion about having your lead programmer also be a driver? We have someone who has driven in the past and has done well. However this year is our lead programmer. Can someone do both jobs well? If you've done this, how did it work out? Does the complexity of this year's control system affect that?

Thanks!

[GBIT]

Well if it is anything like having a lead mechtite as driver it should be no problem. for 2 years now i have been a major mechtite as well as lead driver... and i have found no issues with it....

[RyanN]

If they're good at driving, then let them drive, especially if he/she is up to driving and programming! In fact, I think it works out better having someone that has a lot of knowledge run the robot. They know the limits of the machine more than anyone else.

[Akash Rastogi]

This is actually one of the first years MORT has NOT had a lead programmer be a driver. In previous years the programmers in question performed their tasks perfectly and were still great drivers. One of the reasons is because the programmers spend the most time working with and testing the finished robot and drivetrains.

[Booksy]

I am a lead programmer/driver. I think it works great. I know the code. I know the low level stuff, what I can and can't do, and what I have to do to make something happen.

[Meredith Novak]

We have a new driver this year and he is one of the programmers. It is nice to have someone who understands the control system.

Our other operator is the business group leader...and that is a whole other question

[Nuttyman54]

190's operator in 2007 and 2008 was also the lead programmer, and he did an amazing job. It is often extremely useful to have someone on the drive team who knows the programming inside and out and can make quick assessments when the robot is not performing as expected.

[Kimmeh]

We're doing that this year. Our lead student programer is also our best driver. He's said it can be a little stressful at time, but it's worth it to be able to experience the code first hand and know exactly what it's doing on the field. It's much harder to have to explain the problem to someone else. Once he comes off the field, he's back in the pits fixing the code.

At our meeting tonight, he admitted that he changed the code between almost every match. And the robot did indeed drive better. =]

[hipsterjr]

I'm sure there are great, competent programmers out there, but I would never let our programmers touch the controls lol. They just don't have the understanding/feel the the mechanical limits of the machine the same way the mechanics who built it do.
*I hope Evin doesn't read this lol, and if he does, GET OFF Delphi and finish the auton!*

[Mike Betts]

I have to agree that I am very happy when a driver is chosen from our controls team. They come back from the arena with much more detailed information regarding the problem (example: LED status) and not just "it broke".

At the same time, when a student becomes a driver, they must move aside and let the other control team members pick up the baton. At the competitions, the drivers should be spending their time between matches discussing strategy, meeting with alliance partners and looking over the competition.

Many students have a hard time letting go. This is especially true if they are the "lead" in some key role such as programming. However, the other team members can and will pick up the slack and do a fine job if given the opportunity.

This is just another aspect of teamwork and individual maturity that FIRST forces on us.

JMHO.

Mike

[monty1540]

Our strategy has generally been to try and have people on the drive team that can easily understand what is going wrong if the robot starts malfunctioning. When something goes wrong on the field it's good to have members on the drive team that know the robot inside and out from both the software and hardware sides. On the hardware side, if something breaks mechanically, you want someone who can understand what broke, and can quickly decide whether the issue necessitates disabling your robot. On the software side too, if part of the software is not functioning correctly, having a programmer on the drive team may allow you to come up with a solution to the issue on the fly, or help the software team understand what to fix when the robot gets off the field.

Looking on towards elimination matches, these experienced people are also the ones you want down at field level so that they can fix any issues in short-order between matches.

In other words, having programmers and fabrication members on the drive team has been our strategy in the past, and has been quite effective/advantageous for us.

[Jetweb]

I have seen it work great many times. I would even venture a guess that over 50% of drivers are programmers.

One success case that comes to mind is Qbranch on 1024 in 2008, took the robot all the way to Einstein and had one of the best autonomous routines of the year. ( of course he may be part robot himself so Im not sure if that is a good example )

[Brdn666]

I'm the programmer and the driver. It's great because if there's a problem with driving, I know where and how to fix it.

[KF987]

The arm driver when we won the championship in 07 was our lead programer, he also was the arm driver in 08. (graduated last year

This year our lead programmer is going to be the arm driver too... (new driver)
In some ways it helps to have a programmer as a driver because they can quickly diagnose problems that may come up in a match and be able to better fix the program because they experienced first hand what was wrong.

Just don't let them make the control board.

My .02

-Keaton

[FoleyEngineer]

Great feedback, thanks! My one concern is that our drivers are usually busy with strategy meetings, driver meetings, and of course being in queue and on the field. Normally our programmer works on the code during those events changing what the drivers have requested. How do you do both jobs simultaneously? I'm open to the possibility (that's why I asked), just want to know about how to handle the dual-responsibility. The programmer is really the only team member who knows the code well enough to make changes... just makes me nervous to stretch anyone too thin?

Thanks!