Advent of Code 2021, The Dark Side

I got something out of Advent of Code 2021, but I didn’t like how it affected me.

I finished Advent of Code 2021 with 43 out of the 50 stars. (The last one you get automatically for getting to 49.) The highest ranking I achieved was 7372, on Day 25, presumably because everyone else was busy with Christmas presents (it seemed like an easy one everyone else would get in mere seconds).

The only person I know of who actually completed it was Tipa over at Chasing Dings, so a hearty congratulations to her! It was an ordeal, the programming equivalent of a Boston marathon.

I don’t necessarily regret taking part in it, but I learned some life lessons.

A long time ago, when I started writing code on a middle school Apple IIe and then at home on a TRS-80 Color Computer, I believed I was good at it. Nobody else in my immediate circles knew a thing about computers. I took to it like a duck out of water, or whatever the saying is.

I took a handful of classes, but they were mostly a waste of time, because I already knew more than the teachers did. Most of my formative programming philosophy and knowledge of data structures came from perusing the Amiga developer handbooks and studying the work of the original Amiga engineers, not from schools.

The point is, I developed a fairly big programming ego. Back then, “rock star” programmers and the associated cults of personality were common. I was sure I was better than other programmers, so I was sure I was a “rock star.” Faster, smarter, more productive, more elegant, etc. It was easy to develop such a competitive attitude, because I almost never encountered other programmers in real life.

“The three principle virtues of a programmer are Laziness, Impatience, and Hubris.” -Perl manual

When I first saw that Perl mantra, I nodded immediate agreement. Exactly so. My entire programming life philosophy to that point boiled down to one concise sentence. The late 80s and early 90s programmer in a nutshell.

After all these decades of life experience and access to the Internet, though, I got over all that and embraced the philosophy that no matter how good you are, somebody else is better. There’s always room to learn new things. In fact, it’s imperative to continue learning new things in the software field. Software development (and life in general) has grown into such a broad field that it’s impossible to know everything. You can know a lot about a few things, or a little bit about a lot of things, but you can never know a lot about a lot of things. And most things you won’t know anything about.

But sometimes I still fall back into that old place of hubris. To think, “Yeah, I’m really good at this. Better than most people, actually. I’m definitely one of those mythical 10x programmers we’re not supposed to acknowledge.” Sometimes it takes intentional effort to avoid that mindset.

It’s a competitive mindset. Competitiveness can be useful in software development: Say, in startups and entrepreneurially-minded ventures, where the goal is to be first to market. I imagine it would be useful in game development, the development environment I would definitely categorize as the most toxic of all development environments. But in general, competitiveness isn’t much use in day-to-day development work. In fact, it’s usually a hindrance. It’s best to put it aside.

So along comes Advent of Code 2021.

“Just when I thought I was out, they pulled me back in.” -Some Godfather Movie

It didn’t take long for me to fall right back into that competitive programming hubris mentality, because Advent of Code is designed to push you there. There’s a timer. There’s a ranking. There’s a gold star for winning. Two gold stars if you’re really good. There’s a leaderboard and, perhaps most importantly of all, there’s bragging rights at stake.

There’s a whole community of people on Reddit who can’t wait to show you how fast they solved each day’s puzzles, and generate a nifty visualization, and write a lengthy explanatory blog post, and commit clean, well-documented code on GitHub, and pretend it’s normal to do all of those things in a single day. And it’s a heavily-sponsored event. It’s the ultimate hubris-building machine.

I felt driven to finish each day’s puzzle. Like it was important to show that I belong in this bubble, like I was a teenager again, when nobody else even understood what I was even doing typing on a computer keyboard. It was important to be able to say I was in the top 10,000 best of the best in the entire world who could turn in an answer to these puzzles in less than 24 hours.

It started to get bad with Day 12, “Passage Pathing.” I hate pathing problems. They almost never occur in real-life day-to-day programming tasks. Nobody ever needs to know a Dijkstra “shortest path” algorithm by heart outside of a coding interview or a classroom. All you need to know is how to type “shortest path” into Google, and how to use one of the bazillion open source libraries or language features that have already been written to do that. But you probably won’t even need to do that if you aren’t in game development (or network infrastructure, I learned).

It got worse with Day 15, “Chiton.” Another pathing problem. For that one, I really did have to Google and implement the Dijkstra algorithm to solve it–for the first time in my entire life–because the algorithm I worked out on my own and spent most of the day optimizing for part 2 was never going to finish in time.

It officially got out of control with Day 19, the infamous Beacon Scanner puzzle.

