Not Good at That

January 17, 2026January 17, 2026 ~ Sean Nolan

Folks often seem surprised to hear I didn’t get a Computer Science degree. Back in the late 80s, CS was still considered (at least at my school) mostly a math discipline and, despite apparent expectations, I am decidedly not a fan of advanced math. I handled this by combining two things I do love (CS and psychology) into a custom degree. I’ve (almost) never needed the math, and psych has proved useful again and again. Well played!

Still, it kind of grates at me when I know something is out there that others “get” that I don’t. A sampling of my (copious) kryptonite: logic puzzles, think-ahead games like Go and Chess, 2D drawing and 3D sculpting, playing both hands on a piano. There are some obvious commonalities in that list, like maybe somebody in the nursery poked their thumb into a very specific part of my brain. I guess we’ll never know, will we, Nurse Brenda?

Sudoku December

Anyways, a couple of months ago I got to catch up with Thomas Snyder, a guy I was lucky to work with back at Adaptive Biotech. One of the smartest people I know, Thomas is a three-time world Sudoku champion and recently started a gig building puzzles for LinkedIn. The LinkedIn puzzles fill a great niche; quick but entertaining — I run though Zip, Mini Sudoku, Tango and Queens most mornings before getting up.

Inevitably the conversation turned to Sudoku, and in particular my lament that I’m “just not good at it.” While acknowledging that he sees patterns more easily than most, he also implied (not his words, he’s more polite than this) that perhaps I was just being a whiny little baby. Practice is a powerful thing, and I resolved to spend a few weeks trying to knock the Sudoku monkey off of my back.

If you’re one of my few regular readers, you may remember a similar experiment I did a few years ago with the NYT Crossword Puzzle. In that case, I actually became pretty proficient; let’s see what happened with this one.

The Basics

Most folks know the basic rules of Sudoku. Each digit one through nine must appear in each row, column and 3×3 box in a 9×9 grid. The easiest puzzles can be solved entirely or almost entirely by looking for “Unique Candidates” — groups where there is only one open place for a number, like the red three in the puzzle below. There must be a three in the bottom-left 3×3 box, and every other cell is either already filled or is blocked by the presence of an existing three. Simple enough.

Solving Strategies

Of course, those puzzles get boring fast — the answers are just too obvious. The next step up is what the NYT and other newspapers publish as “Medium” or “Hard.” These require the identification of more subtle patterns that are more difficult to catch by eye. A couple of simple examples:

The existing yellow six below, together with the full column in the red box, means that there are only two places for a six in the bottom-left box (blue shading). We don’t know which one, but we DO know that this excludes a six from in the left column of the left-middle box. Together these eliminate all cells but one, so we can place the green six. Nice!

Most advanced techniques require notations indicating the “candidates” that could possibly appear in each cell. What I’ve added below is “full notation,” which I’ll talk about more later. There are a number of more abbreviated “notation” styles, including a popular one invented by Thomas called Snyder Notation.

In this puzzle, the only numbers that can go in the red box are eight and six. This is called a “naked pair,” which helps us eliminate candidates from all the other cells in its row — none of those (circled in red) can be eight or six. Removing those leaves us with only a seven in the yellow cell. And bonus, by placing the seven we know the one right above it must be a six. Progress!

There are dozens of these strategies, increasingly complex and with great names like “Swordfish,” “Finned X-Wing” and “BUG +1” (check out a big list here). The more esoteric are only needed for seriously difficult puzzles, which are beyond what is considered “Newspaper Hard.”

My Results

I decided to use the NYT as my testing ground; they release Medium and Hard puzzles each day. I did these pretty much every morning through December and early January. using their online version because adding and removing notation is easier that way. I did not use “auto” candidate or other helpers that felt like cheating (one caveat to this I’ll explain below).

My initial strategy was to work in three passes:

Fill in the unique candidates.
Use Snyder Notation to identify pairs and other basic patterns.
Add full notation and sweat it out.

