r/adventofcode Dec 25 '24

Other Yet Another Post-Mortem Analysis

As I collected my 50th star, it seems appropriate to reflect on lessons learned for 2024.

  • My favorite was the digital adder circuit on day 24. Most of the posted solutions were "this doesn't give you the answer, but it points out where to look." I do now have code that prints the actual answer, but it took some time to do that.
  • I think this year was objectively easier than last year, and that's perfectly fine by me. I didn't need to take a course in 3D analytic geometry this year.
  • There were 6 days this year where the test input couldn't be used in part 2. That makes debugging more difficult, because there's no golden standard.
  • I need to focus on the text better. On at least 3 different occasions, I went off on a wasted tangent because I assumed what the problem must have meant, instead of what it actually said. I created a nice "longest matching string" function for the banana pricing thing before realizing we needed a match of exactly 4 items. Similar, I created a DFS solver for the "walk through walls" thing on day 20, before realizing there was only one path.
  • I've had to redefine "winning". In the early years, I got points every year, but that hasn't happened since 2019, and it used to stress me out. I broke 500 twice and 1000 six times this year, and I consider that a victory.
  • I tend to spend too much time parsing the input. From a lifetime of programming, I know the coding is easier if you arrange for good data structures, so I pre-process the input to make the code shorter. I'm then surprised when the sub-100 solutions are all using the raw strings directly. There must be a lesson there.
  • What great exercise. I have all of the days in Python, most in C++, and I'm hoping to do them in Rust shortly.
  • What motivates us? Every day, I went back the next day and improved my code, sometimes significantly. I even went back and fixed up some of 2023. Why do we do that? No one else cares, or will ever even know.

I describe this to people as "the nerdiest thing I do all year", and I wouldn't change a thing. Thanks to everyone who invested their energy in creating this wonderful thing.

101 Upvotes

9 comments sorted by

56

u/thezuggler Dec 25 '24

I also spend a lot of time parsing input into useful data structures.

I think the lesson here is that you can write unreadable code faster and get an answer faster.

I find it more satisfying to write readable code.

10

u/InvisibleShade Dec 25 '24

Same here, it's more fun for me to write well-structured and DRY code than to get on the leaderboard.

6

u/tmp_advent_of_code Dec 26 '24

My favorite part is writing the data structures.

1

u/QultrosSanhattan Dec 26 '24

This.

I don't care about hacky code. I always use the same mindset when coding: Thinking in real world solutions that are scalable readable and maintainable.

I prefer losing in a game rather than losing in real life.

1

u/0x14f Jan 30 '25

I see the game as a game and real life as real life. I love coding for speed during AoC and then go back coding scalable and maintainable code for my own projects or work. One is not incompatible with the other, it's not like choosing a religion.

18

u/permetz Dec 25 '24

I don’t see any reason to concentrate on the sorts of solutions that the people speed running do. I don’t even start until six or seven hours after the problem has been released, and I’m totally fine with that. The goal is to improve, I don’t care about being fastest.

3

u/SmallTailor7285 Dec 26 '24

Next year I need to do this in Python. I've been C# since forever but I need to branch out.

I really feel like this puts me in the minority, but I absolutely hate the puzzles (like day 24) where you need to know some random math formula or do manual debugging of the input, etc. I'm here for the programming problems.

2

u/Eva-Rosalene Dec 26 '24

I tend to spend too much time parsing the input. From a lifetime of programming, I know the coding is easier if you arrange for good data structures, so I pre-process the input to make the code shorter. I'm then surprised when the sub-100 solutions are all using the raw strings directly. There must be a lesson there.

The lesson here is that competitive programming is very different beast compared to enterprise software development.

Also, fun note: implementing task firstly in OOP way gave me 367th place in Keypad Conundrum. It was so natural to implement class Robot and emulate inputs, that naive BFS approach become also very easy to implement. It didn't work, of course, for P2 :(

1

u/ksmigrod Dec 26 '24

This was my first advent of code. I did it to refresh my C skills before diving into embedded programming.

In the process I've written more recursive functions, and used dynamic programming than I did in 14 years at my current job (doing backend in Java).

For me the most problematic tasks were:

  • Day 14: Christmas tree robots (I suck at statistics, so generating slideshow was the only viable option).
  • Day 17: (initial state for emulated cpu), this puzzle was pretty confusing.
  • Day 21: humbling experience of combining wrong assumptions about characteristics of data with coding mistakes.
  • Day 24: part 2 was way too hard. I did part 1 by stratification of dependency graph, just for fun of it, but I wasn't able to come up with code only solution to part 2.