How to identify/recruit your programming team?

Technical Programming
1

Since people are talking about how to find their drivers, I would like to do the same for programmers.
I am really curious on how other teams find their “star programmers”. Our team has been struggling for many years and it has been hit and miss. Some years, we would have really good programmers and we lost them when they graduate. Other years, we would have completely novice programmers and training them from knowing nothing about programming to proficiently programming a competition robot is almost impossible in the short build season of 6 weeks. Even if we start training them when school starts in September, it is still a challenge to get them up to speed in that amount of time. To make this even more complicated, our lead mentor insists that we will admit any students who “want to learn programming” into the programming team. But for the drive team, they would hold try-outs and pick the ones they feel that are good fit. When I asked for “programming tryouts”, they said “No, you must admit anybody who wants to learn”. In one season, I got a 12-student programming team who knew next to nothing about programming. To make things worse, most of them didn’t want to spend long hours to work on the robot. They came late for our 2-hour programming meetings and they often left early. Some of them were constantly on their phones. A lot of them joined because it’s good on their resume for applying college and they thought programming team is less work than the mechanical team. So the questions are:

  • Do you have a policy on who can join the programming team?
  • What is the process of the selection?
  • What is a good size of a programming team?
  • Unlike the mechanical team where students can miss some meetings, programmers missing some meetings would miss a lot of their learning unless they are already avid programmers and knows robot programming. So how do you handle students missing their meetings?

If I had a choice, I would:

  • Require everyone (or at least the core programmers) knowing Java or C as a minimum prerequisite.
  • Must pass a programming test.
  • Must commit to deliver what’s been assigned to them.
  • Must commit to show up if they are needed, not just to programming meetings (e.g. attending drive meetings where they are needed to change code by the drivers’ request).

How does it work for your teams?

2

FRC is a learning experience, not a job. We don’t select our programming subteam (or any subteam, for that matter) based on their pre-existing ability, but instead their desire to learn the programming discipline. By making people take a programming test before joining the team, you’re denying them the learning opportunity.

We train our members prior to the season, in ‘preseason’ as we call it. We briefly train them in all disciplines (prog, mech, elec, management, media, etc) and let them choose what appeals to them. Since preseason is run every year, veteran members often choose to reinforce the category they chose last season, or learn something new. This helps in the selection process, but also allows the students to join in the learning experience before being chucked into a 6 week build. That being said, it would be silly to say the learning stops on start build day :slight_smile:

1 Like
3

I think the best way to have a strong programming team is to:

  1. Teach students who want to try programming in the offseason. We teach how to program in Java and concepts for programming robots to rookies in the off season. We start around August and by the time build season comes around, most students can at least contribute some code to the robot.

  2. Set clear expectations for what it takes to contribute to programming. When we start training, we immediately make it clear the kind of time commitment it takes to contribute effectively. We leave the choice of how much time to put in down to individual students, but we let them know what the minimum amount looks like.

Another benefit of the offseason training is it sets the expectation for build season. We only have training meetings once a week, but students can’t miss more than one or two of the meetings without falling behind (unless they try to catch up on their own time). This usually filters out anybody who has too many other activities or is not responsible enough or has any other reason that they can not show up reliably.

This process has worked quite well for us in the past few years. We usually enter build season with 4-6 programmers who can contribute meaningful code.

1 Like
4

I don’t have a problem if the students genuinely have a desire to learn. In fact, I have a student who always stay late and asking what else he can do to help. I am not asking for a tough programming test, it is more of a problem solving and attitude test. I am just frustrated with students wanting to do just enough hours to go to competition.

5

First, I tried to start training in the summer but I ran into road blocks:

  • we can’t identify new members until school starts September when the club starts recruiting. I tried to ask the club to start the recruiting process at the end of school year in addition to the start of school year but that never materialize.
  • I tried organizing summer training for existing members but most of them are taking vacations with their families.
  • For the few that attended, some of them didn’t show up consistently, so on every training meeting, I had to do a quick summary repeating what I taught in the last meeting just so the ones missing them would know what’s going on. That’s a huge waste of time.

So I would ask, how do you guys do it?

6

No matter how you implement this (attending driver meetings, weekly meetings with the other groups, suggestion box, etc.), communicating with the drivers regarding features is important. From personal experience, discussing the features of a program with the people who will be using it will save a lot of time and confusion. I’ve spent a fair amount of time adding suggested features to programs because I hadn’t stopped to think how others would want to use it. It’s almost anyways small details, but those add up over time, and they drag you away from implementing other features.

7

