First, find the song “Dead Pixels in the Sky” by Nigel Stanford. You can find it on his latest album Automatica. Press Play, as it will be a nice 4:30 backdrop while reading this post of 1,100+ words.

If you’re a slow reader — and you become one when participating in Advent of Code, trying to carefully parse all instructions to swat a final (?) bug in your code — continue with “Space Cowboy” by Jamiroquai. At the end of this blog post, it’ll be clear why these songs are so fitting for today.

Positioning an asteroid monitoring station

Today’s Advent of Code challenge was about picking a position in a region of the galaxy with a lot of asteroids. Depending on the number of asteroids in an unobstructed line of sight, an optimal position was to be found.

Upon reading the puzzle description, I realized what kind of Advent of Code challenges I like, and which kinds I initially shy away from.

Apparently, I favor puzzles describing a concrete situation, a situation that I can visualize mentally (or on paper). Puzzles about navigating through real and solid stuff, like rooms, mazes, trees, and forested areas. Challenges about moving physical things, like packages, elves, trees (again) and elevators. Problems on manipulating strings or numbers, stacks, trees (again) and lists.

Positioning addresses, instructions and bugs

That leaves out the kind of problems that I still complete — and need to complete, I say to myself — that are more of the abstract kind. Puzzles in which an imaginary situation or device is described, which needs to be simulated. Things that are harder to make a mental image of. Yes, those assembunny programs, communicating devices, and programmable wrist devices clearly fall into this category.

Fortunately for people loving to write assembly interpreters and debugging their interpreters against test programs, Advent of Code 2019 caters to those desires in a more than sufficient way. We’ve seen the Intcode computer on four separate days already, and the calendar only reads December 10. It’ll be a safe prediction that this one will rear it’s head at least once more.

Especially yesterday’s challenge was tricky, and I saw a couple of colleagues participating in #XebiaAoC venting their frustration early in the morning. Day 9 added a new (and final) instruction to the Intcode computer’s instruction set. Quite uncommon for Advent of Code, the puzzle text was a bit ambiguous on that instruction, and the samples provided did not really address the full capabilities of it.

I only had time to start with the daily puzzle in the evening, and hit a similar bug that many of my colleagues encountered. After analyzing my interpreter, and trying to carefully follow the example test cases, I found myself unable to spot the bug. It was frustrating to apparently have reached the frontier of one’s mental capabilities, at least in a sleepy state.

It was a bit after eleven o’clock that I needed to take our dog for his final round before the night, went outside into the fresh air… and lo and behold suddenly I realized the nature of my bug.

The method is a variant of the common practice of Rubber duck debugging in software engineering. So, for myself, I’m renaming this procedure “Dex the dog debugging” from now on:

Insights are often found /
by describing the problem aloud /
to the family’s hound

Positioning your programming language

A short while ago, I asked colleagues “Which programming language(s) are you typically using for solving Advent of Code puzzles… and why did you pick that language, this year?” The answers are insightful, so I’ll just copy and paste most of them verbatim:

  • Scala, as this the language I am most familiar with. Furthermore, I can reuse some utilities I created last year. My goal is not to learn a new language but to be as fast as possible…”
  • “I’ll be doing AoC with Ruby again, just like previous years. Foremost because this December […] I’ll not have time to adjust to a new language (otherwise I’d be thinking about Go). Secondly because I really like Ruby as a programming language, as it often results in beautiful, concise code, and does not require a lot of mental steps between the solution in my mind and the algorithm in my code.”
  • “I have abandoned Bash this year. Doing a quick-n-dirty solution in Python first because it is an easy language and I want to become more proficient with it. Then I try to convert the solutions to Apache Beam / Google DataFlow, which is also Python.”
  • “I’m using it to learn Python.”
  • “Kotlin, I have had some experience in Kotlin and love it so far. It has better functional language support than Java (another language I use most of time). It also provides some extra functions (compared to Java) which made my life easier and helped me solve puzzles faster.”
  • Python, to practice Python.”
  • Go, because I want to learn more than the ‘build a REST API in Go’.”
  • Kotlin, because I use it at my current project and AoC helps you find those exotic functions I usually don’t use.”
  • Go, because I want to get a better grasp of the language (and get a feeling for how to do TDD with it).”
  • TypeScript, because it contains a lot of helpful functions and the notation is short (and easy to interpret).”
  • Clojure, because I love the language and it really matches my way of thinking (99% of the time). I was thinking of using AoC to learn Rust, but I can’t use Clojure that much so I fell back to it.”
  • Clojure as well, trying to learn it during AoC.”
  • “First time doing AoC. Using Python because it’s the language I’m most familiar with.”
  • “I’m using Go this year to learn go a bit better beyond the trivial stuff. If i was trying to be efficient I’d use Scala.”
  • “I use Go this year for the first time, the previous years I used Java and the first year even Python. Mostly I use the language I’m currently working with and/or most proficient in.”
  • Python, of course! Already got my numpy and networkx imports ready to go. For me it’s about finding the algorithm to solve the challenge, not how to calculate an intersection of sets. Python suits well for that.”
  • Python, because it is my favorite language, and since I don’t program full-time anymore this is a chance to maintain my skill level in at least one language.”

It’s quite nice to see this variety in programming languages and reasons within #XebiaAoC.

Positioning a laser for vaporizing asteroids

“Dead pixels in the sky? A space cowboy? What’s the relevance?” you might ask. Part 2 of today’s challenge immediately clarified why that monitoring station was to be positioned so carefully. The monitoring station is equipped with a giant rotating laser, and all those asteroids needed to be vaporized by hitting them with the laser beam. Remember that a space-themed  shooter arcade game “Asteroids”? Exactly that, but from a fixed position and with non-moving asteroids.

Finally, a concrete challenge, with a situation that I can visualize in order to help wrapping my brain around intermediate problems and possible solutions. I love solving these types of puzzles.