Advent of Code 2022: Summary and lessons learned

#advent of code 2022

Advent of Code 2022 is finished so I thought I will write a summary. It can also serve a summary of year 2022. In short, I am very happy. This was the first year when everyday during the Advent of Code I was checking out and solving tasks everyday. Some proved to be more challenging and it took me couple extra days to solve them, but I guess the goal is to code everyday not to race with solutions.

Another thing is I rediscovered my passion for programming. In the recent years in my careers I was shifting into management and coding less on a daily basis. But solving those puzzles and doing other coding exercises turned out to be really fun.

I just hope I will maintain current level of excitement throughtout the year 2023.

Lessons Learned

  1. Read the description carefully. It may be obvious, but a couple of times I was getting wrong results or my program was running very slowly because I missed some tiny requirement from the description. On Day 19 I missed that you can build just one robot per round and I was exploring way too many cases.
  2. If the naive solution has exponential complexity there must be a way for some optimization to limit the number of solutions to explore. If you look at leaderboard, the more challenging problems were solved still pretty quickly.
  3. Ruby eval can be very useful. You should probably avoid using eval in production code where user input is involved, but this is a very useful feature sometimes. Like when you need to parse puzzle input. You can check my solution for Day 11, Day 13 and Day 21.
  4. Cloning Ruby hash does shallow copy only. This thing bit me multiple times. If you think about it, it is obvious. But when you are actually implementing lots of other stuff it is easy to forget. I heard about the trick to do Marshal.load(Marshal.dump(hash)) which will do deep copy.
  5. Breadth-First Search. I learned about it long time ago, but now had a chance to practice a lot. I used it on Day 12, Day 18 and Day 24.
  6. Taxicab geometry. It was in previous years. This time I had to spend some time on implementing segments intersection point using Taxicab. This one took me a lot of time for a probably simple task.
  7. Modulo can do wonders. Just a interesting observation how storing integers modulo value can speed things up. Check out my solution for Day 11.
  8. You still should know how to implement basic data structures ie. linked lists. Check out my solution for Day 20.
  9. Balanced ternary and balanced quinary. Can’t even spell the latter. Those are numeral systems like binary, but with negative values for single digits. It was pretty interesting to implement conversions for such system. Not sure what are the real world applications. Check out solution for Day 25.
  10. Sometimes it is good to write something on real paper, sketch or build paper model :) It was really hard for me to visualize how your direction should and coordinates should change when moving on a cube. So in the end I did little paper models. Check out Day 22.

Challenging puzzles

  1. Day 15, second part was the first difficult for me. I knew what should I do, but I was really struggling with implenting code for segments intersection. I don’t know, I am not used to do geometry anymore.
  2. Day 16, I think it took me the longest. I wrote the good solution, but forgot one stop condition and it was running forever. I thought I should write another one and was losing time exploring other options. Finally I figured out missing stop condition and it was a success. My mistake was that in example testcase it was possible to open all valves. It had just 6 valves and plenty of time. In the real test case, there were 15 valves and it was not possible to open them all, but my code was still trying to do going into negative minutes.
  3. Day 17, not that difficult but took some time to figure out the pattern and edge cases. I was running the simulator with a lot of printing out and found the correct answer from that. Later I added the code to actually compute it.
  4. Day 19, I had solution that was exploring too many cases because I didn’t read description properly. I ran my code overnight and it found a correct solution. Later I added more optimizations and got it to compute in seconds. It was easier with having the answer.
  5. Day 22, it was hard to imagine moving on cube. I did paper model in the end and it went smooth from that time.


I did separate articles about each puzzle. You can check them all out here.