In case you missed them, here are parts one – Ask John: Competition Teams – Part One – How to get started and two – Ask John: Competition Teams – Part Two – Resources to use.
OK, I found some good resources. Now, how do I practice? What are some tried and true methods to use? I’d appreciate some advice on that.
As the old saying goes, “How do you get to Carnegie Hall? Practice, practice, practice!”
OK, how do you practice for computer science competitions? What is the best way? What are some good strategies? Let’s hear from some who have done this very effectively over the years.
Annette Walter, a highly successful veteran CS teacher and team sponsor in the Houston area, makes these observations about practicing.
- Schedule some time for the students to practice before or after school.
- Have the teams work together on solving programming problems. Since there are three members to a programming team, it is important that they get along and are able to work together.
- Let each team member know that it is necessary to divvy their time up on the programming portion. In other words, set a time limit that if a team member has not solved a program in 15 minutes, have the member print off the code (and perhaps the output they are getting so far) and look at it on paper while another member tries to solve another problem on the computer. Do not have any team member monopolize the computer at any time.
- Work hard to build up your program so that you have a “JV” team waiting in the wings when your seniors graduate. With their experience of competing, they will be ready to jump in and take over.
- If you are planning to compete in UIL, then have students look at the written tests. The UIL store has last year’s contests for a minimal cost.
- Attend a summer UIL CS workshop held at UT-Austin. This will give you a deeper insight into the contest and where you can ask pertinent questions. (italics mine)
Gina Wilder, a veteran CS teacher and team sponsor whom you met in a previous blog, has these great ideas about practicing.
Find a day or two after school to devote to practice. I have my kids come one day per week, but I stay for 2 hours. Some of my students can stay for only 45 to 60 minutes. Others can’t come until the last 45 minutes. Regardless, this method allows me to work with my programmers at least some each week. At your practice, serve food. This is important because not only are the students hungry after school, but eating together creates a sense of family and lets your students know that you truly care about them. I buy sodas and water, chips and dip, Little Debbie snack, cookies, cheese and crackers, apple slices and peanut butter, whatever they like to eat. For $1, each student gets a drink and two snacks. Charging $1 helps to cover the cost of the food. If a student can afford the dollar, I make sure they still eat. Don’t limit yourself to training just 4 students. The more, the merrier! I often have 15 students in practice. Make your practice an event students want to attend.
Crystal Riley, the 2010 UIL 4A State Champion you heard from in an earlier post, suggests that one way to practice…
…is to get some of the problems from a previous contest and attempt to solve them. The majority of contests will have materials from previous contests going back several years. If your students have never done a contest before, it maybe best to let them solve a few without a time limit, just to get accustomed to what some of the problems are like. Go through the problems ahead of time and ensure that there are some simple ones to get students excited, and a few difficult ones to attract your more advanced students. After they have solved a few without a time limit, start putting a time limit on some of the problems. Ask your students to get as far as they can on a practice problem in 10-25 minutes for easier problems and 30-45 minutes for harder problems. After their time is up, work through the judges solution with them so they can see the simple way to solve it. This last part of the process is important, otherwise your team will only get faster at solving problems they know, but will never be able to learn the solutions to any new problems!
During the 23 years I taught CS and sponsored contest teams, I tried many different ways to help students prepare, and reached a fair level of success in preparing teams for competitions. Here are some of my ideas.
- Once your students have some solid fundamentals down, start showing them some easy contest problems. The UIL Dry Run is a great way to start, where the only thing required is to link your program to a data file, read the data from it, and produce some simple output. Then show them some contest packets from previous contests (see the previous post for resource ideas), picking out the easiest problems first, and then moving on to the harder ones as they gain confidence and skill. Work through the contest problems together, showing them different ways to solve problems. Of course, this requires that YOU know how to solve the problems yourself, so YOU must work through them beforehand so that you can lead them with confidence. If they see you can solve the problems, they will gain confidence in you as their leader.
- Use the codingbat.com website, a wonderful (and free) website chock full of easy to medium to downright “tough as nails” exercises designed to help students develop their problem solving skills.
- For after school practices, put your students together in teams of two (and eventually three) to get them used to the collaborative process. Put together a packet of three or four problems, first with a variety of easy ones requiring different skills, data structures and algorithms to solve. Have them work together to solve the problems.
- When pairing together students, do your best to match up equal abilities. Otherwise, the stronger student will tend to dominate the work, leaving the weaker partner not doing much of anything. If making equal pairs is not possible, make them work by themselves first, but still using the same computer, and then collaborate only when one has a question.
- The other habit you MUST instill in them is using the shared PC efficiently. Too many times students get used to solving the problem on the keyboard since they are so used to working alone, having exclusive access to the keyboard. This is not good for competitions! We all tend to do that when we are working alone, and it is a hard habit to break. One way to “break” them of this is to insist that they think through and write out their solution by hand on paper first, and then when it as complete as possible, go to the keyboard.
- In her comments above, Annette Walter suggested imposing a time limit on a student to solve a problem, and then making them “print out and get off” so another student can work. This is a hard discipline to develop, but one that will pay off in the long run.
- The other bad habit that you absolutely MUST break, is allowing a student to debug a program from the keyboard. This is NOT a good idea! Here’s why. It wastes time, especially if another team member needs the keyboard to type in a solution they have ready to go. You absolutely MUST train your students to “give up” on a problem if they are stuck on it, trying to figure out what is wrong by looking at the monitor. Instead, train them to print out what they have so far, including the source code so far, as well as any output that is showing, whether it is flawed output, or error messages. From the printed pages, the student can then debug “offline”, sometimes more effectively than looking at the monitor. This then allows the other student to use the keyboard to input the solution to another problem.
These are strategies that are useful in actual competitions, but you must practice at home like you’re going to play in real competitions. This is certainly true in any team situation, like football, basketball, volleyball, band, choir or theatre. We’ll talk more about strategies for actual competitions in the last of these four blogs next time. However, here is a sneak peek at a couple of situations I’ve seen.
I once observed at a competition a powerful team from Langham Creek High School in the Northwest Houston area, (coached by the incomparable Mr. Scotty Johnson, one of the finest and most successful computer science teachers and team sponsors I have ever known) and marveled at how they worked.
Throughout the contest, the same student was at the keyboard the entire time, perhaps because he was fastest on the keyboard. The other two would work out the solutions on paper, and then pass it down to the keyboard person who would type it in. They were so smooth and fluid as they worked through the packet (which they swept, by the way), that it was like poetry in motion. Clearly, they had practiced this process and knew each other so well that it worked great for them. Needless to say, they won that contest.
On the other hand, I’ve seen equally successful teams where each student works out and types in their own program, first writing out their own solution completely on paper, and then announcing they were ready for the keyboard. As soon as they announced this, whoever was typing stopped, saved and printed out their current work, regardless of where they were in the process, and exchanged places with the ready student.
Throughout the two hours of work, they were constantly switching out with the keyboard, printing their incomplete work, using their workstation efficiently, never debugging from the keyboard, always making the most of their time. More often than not, those teams also win, or finish pretty high up in the standings.
I wish I could claim my teams were always efficient with these ideas, but they weren’t. High caliber students like this are often hard-headed, stubborn, and find it counter-intuitive and against their nature, to “give up” the keyboard, saying things like, “I almost have it!”, or “Just five more minutes!”, which turns into 20 minutes, just like that. The statement from my team after the contest was over I never wanted to hear was, “we had some problems ready that we never got to because he/she wouldn’t get off the keyboard!” They could have spent those twenty wasted minutes of fruitless keyboard debugging time typing in some other problems that actually worked, and could have earned some more points for their team in the process.
Regardless of how you practice, you must practice, and do it as often as possible. Seek out problems that will fit your students’ current abilities, and challenge them a bit, slowly raising the bar each week so that come contest time, they have reached a competitive level and are ready to “hang with the big dogs”, or at least come away from a practice contest with a positive experience, ready and motivated to improve even more after seeing some really good teams do so well.
Once you have practiced, you MUST go to practice contests. The more, the better. If you wait until District, you might win there, but you won’t have as good a chance at Region, much less State. You must assume that your other Region and State opponents have gone to more practice contests than you did, and are quite likely better prepared than you are. Eventually, if you keep at it, YOUR team will be that team that has out-practiced and outperformed the others, and will come out on top as the winner!
Next time we’ll discuss more about the contest day, what to bring, how to get set up, and what strategies to use, and which ones to avoid.
Until then, thanks for all you do for your students, and for our future technology leaders!
About Ask John
As he always emphasizes in his classes, courses, and workshops, there is no such thing as a silly question, except for the one you do not ask. John Owen has taught high school Computer Science very successfully for many years, and has a team of CS colleagues who are ready and willing to lend their expertise, experience, and wisdom to help you become a better computer science teacher. This blog is for you! Ask your questions, and he will do his best to give you sound advice that will get you back on track with whatever issues you encounter, and for which you seek answers.
Have a Question?
CS Teachers are encouraged to submit their questions about teaching CS or other aspects of CS education. Send your question to firstname.lastname@example.org and we’ll be sure to let you know if your question is featured in the Ask John column of the WeTeach_CS Blog.