Miguel Ventura's blog : Advent of Code 2020

Another year, another December, another Advent of Code — an advent calendar where each day you get a problem to solve through programming, all wrapped in a surreal Christmas-themed story. @ericwastl does a phenomenal job of creating very varied problems where several types of computer science knowledge can come in handy, but (especially in the age of Google) none are hard requirements to get through the challenges.

There are points for those who finish faster with a public leaderboard to show off your skill. I never competed for time to completion, because my timezone is not ideal (problems are released at 5 AM, when I'm definitely not at the top of my coding game) and because life tends to get in the way of being able to allocate the same time slot every day for the challenges. Not racing for time doesn't mean I don't get a lot of fun. And this year was no exception.

Using fun technology

I write computer code for a living. It's serious business, which means that on the job I often choose boring technology, and you should too. But in AoC you're solving problems with limited scope and you won't have to maintain that code running in customers for years to come. You can chose whatever new technology you heard of yesterday and you can try stuff you have no experience with. Unless you're competing for time (in which case you should use whatever you're most proficient with), it's a great opportunity to gain experience in a new programming language and with new tools and libraries. I've been using the Advent of Code challenges to either learn new programming languages or sharpen my skills in those I use the least.

This year the challenge for me was attempting to solve all problems using purely functional programming with F#. This meant reaching solutions where I didn't mutate any variable, and for that using a functional-friendly but at the same time pragmatic programming langauge. This was the second time I tried solving all problems without mutating a single variable. And this year it felt a lot easier. The only problem where I really felt the need to do mutations was one where the obvious efficient solution for me was using (and mutating) a linked list. I was ready to give up on my goal and started writing a rant for some friends who were also participating. By the time I wrote about it, I remembered an alternative solution1. A great rubber ducking moment.

Learn with everyone's mistakes (including your own)

This year, a few folks at OutSystems also decided to participate and tried their best to keep the daily pace with the challenges. This wasn't the first time it happened. In previous edition, we'd have a whiteboard at the office with the private leaderboard. Due to the COVID situation none of us is at the office now, which strangely made everything better. Here's how it went:

This meant that like the previous year, we still had the private leaderboard to compare our progress. But the discussion threads and the ability to easily see everyone else's code was the most interesting aspect. In programming there's often no "single right answer" and looking at other people's solutions, especially when they were thinking very differently than you is a great way to expand your way of thinking. In fact this was the way I got to know about AoC in the first place — I was browing Peter Norvig's notebooks when I found a reference to AoC and I got hooked since then.

The daily discussion threads were also great. They enabled us to help eachother keep motivated and they provided a great rubber ducking experince.

Wrap-up

This was probably the year I enjoyed AoC the most. I don't think it was the one with the best problems, but it definitely was the one when I had the most fun. The adding of an additional constraint made it more challenging, but the social aspect was the best. A great thank you to Eric Wastl and to all the friends that walked this journey with me. And in case you're curious, you can look up my solutions here.


  1. A linked list can be implemented with a Dictionary/Map where the value for each key is the next node key. So Immutable Maps can be used for an algorithm that would rely in mutations to a linked list as a substitute data structure.