Two things seemed to be working against me. First, I would just straight up make mistakes — typically missing things in visual scans. It’s weird to think that in such a bounded puzzle I could miss things, but it happened a lot. And unfortunately, Sudoku errors don’t generally reveal themselves until you’ve gone further down the road, and winding them back is really hard and frustrating.

This is where I took advantage of one “helper” feature that feels a bit cheaty — the “Check Puzzle” option just highlights errors, and from there I could “undo” back until the board was clean again. As I’ve gotten more proficient I do this less and less, but I think I may have just quit in the early stages without it.

The second issue has proven more difficult to practice away — I just can’t keep a bunch of arbitrary things in my head at once. Great solvers can see dependencies and patterns with little or no notation, for example “forcing chains” that start with an assumption and follow it along a path from cell to cell. By the time I get to the third element in a chain I have absolutely forgotten the assumption from the first one.

The only way I was able to get beyond this was by writing it all down. Since I found that for most puzzles I always ended up at full notation anyways, I started doing that first thing — fill it all in, 3-5 minutes of busywork, and go from there. This was a turning point — not only did full notation give me anchor points to start complicated patterns, it made others just leap off the page. For example, I get a ton of mileage out of naked or hidden triples and quads, but seeing those without notation takes a level of visualization I will simply never possess.

Except Not Quite

At this point I can consistently solve Newspaper Medium/Hard puzzles in 15-25 minutes, and my kit of strategies is such that I rarely feel “stuck” for more than a couple of minutes. They’re fun to do and I’ve continued to play. This is lightyears beyond where I started, so that’s cool. BUT.

First, entering full notation for the puzzle at the beginning is super-annoying busywork. It’s totally mechanical, but it just takes time — so even if it wasn’t boring, it’s a built-in handicap as to how fast I can solve compared to folks that use more abridged notation. Many of the online tools have “auto” modes where the candidates are managed for you, dynamically updating as you put in solves, but that absolutely feels like a cheat. I’d just like an initial autofill that I can then work manually. Easy feature.

The second is more problematic. I keep talking about “Newspaper” puzzles — unlike in the crossword case, the NYT Hard Sudoku is in no way considered the pinnacle of the form. There are many much more difficult puzzles out there, and that’s where the “real” Sudoku aficionados live.

I’ve done enough to prove to myself that if I really spent the time, I could probably at least get “ok” at these, but there’s a built-in arbitrary-ness that I’m struggling to get past. Sure, crosswords may be easier or harder, but that scale is less black and white (ha). Very occasionally I just won’t have the vocabulary (or opera knowledge) to fill in that last square, but somehow that’s OK. When I start a Sudoku but get stuck because it (invisibly) requires that one specific strategy I don’t know — it feels like a waste.

Where to Next?

Would I find it more engaging if, for example, the puzzle could tell me the “minimum” strategy required to take the next step? Maybe, but I’m not sure if that’s even feasible.

But that has me thinking about puzzle design in general — I’ve only been a casual consumer of this stuff, but there is actually part-art-part-science hiding under the covers. Of course Thomas pops up when I start looking for good books on this, but I’m going to start with something a bit broader: A Theory of Fun for Game Design. I swear this world is just full of the coolest stuff ever, always something new to learn. More to come!

Work the Problem

April 24, 2024April 24, 2024 ~ Sean Nolan

My father-in-law is actually a really great, super-nice guy. But that doesn’t mean he’ll pass up an opportunity to give me a hard time — say, paddling the canoe towards the alligators while I’m in the bow. Or more to the point of today’s post, bringing over the New York Times Crossword puzzle and pretending we’ll do it “together.” For years we’d sit down and he’d basically watch me stare blankly at the clues. Then, on cue every thirty seconds or so, he’d throw one out like he was just guessing: “maybe try OBLIGEE for 20 across?” He always knew the answers, and he knew I knew he knew the answers, and that was the fun part. Infuriating, but I’m just too competitive to not get sucked in again and again.

