To mark SRM 500, we asked members of our community to provide a retrospective on the ten year history of Single Round Matches – the timelines, people and events that over the years have made SRMs such an important part of so many members’ lives. Here is the first in a four part series of member-written articles.  Enjoy!

Here be dragons

I remember how nervous I was during my first Single Round Match. The breeze of a late summer day came in through my open window, and I could hear the shouts from a football game across the street. I was inside my dorm room, staring at green and white characters scrolling down a black background. It reminded me of the Matrix movies, but I wasn’t Keanu Reeves and I didn’t feel ready for battle. I was trying to keep myself from rocking back and forth in my chair. I wanted my fingers to stop trembling so that I could start to peck out some code on the keyboard.

Two weeks later when I took part in my second SRM, I had a bad case of nerves again. It wasn’t until I had a dozen SRMs behind me that I could calmly read through the problem statement and begin typing with a steady hand. I find it difficult to explain to people who don’t take part in algorithmic programming competitions why I was ever so nervous. When I take part in an SRM, I am nearly anonymous. I am represented by a brief string of characters on a computer screen. I rank near the bottom of Division 1, and no one is all that interested in how well I do. I am the opposite of someone like SnapDragon.

In the fall of 2002, SnapDragon was a recent graduate of the University of Waterloo, where I was a grad student. He worked at a bioinformatics firm during the day and came to the university two or three nights a week to help train the school’s ACM programming team. I first saw him at a workstation in my lab during a practice contest. His name was at the top of the scoreboard, comfortably ahead of all the teams from Waterloo and elsewhere. I asked the coach how often a solitary SnapDragon was able to beat the three-person teams.

“Almost always,” he said.

I marveled at the sight and the sound of SnapDragon attacking the keyboard. He hammered away at the keys like a concert pianist performing one of Beethoven’s more frenzied passages, but the noise was like that of a machine gun. On his screen, the text cursor was churning out dense blocks of cryptic code, seemingly all brackets and single-letter variable names. It was nothing like any code I had ever written. I had seen SnapDragon’s name at the head of the TopCoder rankings, but that was my first glimpse of a top coder in action.

Later that winter I had a memorable conversation with SnapDragon after a training session. Fueled by countless cans of soda from the lab fridge, we talked into the early morning hours about programming competitions and about computer gaming, his other great passion. He owned all the major game consoles and played them for hours every day. I asked him if gaming didn’t interfere with his programming pursuits.

“Games actually make you smarter,” he said. “But they also make you lazier.”

We discussed how the Arena compared to other types of programming contests. He said that one of the virtues of TopCoder’s format was how rigorously the problem constraints were specified. And then there was the cash to be made from SRMs. SnapDragon told me that for a while he was winning hundreds of dollars a week in the Arena, which was pretty sweet for a few hours of playful problem solving.

The financial picture for TopCoder and for the world was very different then. It was two years since the dot-com bubble had burst, and the tech industry was on an upswing. Web 2.0 was on its way. Silicon Valley was hiring at a rapid pace. TopCoder was busy marketing its employment services to companies looking for the kind of programmers who excelled at algorithm contests. Sponsors funded two SRMs a week, with substantial cash prizes for top placements in each room of the Arena.

As TopCoder diversified its activities from recruitment to software development, the algorithm competitions diminished in frequency and in financial reward. SRMs were no longer very lucrative, yet they remained a vital fixture on the TopCoder calendar, and the Arena grew as a gathering place for algorithmic problem solvers from around the world.

From the Arena to the workplace

A member whose name I recognized without having met him was radeye, who participated in SRMs frequently from 2002 to 2005. I knew of him from the LaTeX software stack, which is used throughout the academic world to typeset technical papers. Because radeye is the author of dvips, the popular DVI-to-PostScript compiler, I had seen his name many times on the command line while preparing documents for printing.

I wrote to him recently to ask why his participation in SRMs has been so sparse compared to earlier years.

“The cash prizes provided a significant incentive to compete,” he told me. “But primarily, I’ve been too distracted by other pursuits.”

