If you don’t know what the “Advent of Code” is, you can check my previous post on the topic.
Getting in the top 100 requires a kind preparation, and mindset I don’t have.
It’s the kind of skill you train when you routinely compete in online events where the super-fast win and, while I respect it, it’s not the approach I like when coding.
I golf to be deliberate and thoughtful, and coding clean instead, so I took the competition at my own pace, with only one exception: I tried to solve each problem in its own day.
Here is my take-away on the competition itself, which I’ll hopefully follow with an entry about doing “Advent of Code” with Clojure.
Even one problem a day can be too much
Having a regular job and a family, I often started the day’s problem at 10PM, only to finish it at 3AM.
Maybe other people are faster than I am, but for as long as I managed to ride the wave of each daily problem, it’s been taxing.
It’s fun (most of the time)
You wake up and you are being treated with a new, absurd MacGyver-esque problem. You wrap your head around it, find an elegant solution, and give yourself a pat on the back.
Some problems required more time to crack than others, it’s hard work sometimes, but the lasting feeling is rewarding.
This is what happens on a sunny day.
It’s less fun when you remain stuck
Day 23 turned out ugly. I got seriously stuck for two days on a problem that – I realized afterward – was embarrassingly simple.
From the statistics on the website, I know all other participants are moving forward. The leaderboard doesn’t lie: I’m among the few who are finding that problem a challenge.
At some point, I literally felt like the last sucker: I personally questioned my value as a developer. And I was still stuck, so I had to bite the bullet and check Reddit for other people’s solutions.
It turned out the problem was among the simplest ones, and right because the solution was so simple, I had pre-emptively discarded it a priori.
I won’t lie: It did hurt. A LOT.
Finishing the remaining two problems 2 days late didn’t really deliver much joy or a sense of accomplishment, but I tried to put the experience in perspective.
In hindsight, there are some considerations that help to mend my ego a bit, but that can have some sort of general value.
First, I may have been trailing after the group, but it was still a small group of people who don’t just code but also love so much doing so, it solves coding problems while on vacation. So yes, I may even have been “the last”, but I’m definitely not the last sucker.
Second, of the almost 150000 people who started participating only 8% managed to finish it: so even if I was among the slowest 10% of people to solve day 23, I’m in the top 8% who didn’t give up!
The best day was the worst day
More importantly, however, day 23 has been the most enlightening day.
Maybe the other ones may have been more pleasant, and they may have even managed to let me think and improve a bit, but thedebacle of day 23 highlighted a fundamental flaw in my way to approach problems in general, and hopefully managed to get the point across.
It did also show my shortcomings in responding to failures, in general: letting myself feeling down, grudgingly pressing on, losing the sense of perspective are all pains I could have made without.
I picked up the (wonderful) “Thanks for the Feedback: The Science and Art of Receiving Feedback Well” (Douglas Stone, Sheila Heen) again to re-read the chapter about “giving yourself a second score”.
The idea is that failures are not always under our control, but the way we react to them is and, like in this case, so it’s the way I react to my failure to react to failure.
I also refreshed a bit another favorite book of mine: “The Subtle Art of Not Giving a F*ck, A Counterintuitive Approach to Living a Good Life” (Mark Manson).
I didn’t re-read it all, I just picked two sentences:
“Pain is part of the process”
and
“Failure is the way forward”
And only God knows how much pain and failure I face every time I code…