In response to your 3 roadblocks:

  1. September still gives you a decent chunk of time to train new members. If you need to, you could even meet more than once a week to help get through all of the curriculum you need. We actually started meeting 2 times a week as we got closer to build season, until we took winter break off.

  2. Yeah, it is hard to do stuff during the summer, especially with rookie members. We usually limit our offseason activities to working on offseason robots with veteran students

  3. Consistently showing up is an issue, and the delays associated with it was part of why we started meeting twice a week towards the end of the offseason. But here are some things you can do to alleviate it:

  • Try to pick a day for meeting that works for the most students (if this is a flexibility you are granted)
  • We tried to end training sessions with a bit of homework for students to do. This was sent out in an email, usually with additional resources related to the homework. That way, even if a student misses they can still attempt the homework, and if they have questions they can ask questions in an email back. Then we would start the next meeting with going over the homework and answering questions again just to cement the content
  • If we ever had a meeting where we knew in advance only 1 or 2 people could show up, we would try to reschedule or just cancel the meeting. That way everybody stays at the same pace. But we tried to avoid this as much as possible and we encouraged students to show up at the original times as much as possible

A certain amount of having a successful programming team also comes down to luck of the draw. Every year the amount of students that have the capability of becoming good programmers in the limited amount of time there is to train them varies. But every year we generally find more of these than end up graduating, so I feel like overall our process is sustainable.

8

Yes, communication with other teams is very important but I am talking about when the drivers are practicing their driving at the drive meeting, they would make real time requests such as “hey, can you switch this action to another button on this side of the joystick, I am left handed?” or “Can you make this button to switch the drive direction?”. Unfortunately, no programmers were around so the only thing we can do is to note down the requests so that the change can be made in the next programming meeting. I have requested many times that a programmer needs to be at the drivers’ meeting to fill those requests. But the students seem to think it’s wasting their time if there was no request.

9

Thank you for the suggestions.

The problem I have is that I am also involved in FTC so September is really busy for me. That’s why I really want to do a chuck of training in the summer.

Like I said, a lot students are not available. In past years, I sent email with a list of summer projects I would like the students to take on investigating but I generally got very few responses. So I can’t figure out how to get around that.

I am extremely flexible with my time, so I let the students pick the days and time and I will be there. But even only a few students don’t show up, how do you “catch them up” without wasting a chuck of time repeating what they missed?

Believe me, I tried. For example, in one season for vision processing, I gave them a tutorial on the math on optics and trigonometry and ask them to go home and figure out how they can calculate the target distance and angle with the given target rectangle coordinates. At the next meeting, nobody even attempted the problem.

So if the students decided that most of them can make Tuesday, for example, but one said she couldn’t because of some other activities. In fact, she said she can’t make it ever on Tuesday. What should you do? She will always miss Tuesday. How do you catch her up?

I am even happy if I find just one that genuinely has the enthusiasm to learn. I would get one of those once in a while but not too often. BTW, we are a very small school with only about 500 students total from 6th to 12th grade. So it may be easy for your team to find a few of those, but not us in general. In fact, we often accept students from other schools to join our team and often these are the students who are more enthusiastic to learn since they seek out to join our team.

10

Other than the first two years of our team, we have never had a rookie programmer contribute more than a few lines of code to the competition robot. This isn’t something we really like, and we do start two-a-week programming classes in September or October, but our rookie programmers are usually still learning the language and development environment by build season. Take a multi-year approach.

As we only meet 14 hours a week during build season, it is really important that at least one or two of the programmers take the work home with them. The same is true of our CAD and chairman’s and media teams. Because of this, we are a bit more relaxed about members of these subteams missing a FEW sessions as long as they are being productive and staying in touch.

Edit: I read the above and it sounds like rookie programmers don’t contribute. They do contribute a lot in terms of calibration, deploying code, documentation, coordination, and testing, just not much code, at least in the last four seasons.

Also, our program group tends to be about 15-20% of the team. This year, 3 programmers on a team of 20 - two veterans and one rookie.

11

Sounds like they don’t want to “learn programming”.
Though honestly, my first guess would be that they don’t have anything to sink their teeth into. We are still working on getting our programming training solid, but we have found that small scale projects that each student can **meaningfully **contribute to can be very effective. I’m not sure exactly what your lessons are like, but providing something interesting and cool to do where each person can contribute can work wonders.

12

I’ve been working with our lead programmer on changing how we handle programmers for a couple years. We would start out with 7-12 students interested in programming, and by the end of the 6 week build season we’re at 2-3. FYI, we have VEX the first half the school year, so we don’t get much FRC training done during that time.

We’ve tried programming classes in the summer. But low turn out and the gap between the classes and the seasons were problems. The Use it or Lose it issue.