I got up early on a Sunday expecting to knock it out early and have a free day, but in fact, I spent all day off and on working on that. And I kept working on it far beyond the point where I was making any reasonable progress, which is a sure sign to put a project away and come back to it later. It’s a waste of time and energy to work on any software project if you’re not mentally fresh. I always complete tasks faster when I work on them in smaller increments over a longer period of time, than I do working on them continuously until they’re done. At my advanced age, I can’t reasonably focus on a single programming task for more than a few hours a day. But I kept drilling away at that stupid Beacon Scanner, because I had to get those stars and the timer was ticking. I would be a shameful failure in the eyes of the world if I didn’t get it in time. I spent most of that day being angry at myself.

I also fell back into an old bad habit from my younger days of forgetting to eat. I’d suddenly feel like I was going to faint and notice I was ravenously hungry and realize it was some two or three hours past time when I should have eaten something. That’s a terrible habit of mine that I don’t often return to anymore, but it still happens sometimes when I’m deep into programming (or writing). It happened on Day 19. Twice.

And the Beacon Scanner was mainly a math problem, too. It wasn’t much of a programming problem at all, it was a math problem. I hate math. I’ve always hated having to solve math problems in programming. Some people mistakenly assume you have to be good at math to be a programmer, but that’s 100% false. I’m terrible at math. I can’t do simple math without a calculator. (I’m not quite as bad as all the younger people on those D&D shows who can’t add up 6-sided dice without using their fingers and try to laugh it off as if it doesn’t exemplify how far behind the American education system is on the world stage, but I’m pretty close.)

I had to walk away from Day 19 unfinished. It was hard. It was really hard. I was very angry at myself and the world and had some trouble getting to sleep that night.

It remains unfinished to this day, and it still annoys me. There’s either a persistent bug in my code somewhere or I have a fundamental misunderstanding of the puzzle. (I didn’t think that one was explained or demonstrated particularly well, leaving me with a considerable amount of confusion, possibly related to my lack of general 3D math skills.)

Not to mention how much I hurt my back sitting over a laptop all day. I was in a fair amount of pain last Sunday night and Monday, and my back still hasn’t fully recovered yet, a week later.

After Day 19, I resolved to try to walk away from the puzzles the moment I felt like I wasn’t making progress. I didn’t quite manage that, but I did walk away from several others soon enough to keep my back from getting worse and leave some time in my evenings to do other things, so I’m fairly pleased with myself for that.

The point is that I didn’t like that feeling of competitiveness that infected my programming workflow like a cancerous growth, a workflow which is essentially an artistic workflow. It’s bad for me, so in the future I’m going to have to be more careful about these kinds of programming challenges.

I’ve developed the same sort of feelings about NaNoWriMo, actually, and any sort of “writing challenge,” so I tend to distance myself from them now. Whenever you add an implied competitiveness to an artistic process, I have to be really careful to ensure it’s a positive experience for me instead of a negative one. Being “unsuccessful” at an artistic challenge can do a lot of damage to my fragile artist ego, so I have to define the parameters of the challenge for myself in such a way that I will always be successful, no matter what.

Regardless of all that negativity, I got a lot of value out of Advent of Code in that I wrote most of the puzzles in Kotlin, a language that is brand new to me. And when I focused on learning Kotlin, it was an enjoyable process. (I mean except when Kotlin is weird an unintuitive, like the most basic of for loops.)

Some of the puzzles were enjoyable, too, they weren’t all math problems. (See my other post.) If every day had been a different packet decoder, for example, that would have been right in my wheelhouse.

I’d still like to go back and finish up the puzzles I walked away from, if for no other reason than to cleanup my GitHub repo for the future. (Actually I’m going to redo it completely.) I’m hopeful I’ll keep my current job until I retire, but you never know when you might need some sample code to show a potential interviewer.

But in the future, I might wait until the actual event is over to start working on the puzzles. Or else aggressively mute everything related to the event so I don’t get dragged back into that black hole of competitiveness.

I’m also interested in going back to work on previous years for more and different language practice (eg. I’m curious what visualizations I might be able to make with Kotlin compiled to TypeScript/React), and I imagine it’ll be much more enjoyable without all the competitive time pressure. (I mean, as much fun as programming for fun can be, that is. There’s a limit.)

Incidentally, I blew away my previous working GitHub repo. I’m going to make a new one now that I know more about Kotlin project structure. (Also because I read somewhere that you weren’t supposed to commit the puzzle inputs. Oops.)

P.S. Kotlin is interesting but I’m not sure it’s ready for prime-time yet. There’s, um, no namespaces. Yeah, you heard me right. No namespaces! And–shockingly–there’s no number formatting in string templates!