1. Skip to Menu
  2. Skip to Content
  3. Skip to Footer>

Strengths/Weaknesses & Backseat Coding

Last Friday (January 20, 2012) marked the first Programming Team practice at the University of Akron this year. The topic was Solving Problems Quickly (link shows the problems we worked on and a couple sample solutions).

Background

If you’re not specifically interested in the UAkron Programming Team (or Programming Team coaching in general) jump down to Backseat Coding.

For the last several years we’ve really focused on algorithms and I think the team has benefitted greatly from that, taking 13th and 28th place out of 122 teams at the ACM ECNA Regional last semester. However, the actual scoreboard from the contest show something troubling:

  • Consider our team qUArk which took 13th place with 4 problems correctly solved. Their first correct solve was at 53 minutes, second correct solve not until 135 minutes….
    • The team in 14th place had all 3 of theirs by the time we only had 2.
    • The team in 11th place had 3 of theirs in just a bit longer than it took us to get 1.
    • We were the slowest team to solve 4 problems (ranging from a 1 minute delta against 11th place to a 272 minute delta against 9th place).
    • The 4th problem solved was, statistically, one of the harder problems. Problems C and E should have been easier.

What’s the takeaway? We have smart kids who can solve hard problems given enough time. The fact that they solved F proves this. But, imagine if they had solved the three “easy” problems ({B, D, I}) in the same amount of time as “Cowgorithms” (the fastest team to solve 4 problems, who were unable to solve F after 6 attempts) who were done with {B, D, I} at the 68 minute mark (versus our time of 194 minutes). I firmly believe we would have solved a 5th (and maybe even 6th) problem given that extra 126 minutes. We need to get better at solving the “easy” problems quickly. It’s not as fun as dynamic programming or as exciting as getting a complicated graph problem to work, but it’s essential to the continued improvement of our program.

Backseat Coding

(I’m purposely avoiding calling this Pair Programming because of the connotation that comes along with that term. While similar in implementation, our goal is different – we are not concerned with code maintainability, exception handling, usability, etc. – we are worried with getting a correct implementation in the absolute minimum amount of coding time possible while also thinking about upcoming problems in the background.)

When I started programming competitions, I was awful. I had problems with syntax, couldn’t visualize a solution to relatively easy problems until I had been coding for maybe 40-50 minutes. We had programming team practices (via a course called Competitive Programming) once a week, and simply showing up and solving problems eventually made me faster, but still not fast enough.

Then I met my eventual coding partner in crime, Corey. By the time I was a senior, we could solve easy problems fast as a pair. Check out these results from Denison’s 2006 Contest (we were team BW-CD) –problems solved at the 9, 24, 53, 98, 105, and 148 minute marks. I don’t think we were any smarter than team “UsII”, but we had 2 solved by the time they had 1 solved, 3 when they had 2, and 6 when they had 3. Problem C was arguably the only hard problem in the set (modified DFS), and the other teams at the top just didn’t have time to properly tackle it.

Why were we able to execute so fast? Because of our great communication and our willingness to be involved backseat coders.

Luckily, Corey and I were friends and we felt comfortable asking questions, requesting clarifications and, sometimes, telling each other they were just wrong. We also both enjoyed proving the other person wrong so we would both be constantly trying to think of edge cases or counterexamples that would break the other’s code. This is a great practice because the judges have spent many, many hours coming up with edge cases for the exact same purpose.

Because the programming team typically has 3 members and 1 terminal, it’s often a good strategy to have two developers at the computer at the same time. I almost always see the person typing quietly coding away while the other person watches and looks for syntax errors, copy/paste errors, etc. This is not good enough. The person typing has a lot of things going on in their brain. They’ve got their idea of the algorithm in their head. They’re making sure everything is tabbed in and braced correctly. They’re worried about loop bounds… Both team members need to worry about these things, but even more importantly, they both have to have a firm understanding of the algorithm and be on the same page.

Algorithms need to be conveyed using words:

  • “We need a loop to read the input, just make a while loop”
  • “If the input is 0, we quit.”
  • “We need to read in n nodes, so make another loop from 1 to n to read them in.”
  • “Now, we just need to make a recursive method to traverse the loop with a global list of visited nodes… Just call the method here and we’ll implement it in a minute”
  • Etc.

If there’s more than about 30 seconds of silence while two coders are at the computer together, I start to worry. At least one party should be conveying the algorithm in words, calling out syntax errors, asking questions, etc.

If the person not typing has a posture that is less engaged than the typist, I worry. The only excuses to not be leaning forward, reading code, talking about the algorithm are deep thought about potential counterexamples that will invalidate the entire approach and drawing out examples on paper.  Excepting these situations, the absolute minimum amount of communication otherwise is the non-typist saying “Yep, looks good, makes sense,” because even that lets the coder know that they’re both on the same page.

Want to solve the easy problems faster so that you can have more time for the hard problems?

  • Communicate while you type. Explain what you’re doing, walk through the algorithm.
  • Lead the way without a keyboard. Make sure you’re in sync with the coder. Walk through the algorithm, think about counterexamples & edge cases. Draw out example cases.
  • Use phrases like
    • Next, we need to loop through the…” This shows you both understand the overall approach to the algorithm.
    • Did you account for the case where…” You should be thinking of edge cases and counterexamples. Is it going to blow up when n = 2,000,000,000?
    • Why are you doing that?” If you don’t understand something the other types/says, you won’t be able to effectively help at all.
    • It’ll take half the time to code this if you… If you understand what they’re trying to accomplish and see them taking an approach that takes a long time to code or is highly error prone (picture a long list of if/else’s due to bounds checking that could be avoided by adding a buffer row/column to a table), you should step in and dictate the faster solution to them. This only works if every other bullet point has been accounted for and your teammate trusts you.
  • Do NOT use phrases like
    • It’s faster if you write ++i.”
    • You should never write while(true).”
    • You know you can decrease the size of tabs in the editor settings…
    • But you’re wasting like 65 array entries.” (More on this one in my next post…)
    • ” (That’s the sound of you being too passive.)

I realize that I’m making this sound easier than it is.  Well, actually, I do think it’s easy… but it requires practice. The amount of practice necessary really depends on personality type – some developers think they’ll never be the type of person who can effectively communicate ideas about programming in real time… I think those people just haven’t had enough practice or perhaps never had a safe environment in which to try without fear of failure.  I believe this is one of the main benefits students receive by participating in ACM Programming Teams, but most coaches (myself included) struggle with teaching this skill.

Any suggestions on teaching this skill, thoughts on Pair Programming, or other comments are welcome.

This entry was posted in Pair Programming, Programming Contests. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>