Blog Post

Thoughts on Advent of Code

,

Over the past couple of days I’ve posted several times about the Advent of Code Contest and worked my way through the first three puzzles, now I’d like to share some thoughts about how it works and what I’ve learned so far:

  • The site is well done. Simple to use and the xmas tree provides a bit of ‘keep going’ motivation. I also like that, at least so far, each puzzle has a part 2 that builds on the problem (and maybe the solution) from part 1.
  • I like that the puzzles are language agnostic. I used TSQL for the first three because it’s the language I use most and I wanted to see how it would work out, but I will probably switch to Powershell at some point because I need to build muscle memory there.
  • These would make great interview questions. Even if it couldn’t be solved entirely, just talking through the approach the candidate would take would be revealing.
  • You get to decide how elegantly you want to solve the problem. Quick and dirty and unreadable still works if you get the right answer. Note that I’m not recommending that, but part of what you get from doing these is figuring out a way to solve the problem. That’s good for your brain.
  • I do wish that there was a better mechanism for sharing solutions than the subreddit. I like seeing how people solved it.
  • I wonder if we don’t think differently based on the language. I was talking with Steve Jones yesterday about the Santa problem and he asked how I tracked the delivery locations. I used a table with x & y values. He used a dictionary. Same idea, except he used the dictionary to store the unique pairs, while I stored every visit knowing that I could easily derive the pairs later. As a “data guy” I like having the raw, and knowing that there was a part 2 made me reluctant to make my solution too specialized. Note that I’m not saying my solution was better, just a different approach on the storage (and the persistence of the data isn’t that important).
  • It’s easy, maybe too easy, to see all of these as problems to be solved with loops. If you’re not a SQL person, dare to try it as a set based problem! I can also see that at some point it may be unreasonable to use a set based approach just to avoid a loop – we’ll see.
  • We also talked about #4 yesterday (which I haven’t solved yet) that has to do with an MD5 hash. I was thinking about a way to do in the minimum, or at least less than maximum iterations, if I could see any kind of pattern that would let me do something along the lines of a binary search. DBA’s have a deep bias against loops and we talked about using a tally table (a loop of a different stripe). I wasn’t sure, because the tally table would force me to calc the hash for all rows, in a loop I could exit earlier (faster)…in theory.
  • I had fun doing the first three, but what made it more fun was talking through my solution with someone else who had also done it.

I don’t know if I’ll do all of them, but I’ll definitely do some more.

 

 

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating