alt text

“It’s fine, I’ll just implement a quick DFS and call it a day.” — Me, 30 minutes before discovering that Day 16 required bidirectional search and completely restructuring my approach for the third time.

The Setup: Another July Adventure

I have a confession: I started Advent of Code 2024 in late July, just like I did with AOC 2023 (which I tackled in August 2024). There’s something liberating about approaching these puzzles without the December time pressure, when the rest of the world is frantically debugging race conditions while battling holiday shopping deadlines.

This marked my second year using Rust for competitive programming, and honestly? The difference was night and day. In 2023, I spent most of my time fighting the borrow checker and questioning my life choices even with lots of “cheating” (browsing around Reddit forums, blogs, YouTubes, …). In 2024, I actually got to focus on the algorithms. Whether that says more about Rust’s learning curve or my own stubborn persistence is… debatable.

But here’s what I know for sure: I ended up with all 50 stars, about 6,500 lines of Rust code, and a much better understanding of why some programmers get genuinely excited about graph theory. Also, a healthy respect for anyone who attempts Day 24 (circuit analysis) without a computer science background.

The Brutal Honesty: Lines of Code by Complexity

Let me start with the numbers, because nothing humbles you quite like seeing how much code it took to solve “simple” puzzles:

The Warm-Up Phase (Days 1-5): 80-120 lines each

  • Day 1: Parsing and basic algorithms
  • Day 3: Regex hell (why do I always forget escape characters?)
  • Day 5: Print queue ordering that looked easy until part 2

These felt like stretching before a marathon. I was optimistic. I was naive.

The Building Confidence Phase (Days 6-10): 120-200 lines each

  • Day 6: Guard simulation with cycle detection
  • Day 8: Antenna positioning that taught me GCD can solve geometry problems
  • Day 10: Trailhead scoring that made me appreciate BFS all over again

Still manageable. I started thinking, “Maybe I’ve actually gotten good at this.”

The Reality Check Phase (Days 11-15): 200-300 lines each

  • Day 11: Stone splitting with memoization (thank you, CS coursework)
  • Day 12: Garden regions where I learned corners equal sides (geometric eureka moment)
  • Day 15: Warehouse simulation that broke my brain with wide boxes

This is where things got real. Memoization wasn’t just useful – it was mandatory. And I started writing documentation for nontrivial logics used in my own code.

The “What Have I Done” Phase (Days 16-20): 300-400+ lines each

  • Day 16: Maze pathfinding that demanded bidirectional Dijkstra
  • Day 17: Reverse engineering a 3-bit computer (still proud of this one)
  • Day 20: Race condition analysis with 20-picosecond cheats

My imposter syndrome kicked in hard here. These weren’t just puzzles – they were legitimate computer science problems that required real algorithmic sophistication.

The Summit Attempt (Days 21-25): 250-450 lines each

  • Day 21: Recursive keypad control (25 levels of indirection!)
  • Day 23: Maximum clique problems (hello, NP-completeness)
  • Day 24: Circuit analysis that made me question everything (450+ lines of pain)

Day 24 nearly broke me. Binary adder analysis, structural pattern recognition, and debugging that made me take actual coffee breaks just to think clearly. If you completed Day 24 without looking up binary arithmetic, or did not rely on context-dependent heuristics but did come up with generalizable solution, you have my respect.

The Learning Curve: From Survival to Optimization

2023: Fighting for My Life

Looking back at my AOC 2023 experience, it was basically:

  • 70% wrestling with Rust syntax
  • 20% fighting the borrow checker
  • 10% actually solving problems

Every solution was a small miracle. I’d get something working and immediately commit it to Git before the compiler could change its mind. My code was littered with .clone() calls like a desperate person throwing money at a problem until it goes away.

Here’s what a typical 2023 debugging session looked like:

1
2
3
4

// My 2023 approach to Rust ownership
let data = expensive_computation(&input).clone();
let result = process_data(data.clone()).clone();
return result.clone(); // Just to be safe

I was basically writing Python with extra steps and a really judgmental compiler.

2024: Actually Understanding What I Was Doing

Fast forward to 2024, and my internal monologue had shifted from “How do I make this compile?” to “Is there more elegant or beautiful ways to express this algorithm in Rust?”

The year of CS coursework between attempts made all the difference. Problems that would have stumped me in 2023 became pattern recognition exercises:

  • “This looks like a shortest path problem” → Dijkstra
  • “This has overlapping subproblems” → Dynamic programming
  • “This needs to track all optimal paths” → Bidirectional search
  • “This has exponential complexity” → Time to get creative with memoization

Furthermore, low level training (computer architecture, OS, etc.) helped me better understand compiler error messages and root causes of panic situations. In other words, my Rust literacy has been improved as I learn more CS fundamentals.

Here’s the thing though – I didn’t become a better programmer overnight. I just finally had the algorithmic vocabulary to match Rust’s expressiveness.

Where Rust Actually Shined (And Where It Didn’t)

The Wins: Pattern Matching Paradise

Rust’s match expressions turned complex state management into poetry. Day 15’s warehouse simulation became elegant with enum-based cell types:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

enum Cell {
    Wall,
    Box,
    BoxLeft,  // For part 2's wide boxes
    BoxRight,
    Robot,
    Empty,
}

// Clean state transitions
match self.get_cell(next_pos) {
    Cell::Wall => return, // Can't move
    Cell::Empty => self.move_robot_to(next_pos),
    Cell::Box => self.try_push_simple_boxes(direction),
    Cell::BoxLeft | Cell::BoxRight => self.try_push_wide_boxes(direction),
}

This kind of exhaustive pattern matching caught so many edge cases that would have been runtime surprises in other languages.

Iterator Chains: Functional Programming Joy

Day 1’s similarity score calculation became a one-liner that actually reads like English:

1
2
3
4

left_list
    .iter()
    .map(|&num| num * right_counts.get(&num).unwrap_or(&0))
    .sum()

Coming from Python’s list comprehensions, Rust’s iterator chains felt like a natural evolution—functional programming with zero-cost abstractions.

The Struggles: String Handling and Borrowing Across Async

Not everything was smooth sailing. Day 3’s regex parsing reminded me why people complain about Rust’s string handling:

1
2
3
4
5
6
7
8
9

// More verbose than it should be
for captures in regex.captures_iter(input) {
    let full_match = &captures[0]; // Careful with borrowing here
    match full_match {
        "do()" => enabled = true,
        "don't()" => enabled = false,
        _ => { /* Complex extraction logic */ }
    }
}

And when I tried to implement parallel processing for Day 14’s robot simulation, the borrow checker had opinions about my life choices that took an entire evening to resolve.

The Computer Science Education Dividend

The biggest difference between 2023 and 2024 wasn’t only Rust fluency – it was also algorithmic maturity. A year of formal CS coursework fundamentally changed how I approached problems.

Graph Theory Everywhere

What used to look like mysterious grid traversals revealed themselves as textbook graph problems:

  • Day 16: “Oh, this is just Dijkstra on a state space where direction matters”
  • Day 18: “Binary search to find when the path gets blocked”
  • Day 20: “Find all positions on the shortest path, then test cheats”

Dynamic Programming Recognition

The memoization pattern became second nature:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// Day 21: Recursive keypad control with depth-based caching
fn min_sequence_length(
    sequence: &str,
    depth: usize,
    memo: &mut HashMap<(String, usize), usize>
) -> usize {
    // Check cache first
    if let Some(&cached) = memo.get(&(sequence.to_string(), depth)) {
        return cached;
    }
    
    // Compute and cache result
    let result = /* complex recursive computation */;
    memo.insert((sequence.to_string(), depth), result);
    result
}

Without formal DP training, I would have attempted brute force and given up when it timed out.

Complexity Analysis Before Coding

The most valuable skill wasn’t any specific algorithm – it was learning to analyze complexity before implementing:

  • Day 23: “Maximum clique is NP-complete, need Bron-Kerbosch algorithm”
  • Day 17: “Brute force is infeasible, work backwards from desired output”
  • Day 21: “25 levels of recursion need aggressive memoization”

This prevented countless hours of implementing solutions that were doomed from the start.

The Standout Moments: When Algorithms Clicked

Day 12: The Geometric Insight

Day 12’s garden fencing problem seemed impossible until the breakthrough: number of sides equals number of corners. Instead of tracking fence segments, count corner configurations:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

fn count_corners(&self, point: Point) -> usize {
  let corner_checks = [
    ((-1, 0), (0, -1), (-1, -1)), // Top-left corner
    ((-1, 0), (0, 1), (-1, 1)),   // Top-right corner
    // More corners...
  ];
  
  corner_checks
  .iter()
  .filter(|&&(side1, side2, diag)| {
    let side1_same = self.is_same_region(point, side1);
    let side2_same = self.is_same_region(point, side2);
    let diag_same = self.is_same_region(point, diag);
    
    // Corner exists if both sides different
    // OR both same but diagonal different
    (!side1_same && !side2_same)
    || (side1_same && side2_same && !diag_same)
  })
  .count()
}

The moment this clicked, what seemed like an impossible counting problem became elegant geometry. Pure algorithmic joy.

Day 17: Working Backwards Through 3-Bit Logic

