This content originally appeared on dbushell.com and was authored by dbushell.com
Advent of Code is an annual advent calendar full of fun festive themed programming puzzles. Over my winter break I had a great time solving all puzzles for AoC 2024.
This was my first year participating in AoC. It was such a fun experience I’ve gone back to previous events and started solving from 2015 onwards. I’ve got 11 months to catch up on the previous 10 years. I want all 500 stars before AoC 2025!
TypeScript has been my main hand weapon but I’ve started solving a few puzzles in Zig — I’m diggin’ Zig. I publish all my Advent of Code solutions on GitHub. In respect to the copyright rules you’ll need to visit adventofcode.com to get the context.
If you’re curious how Advent of Code works I’ve written a spoiler free guide below:
Puzzle Format
AoC puzzles start with a colourful story and setup. Think of elves playing a game of pass the parcel with unusual rules, for example. You’re assigned a puzzle input that contains the game parameters. You’re then asked for an answer to a question such as: what is the winnings elf’s position after 10 rounds?
The idea of AoC is to code a program to solve the puzzle. Inputs can vary from person to person, so your answer may not be my answer, but a good solution would technically work for all inputs. There is a new puzzle every day from the 1st to 25th of December.
Reading comprehension plays a big role in AoC. Are the elves numbers 0 to 9, or 1 to 10? Is a particular number inclusive, or exclusive? Off-by-one errors are a classic mistake. The AoC author achieves a good balance between appearing vague yet providing all the information. Only once have I felt a puzzle was poorly worded to it’s detriment.
So how are Advent of Code puzzles solved?
Parsing Input
The first step to solving any AoC puzzle is parsing the input.txt provided. Sometimes that is a single integer. More often it involves reading lines and extracting values with regular expressions or string functions. Dynamic languages like JavaScript are great for this.
Some people prefer to parse and solve in one pass. I like to get my data and types nicely validated first. My approach leads to more boilerplate code but I’ve yet to fail a puzzle due to a parsing error. Bad parsing would be a nightmare to debug since you can write the correct solution and still get the wrong answer.
Each day’s puzzle rewards two stars.
Star 1
Once parsed it’s time to programmatically simulate the scenario described. If elves are playing a game this might involve a for loop, some kind of circular array to track positions, a map of scores, etc. The outcome is often enough to answer part one of the puzzle and gain a star.
For puzzles earlier in the month — they get progressively more difficult towards the 25th — simply following the instructions to the letter leads to the correct answer. Later puzzles will require more thought. For example, they might require special ordering of inputs in a way that the rules can be applied.
Star 2
The second star is much harder to earn. It challenges your understanding of the puzzle. Using the elf game example, a common theme for part two is a question like: what is the outcome after one billion rounds?
Often the solution can be brute forced. But that’s no fun and many puzzles are designed in a way to resist that approach. To find a proper solution you must look beyond the creative setup. There are no elves, only numbers and patterns! What is actually happening and how can you reach an answer without running the entire simulation? What values can be skipped, ignored, cached? What order of operations avoids unnecessary work?
Coding Practices
As mentioned, getting my elves in order by parsing first with strict types has helped me avoid errors. However, this can be a double-edged sword. Over-engineering how data is represented can lead to CPU and memory bottlenecks. Hitting the bounds of a JavaScript Array or Map is a surefire sign that something is wrong. Often I’ll realise that much of the data is superfluous in calculating the actual answer. When optimising a solution for star two it’s not uncommon to see that the majority of code for star one was pure overhead.
I’ve found liberal use of assertions in my code immensely helpful. I find it vital to know that my code is doing that I think it’s doing. I’ll pre-emptively add assertions if I suspect there’s a value or condition that should be unreachable.
All puzzles include examples, so writing test cases is possible. The examples are ingeniously engineered to avoid edge cases that appear in the real puzzle input. You can use this to your advantage by looking out for such opportunities to trick you. Are the examples provided using the same logic, or are there subtle differences easy to miss? Assumptions will be punished so read carefully.
Reviewing the puzzle input and logging data along the way is crucial. If you only attempt to output a final answer you’ll miss rather blatant clues.
“Cheating”
Out of all the puzzles I’ve solved to date I’ve only outright cheated on a couple. Those involved math concepts that I was entirely oblivious to and never would have gotten near. I at least attempted to understand the solution after cheating! A handful more I looked for minor tips on the AoC Reddit to ensure I was on the right track.
The puzzle for 2024 day 21 is notoriously tricky. The setup involves a line of 25 robots controlling each other. I understood the problem, I knew theoretically how to solve it, but the implementation took me three days to get right. By the time I was done I’d studied many other solutions. Despite not earning the star entirely of my own accord, it was still one of the most rewarding to achieve.
Final Thoughts
Personally I learn by doing. That means actually coding and not just reading documentation. If I’m not writing code I learn nothing. I’ve found AoC puzzles to be perfect little projects for learning Zig. Be aware of Zig optimisation modes. The zig run command is debug by default and potentially quite slow.
If you enjoy coding and you’ve an hour to spare, jump into Advent of Code — there’s no time limit; start whenever. I’ll continue my journey throughout this year in an effort to earn all 500 previous stars before AoC 2025 begins.
This content originally appeared on dbushell.com and was authored by dbushell.com
dbushell.com | Sciencx (2025-01-16T10:00:00+00:00) Advent of Code. Retrieved from https://www.scien.cx/2025/01/16/advent-of-code/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.