My primary goal is to create an elegant Racket solution for each day’s puzzle that is clear, commented and tested. For some of the days, I may also create variants that emphasize performance or conciseness.
Index of Solutions
- Day 0 - Preparation
- Day 1 - Calorie Counting
- Day 2 - Rock Paper Scissors
- Day 3 - Rucksack Reorganization
- Day 4 - Camp Cleanup
- Day 5 - Supply Stacks
- Day 6 - Tuning Trouble
I like the idea of developing Advent of Code solutions using a notebook for the development process, and to allow a more complete explanation of the solution. For those unfamiliar with Advent of Code, each day has two parts, and the second part is not explained until a correct solution to the first part is submitted.
Using a notebook, I’ll show how I developed the solution to part 1 prior to any knowledge of part 2, and then the changes I made to solve part 2, which will hopefully be able to make use of some of the effort for part 1.
The skill to develop code in such a way that it can be more easily modified, as requirements change, is a super important one for a professional software developer, and it’s a skill I still need to improve after forty years of experience! Granted, the way requirements change in Advent of Code is often contrived, but there is usually something to learn in this regard.
UPDATE: - after doing a few days of blogging, I no longer like the idea of showing Part 1 in its original form, then showing Part 2, and then optionally having a Refactor section. I think it’s better for me to wait until I have a refactored solution, and then walk through its development. Although sometimes there is real world value in adapting Part 2 to what was already created in Part 1, I now feel like this is too minimal to be worth the extra blogging effort. So, starting with Day 6, I’ll be using this new process.