Golfing A Duffers Dictionary

I spend too much time on code golf. Not the kind you play on a grass course with a nine iron, the kind where you shrink a function down to its absolute smallest valid form. A few weeks ago I hit a wall with a task that seemed straightforward on the surface. Build a compact mapping between common golfing problems and their solutions, essentially a duffers dictionary, but the output had to stay under a strict byte budget. That's when I started thinking about it differently. The core problem is simple: you need a lookup structure that covers a reasonable range of inputs without blowing up your character count. Most beginners just dump a standard dictionary definition straight into their code. That wastes bytes on type declarations, spacing, and redundant syntax that the compiler or interpreter already understands from context. In Python, for instance, {'shank': 'open face', 'top': 'hands ahead'} is clean enough, but the moment you add string quotes everywhere or verbose variable assignments, you're burning through your budget fast. The trick is to only write what you must. I ran into a specific edge case that cost me nearly two hours. I was building a mapping where the keys needed to be single lowercase characters and the values were short strings, but the validator rejected anything longer than 60 bytes total. My first attempt used dict() constructor calls and escaped quotes because some values contained apostrophes. That alone ate 14 bytes. The workaround was to drop the quotes around single-character keys entirely—{'a': 1} instead of {"a": 1}—and for values with apostrophes, I switched to double-quote wrapping and replaced the internal quote with a unicode smart quote that the validator accepted. Saved 6 bytes right there. The rest came from merging adjacent key-value pairs onto the same line and removing every unnecessary whitespace.

Here's the practical method I use now when I start any golfed dictionary project. First, write the fully correct, readable version. Get it working. Then count your bytes. Then strip aggressively in this order: remove all whitespace outside of strings, shorten variable names to single characters, replace verbose built-ins with their shorthand equivalents, and merge multiple entries together where the language allows it. Don't skip the first step. I've lost track of how many times I tried to golf from the start and ended up with code that didn't run at all. There are a few counter-intuitive things about this that most people miss. One is that shorter doesn't always mean fewer bytes when you factor in escaping. A 12-character string with four backslashes inside it actually takes 16 bytes. Sometimes the smarter move is to restructure the data so you avoid escapes entirely, even if the resulting code looks uglier. Another thing: many languages let you use implicit returns or auto-type inference to drop entire tokens. In Python, for example, you can often skip the return keyword by making your function a one-liner expression assigned to a variable. The downsides are real though. Golfed dictionaries are fragile. Change the input format slightly, add a new case, or get the validator rules updated, and your carefully trimmed code breaks in ways that are painful to debug. When the character budget is under 50 bytes and you've spent twenty minutes removing a single space, you're not doing it right anymore. I usually step away from pure golfing after about an hour and switch to a readability-first approach, then compress again only if I still have room to spare. If your target audience is anyone besides other golfers, stop at readable. The 40-byte savings isn't worth the three days someone will spend trying to figure out what your code does.

For anyone actually trying to build a useful duffers dictionary for golf instruction, I'd recommend keeping the raw data in a separate config file and only golfing the parsing and lookup logic. The separator can be a tab character or a pipe, whichever your language parses faster, and you can read it in with a single line of split logic. That's the part worth optimizing, not the dictionary contents themselves. I've published a working implementation on my public gist if you want to compare your byte counts against mine. Link is in my profile. Not gonna walk you through the whole thing here since most of it is just stripping exercises, but the core trick I ended up using was a compressed tuple-based entry format that cut my value strings down by about a third without sacrificing readability for other golfers.