We’ve tried having classes in season, on programming 101. But the problem I had there was student to mentor ratio. Having 6 students asking “why doesn’t my code compile?” doesn’t work well with just 1 person.

In both case, we ended up with 2-3 at the end of the season. This year we actually had success. We divided up the students in to 3 categories:

Rookie : Those that want to program, but have never done it before.

Junior Programmer: Those that have programmed, but don’t know robotic programming.

Senior Programmer: Those that know how to program the robot.

Our lead programmer found an online course on Java 101. The rookie programmers did a self paced lesson during in-season during our meetings. Once they finished, the became Junior Programmers.

Junior Programmers were explained how the wpilib framework works, shown some sample code that did simple stuff. They then had to make a test bot move, make a test bot move in auton, make a test bot move x distance.
We gave the mission of writing simple prototype code and simple middle peg auton code to the Junior programmers. Junior programmers don’t move to senior programmers in season, since it’s too risky and stressful.

Senior Programmers did advanced stuff, vision processing, work on motion profiling, etc. They would also take the junior programmers simple auton code, review and bring in to the competition code.

Each group of programmers has a lead, so Rookie Lead, Junior Lead, and Senior Lead (The lead programmer). So the Lead programmer could know how things were going, but without have to directly manage them. It also gave younger students the change to “lead a group”. Rookie programmers would get help from Junior programmers when they were stuck. And Junior programmers would ask seniors when they had problems.

The upside is that the “junior programmers” were proud that they auton was used. As the season goes on, and vision processing is added, the Junior programmers still had the pride in their code.

At the end of the season, we lost 3 programmers out of the 10 we started with. So it worked a lot better.

YMMV

Brian

1 Like
13

One thing that I have found helps with getting programmers to contribute more is to give them specific, bounded tasks. At the start of the build season once we have a general idea of what our robot will look like we make a list of subsystems and then we assign them out. Usually it ends up being 1 person per subsystem, but sometimes people pair up on them too. We try to assign them based on difficulty, so something simple like a climber we give to less strong programmers and more complicated stuff like a turret we give to veterans. But we don’t just go off of when a student started, we decide it based on how much experience they have. Then all of the subsystems go through the same basic process:

  1. Go talk to the mechanical designer of the subsystem and figure out what hardware there is associated with it. What motors/solenoids/encoders/sensors are associated with it? How does it operate? What special considerations are there?

  2. Add the WPILib classes corresponding to the hardware to the subsystem.

  3. Add more high level functionality to the subsystem, like control loops or state machines

  4. Add commands that can be used for autonomous or driver control

As we are going through this process, we generally talk through what functionalities and commands the subsystem needs with the student. Since we can give them specific tasks like “add a command to rotate to an angle” they generally have more success than they would if we just told them “make auto driving work”. And if they need more help with accomplishing that, either another student or I sit down with them and help them through it.

I think that students might be more interesting in writing something like a subsystem rather than working on the match involved with vision because it’s a lot easier to go from code to seeing something move and work. There are so many steps in writing a vision system that just working on the math involved can seem far removed from a final product.

In terms of catching people up, at a certain point you have to decide whether or not the student is dedicated enough to be justify the time to catch them up. When we have 2-3 new students that show up every time and put in the effort to learn and 3-4 students that show up 50% of the time and don’t attempt the homework we send out, it’s hard for us to take time away to catch the 3-4 up.

Larger projects such as vision or motion profiling are more difficult. They generally require one person with a lot of drive and talent to accomplish them, and so far I haven’t find a way to instill that into somebody that doesn’t have it from the start.

Sorry for the long rambling post, just trying to report my observations from ~4 of being on our programming team.

14

With recruiting the programming team, I don’t think the major issue is not knowing about programming. In fact 2 years ago, I knew no programming (not even scratch). But, right now I am the programming lead of a pretty successful team. Our team only has 2 -3 programmers, right now, and we feel content about it at the moment. The major issue about recruiting programmers (I think) is their dedication level and the willingness to work on their weaknesses. I feel like more than half of the new members give up on simple projects I give them (and that’s the problem). It is very hard to find members who are willing to put a lot of hours into build season and off-season, and I think that’s the major problem.

And as far as teaching code, I would just teach the fundamentals first (I would not have a new member take a code test before they join). After the fundamentals are thought, I think you can work on complex stuff for about a month. After that, I would have the programmers code simple parts of the robot first (such as drivetrain, climbing mechanism, etc). I think as the years go on, you should have your programmers do more complex stuff (such as Vision, etc).

