Advent of Code 2024 retrospective

Last month, I once again took part in Advent of Code which is one of my favourite annual, global software developer community activities. After doing it for a couple of years with Python while writing explanations for my solutions, I wanted to expand on that this year.

A couple of days before December started, I got an idea about a digital garden in which I’d share all my notes created for Advent of Code. I booted up Obsidian, started a new vault and set up Quartz with mostly default configuration. Every day, I wrote a piece about my solution and wrote down notes for things I didn’t yet know but wanted to remember. I then published these at my Advent of Code 2024 Digital Garden.

For me, this year’s Advent of Code was less about solving puzzles and writing Python. It was more about writing explanations, teaching Python, showcasing how to get started with blogging as a developer and experimenting with the tooling to build websites out of Obsidian notes.

As I wrote about these solutions and the extra notes, my assumptions were confirmed: this would be a wonderful way for any developer to get started with writing and sharing and building a technical blog. Every day, someone provides you a topic to talk about and once you solve the puzzle, you have code snippets to share and explain. And during the way, you’re required to learn new things. From them, you have even more topics to write about.

Advent of Code 2024

I’ve solved puzzles from all the 10 years of Advent of Code - some of them after their original years. I think Eric, the creator of Advent of Code has found a great balance in the difficulty curve this year. I solved some of the 2016 puzzles in parallel with this year’s puzzles and those were tough from the beginning.

This time, the curve was more mellow, giving people new to Advent of Code, puzzle solving and programming a more pleasant start. The difficulty curve is never smooth or linear in its trend for every individual. The difficulty of a single puzzle depends on what specifics you know or have previously experienced with.

For me, this year the pathfinding puzzles were easier than they have been in the past years thanks to good notes and years of practice and help from fellow code adventers in my communities. On the other hand, puzzles that require specific math knowledge like spotting a right formula or knowing how to apply them to a problem at hand are very hard for me even if the puzzle itself after that would be somewhat trivial.

I finished the year with 37 stars. I missed the second half of Day 16. I knew on conceptual level what I needed to do but wasn’t able to adjust my pathfinding solution to account for multiple paths. It’s where my skills hit the ceiling right now: I’ve learned how to implement and reason with the pseudocode example from Wikipedia for various pathfinding algorithms but the ability to change and adjust them to different needs is beyond my capabilities this year.

Days 20-25 I outright skipped because I shifted my focus from the Christmas story to the actual Christmas preparations. I’m very glad I made that choice this year. Even if I could have solved some of those puzzles, I know they would have taken a major chunk out of my day and led me to stressing out about Christmas shopping and prep.

All in all, I had a lovely time with it. We had active groups in various communities with daily discussions. We helped each other learn new things and find ways to solve these puzzles. With our local Python community archipylago, we hosted an evening event on the 12th to get together and solve puzzles. It was the first time I did a in-person event for Advent of Code and solving the puzzles together was so much fun. I can highly recommend doing some pair programming with a colleague or friend next year.

Learning from others

As always, my favourite part is the community. A special shoutout this year to our Koodiklinikka group for in-depth discussions and always helpful atmosphere.

Elsewhere in the web I enjoyed reading and discussing solutions by

• Saaste (in Finnish, with Go)
• Antti Laaksonen (in Finnish, QBasic)
• Neil Smith (English, Haskell)
• Abizer Nasir (English, Swift)
• Rob Simmonds (English, Dusa)
• Adrien Foucart (English, Python)
• Mina (English, Perl)

Thoughts on the digital garden experiment

Looking back now, I’m so glad I started experimenting with this “publish your notes” idea with a small, isolated example. I got to experiment safely and learned a thing or two that I can bring with me for my future digital gardens.

All of these three are possible issues that all lead to my notes becoming bit less useful for me at the tradeoff of making them more useful to the world. It’s not purely a negative tradeoff although I do want to find ways to minimise its impact over time.

Link rot

The first thing I noticed straight away is the challenges with link rot. Link rot refers to the phenomenom that happens when URLs for a site change, causing existing links elsewhere in the web to start pointing to 404 pages, causing resources to become less useful.

Tim Berners-Lee wrote about the perils of link rot back in the 1990s.

This is a problem in any kind of web page if developers don’t care enough but with a digital garden, I feel it becomes even bigger challenge. What I want my digital garden to be is a subset of my actual notes. Not a publication but raw and daily usable notes.

The thing with notes is that they change all the time. You merge, you expand, you split off, you rephrase. All of these have the danger of introducing link rot.

There are a couple of options for how to tackle it and all of them have tradeoffs:

1. Focus on keeping URLs stable by not changing notes → leads to less flexible note system and adds layers of unwelcome complexity and clunkiness to actually writing and working on notes.
2. Build a redirect system that keeps track of every published URL and then keeps track of where they have moved. This can be automised to some extend but also requires manual labour to keep up to date. Over time the redirect rules can grow massive.
3. Let it rot. Focus on serving as an effective note system rather than a sustainable web project.

Copyright question: what can be published

In my private, personal notes, I capture a lot of the content on different pieces I read or watch. I copy images, take screenshots, capture code examples and so on. They are all real valuable in the notes.

However, once I start publishing these notes, I need to take different things into consideration. I need to be careful with the ethical and legal rights for these pieces. Once again, this leads to a crossroad of decisions: how do I organise my notes if I want to keep publishing my actual notes without sacrificing the usefulness of them as my notes.

I’m looking for a way to mark parts of my notes as private parts.

Can’t cross the barrier between private and public

The third main cause of trouble is that publishing a subset of notes creates an uncrossable barrier between the private parts and the public parts. I cannot reference anything that is in the private side from any of the notes that is on the public side.

Once again, this can lead to the actual notes becoming less useful as I need to artificially keep some of my notes limited.

Introducing Garden of Learning

I took these learnings and the excitement the experiment sparked in me and created Garden of Learning. It’s a public subset of my personal notes and to kick it off, I reorganised the first couple of hundred notes from my notes system into here and I’ll continue doing so over time. Due to the reasons above, I need to do a bit of extra work at the beginning to move my old ones into the new system but over time, new notes will simply gain a spot in either the private or public side and be automatically published to the garden.