A friend shared this great Game Maker's Toolkit video with me, What Makes a Good Detective Game?, while we were researching in preparation for Tiny Mystery Club. He made a side comment about how programming can be a lot like solving a mystery, a comment which has been popping back into my head nearly every time I've worked through some code since.

My favorite segment of the video is about Sherlock Holmes: Consulting Detective, a video game based on a board game of the same name.

So, in this game, you actually get a newspaper in the box and you have to scan through it for articles that might be relevant to your investigation...

Then, in the game itself, you open up a directory of every person or business in London. There's roughly 200 entries in here at least, so you'll have to rifle through it to find the right person. The idea is to hide the relevant names in a sea of red herrings.

I had this example in mind while working on a recent project. During the past week, I'd been working on building and deploying a new Next.js website with my work's internal tools. The tools are well-documented for lots of different kinds of sites, but not Next.js (yet).

After some digging, the most effective way I found to solve this problem was to try a bunch of different build scripts based on reading the documentation for Next.js and our internal deploy tool, then search GitHub Enterprise for repositories where folks had tried the same thing. The documentation was my newspaper, and GitHub was my London full of red herrings.

Game Maker's Toolkit also mentioned a 2009 game called Blackwell Convergence:

In Blackwell, you can type interesting place names you've heard or seen written down into the Internet to get addresses before they're added to your map as locations you can visit. The magic of the search bar is that these people and place names are only acknowledged by the game as useful clues when the player has proven that they know they're useful clues by typing them in.

In some ways, this hews even closer to my experience at work. While reading the documentation, I had to recognize which keywords were significant and search for them using an actual search bar in GitHub. I'd know the keywords were useful clues when they led me to someone's repository in which they were trying to solve a similar problem.

For example, the documentation for our internal deploy tool indicated that I'd need to build to a specially named directory called target. I cross-referenced that with the Next.js page about how to set a custom build directory, specified a distDir directory for my website, and searched for distDir: 'target' in GitHub Enterprise. There were a few results! This indicated to me that I was probably on the right path. Even better, the results led to more repositories where I could hunt for even more clues.

Of course, I'm not trying to play a game while I'm working - and for most tasks, I'd really prefer a simple list of steps to follow. In fact, how similar my work is to a mystery game is probably inversely proportional to how much coverage a tool's documentation has. In mystery games, the goal is to make the player have to work to solve the problem without spoonfeeding them answers. In development, I want to complete my tasks as quickly and efficiently as possible.

Published about 3 years ago