But I have this little note at the top of
/** * TODO: * - Refactor to be prettier. */
It's almost the last TODO left before the game is complete. And I'm not going to do it. The game works already, so why should I spend precious hours rebuilding it all just in case one day a Haskell-loving purist* scoffs at my ineptitude? This is not the kind of thing I'm going to come back to in a few months unable to remember how to fix a mission-critical bug. Time to push it out the door.
I might write another, much more complicated game in JS+HTML5 after this. After all, there's at least one contest coming up. Having written a game in JS now, I'm sure the next one will be much better architecturally. But even the best programmers sometimes need to take a step back and just write something fast and dirty sometimes. It's hard not to get caught up in doing things right instead of just getting things done.
* Don't get me wrong -- I have nothing against Haskell-loving purists. I learned OCaml from Benjamin Pierce and later helped Stephanie Weirich teach it. In programming projects I usually insist on carefully following coding standards and writing thoughtful, intuitive APIs because I believe in laziness, impatience, and hubris. But over-engineering doesn't help anyone. Users don't care why or how it works, they only care that it works; and especially if your users are not developers, there comes a time when the effort of making code pretty is just not worth the reward.