[joelgrus]

Yeah, I made it about 5 days in this year and then quit because I wasn't having fun.

Too many of the problems had the structure:

* here's Part A * submit solution for Part A * OK, now here's Part B * Part B is just different enough that you have to do a not-fun refactoring of your Part A code (that wouldn't be necessary if you'd just been asked to also design for Part B up front)

It was too much like working with an awful PM who can't decide what they want, and it mostly just made me angry.

[steveklabnik]

I didn't get that far either, as I got too busy, but that's the part I liked the most about it: did I write my code well enough for part A that I didn't need to do a lot of work for part B? What could I have done differently to make the code resilient to requirements changes?

[tptacek]

One way to look at it is that the part-2 problems are un-fun retreads of the part-1 problem.

The other (better, I think!) way of looking at it is that the part-2 problems are incentive for you to think carefully about your part-1 solution, so that it generalizes.

Norvig's keypad is a perfect example. Norvig's solution of a sentinel character generalizes, as would a solution based on a simple graph structure. But I plowed into it with a flat array of integers and the modulo operator, and had to rewrite for part-2; my solution was, in the context of the contest, inferior to Norvig's.

[justinhj]

I made a graph and it adapted nicely to part 2. An advantage of the graph is that it would have handled the keypad becoming 3 dimensional or some other change that stopped it working as a simple grid. A big disadvantage is I made several errors while building the graph in both parts which took a while to track down.