[matsemann]

There's a graph here of the "hardness" of each day/task, based on how long the 100th place on the leaderboard used. https://aoc.xhyrom.dev/

So it's not linear, and also based on your own knowledge. So perfectly fine to skip some days and still it's possible to solve some of the next ones!

[schneems]

> So perfectly fine to skip some days and still it's possible to solve some of the next ones!

You try telling that to my brain. That guy doesn’t listen to me.

[tg180]

This is why I usually do the simpler ones and then stop... Otherwise, I just can’t skip, it’s stronger than me.

[mvdtnz]

For those just glancing at the chart do note the scale is logarithmic, so the difficulty increases exponentially.

[kwertyoowiyop]

Either the problems are getting easier each year, or perhaps there are just more people participating which drives down the 100th-place times.

[roncesvalles]

There are some "filter" days for sure, usually those are when the solution needs a major leap in your approach such as concurrency, dynamic programming, or geometry equations.

[abound]

It's usually not concurrency FWIW, it's almost always algorithmic in nature. On a modern machine, even highly concurrent* code would only execute 10-20x as fast and you could just wait a bit.

One common AoC trick is that you can brute-force part one (e.g. O(n^2) complexity or worse), but part two scales up `n` to make that intractable.

*ignore my sloppy conflating of concurrency and parallelism

[Jtsummers]

I agree with you. I don't think either concurrency or parallelism have ever been necessary. In 2019 with Intcode, it was the simplest approach (use multiple threads, one per VM) for a couple days, but it was never actually necessary. You could do the same thing with purely sequential code, but you had to juggle the state of multiple running systems yourself then. Threads were much easier (or coroutines, go routines, processes, etc.; some concurrency system).

And by design, every problem is solvable on decade old computers in a reasonable amount of time (seconds) so parallelism is great if you're looking to minimize the runtime, but it's never necessary.

[codr7]

I very much enjoy the cat and mouse game of assumptions regarding part 2, it always makes me happy when the second part is just a simple adaptation of the existing solution.

[ruuda]

Cool, it would be nice if that one aligned the days which were on weekends, as those tend to have harder problems.

[SketchySeaBeast]

If I understand correctly, and I'm not sure if that graph proves that, they try to put longer puzzles on weekends.

[wjholden]

Right, Eric Wastl addresses exactly this in his talk. He considers weekends and burnout in the pacing of the event. I think this is the right video: https://youtu.be/bS9882S0ZHs

[torginus]

Ugh, I hate log scales used arbirarily, every silicon valley nerd things it makes them cool like their EE profs teaching actual science or Ray Kurzweil singularity whatever nonsense.

[dahart]

Ray Kurzweil is indeed full of crap (I have a specific bone to pick with his intentional mis-use of life expectancy among other things), but what makes you think in this case the use of log is arbitrary? Did you look at the data with a linear axis? I just tried it, and the vertical space is dominated by 4 or 5 outliers, and on top of that you can’t see the trend as well when it’s linear and all the data is smooshed at the bottom. Log plots are great when your values span many orders of magnitude. That’s true in this case, and the log plot both uses less vertical space, which is nice, and it more clearly shows the trend and wastes less empty space on the small minority of outliers.