How can I be an effective programming leader?

Technical Programming
1

I am a senior and 2nd year member of my schools FRC team (our team was started last year). I was the only programmer last year, and this year I have another student I am trying to work with and one or two others I can have join me if needed.

The only problem is the closest thing we have to a programming class at my school is spending a week doing simple programs with Visual Basic in a computer science class. And while I do have a mentor I can send code to have reviewed, there is no one on site who can help me.

We are programming in Java this year, and while it is going better than last year (due to me understanding the concept of Java better than last year), I am still learning the language as I go. This isn’t a huge problem for me, as I am inquisitive and patient, however the kid I am trying to teach to help me has a more difficult time with this. He tends to get upset by every single error he has, and has adopted the attitude of, “Well of course it doesn’t work, it’s Java”. I have spent a lot of time teaching him, because my main concern is making sure the team has a semi-able bodied programmer when I leave for college.

My question is on how I can split up what needs to be done effectively. Yesterday I spent half an hour writing up a piece of paper on how to do two things I wanted him to do (create a gyro instance and make 2 joystick buttons to fiddle with it), and I gave him all the instructions I felt were needed, however it still took him fifteen minutes to code something I could have done in five (and I still helped him through most of it).

In addition to knowing what people think is the best way to teach programming while also being efficient, in general how do programming teams share the workload? Does one person do vision processing and the other does work on driving, or do people typically use pair programming?

Thanks for any advice, I wholeheartedly appreciate it.

2

I think you’re on a great start by being humble and asking us how you can serve the team. You’re not bragging about how much better you are or ranting and complaining about how bad your other programmer might be. There is a way to make the situation better with a positive attitude, so I’m glad you’re trying to search for that.

You might end up having to do the brunt of the work. But don’t do all of the work as if you’re shoving him aside and he doesn’t matter. Let him do projects that he CAN do, keep teaching him, and give him projects for what he just learned.

If you’re pressed for time, try not to give him things that are above his level, or that you know you’ll be constantly helping him with. This is probably tough, because there might not be much he can do without help.

Maybe you can tell him to go learn and catch up a bunch during a meeting on his own. People will suggest Java tutorials to you - have him go through a bunch of those so that he’s ready for some more things.

What would be the best is if he can get an attitude for striving to learn and getting things done. Try to be happy and congratulate him when he finishes something. Let him know that it is important for the team for him to help programming. Let him know that the build season is busy and that both of you need to work to get things done in time.

Maybe you can ask him “What do you want to program? What do you think you can help with? How could I help you best with that?” Then you get feedback from him and he can have some ownership in the task.

Hope that’s helpful! I was a programming leader too.

3

If he really doesn’t understand the language, it may be helpful to take a few days off and really teach him the basics of the language. It may put you behind now, but later on you’ll be able to work faster because you won’t have to help him, or help him as much.

You could even just write code for the robot, then explain it to him as you go. Then you’re teaching him and getting your job done at the same time.

Try to be friends with him, its okay to joke around sometimes. Treat him as an equal, and he might feel more important and more motivated to do the work.

4

I program in 18+ languages professionally.

I haven’t had all that much education in a structured sense over the years towards that goal (my degree is not in programming but I have taken and taught college level classes).

I am not a prodigy, brilliant, or super-intelligent…I commit my time and my efforts towards a goal and for better or worse unless safety or realistic incapacity denies it I do my best with that goal. Sometimes my best isn’t as good as someone else’s best. Sometimes it’s much better. That’s just how things work out. You can’t win them all, but you can do enough that you feel you met or exceeded practical expectations and if you can look in the mirror and tell that to yourself honestly…you’re doing just fine in my book.

The problem you are touching on is one I frequently see.

Firstly, you indicate that you feel that others could do a particular job faster and you know you could. I encourage you to remember that while sub-dividing a job is important (and an important programming concept), it’s possible for someone to do one part of the larger task much slower than yourself and still accomplish the larger goal faster than yourself. The key is to look at the entire picture broadly.

Secondly, we often start off with 30+ programmers in our team. Ultimately I wish that all 30+ would show deep commitment to persevere to be really excellent in all aspects of this task. However, programming may not be their forte, it may not be practical in this time frame, they probably have distractions that might actually be more important overall and the situation might not be quite right to reach them as students. Really excellent teachers understand and value diversity in their students and they recognize that they have to adapt as much as their students.

Having written all that, it sounds to me as though your team is in a place much like our team was for many years. I was originally brought into this in 1997 because the school and the 1 or 2 other mentors felt they could build a robot, but they weren’t convinced they could program it (that was when the control system was essentially a framework around the Parallax BASICStamp). During the first year it struck me that it wasn’t very good that I had to do this as a mentor because the school’s education towards that goal was lacking. The students could pass their classes, but didn’t really understand binary, we didn’t have any practical examples to reinforce the education (except the robot and that was a billion parts on the floor for 5.7 weeks of 6 weeks) and there was originally no electronics education at all at the high school level (I went to vocational technical classes during high school myself because of that as this is the school from which I graduated merely years before, because of my age people often think I participated in this during high school but unfortunately it didn’t exist at the time).