So when I retired a few years ago, one of the many items on my to-do list was “get good at the NYT crossword.” Since then I’ve done the puzzle pretty much every day, missing maybe a half dozen over three years. And of course, it turns out that solving crosswords is a skill like any other; enough practice and it becomes pretty straightforward. Most interesting to me, it turns out that techniques for solving puzzles overlap a ton with techniques for debugging software.

Now maybe I shouldn’t be surprised that this is the case, because both tasks are about establishing possibilities and fitting them into a set of constraints. Or as Gene Kranz (or Margo Madison) might put it, “working the problem” until you find the answer that was hiding in there all along.

Note: I’m going to be spoiling a few answers for recent NYT puzzles — if you do them in arrears you have been warned!

The Basics

OK, on the surface this seems pretty obvious; we’ve all been doing some form of crossword since elementary school vocabulary worksheets. A bunch of clues to interlocking words, across and down in a grid. It helps to know a lot of trivia, a few foreign words and the names of various artists (modern and not so much). The NYT puzzle goes through a weekly progression where Monday is the easiest and Saturday the hardest. Many folks are surprised to learn that Sunday isn’t the most difficult; it’s just the “biggest,” meant to be done leisurely over your weekend soft boiled egg and tea looking out from your brownstone over Central Park or whatever. Thursday is an interesting day, because it tends to have a “gimmick” — more on that in a bit.

Beyond just “knowing stuff,” the first thing folks learn about puzzles is that there are certain words that repeat all the time. Just a very few:

The artists Sia and Ice-T are quite popular with puzzle authors.
Their favorite Olympic sport is definitely fencing, specifically épée.
Just about every disturbance is an ado, many people are prigs or fops and get into snits.
Authors all wish they drove a GTO or at least a car with a T-top.
In amour with your amie? Maybe it’s just the romance of été along the Loire.

You get the idea. These common words are usually the quickest way to get started on a puzzle, because they’re easy to pick out. The checklist of things I walk through when faced with a weird debugging problem works much the same way:

Off-by-one?
Out of memory?
Infinite loop or recursion?
I/O failure?
Unexpected input?
Divide by zero?

In both cases, a relatively small number of solutions account for an outsized proportion of problems. And because they happen so frequently, you being to develop a “feel” for their symptoms (or clues) … most of the time running through these common cases will put you on the right path to a complete solution.

Confirmation

Another sort-of obvious technique for puzzle solving is to increase confidence or eliminate possibilities through confirmation. As much as I can, I defer writing in answers until I find and least one intersecting answer that corroborates the first. For example, since I can’t remember what networks show what shows, the four-letter answer for “Several CBS dramas” could be either “CSIS” or “NCIS”. If overlapping clues support a C or N in the first position, or a S or C in the second, that gives me greater confidence in both of them.

One thing that makes a puzzle harder is to provide fewer or more complicated opportunities for easy confirmation. Saturday grids tend to have more “open” sections with longer, multi-word answers placed intersecting and side-by-side. Another approach is to isolate sections of the puzzle from each other, so that solving one doesn’t help you get started on the others.

Confirmation is key to debugging as well. Theories are easy to come by, especially with bugs related to user input or distributed systems. Maybe two users clicked “submit” at the same time. Perhaps one system crashed while another was holding an open network connection. Or it could be something that happens on every 32^nd request. Coming up with these ideas is important, but proving or eliminating them is the heart of the work.

Unless you’re able to reproduce the bug on demand, your best friend for confirmation is detailed, timestamped system logs. These let you look back in time and see who was doing what when; the tiny performance hit is always, always, always worth it. Today most enterprises use third-party or cloud-provided distributed logging solutions, but an old-school rotating disk file can do the job just as well. Either way, great engineers learn to slice and dice logs to find evidence that corroborates and confirms their theories — there’s no rush like finding that smoking gun.

Getting Stuck

