I closed Part 1 of this article with the line “In Part 2 of this article we’ll discuss why this solution does not work, and likely never will”.

I thought I was writing an article about the details and nuances that go into creating what appears to be a straightforward piece of code. I thought I was doing this in a creative way with the format—a piece of writing that could be executed as a script. What I was actually doing was writing an article about failure, why it is OK, and why failure can sometimes be a good outcome.

I had tested the code as I wrote it using the live values pulled from the NYY site—given that I wrote it over a couple of days I had seen 2-3 different values. Everything appeared to be as expected. I tested it one more time before I hit “post” on the article.

The script generated multiple results, a very long word and a shorter one, which was how it had been designed—sorting—then starting with the word that contained the most letters from the puzzle. There were several possible two word answers starting with the same word—none of them looked like the NYT ‘Our Solution’ pulled from the puzzle that day.

I decided to enter the values it had given me into that day’s puzzle. Perhaps I had beaten their solution, perhaps I had a better, more interesting combination of words. I had not. My first word was not valid ie: it was not in their dictionary.

I went back to my code, perhaps if I moved this, did this, changed this. I was having a feeling I have felt many times in my life and career. Gone was the careful consideration and I just needed to make it work, I’d clean it up later.

I took a step back and reminded myself that I was largely doing this for fun and I asked myself “What was supposed to happen?”. That was when I realized this was a lesson about failure, and a good lesson, because:

Failure can be great at showing us that we often poorly define success.

When I looked at those first outputs it became apparent that they did not feel right but I could not quite articulate how. Looking back over the decisions that I had made I think that somewhere in my mind I was chasing a possible one word solution to the puzzle, then if that wasn’t the case I’d take the shortest route (minimum number of letters) to the solution. When reviewing this the only thing that was clear to me about my intention is that it was unclear.

There are a couple of directions that this might lead us next. The first is to redefine (or in this case define) success to be the results we achieved. This might seem like we are “moving the goalposts”—or in this specific case “building the goalposts”—but given that I had no measure of success previously this definition may be as good of a starting point as any other.

The second direction would be to reassess our definition of success given the information that we have learned through our attempt. Failure is useful here because rather than discussing abstract ideas we have a real object (in this case a script) with a defined behaviour and outputs we can test and examine.

So failure has shown me I have a choice here between “I’ll call this good, and then I’ll iterate and make changes from here” and “I’m going to go back and rethink what I intended to do”. But I won’t be doing either of those because failure has one more lesson to teach me:

Failure can show us that we haven’t correctly defined the problem we are solving.

This might sound like I am about to repeat the first lesson but we can think of these two lessons as being about functional requirements (ie: what it should do and how it should behave) and technical requirements (ie: how it will do it).

An analog might help us differentiate these ideas.

Imagine a scenario where there is food on the other side of a river and we are hungry. Needing to get the food is our functional requirement and satiating our hunger is our measure of success. The boat we decide to build is our technical requirement for solving our problem.

It is easy to imagine in this scenario how each part can fail independently. Perhaps our boat isn’t up to the conditions of the river and sinks, perhaps we get to the other side and the food isn’t there, perhaps we eat it and it doesn’t satiate our hunger.

In this case with my script—and to mix a metaphor—my boat sank (and I wasn’t even sure what was on the other side of the river).

When attempting to solve the problem I had assumed there would be some kind of “wordgame dictionary” or other standard collection of words (like a literal dictionary) I would be able to use as a reference. In this case the puzzle uses a custom dictionary of about 6-700 words that are valid for each day’s puzzle. Typically when solving this puzzle we would enter our best guess and the puzzle would tell us if that was a valid word (ie: it was on the list for today).

In this case we can retrieve this dictionary in the game configuration—then the equivalent of a person trying a word on the web page—is to simply check if the word is on that list with our script. So if we extrapolate this we can assume that if our original dictionary (which is about 900K works) contains the 6-700 for that day’s puzzle we can solve it.

What do we mean by “solve it”? Based on the game’s rules it would be to find a number of words within the game’s “par” for that day. We could also say the optimal solution was the one defined as “Our Solution” in the configuration (it’s in the name).

If we redefine our technical requirements again now we have this new information it may become obvious that the actual technical solution might be just to email ourselves the game’s author’s suggested solution. Which is not really a coding challenge.

So given all of the planning and detail that went into writing this (in part 1) how did we not see this?

That was my last lesson about failure:

Failure can help highlight our blindspots and biases.

As much as I advocate for careful and thoughtful planning—collecting data, requirements, and predicting possibilities—no process is ever perfect. At some point in the planning process we may have to accept the risk of failure and move forward. 

Blind spots and gaps in our knowledge can be very hard, or even impossible to detect because we literally “don’t know what we don’t know”. The best analysis in some cases might be the one we make after we make a calculated risk by attempting to solve the problem.

We may be tempted to use the word faith instead of risk, but faith implies that we have confidence that something will happen the way that we expect. Accepting risk is actually the opposite. It is to admit that there is a chance that we’ll see something that we didn’t expect and that regardless of how much planning we have done we may fail. It is to accept that we are not only fallible but that failing (and accepting it) is sometimes the best outcome.

In this case the risk was negligible and the loss trivial but I have seen people spend millions of dollars on undefined problems with no clear definition of success. Learning to analyze failure and define success in a timely and efficient manner can be very important—when keeping going costs us resources that may be irreplaceable—knowing when to change direction or give up altogether can be vital.

When we approach failure as not just a possibility but as part of the process that can help and sometimes literally define success—it becomes just another tool in our process and our development (both software and professional). If you are open to failure it can change your life, if you don’t learn its lessons, it can change your life.

One of the most unexpected things I got from this process was the way I now play the game Letter Boxed. Now I strive for “failure”—literally trying to get as many short words ‘over par’ as I can. It feels different, deliberate, familiar, and very me. It keeps me open to the possibility that by doing something that I think I might not like, or may “fail” at, I may discover a new blind spot—or at the very least help define what I do want.

What this particular process has uncovered is that you might not want to hire me to write an algorithm but if you are wondering about the several millions dollars you are about to risk—I’d be happy to chat with you about that.