Today, an RC colleague organized a group to tackle a git mystery, in which murder has been done and the clues are hidden in commit messages. My group did not solve the crime within the hour, nor did we limit ourselves to git commands. But we appreciated the spirit of the exercise and became familiar with git concepts such as tags, log vs. show, the --author, --after, and --until flags, the HEAD~n syntax for referencing the nth commit, and how to read diffs. Many objected to the flimsy evidence used to finger the suspect, and I do wish there had been more clues - the story resolved abruptly. I enjoyed myself, though, and look forward to next week's command line murders.

To get into the proper mood, I spend some time earlier solving an SQL mystery, with a similar premise: investigation reports and clues are scattered through a database, and you need to query them properly to narrow down the suspects. I liked that this mystery did not stop after you found the culprit, but asked for more complex queries to identify the mastermind behind the crime. I managed to solve it nearly entirely with SELECT * FROM example WHERE field1 = x AND field2 = y, by taking copious notes and replaying queries periodically, but I'd like to re-do it with more sophisticated JOINs now that I've reviewed the walkthrough. My lackluster showing suggests I should go ahead and dive into A Curious Moon, a science mystery using data from the Cassini mission, which several RCers have recommended / gone through.

I also participated this week in a birthday puzzle party in which we learned how to solve yajilin puzzles, a particular favorite of the birthday girl. In fact, she's been learning to write them, although she didn't include her own puzzles in the festivities. I had fun collaborating with some RCers I haven't spent much time with previously, and of course solving puzzles is always a blast. Some people got predictably hung up on whether each step was provable with how much information on the board, but I'd rather intuit my next steps and backtrack if they turn out to be wrong.

This lack of rigor has also lead me to solving some Leetcode problems in non-standard ways, or at least, without using whatever data structure I'm supposed to be learning about. Usually their solutions seem extra convoluted to me, but maybe they make sense in other languages. I'm slowly getting over my resentment about the interview hazing that Leetcode and its friends represent. I'm trying to be grateful that someone has identified a relatively finite amount of content that can be mastered, and organized resources for learning it. Treating them like Advent of Code puzzles also helps, except I keep running into the pesky runtime limit.

Four things more than make a post, and I need to throw together some slides for a PageRank talk this afternoon.