Sometimes — whether you’re working a puzzle or debugging code or something else — you just get stuck. This is what separates the grownups from the children in the room — do you stick it out and find some way to make progress, or do you just give up, go home, and let it be somebody else’s problem? If you sense a little moral judgment in that phrasing you’d be correct. 😉

While it’s not the easy answer, years of experience have proven to me that the best thing to do is just keep trying. Read the clues again. Force yourself to look beyond your initial interpretation — a “70s Ford” may not actually be a car! The answers are in there, and if you give your brain enough chances to fire the right neurons, it will happen. And it works for debugging too; a full decade ago and in another life I wrote about it here: The definition of insanity works!

But while giving up is not an option, walking away for a few minutes often is a great idea. It’s quite surprising how often a change of scene will help shake out a solution — answers just pop out where they seemed impossible before. Sticking it out and changing context — it’s all about giving your brain space to make connections.

Patterns and Partial Answers

Something is better than nothing — so when you just can’t figure out that next answer, there are a few ways to keeping pushing forward:

Plurals usually end with -S, past tense with -ED and active verbs with -ING. Of course these are often wrong, but they can be super-helpful as confirmation for intersecting clues.
Sometimes you can make a guess at part of the answer. For example, it’s a pretty good bet that “Where you’ll find women out to drink” ends with BAR, and “Platonic outing” starts with FRIEND.
Even when you’ve got no confirmation at all, it can be helpful to write in guesses that fit. Seeing letters in place is a great way to trigger those stubborn neurons, and I can easily scribble over at least two mistakes before the square becomes illegible!

These techniques all reduce the unknowns. We’re not built to juggle too many things in our head simultaneously, and fewer empty squares makes it easier to focus on the ones that remain. It really doesn’t matter whether the guesses are right or wrong — that will become evident as we make progress on their neighbors.

Once again (and I swear I’m not just forcing these), this same approach helps debug code, where it’s called “divide and conquer.” Split the problem in half and just assume that one half is working correctly. If that’s true, the bug must be in the other half — so find it there. If you can’t, then your assumption must have been wrong. Either way, you’ve made progress.

The Reverse Solve

I mentioned that Thursdays are often a “gimmick” puzzle. Sometimes these are structural — answers extend into the black squares, or multiple letters go into one square. Other times they’re just tricky themes. For example, last week the trick was about missing letters in a set of clues:

First, solve the clue “thrice-remade movie” (A-STAR-IS-BORN)
Next reparse that answer as six words (A-STAR-IS-B-OR-N)
Replace the stars in clues with a B or an N to get the actual clue. For example, replace the star in “*acre on the ocean floor” to get “Nacre on the ocean floor” for the answer “MOTHER-OF-PEARL”

There was no way I was getting this by working “forwards” — I got the movie title, but couldn’t for the life of me figure out how to parse that into six “words.” Instead, I ended up working in reverse. I was able to solve “Acre on the ocean floor” as “mother of pearl” based on confirmation — it had to be correct, but it made no sense. But I knew that M-O-P was another term for NACRE (one of those commonly reused crossword favorites), and eventually it dawned on me that that could fit with “acre” in the clue, and eventually that let me work out the “B or N” part of the primary clue. From there, things fell into place quickly (“*assist in a foursome” was MCCARTNEY, etc.).

And believe it or not, this is yet another way to make your way through a debugging problem — you know the outcome of the bug has to be true because you see it happening. Look at the step right before this — what has to be true for that outcome to happen? And if that’s true, what has to come before that? It’s kind of amazing how often novice debuggers will simply deny what they are seeing right in front of their face. If only I had a nickel for every time I disproved “that just can’t happen” in production code….

… and that’ll do it for yet another wander through “something-that-isn’t-code actually working a lot like code.” It seems clear that over the next few years, AI is going to be writing a lot of software. And that’s OK because progress is progress and there are tons of coding jobs that at their core really should be done by machine. But I do love the craft of it all, and I hope there will remain some space for artisan code, just like we still value artisan woodwork and clever crosswords. I know that sounds a bit funny, but I mean it. We will see!