Any ideas? I know that to be a successful programmer (at least on our team) you need to have a lot of drive and self motivation. To be able to take a statement such as “tell me about vision tracking” and the rookie programmer be able to go run off and come back knowing “everything about everything”. Is there any pre-tests you put your teams (specifically programmers) through to find out if they are going to be a good active members? Lastly, any ideas on how to make those not self motivated to learn?
I would be careful about “guys” who run off and come back “knowing everything about everything”, they may cause more problems than finding solution. I would rather have someone who takes time to think about and finding a solution, this is bit vague but in short someone who has patience. Especially with programming debugging is part of life and many times its not easy. Someone with short attention span may not be the best candidate.
To get students interested in programming, we give mini-tasks to team members to program. We use Labview so our typical challenge is creating a dash board showing water level in a tank, as they make progress, we will make it more animated and add controls and alarms etc to control flow rate, and alert when tank fills up. Since they can see on screen what is happening and how controls work they would be interested. Then we step up a notch, give them cRIO and ask them to program, control pneumatic system, one step at a time, and so on.
You interested in programming?
Sure
Ok.
+1
Just about every programmer I know has been self-motivated to learn. If they’re not interested enough to learn than maybe programming isn’t for them.
I was interested in it, but never put forth any real effort to learn it. Once I finally took a class on it, I quickly learned that it was not for me.
One of the things that is helpful is for those who want to be programmers to be in computer science in order to know ‘programming’. That is, how if statements work, return, while loops, for loops, that kind of thing. It is easier for a person who is trained in teaching students to teach them how to program than it is for a mentor or another student to try. Even so, our team created a python training module that you can find here. We went through this as a group and now most of our team is somewhat up to speed.
We don’t actually pick people, instead they tell the captain they want to program, and that is that.
There are multiple ways to go around with this.
I really suggest to pick people with at least a little bit of programming background, at this moment of time, as we are really close to the new season.
In my programming club, I have it as open enrollment – anyone can join – no experience required. Of course, this means that you need to know how to use a computer, and how to install software, for example.
This “open-enrollment” option means that you will tend to spend a lot of time just teaching students the basics of programming.
If you get students that know how to program, even in just a different language, say Python instead of C/C++/Java, they should be able to catch on quite quickly.
From my experience of my team as well as talking to many others, programmers are pretty rare on most teams. You really can’t have enough considering how many potential programming projects and problems there are so I would take anyone that is interested. Whether or not they are dedicated is another story but that’s why you have them work with someone more experienced or have them work on smaller projects before you give them a really important task.
How to choose programmers?
It’s the ones you have to pull away from the computer and shove out of the building late at night.
(And the obligatory “cans of Mt Dew and bags of chips”.)
On the “if interested, join.” aspect, my team had an issue with that last year. We had about 8 people interested in the “romantic” esque aspect of programming, as in they wanted to become like super hackers or something. However, come build season,after teaching them all the way from September 1 to January 1, we had on average maybe three for the first three weeks, and then we were lucky to have one or two of the original 8 every night. I’m also trying to find a way for our team to find new programmers, that are capable and willing to come.
I think the idea of a “patience game” is perfect for at least the text based languages. I think that would be the best way to do it by far! Thanks so much from all of you!
+10
Let them learn the basics. They’ll need some instruction so a mentor of some capacity will help them to learn. If they learn well, then keep them on the learning path. Any student who has the will to learn to program or learn to do anything on the team, I would never turn them away.
But if you insist on a test before competition to see if they’re ready, try this one on for size. 
- Put them in a room with a robot, robot control system not even imaged. (Simulating swapped C/RoboRIO)
- Give them laptop with the IDE on it with the most basic template for the language you’re using. (Simulate programming laptop having died)
- Give them one hour. (About the average time between matches at competition)
To completely pass it, they must reprogram said robot to be as close to competition ready as possible. If a student programmer can complete the above and the possible drive team be able to be competitive with the robot, then that student has earned their weight in pizza.
This seems about right. We always have labview classes on our team, but a significant amount of motivation and interest is necessary to be a successful programmer. From the past two years, only one student (myself) has ended up working on the robot code.
It seemed like the only way to get on the programming team was to take action yourself to program things, rather than waiting for someone to ask you to do it.
This year, however, we’re trying to push the involvement of other students more, and it looks like there are some students that have the necessary motivation. This year, I expect a programming team of around 3 students, maybe 4.
I really like this idea! Just throw them in a room and see what they can do and learn!
+2
Our method includes this…and a whole lot of begging.
I recommend every team member to write an essay and have the coaches along with mentors review it.
The essay should answer these three questions:
- why you joined the robotics team ?
- what skills you bring to the team ?
- what skills do you want to learn ?
From the essays not only you can find out who would be interested in doing programming and their level of experience, but also help to find volunteers in other areas.
Cheers,
M.C
A lot of times, what looks like lack of motivation is actually someone needing guidance. Personally, it’s very hard for me to learn unless I’m being taught. I mean, if it’s something where I have a little background knowledge, then all I need is a brief refresher. At the beginner level, at which I assume is where a lot of people you want to teach are, it is important to build a solid foundation in any skill, whether it be programming or some other area. Mentors and teachers can really help with that. I know they’ve made a difference for me.
It can be very intimidating to learn, especially if every other programmer has very very advanced skills. Sometimes, juniors and seniors are not the best teachers (a lot of times, we’ll assume that our underclassmen know something seemingly fundamental, or we might forget to teach something because we think it is too fundamental to be mentioned), so I must stress again the importance of mentors and teachers.
It would be nice to have a way to track progress. I think that could help with motivation. Maybe have checkpoints, like “Level 1: be able to write a program to _____,” and set a minimum level for each area (ex. lead programmer must be at Level X or higher).
So, yeah. I think I’ve given you more of a how to go about training rather than specifically what to do. I have not done programming, but I know that that would help me when I learn… or when our strong programmers graduate. Best of luck!
Pointing them towards places like CodeAcademy and having them work on that on their own is a good way to teach some of the basics.
I’m going to resurrect this older thread, because I was reading through it and this post made me laugh… this is pretty much exactly what happened to me as a new mentor!
At my first meeting they said “So, you’re interested in helping with programming? Cool, go see [mentor]”. He handed me a package he had just received that day… a set of I2C addressable LED strip lights, an Arduino board, and a power supply. My directions? “Take [students] and make this work!”
In the remaining hour and a half I had to find a laptop, download the Arduino IDE, drivers and sample code for the LED strips, figure out how to wire it all up, debug a wiring problem (turns out the power supply connector polarity was backwards!) and… yes… we made it work!
On my way out another mentor shook my hand and said “Well, you did pretty fantastically for your first time out!”
We did tryouts this year for the first time. Everybody who didn’t make varsity last year had to try out (tryouts were given by members and varsity). Everyone had to do all the tryouts, including some mechanical, wiring, and programming tasks. We kept track of both attitude and aptitude. We selected members primarily on attitude, and assigned them to departments based on a combination of aptitude and their preferences. We know we always have to get a lot of programmers to start, because there will be those who don’t properly engage or get it in a couple of months. Some of these leave the team (most just stop showing up; we get this in every department), others move to other departments.