Advent of Code 2024 two week recap

Published

How are you progressing through Advent of Code 2024? If you're like me, the ramp up in difficulty over time has meant that other side projects (like blogging here) have fallen off. For the past two weeks, I have tried to prioritize the coding problems from Advent of Code over blogging and other learning.

I find that the style of problems in Advent of Code are totally different from my day to day work as a full stack developer. They engage a different part of my brain than moving the "Fix the shadow on the sign-up form" ticket through the Jira swimlanes.

At first, I found the problems easy enough that I would try to write my problem solving strategy and blog about it the same day. This lasted for the first three days (1, 2, 3). I'm stoked I was able to get those blogs out while also solving the code. By the fourth and fifth days, it was clear that there wasn't going to be extra time to write the blog posts after working a day job, doing the Advent of Code puzzle, and keeping all the other balls in the air.

What makes Advent of Code so difficult?

Writing loops manually isn't necessary for me day-to-day

Depending on the problem space you work in, you might never actually have to write a for loop "the hard way". As a full stack developer, I'm spoiled for choice when it comes to JavaScript array methods that add syntactic sugar to the often bug-prone act of interacting with iterative structures manually.

I spend a lot of time in React apps where I'm ingesting data from an API or accepting user data and pushing it into arrays. In JavaScript, arrays are dynamically sized. Usually, you don't even care about the length of the array until you're deciding what happens in the frontend view when you have zero items or when you need to paginate items.

I don't remember that anything outside of my usual problem space exists

Similarly to writing loops by hand, I almost never have to do division and worry about a remainder. The modulo operator is awesome, but I almost never have a use for the poor guy in my CRUD apps.

So much of what I do can be boiled down to "fancy looking web form". The first time I wrote a bitwise operation was also the last time.

Right now, when humans are still mostly responsible for writing the code that does the thing, we naturally develop areas of expertise. I forget 90% of the surface area of JavaScript until I stub my toe on it and have to google what it is.

Writing performant code isn't what pays my bills

I also don't have to write code where performance really matters. Being "performant" for me means minimizing frontend bundle sizes, pruning dead code, avoiding waterfall loading of assets. This is stuff that makes an app feel snappy, but it ultimately doesn't matter to users if they can suffer through your garbage to get a carrot at the end.

I'm never down in the silicon guts of the machine writing kernel code. I should not be trusted to anything but the simplest stored procedures in SQL. I can do it, but I'm really glad I don't have to.

I'm spoiled, is what I'm getting at.

When I'm writing code to solve Advent of Code or Leetcode problems, I'm going brute force and I'm moving on the minute the test passes. This works great until it doesn't.

What happens when part 2 of the problem pops up, and it's explicitly designed to deal with an amount of loop iterations that will overwhelm a brute force solution? Or you have to count above the maximum integer size in JavaScript and get into BigInt territory?

It's at these points that I need an adult.

I still find the thing valuable

I think it's a useful exercise to get comfortable with the stuff you don't have to do everyday. This builds personal resilience, and gives you insight into what your teammates do.

I'm going to keep cracking away at Advent of Code. I would love to get all the stars. Even though I won't always be happy about it at the time, I will feel better that I did after the fact.