Days 9 and 10 were my favorites, for slightly different reasons. For both of them, I had a "idk what to do now" moment and had to do some careful web searching to avoid full spoilers. I think getting stuck on both, then (re)learning something, is a big part of what was fun.

Day 9 is a problem I traditionally would have avoided had I not set a completion goal. The graphicsy coordinate manipulation stuff is fiddly and I always get it wrong. Fortunately, AI fixed all my bugs this time, and I really enjoyed doing the coordinate compression into flood fill into prefix sum into brute-force solution for part 2. Coordinate compression and using prefix sums in this way were both new to me and both really cool.

Day 10 was super fun. It's a hard problem of exactly the style I was looking for. It requires a good algorithmic approach, but no really clever ILP space pruning or anything super fancy. Mechanically, writing and debugging the code for Gaussian elimination was tons of fun. And, the problem leaves me with a lot of followup ideas to explore and questions about how other people's solutions work. Great problem, 10/10.

Overall, yes very fun! It was nice to be able to complete the full set of problems.

The AoC problems I enjoyed had a pleasant balance between big-F Fundamental Problems and real world problem solving. I'm attracted to these big-F Fundamental Problems, especially when I can use a bit of low-level computer architecture stuff to make solutions go fast. In a (reductive) taxonomy of problems including (1) fundamental problems, (2) hard core engineering problems, (3) product problems, working through AoC reminds me that I'm most attracted to things in the intersection between (1) and (2).

The self-reflection exercise I'm able to do following completing the problems is also fun.

According to Claude, what I ended up doing was more Common Lisp than Emacs Lisp:

You're writing Common Lisp that happens to run in Emacs, not Emacs Lisp.

I struggled with choices around mutation and program shape throughout these problems.

I didn't use any external packages because I didn't want to break my editor messing with the packages. The built in libraries are great, though a bit inconsistent (see elt vs nth vs aref argument order). There is a built-in function for almost everything, though sometimes finding them is a bit tricky without reading all of seq.el over and over again. I'm sure I just didn't leverage the built-in help system to its fullest, and that this complaint isn't well founded (though nothing really comes close to hackage for discovery).

I don't feel like I took advantage of the text processing tools in emacs, even though I needed to parse a lot of text. In only one problem did I drop the input into a buffer then walk it with a regex for input parsing. This wasn't necessary for many of the problems, but it was powerful when I needed it.

All of the developer tools are great (profilers, debuggers, help system, etc). The emacs living-system, where I can inspect or change anything, is a nice change of pace.

The most powerful part of working in emacs, in my opinion, is the ability to pop up a buffer with some internal state, and just look at it. For example, want to inspect a matrix? Just pop up a buffer and look at it:

(defun show-mat (m)
  (with-current-buffer (get-buffer-create "*mat*")
    (erase-buffer)
    (cl-loop for r from 0 below (mat-rows m) do
             (cl-loop for c from 0 below (mat-cols m) do
                      (insert (format "%2d" (mat-ref m r c))))
             (insert "\n"))
    (goto-char (point-min))
    (pop-to-buffer (current-buffer))))

This is a fantastic level of introspection capability. The debugger of course also gives you significant access to internal state.

Additionally, I automated much of the problem workflow, including running solutions and copying the result to the system clipboard to paste into AoC. I want to find a way to use emacs in my day job to drive more of the workflows I use on a regular basis.

Elisp is probably the wrong choice for AoC, but that's okay. I'm happy to have learned more of the language; I will hopefully be using a lot more of it for workflow automation. Programming in this environment was joyful. It scratched the "programming can be fun" itch.

Programming, the mechanical bits of modifying some code, thinking about the code, debugging the code with nice tools, and automating repeated parts of the mechanical programming process, is something I find enjoyable. The hyper-focus is enjoyable and incredibly relaxing for me. I had a lot of fun reflecting on, evaluating, and trying to tweak my programming style/behaviors as well.

The mechanical process of writing and debugging code is extremely fun. Getting into a flow state while writing code is deeply enjoyable.

Many of us love code, and love to argue about the right way to write it. Many of us enjoy the fun colors we've configured in our text editors, the keybindings we've internalized, the cool new LSP thing we found last week, etc. It's a huge bummer to me that there's probably not as much of this in my future.

It's possible that I might be able to restore some of the flow state with AI tools and good integrations between them. I will spend significant time trying to make the new workflow fun and joyful. I'm optimistic this AI-fueled coding thing can become mechanically fun too, just in some different way.

I'm in a bit of a pickle over how AI tools and programming work for this second thing.

The act of programming is a tool for thought and a tool for discovery. Nearly all of the code I write is thrown away; the point of writing it was to figure out what the problem even is.

A great analogy here is writing text. This blog post, for example, took me a month to write. Writing text over and over again is how I figured out what I actually think!

The specific thing I'm thinking about varies, but programming languages (for me) are often a good tool to explore the problem space (for problems I actually like working on). That is, programming languages are great tools for thinking about questions like:

• What's the right algorithm for this Fundamental Problem?
• What does the data look like?
• How do I lay all this stuff out in memory to go really fast?
• What is the interface that hides just the right amount of stuff?

This "programming as thinking" also directly relates to the programming styles used, and why it's fun to explore different styles. Trying and thinking about styles of programming is a way to understand the problem better.

I care about my tools, about programming languages, and interactive/iterative workflows because these are tools for thought.

There's tons of good content in this discussion on HN related to this concept: https://news.ycombinator.com/item?id=46881264 and https://news.ycombinator.com/item?id=46909439 and https://news.ycombinator.com/item?id=46917567 and many more

You’d be right to say “you know you can still write code, right?” Yes, of course, but it's really hard to know when the problem is defined well enough to switch from thinking to executing. Switching over when it is execution time is probably faster. But, the feedback loop between half-formed ideas, concrete representations, and small experiments is fragile. Writing bad code, throwing it away, rewriting it in a different style, or changing the representation entirely is how I notice when I have something wrong. When execution is outsourced too early, I worry that I lose the friction that tells me when something doesn’t make sense and get caught in the "one more try" prompt loops.

This isn’t unique to AI-assisted programming. We see this problem frequently when working with design docs. You can write the design up all day, but when you actually go implement your ideas you'll almost certainly discover incorrect assumptions, important missed details, etc (this does not invalidate design doc writing, as long as everyone accepts that they are just a hypothesis of a design).

Maybe getting the thinking/executing balance right will come with time and practice. Maybe it will get easier to tune my instincts when the progress on the models slows.

Maybe the new experimentation is just making Claude write all the code, then A/B testing it in prod and spending all my time debugging stuff. This is sort of happening right now in day job, so it's a plausible future. Debugging someone else's code all day is a pretty grim job, and "production" is almost too late to be discovering what the problem actually is.

A more optimistic path could be that thinking moves to tools other than classical programming languages. I already sometimes prototype in higher level languages than my final implementation, maybe that is taken to an extreme? Maybe thinking happens in specification languages, proof assistants, simulators, deliberately constrained DSLs, with models acting more like "compilers" that can plug the ideas into the final codebase and convert between languages or something. Maybe team-work works better with these models in a specification language? That's worth some experimentation.

I am not sure what comes of this but it's fairly clear we still need tools for thinking (until Appendix: For now…).