His recent exploits in recreational programming include an exhaustive exploration of the states of the Rubik’s Cube, showing that it can always be solved in twenty moves or less. There is plenty to occupy radeye, but he still competes on TopCoder occasionally, and he holds the quality of SRMs in high regard.

“TopCoder provides excellent, well-tested problems,” he says. “I believe they do a better job of this than anyone else.”

Although he has never competed in TopCoder’s software design and development contests, radeye has applied lessons from algorithmic programming competitions to real-life software projects. He says that he has applied “tools, tricks and APIs [that he has] learned from other competitors” in his own work.

“I know TopCoder has improved my programming,” says radeye.

I recently asked dangelo, another elite competitor in the early years of TopCoder, about the correlation between success in algorithm contests and proficiency in software engineering. From 2002 to 2005, dangelo competed in 77 TopCoder matches as a way of spending “a lot of extra energy that wasn’t being taken up by [his] coursework at Caltech.” Today dangelo is a well-known Silicon Valley entrepreneur. He was the Chief Technology Officer of Facebook before leaving to found Quora, a social question-and-answer website.

In dangelo’s experience, the ability to work with large data sets at an Internet company depends on many factors, “including writing good code, reading code, building good abstractions, systems knowledge, applying and designing algorithms, documentation and communication, experience and working hard,” he says.

“Programming contests mainly build skill at applying and designing algorithms quickly,” he told me. “As an engineer, having this background can be a big advantage, but the other skills are equally important and need to be developed.”

I asked dangelo if he could recall specific cases where he had applied something he had learned in algorithmic programming competitions.

“This happens all the time,” he replied.

While dangelo was coding the first version of Quora, these were some of the challenges in which his competition background helped him: “Designing the data structures and algorithms for our question search service. Writing the algorithm to compute the difference between two rich text blocks (after someone edits an answer or other content). Structuring the abstraction for some of our real-time update infrastructure. Optimizing various parts of our code that operate on large datasets.”

So if you come across people who believe that the mathematical tricks and puzzles we encounter in SRMs are divorced from the realities of software engineering, you can tell them to think again.

The crème de la crème

The Arena is just one of many venues for algorithmic competition while you’re a student. There are the USACO and IOI contests in high school, and university undergraduates can take part in ACM competitions at the local, regional, and global levels. Of course you can compete in SRMs at the same time, as many collegiate competitors do.

When you’ve graduated out of the realm of ACM competition, the Arena is still there for you. TopCoder functions as the major league of the competitive programming world. This was underlined recently in the final online round of the Facebook Hacker Cup, an algorithmic programming contest that was open to everyone on Facebook. All 25 of the top 25 finishers were TopCoder members, two of them rated yellow and the rest rated red.

Red is the highest color in TopCoder’s rating rainbow. At the top of that narrow red band are the brightest stars in the coding firmament. Like in any sports league, there is a small group of phenomenal talents whose names are known to the masses. No two contestants are better known or more feared in the Arena than Petr and ACRush.

Upon his debut in March 2005, Petr spent a single round as a yellow-rated coder before zooming up to red. At the time I am writing this, just after SRM 498, over 85% of his Level Three solutions have passed the system tests. Those are the hardest problems on TopCoder. His passing rates on the Level Two and Level One problems are 93% and 96% respectively. Close to perfect: that’s the level of performance it has taken Petr to rank number one in 136 of his last 230 rounds (not adjusted for unrated matches).

ACRush took part in his first SRM eight months after Petr, and rocketed on a similarly steep trajectory toward the peak of the algorithm charts. He has held the top spot 30 times out of the 79 rounds since he first became number one. ACRush and Petr have reached similar heights of success along quite different paths. Petr’s ACM teams took second place at the World Finals on two occasions, whereas ACRush has won the TopCoder Open and the Google Code Jam. And they have very distinct coding styles; ACRush’s solutions tend to be more compact and more arcane than Petr’s.

These two formidable competitors may dispute the mastery of the Arena, yet they have nothing but warm words for each other. When I contacted ACRush recently, he said that he was “very happy” to have Petr as a rival and that he never worries about how their rankings compare to each other.

