Non-code

IPSC 2014 Postmortem

I decided to give the Internet Problem Solving Contest (IPSC) a go this year, with a couple of friends. I've done it in the past and enjoyed it. I like how it only eats a few hours one day and I like how the variety in the problems they give you keeps things interesting.

That said, my performance in the IPSC this year is probably best described as, "Three strikes and you're out!" I did terrible.

I solved one very simple problem. I spent the rest of the contest chasing after a much harder challenge that I couldn't complete in the time allowed.

The worst part is that I made some silly mistakes that I've learned to avoid in the past. As penance, I offer up this article, mainly as a reminder to myself, but hopefully also as a tool that could save others from some of my folly.

Let's start with a simple mistake I made…

Not All Problems are Programming Problems

The IPSC does a great job each year of reminding us that some problems are trivial to solve without programming. It's a good thing they do too, because I seem to need a lot of reminding.

A great example of that in this year's contest was the problem that had you listening to sound files. The goal was to get a simple number out of what you heard. In the easier case, a digitized voice is reading ones and zeros for the listener to transcribe.

While you could solve this problem with programming, that's a lot of work. You would need to process the sound data and search for patterns.

Of course, the obvious non-programming solution also has problems. You can just listen to the file, writing down what you hear. But the file goes on for almost 15 minutes and I don't trust my ability to maintain focus and accuracy for that long. It's too error prone and takes too long.

What I really wanted to be able to do was to read the sound. Sadly, I didn't realize until after the contest that I could do exactly that. See for yourself:

That's right, open the sound file in most any sound editor and it will show you a graphical representation of what you are hearing. You can play it for a few seconds to spot the shape of the ones and zeros, then stop the sound and literally read the number out of what you see.

I'm super sad that I forgot this because Mandy Moore talks about how she can spot an, "Um," visually, while editing the Ruby Rogues podcast. I knew better.

The point I want to remember here is that I should be using every tool in my arsenal, not just programming, to solve problems.

Quitting is a Valid Move

As I said earlier, I blew most of my problem solving time on a problem that was obviously too much for me. I knew this about an hour into working on it. But I have this problem: I can't quit. This is a disease. Please don't be like me.

I'll give a non-IPSC example to drive this point home. I've been working on some code that displays a grid of images. Items in this grid have some connections drawn between them and other little images drawn around them. These extras kind of break the grid concept, since they can be in multiple cells.

Now I had to write some code to select these cell-spanning extras. This proved pretty challenging, again because of the complexities of the grid they are in. The code got hard. I kept hacking. It got harder. I pushed harder.

My problem, in both of these situations is the same: I keep telling myself that I'll get it. The worst part is that I'm right. I will eventually break through and land on a solution.

However, and this is the super critical realization for me, that's totally not the point!

I blew about four hours in that contest chasing a problem that I knew was hard. I've blown about two weeks of free time banging my head against this grid selection code. Even if I solved them both right then, I lost.

Let's go back to thinking about that grid problem. I figured out that there are nine special cases that I need to solve. Then I started attacking them. I had six handled at last count. While I can probably get the current approach working, eventually, I don't want to maintain that code! What am I going to do when the first bug report comes in? Pause for three weeks to get back into this code enough to debug the issue? Fail.

The contest is the same. Even if I had scored the solution before the buzzer (which I did not), I would have still been creamed by anyone who went after two or more easier challenges. Their tasks would have been simpler and more rewarding. I was pushing through the pain for less gain. That's just silly.

It's far better to quit.

I've had plenty of time now to re-architect the grid problem to remove the grid itself, which clearly doesn't fit, in favor of a better abstraction. In the contest, I could have quit when I noticed the depth of the problem and still spent three hours solving other problems.

It's so important to learn the value of quitting.

Teamwork: It's a Thing

If I had been smart enough to give myself back all that time I wasted, I sure could have made better use of it. One way I could have done that would have been to remember that I was on a team.

The three of us just picked problems and worked pretty much in isolation. While that can be a valid approach, it may not be ideal in all cases.

I've already mentioned that I got hung up on a problem, but my teammates did as well. One spent time trying to work out all of possible scenarios for a simple game while the other was building a crossword solver.

I'm not sure if I could have helped with either case. The game may have been mostly about getting your head around how it works and adding another head to fill may not have made that any easier. Then again, talking out ideas may have.

The crossword didn't look too tough overall, it just had a fair bit of busy work in it. You had to build handlers for each of the clue types. I likely could have contributed there, just by offering to handle some of those types.

But here's the real kicker: I never asked!

Talk about a rookie mistake. How hard is it to say, "I'm clearly spinning my wheels over here, is there anything I could do that would help you?"

Lessons learned… again… I hope…