The state of competitive programming at UBC

Post date: Sep 20, 2013 11:35:00 PM

UBC attended the World Finals during 2004 to 2010 and 2012 to 2013. An impressive feat -- but this was due to the efforts of extraordinarily talented people attending UBC at just the right time. The same could have happened at any other university. In truth, the state of competitive programming at UBC is not as mature or stable as that of many universities, and the root of the problem is that there simply is not enough interest. This leads to a lack of skilled participants for a twofold reason: because there is a much smaller pool people from which to choose, and because the existing participants form an elite which does not easily accept newcomers.

This is not an appeal to affirmative action. Rather, I specifically name these problems, with the aim being to resolve them:

(1) The poor state of Computer Science education at UBC

(2) Lack of visibility of competitive programming among students

(3) Lack of appeal of competitive programming among students

None of these problems can be named as the cause or effect; all contribute to each other and raise the barrier of entry ever further.

Point (1) -- however true or untrue it may be -- is largely out of control of students. Nonetheless, students can take measures to maximize the value of their CS education. One can participate in coding whenever a lecture calls for it, or if coding would be especially relevant to the topic at hand (such as when discussing some kind of algorithm), or when the lecture is boring (all too often). One can visit office hours; take notes before office hours to sort out their thoughts, and after them to summarize what they gained. One can seek out more seasoned students for help in various ways. Perhaps most importantly, one can build any kind of program from scratch, regardless of how simple.

Also, I observe that most competitive programmers at UBC come not from a pure CS background, but a combination of CS and another major, or engineering, or mathematics. Some engineering courses involve large amounts of coding using lower-level programming languages; one can argue that this prepares the student for competitive programming more effectively than, say, a background in object-oriented design. (Since some engineering degrees require the completion of CS courses, it should be noted that the CS department is doing a disservice to those who pursue such degrees by failing to improve the state of its education.)

Point (2) is addressed by improving the effectiveness of communications which have to do with competitive programming. But one can argue that this is not very practical: students in general may be too busy to care about competitive programming, or consider it irrelevant to their education. One can not force a student to join. Yet there may be hobbyists outside of CS or engineering who are capable of the required mental feats, and given the state of CS education the prospects of finding talent within CS is not much better than that of finding it across all of UBC. How can we find talent if we can not reach talent?

Given that a student can not be forced to do anything, the best thing to do would be to emphasize the enjoyment of competitive programming and the opportunity to improve one's skills. On the other hand, mentioning the chance of glory is a bad idea -- it serves only to discourage those who think they would be unable to attain that glory. Perhaps advertising may begin from the CS student body, but eventually it can be made to reach wider audiences. (Of course, the sky is the limit in advertising; devising creative advertising strategies is left as an exercise to the reader.)

Even if advertising reaches the right eyes, we must still address point (3). Why do people not feel that competitive programming appeals to them? Why is that they start doing it, realize they do not like it, and lose interest in it?

One contributing factor is that competitive programming is not enjoyable for many people. An activity is most enjoyable when when the level of skill required matches the level of skill possessed by the performer. Competitive programming is an activity which requires very high levels of skill to enjoy, something very rare in the general population. Thus it would make sense that the average person feels frustrated at the level of challenge, becomes discouraged, and eventually abandons their interest.

It does not help that highly skilled people have a tendency to trivialize their achievements. After all, something which is hard for the general public is easy, routine, trivial for them. An athlete may think nothing of running five miles every morning, something another person couldn't do even once. And so, in trying to explain how to solve problems, they skip steps, write things off as trivial, can not comprehend the difficulty people may have in solving the problems. In fact, it may be painful for a skilled programmer to think about the difficulties they have faced. Sometimes a programmer would claim that they never had such difficulties -- however true that may be, they would still have difficulty empathizing with newcomers.

Thus arises the question: how can competitive programming be made more enjoyable for newcomers? Or, how does one go from having little or no experience to finding problem isomorphisms, designing data structures to fit specific needs, and devising algorithms in the blink of an eye?

Programming is inherently an enjoyable activity because of its complexity and the amount of concentration required to perform well. Therefore it requires very little in the way of external factors. Instead I focus on improving the activity itself by posing problems of suitable skill levels, and giving clear, frequent feedback of progress.

At higher levels, these factors are already present: many competitors actively seek out suitable challenges, gain feedback with each competition, and improve constantly. At lower levels, there is a lack of suitable challenges (or it is not so easy to find them) and not enough feedback. Receiving grades in courses is certainly not enough feedback, because it happens so infrequently, and in achieving these grades one is made to satisfy arbitrary requirements which detract from learning (a deadline is one such requirement).

Actually, one ought to forget about the lofty goal of solving any problem they counter and proceed at their own pace. Doing things which are difficult has a discouraging effect; on the other hand, one's smaller successes encourage them to pursue more of the same. Thus it is more constructive to do things that come naturally. Take, for example, someone who has no programming experience. Suppose the first thing I had her do was implement binary search on a sorted array of integers. Even if she understood the concept, she would not be able to do it because there are so many details unfamiliar to her -- array indexing, integer arithmetic, control flow, and so on. Overwhelmed by these details, she loses interest.

On the other hand, what if I had her print out the numbers from 1 to 10 in order? It still requires a loop, and she may still not be able to, but there are far fewer details. Thus it is of a more suitable skill level. Now suppose that she has already mastered this challenge, has made it second nature to her -- she can do these things without even thinking. When she now tackles binary search, there are fewer details to deal with. By defeating an easier challenge, a more difficult one becomes more suitable.

How fast one develops varies from individual to individual; in my observations, for example, one semester of concentrated effort can take an average individual with no programming experience to, at the very least, knowing when to use binary search and how to implement it. (Someone at this level would already be able to solve many regional-level problems.)

Furthermore, what is the rush to solve more problems sooner? It is not as if there is some arbitrary goal or quota which must be fulfilled, such as going to World Finals -- unless some external force imposes that goal. But if achieving things sooner is the desired outcome, the surest way is to have the competitor start earlier, giving them more time to develop.

As for improving the quality of feedback, frequency is key. Practice often at suitable skill levels. Collaborate often. Ask for feedback and give feedback to peers; work closely with peers of similar skill levels, to maximize the level of empathy and thus the quality of feedback. Then, put the newfound skills to the test in the arena. Finally, it is very important to apply the skills gained to fulfill one's own desires by doing something meaningful to oneself; even if the work never sees the light of day, it serves as an affirmation of one's skill.

In closing, remember the spirit of competition -- not to crush the enemy, but to improve yourself. The purpose of competition is your own development, your competitor your ally, a battle an agreement to improve each other's skills. Thus remember: do your very best, be proud of whatever you get, make the effort to do better next time, and above all else have fun.