ACRush says that he normally practices about five hours a week. Before a major tournament like the TopCoder Open, he will buckle down for about 30 hours of extra training. Despite the hours of preparation, ACRush likes to emphasize the recreational aspect of the TopCoder Arena.

“The SRM is the favorite game in my life,” he told me.

ACRush says that winning does not increase his enjoyment of an SRM. What counts for him is the quality of the problems. It’s “more fun if we have a nice problem set,” he says.

Life in the trenches

Despite the competitive nature of SRMs, they are not elitist events. Coders in all echelons take part in them with great enthusiasm. Surely one of the most dedicated Arena warriors is dcp, who has completed 201 matches since his debut in April 2006. His rating color remained gray, the lowest in the TopCoder spectrum, until January 2007. It took 137 rounds before dcp broke into Division 1 in April 2009, three years after his first SRM.

What has enabled dcp to persevere? He told me recently that he tries to avoid setting goals of a kind where he can’t control the outcome, such as earning a yellow rating or placing in the top 50 in an SRM.

“I prefer to set goals that I have control over,” says dcp. “I might set a goal to solve 5 or 6 problems in a week. Those types of goals are totally in my control, because either I put the time into it or I don’t.”

He spends about three or four hours a week practicing for SRMs. Like ACRush, he puts great emphasis on the fun factor.

“As long as you enjoy competing in SRMs, then that’s what really counts,” he says. “Don’t worry about the rating too much.”

Unlike most of the passionate algorithm competitors, dcp is also active in TopCoder’s component competitions, which award healthy cash prizes to the winners. Although SRMs are not a source of income for him, dcp finds them profoundly useful, saying that through them he has learned many things that he would not have learned otherwise. For example, by studying the code of elite problem solvers, he recently learned about the inclusion-exclusion principle.

“I enjoy the challenges and I like to learn new things,” says dcp. “SRMs are like ‘mind exercise’ for me, and it’s always exhilarating.”

How long can we keep at the game? Will SRMs always be worth doing? Minilek, who started doing TopCoder in his third year of undergraduate studies at MIT and is now close to finishing his PhD there, says that he is optimistic.

“I think SRMs are still as fun as they were in the past, and I’m optimistic that they’ll stay that way for a while longer,” Minilek says.

He is glad that the problems have gotten harder because his “ability has only improved over time and it’s fun to keep things challenging.” He does note that “it might make modern SRMs harder for a newcomer.”

Minilek says that competitive programming used to be his “most enjoyable hobby” and is still among his favorite pastimes. It has also benefited him in job interviews.

“Interviewers liked to ask coding puzzle questions,” he says, “and after having played TopCoder a bit they all seemed easy.”

Minilek has completed 193 rounds in the Arena. In the course of the first 151 of those, he improved gradually from green to red. His enjoyment of SRMs has been essential to his progress. He says that it’s best not to force yourself to do something unless you find it enjoyable.

“If you enjoy what you’re doing,” he says, “you’ll do it a lot and naturally improve, and it won’t seem like work; it’ll feel like fun all along.”

Behind the scenes

What is the machinery that makes the fun happen? Who are the people responsible for creating those exhilarating SRM experiences? I turned to Olexiy for his perspective on the operations that take place in the basement (or perhaps the dungeon) of the Arena.

Olexiy was the head problem writer for TopCoder’s algorithm competitions from August 2005 until February 2009, when he handed the reins to ivan_metelsky. He has seen SRMs from both sides, having competed in them before and after his tenure as Algorithm Coordinator. Olexiy has been among the coders who ask the admins when the system tests are finally going to finish, and many times he has had that question asked of him.

Olexiy started contributing problem sets before he became the head writer. He claims that his predecessor in the post, lbackstrom, wanted him to stop writing because one of his problem sets went “so terribly wrong.” But a few months later, when lbackstrom was in a pinch, Olexiy happened to have some problems ready to go. His affairs continued so well that Olexiy rose to the chief position “about six months after being banned as a writer,” as he tells it.