But my first step to finding a good programmer would be to find a member who is willing to learn code and willing to sacrifice a lot of hours. I don’t think you should base it on their background programming experience. (I had no programming experience when I joined my team)

Wish teams the best of luck for recruiting their programmers.

15

(long post warning)

I agree with the sentiments that FRC is a learning experience and my team doesn’t do any kind of tests or tryouts to join any of our subteams (software, electrical/controls, design, fabrication, and business). However, we do expect that students are (a) willing to learn and (b) willing to put in the time.

We’re a new team and just finishing our second year, so we’re still working out the pattern. In our first year we had a few students with FRC experience, some new students that wanted to learn, and no hardware - our first RoboRio and chassis wouldn’t come until we received our rookie kit. That wasn’t ideal, and we ended up in the classic scenario: the veteran FRC programmers did most of the code on the robot, the rookies didn’t have time during the 6 weeks to learn the architecture and contribute much (plus everyone was fighting over time on the robot). Luckily we had enough students interested in learning Android and Raspberry Pi that we built an Android scouting app and a Pi-based vision tracking system, both projects building on existing work brought by a mentor coming from a different team.

This year we had three tiers - the experienced FRC programmers, the experienced Android/Pi programmers, and the rookies who wanted to learn. In the fall offseason we let the rookies learn Python to get the basic concepts, and the other groups were given freedom to decide what they wanted to do. The robot students worked on cleaning up the previous year’s code, getting a base ready for this year. The Android students worked on the foundations for a new improved app. The Pi students were given a project to develop a standalone video kiosk for our pit. We had some students who wanted to play with Arduinos and we saw this as an opportunity to get students trained in the use of sensors.

One thing that was missing here was cross-training. We haven’t yet had, say, Android trained students saying “hey, I want to learn robot code”. We’ll cross that bridge when we get there.

After kickoff we decided our robot needed to have the following subsystems: the drivetrain, the OI, vision, gear handler, climber, and an LED strip light system we call Bling. Students were assigned to subsystems as follows:

  • the rookie students who went through the Python training were given the gear handler and climber subsystems. Their job was to write the Java Subsystem class that would encapsulate the mechanism hardware (motors, pneumatics), the sensor data (limit switches, IR, ultrasonics, encoders, CAN bus query) and build a library of method calls and corresponding Commands. (If you think about it, these subsystems are each pretty simple, well-defined, and WPILib provides a lot of hand-holding.) They also had to ask the drive team what buttons should do what, and bind those buttons in the OI to their newly created commands. This was also how they unit-tested their Subsystems.

  • the new student with some previous experience was given the Bling subsystem to write. He had to deal with interfacing to a RioDuino via RS232, and was given free reign to come up with commands and signalling patterns he thought might be useful, but his job was to get buy-in from the drive team and implement whatever signalling/showoff lighting they wanted. He also did some work in the drivetrain code.

  • the students with previous FRC experience were tasked with keeping the architecture clean and being the “gatekeeper” of our code on GitHub. Their job was to monitor pull requests and provide peer review and guidance to the new students, teaching them to follow our coding guidelines, how to use GitHub, and warning them of pitfalls. They also combined the Commands and Subsystems defined by the other students to write autonomous mode commands. They were also given more advanced deliverables like “write a Rotate command that used the gyro to turn the robot, use PID, tune the parameters so it works quickly and accurately”, and given freedom to try their own ideas (“I want to develop a more detailed logging system so we know what went wrong during auto”, “I want to try a new method of driving along a curve using equation-based path planning”).

  • the Camera vision subsystem was given to a group of students who had mixed FRC/Pi experience. There was code on both the RoboRio and the Pi to adjust as well as physical devices (camera, ringlight) to calibrate.

  • the Android team continued independently working on a scouting app for Steamworks.

  • the Arduino team continued learning and building a training curriculum for a workshop to teach other students. This was more of an outreach project that was ongoing in parallel with the build season.

Some of these jobs continued into competitions - the Android team was on standby to fix any problems with their app while they were scouting in the stands, the robot software students tweaked our auto and fixed any code problems, the vision team’s job was to make sure they made it on the field during calibration windows and get the vision system working to their satisfaction.

We were definitely juggling a lot of people and a lot of tasks trying to keep everyone busy. The key point we made clear was that you’ll be given ownership of a chunk of work, directly proportional to your willingness to take it on. If you’re only casually interested (or available) to come out then we’ll give you casual work - and there’s nothing wrong with that. But if you spend your time goofing off, or choosing not to be helpful, then someone else looking for things to do will eventually start crossing things off your to-do list for you.

The result was that some students have become subteam/project leaders, other students are working on projects and taking direction and training from their subteam leaders, some students who can only come in occasionally will help out wherever they can, and a few students just enjoy hanging out with us.

