Generating crossword puzzles is NP-Complete. Every cell where two words intersect creates a constraint that both words must satisfy, and those constraints multiply across the grid into a combinatorial explosion. There’s no efficient algorithm that guarantees a solution—but with the right heuristics, you can build something that works surprisingly well.

In late 2021, deep in lockdown, my NYT Crossword obsession turned into a side project. I wanted to build a crossword app, realized I needed puzzles, tried making them by hand, found that tedious, and wondered: could I generate them algorithmically? Earlier this year, I finally shipped Crosswarped on iOS and Android — a crossword game powered by the generator I’ll describe here.

When maintaining large software systems, you will likely have multiple environments with names like Prod, Staging, Dev, Eval, UAT, Daily, Nightly, or some remix of these names. To distinguish this type of environment from the dozen other things in software development that we give that same name, these are often formally referred to as Deployment Environments.

One question I’ve never been asked directly is: “What is an Environment?” This is surprising; because not understanding what Deployment Environments actually are is one of the most common pitfalls I see in my day-to-day work.

Last year, I wrote about migrating this blog to Next.js. It ended up being a huge post, so I wrote a <TOC> React component to make it more navigable. You can also see the TOC in action on this page:

The bulk of the logic for this component is based on Emma Goto’s great examples in her ”How to build a table of contents in React”, with a few improvements worth discussing. If you haven’t yet, go read that post! Emma does a great job showing both the final working solution and explaining the thinking behind it step-by-step.

In February 2020, I migrated this blog from WordPress to Gatsby. Using Gatsby also allowed me to switch from hosting my site on a paid plan on SiteGround to a (usually free) plan on Netlify.

The migration made sense to me at the time: static-site generation was all the rage, and Gatsby was the exciting new thing. It promised better performance and improved my authoring workflow with Markdown and React. Saving a few dollars a month on hosting didn’t hurt either.

To this date, schema-dts is the only side-project I have that achieved better-than-moderate success. It took several hours between the time I had the idea for schema-dts and when I had a reasonably working v0.1. I pulled an all-nighter—something that I hate doing and would never recommend—not out of sheer passion, but because:

• I knew how rare a moment of inspiration is, and
• I knew that if I went to sleep, I would never finish this project; there’s a graveyard of unfinished projects haunting me.