If you’re one of the veteran algorithm competitors who feels that SRM problems have gotten harder over the years, Olexiy agrees with you.

“The biggest change [has been] the difficulty of the problems,” he said when I asked how SRMs have changed.

Sometimes a problem set is too tricky by accident, because the writer doesn’t see the challenges posed by his own problems. After all, he has “usually [spent] dozens of hours thinking about them.”

Olexiy relates that when Petr wrote his second SRM, he was confident that the problems were quite easy and that there would be “at least 20 people with all three problems solved.” It turned out to be a massacre: “two coders had the medium and nobody came within a mile of the hard.”

But Olexiy points out that the SRMs have also had to become more challenging in order to meet the rising level of skill among the TopCoder membership. In Olexiy’s estimation, anyone ranked within the top 200 today would be able to breeze through the 2003 or 2004 TopCoder Open final problems in 45 minutes. He adds that the problem writers have tried to keep the difficulty of Division 2 “at the same level,” but that the difficulty of Division 1 has grown “tremendously.”

When I asked Olexiy about the highs and lows of running an SRM, he quoted TheFaxman on the experience of going through an Arena meltdown: “Being admin at such events is like skydiving, but without most of the fun.”

The greatest satisfaction that Olexiy gets from an SRM is when someone likes a problem of his. After a highly ranked coder told him that “TakeBus was one of the best problems he had ever seen”, Olexiy says, “I was truly happy.”

The road ahead

I’m not sure if happiness is the right word for what Rustyoldman, my favorite TopCoder curmudgeon, experiences in the Arena. He does say that SRMs are an important pastime of his: “If there is an SRM going on, everything else is dropped, except work and sleep.”

He grumbles that “the participant base for SRMs has moved far away from my time zone.” Then he brightens at an idea: “I guess I could move to Europe in order to participate in TopCoder more.”

Although I don’t believe Rustyoldman’s claim that he is 154 years old, he is certainly among the older cohort on TopCoder. “I try to get other old farts to do contests,” he told me, but “mostly they [say that] they don’t have the time.”

Rustyoldman takes a relaxed attitude toward training. He estimates that he spends an average of three hours a week helping to make problem sets for SRMs in which he is not competing, but “near zero hours per week preparing for participation.” He concedes, “Zero is probably too little.”

As I look back at my own history in SRMs, I can see several bouts of intensive participation separated by long spans of time in which I was a stranger to the Arena. At the start of this year I returned to regular SRM participation once again. What’s new for me this time is a clear sense of how my training in algorithmic problem solving has contributed to my abilities in software development. I’m convinced that the more time I devote to SRMs, the more efficiently I’ll be able to do my work.

In my recent correspondence with Johan.de.Ruiter, who has competed in 96 rounds since 2006, I gained more insight into my relationship with the Arena. He describes the initial urge to compete in SRMs as an addiction.

“I used to compete in SRMs while sitting in the doorstep of the electrical closet,” he told me, “often at 3 o’clock in the morning. I didn’t have a longer cable, and I didn’t need sleep as much as I needed my fix of competitive algorithmic problem solving.”

SRMs took a back seat when Johan.de.Ruiter became more involved in coaching his university’s ACM teams and in developing his puzzle website, but he is eager to make a comeback in the TopCoder Arena.

“Recently I have found more time and I am still as excited about SRMs as I ever was,” he says. “I certainly hope to be a regular in the Arena once again in 2011.”

It struck home for me when Johan.de.Ruiter, in describing his early experiences with the Arena, put it this way: “My rating became part of my identity.”

The identification with my rating explains some of the anxiety I felt during my first few SRMs, and the pride I take today in my renewed participation. I know that my TopCoder algorithm rating doesn’t wholly define my programming abilities. Nonetheless, my capacity to solve algorithmic problems under pressure is a crucial part of my identity as a software developer. It is evidence of the time I have spent studying some of the deeper mysteries of my craft. My sole regret is that I’ve only taken part in about a quarter of the first five hundred SRMs. I am determined to improve my rate of participation, and my rating, over the next five hundred.