My how things have changed. With the support of the team we now have access to all the older robots and an electrical team committed to providing workable systems we can test with (even if they are screwed to plywood and stuck there with gum). We start teaching programming in August of the year before and the students do the teaching. The school now has programming classes so many of these students have had months of education prior to even our guidance and many of them understand the fundamentals of object oriented programming. Many of our team leaders have deep commitments to programming and participate in not just U.S. FIRST but other contests and things to which they have chosen of free will to excel for their own amusement and enlightenment.

This is wonderful but it’s taken 14 years to get to this point. Even now we do find issues with Java which is what we use. We do find issues with U.S. FIRST KOP hardware. There will always be challenges, but we are committed to do our best with them. My advice to you is to do the best you can with what you have. If you feel you can’t achieve your best within these limits then set your goals more broadly. Even if you end up with poor results this year there will be more years and you have the opportunity to offer guidance which can, over the course of successive wins and losses, do great honor to the most valuable aspects of what U.S. FIRST can really accomplish for yourself and for so many others.

5

Now that the introduction is out of the way.

The team leader has worked with our team in such a way that we have a drive train group, an end effector group, a scouting group (we have a programming effort in that regard this year), a web development group, a video processing group (himself), and we have a student that’s floating between them that adding a little bit of value to each as he goes.

The entire reason for my introduction above is that I think it would be very hard to assign tasks like this without sufficient training up front. Even now it keeps the team leader running filling in the gaps and managing communication with the other parts of the team.

6

I’m a junior this year and in my second year of being the programmer for our team. Last year I had some assistance from the previous programmer, but I was, for all intents and purposes, the sole programmer. This year, I had about four or five people join the group to learn programming. Being my first year having to teach anyone, I figured it would be best to teach during build season. This wasn’t so much the case. I’d recommend doing any teaching during the first semester, even if you have to schedule after-school meetings to sit down and teach the basics. Right now I’ve been programming and letting the “programming team” watch, and I explain what I’m doing as I do it. Once build season is over, you should be able to do a bit more “simple” explanations to cover the basics without having to put off more pressing issues.

7

Do what you can with the time you have during build season. You might have to do the “drag-along” method right now, because you’re running out of time (assuming you don’t have a practice platform). However, I agree with others that said give him manageable projects. Maybe for the more advanced projects, have him write pseudo code and you can help him “translate” it into java?

After the season, get him doing a bunch of projects. Have him write code to do a bunch of simple tasks and slowly work up to harder challenges. I find that hands-on learning is for more effective.

8

One technique I use with the students I’m mentoring is to backseat drive. They do all the keyboard/mouse work (we are using Labview, but training is training), and I tell them what to type/click. They ask questions as we go, and it generally works out fairly well. I find that works better than the “I do, you watch” method because it forces me to slow down and explain better and the student gets the hands-on experience to reinforce the information.

Once I’m confident a student has the basics down, I give them a simple feature to implement and verbally talk through the concepts involved. I watch until they get started, then step aside to work on something else or leave the room for a few minutes (and go check on mechanical or something). After a reasonable period, I check on them and answer questions, then when they’re ready, we test and debug together.

For more complicated concepts, we spend a lot of time in pseudocode/drawings to make sure we really understand what it is we’re trying to accomplish before we start coding, which leads to better code.

9

I second that approach. I haven’t had alot of mentoring experience in FIRST yet, but “pair programming” is a work-model my workplace encourages and uses frequently, typically the learner is tasked with ‘driving’ and the second person thinks about upcoming problems, challenges naming of variables and structure choices, watches for syntax and logic errors etc. (you can also take turns once your closer to the same level, but the watcher has to be familiar, capable, and engaged).

This can be a very effective way to work for any level of programmers, as the driver typically has to focus a significant amount of attention to typing and progressing; the 2nd body can spend some time reflecting on what was just done, or on what needs to be done, and watching for mistakes.

Starting out, your job should be to patiently watch what he’s doing, let him ask questions, when you see a mistake or think of a better way to implement, just make a mental note of it and wait until that particular section is completed before pointing things out so that you minimize the interruptions to the writer.

10

Ok…I am the lead mentor for team 2980. I have a couple of tools that I use to help my team with programming:

  1. Write the parts of the program yourself, and have them (the students go through line by line and annotate each line of code explaining why it is there and what it does. They are not allowed to use code you have written until they show that they understand what it is for and does.) This way you have working code, and you are giving someone else the opportunity to learn from you.)

  2. (This is really the backseat method described above) Keep your hands in your pockets to keep yourself from “doing” anything, and tell them…step by step…what to do and why they are doing it. (This is a lot more time consuming than doing it yourself, but it works. Make sure they take notes and input annotations(comments) so that they can look back over the code and know what you were trying to do.)

  3. Create and sustain a code bank…Little bits of code that can be copied and pasted, and then modified with notes on what each bit does and how to use it.

  4. Have your students write out pseudo code (really have them write comments) then go back and work with them to fill in the actual code.

Hope this helps. By using these techniques we have gone from 1 person able to program in Lab View to 4, and the entire team can at least read a lab view program and tell you a bit about what it should do.

Edoga