Day 17’s “quine” challenge demanded reverse engineering: find input that makes a program output itself. The breakthrough was working backwards from the desired output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

fn find_quine_value(&self, prog: &[u8]) -> Result<i128> {
  let mut frontier: HashSet<i128> = [0].into_iter().collect();
  
  // Work backwards through program digits
  for &required_digit in prog.iter().rev() {
    let mut next_frontier = HashSet::new();
    
    for &next_a in &frontier {
      // Try all 3-bit extensions (A typically divides by 8)
      for r in 0..8 {
        let candidate_a = next_a * 8 + r;
        if self.produces_digit(candidate_a, required_digit)? {
          next_frontier.insert(candidate_a);
        }
      }
    }
    frontier = next_frontier;
  }
  
  Ok(*frontier.iter().min().unwrap())
}

This perspective shift—from “what output does this input produce?” to “what inputs could produce this output?"—felt like genuine problem-solving insight.

Day 24: The Circuit Analysis Marathon

Day 24 nearly defeated me. Binary adder circuit analysis that required understanding:

  • How full adders combine to create multi-bit arithmetic
  • Structural patterns that indicate incorrect wiring
  • Rule engines for validating circuit topology

The solution involved zero test cases and pure logical reasoning about circuit structure. It was the kind of problem that separates casual programmers from people who think in systems.

What I’d Do Differently: Lessons for Next Time

Better Testing Discipline

My solutions relied heavily on stdout logging, which worked for small problems but became unwieldy for complex state machines like Day 15’s warehouse simulation. Unit tests should be more proactively considered.

Performance Profiling

I never systematically profiled my solutions. Understanding which optimizations actually matter versus premature optimization would have been educational.

Alternative Approaches

Once I found working solutions, I rarely explored different algorithmic approaches. Day 7’s operator enumeration could have been solved recursively instead of with base conversion. Likewise, there might be some missed learning opportunity.

The AOC vs LeetCode Philosophy

Here’s why I find AOC more engaging than traditional competitive programming: narrative context makes algorithmic thinking feel like collaborative storytelling.

You’re not just “finding shortest paths in weighted graphs”—you’re helping a reindeer navigate corrupted memory while bytes fall from the sky. You’re not implementing graph algorithms—you’re analyzing LAN party connections to find the largest clique of interconnected computers.

This storytelling transforms problem-solving from mechanical pattern matching into creative engagement. Each puzzle feels like a mini-adventure rather than a technical interview question.

The delayed timeline (starting in July) actually worked well. Real-time participation offers community energy, but delayed solving allows for more thoughtful reflection and cleaner implementations. Plus, no pressure to optimize for leaderboard times—I could focus on learning.

Looking Ahead: AOC 2025 Plans

The Language Question

I still love Rust’s elegant style. But given AOC is great way to learn a new language, for AOC 2025, tempting to several options:

  • Stick with Rust: I may practice more advanced Rust
  • Try something new: Zig, Gleam, Elixir, or even Haskell

The choice depends on learning goals. Rust taught me to think in terms of resource ownership and safety guarantees along with what multi-paradigm languages can offer. I am now curious what mental models would other languages may develop.

Technical Ambitions

  • Visualization: Animated solutions for grid-based problems
  • Parallelization: Identify problems that benefit from concurrency
  • Alternative Paradigms: Compare functional vs imperative approaches
  • Performance Analysis: Systematic profiling and optimization

The Honest Assessment

Was the learning curve worth it? Absolutely. The progression from 2023’s survival mode to 2024’s entertaining mode represents genuine algorithmic growth.

Could I have solved these faster in Python? Probably, but I wouldn’t have learned as much about systems thinking, resource management, and performance consciousness.

Will I choose Rust for AOC 2025? Still deciding. Part of me wants to write more Rusty codes. Part of me thinks of a whole new challenge.

The most valuable insight: AOC success comes from pattern recognition and algorithmic toolkit expansion, not just implementation skill. Rust provided an excellent medium for exploring these concepts, but the real growth was in problem decomposition and solution design.

Final Thoughts: The Journey Continues

Completing AOC 2024 represents more than puzzle-solving achievement – it demonstrates the compound effect of consistent learning. The computer science education, Rust experience, and algorithmic practice combined into something qualitatively different from the sum of its parts.

My 2023 self would be amazed at the complexity I can now tackle logically. My 2025 self will probably look back at this code and wonder what I was thinking. That’s the nature of growth – the horizon keeps moving.

I can recommend anyone considering their own AOC journey. Simply starting where you are, with whatever language you know, the puzzles will teach you what you need to learn. You will end up with lots of valuable lessons.

My AOC2024 Rust solutions can be found in my Github Repository

Also visit the Advent of Code 2024 page!