We had an unheard-of 20 software students on our 40-person team, and we managed to keep everyone busy - no small feat. I hope this model works for us again next year!

16
  1. Do you have a warm body?
  2. Are you willing to work and learn?
  3. This is subjective to each team. As long as you have enough veteran/experienced programmers that can assist the new members you should be fine, but I would never turn a member away unless their attitude is degrading to the team. In that case I would involve a head mentor/teacher sponsor to help them adjust their attitude.
  4. Post training material online on something easily accessible such as Google Drive. Personally I like to do my training in the off-season where we can go at the pace of the slowest learner and do fun activities that make members want to stick around for the entire meeting. It won’t always work, but if you can come up with engaging lessons for the students that is more than pure coding knowledge, you will get more students who are willing to work when the competition season rolls around.
17

Why C? Surely Java would be enough, no?

In regards to how our team does it, we allow anyone on the the programming team. Roughly half of the people who joined programming team had actual experience with any sort of programming languages, but the freshman were pretty eager to learn, so that’s nice at least.

18

C/C++/C#/Java are all C family languages. Knowing one allows you to easily learn the others. So any students knowing any of these languages would allow them to jump right in.
I guess my desire to “filter” is really for attitude and enthusiasm, not so much as the actual programming language knowledge. The logic is that if you have the curiosity to learn and the interest in computer in general, you would have known something already (i.e. like to hack things and put things together). You can tell quite easily for those who don’t really want to do anything unless they are told to do it.

19

I’m not sure how to handle filtering enthusiasm, but I would like to add my two cents in on the prior experience bit. Although I really do understand where you’re coming from and the frustration you are feeling, making that a prerequisite may not be the best option and my restrict a lot of otherwise interested kids from joining. Many kids may not know where to even begin with the sometimes confusing world of coding and this may be able to jump start them in to the field. They also may not have the means at home to begin, as you have to remember some kids still don’t have access to computers. They also may not have had time previously due to family situations, other club involvement, etc.
Whatever the case is, as irritating as non committal members are (believe me, I know), remember that this although a competition is still just an extracurricular (that hurt to type yikes). It is also a learning experience and turning any kid away for any reason like no prior experience is in my opinion very counter to what FIRST stands for. Just try to take it in stride, focus on the students willing to learn, and you can’t force students to do anything they’re really not motivated to do.

20

FRC11 has a pre-6 week education workshop that runs from September to December.
As far as I am aware anyone that wants to program is welcome to attend we often have 20+ students present.

The students have a slide deck they use to teach Java for FIRST FRC.
They give projects out to practice.

The challenge I gave them last year, and I’d like to see the approach every year on our team, is that anyone that is on the programming team should be able to take a laptop and show me a working KoP drivetrain and put that on the robot through the entire process.

I know the more experienced readers will quickly realize that there is literally sample code for this but one might be very surprised how difficult this can still be for people that maybe program in other languages, in other editors or on other operating systems.

This demonstrates:

  1. They have worked with the tools required and likely have them installed (hours of work) also where they are available.
  2. They can explain how the code works.
  3. They know how the build process works in the team.
  4. They know how to communicate with their team mates (Slack in our case).
  5. They know where to find examples.
  6. They know how to get code onto a very basic FIRST FRC robot.
  7. They can make the robot run and understand the driver’s station.

At first one might think that 6 weeks of training 2 nights a week for a few hours is enough but it’s very quickly surprising how you might be able to get this task out of people just before the holidays, but they don’t take notes so they remember, and you find yourself having to retrain people.

The process just to put code into a FIRST FRC robot, to understand how to update all the firmware, where to get all the updates; is pretty specific and fairly involved. So much so, that as I am typically a week 0/1 CSA, I end up sorting out updates when people arrive at the event that were often available well in advance. You could be a professional Java developer and still be scratching your head for a bit if you come in cold.

I’d like to see this process extended to our Kangaroo and mobile vision as well, and that should be much easier for us because the Kangaroo is just a smaller x86 64bit PC with Windows or Linux. Perhaps the sticking point there will be for them to have code on the RoboRio side to exchange information with the RoboRio so the 2 core skills development checks are sequential.

Without the ability to demonstrate this capacity it’s going to be hard to rise to the next challenge which requires all of this plus: PID loops, OpenCV knowledge, NavX coding, etc. So if your find yourselves with programmers with no interest in at least this challenge you probably have to figure out what to do when you need them to really deliver a working robot.

There are always programmers that understand the computer science aspects, maybe can write code, but have difficulty on the engineering aspect of leveraging their science into something practical.