Introduction
While on a recent flight, I turned to the back of the inflight magazine to look for the crossword puzzle. This was something my wife and I could do to pass the time while we also tried our best to entertain our infant son, who was sitting on our laps. So we would take turns, one of us holding the magazine and reading the clues with pen in hand, the other, offering suggestions with baby on lap. We quickly dispatched that and, needing something else to fill up the time, I turned my attention to the other inflight magazine puzzle offerings: Sudoku.
I had done my fair share of Sudoku puzzles, but it had been a while since I really attempted to work through a puzzle. But as there was little else to do that would work as entertainment in the cramped space with a squirmy child, I decided to give it a shot. I chose the easy puzzle and started to work. I had an hour to complete my task.
I never finished. Maybe it was the lack of focus to be had under such conditions. Or maybe I was just out of practice. Or maybe "easy" was harder than I thought it would be and I simply overestimated my abilities. Whatever the reason was, the fact remained, and I had to put the unfinished puzzle back into the seat pouch as we arrived at our destination.
Frustrated by my inability to complete an "easy" Sudoku puzzle, what did I do? Did I decide to practice, doing puzzle after puzzle to hone my skills? Nope. My goal was to complete Sudoku puzzles, so naturally, I thought of the best way to accomplish this goal: write a program to do it for me.
The Program
I chose my favorite language of late, R, to write the program in. Perhaps not the most elegant language or most efficient for my task, but it would suffice. The process for solving the puzzle is as follows (feel free to skip if you don't care):
- Load the puzzle to be solved into a matrix
- Create a work table with a row for each puzzle cell containing:
- Row number
- Column number
- Square number (i.e., which 3x3 square block)
- Possible values remaining
- Apply rules for eliminating values from possible values remaining
- If a row already contains a decided value, remove that value from the possible values list for every other cell in that row.
- If a column already contains a decided value, remove that value from the possible values list for every other cell in that column.
- If a square block already contains a decided value, remove that value from the possible values list for every other cell in that square block.
- Repeat step 3 until no more changes are made (i.e., no more possible values are removed).
- Check if solved (i.e., only one possible value remains for each cell).
- If solved, verify results. If verified, print solved puzzle.
- If not solved or not verified, proceed to 6.
- Choose a remaining possible value for a cell and hold that fixed. Then repeat steps 3-5.
- If no solution is found, hold the next remaining possible value for a cell fixed. Then repeat steps 3-5.
- Do this for all cells until a solution is found and verified.
- Print solved puzzle solution.
Instead of taking an hour, it takes less than a second to solve a puzzle. Hooray?
Missing the Point
Creating the program to solve the puzzle was like solving the puzzle itself. I experienced frustration when my attempts didn't work, excitement when I had a breakthrough or revelation, and satisfaction when I had finally solved the puzzle (i.e., the code worked and solved the puzzles for me). But I don't experience that same satisfaction now whenever I feed in a new puzzle to solve. Wouldn't that be nice? If I could experience each time the satisfaction of solving a puzzle with my code in the same way that I would experience it in solving it on my own? But I don't.
This experience highlights a typical difference in the way people experience life: as a journey vs. a destination. Is life, and its constituent parts (like solving a Sudoku), to be treated like a destination or a journey? Whether any part should be treated like a journey or like a destination probably depends on our criteria for success. At least in the case of solving a Sudoku puzzle, the criteria would seem to be something to do with its ability to produce fun, enjoyment, and satisfaction.
In treating the object of a Sudoku puzzle to be merely the destination (i.e., solving it), I missed its primary method of providing satisfaction, which is the experience of solving it, not actually solving it. Sure, the actual solving is a part of the satisfaction, but it is only a small part of the experience, and hence, a small part of the satisfaction which comes from actually having worked through the solution myself to the final result. That is, the journey is the most enjoyable part, not the destination alone.
I am reminded of the hedonistic paradox: if you aim at happiness as your only goal, you will miss it; if you aim at other things, you will find happiness as well. In my attempt to automate Sudoku solving, I was aiming for the happiness of solving the puzzle, and I missed it.
So What?
This isn't really about Sudoku, but about life in general. I love automation and greater efficiency, but certainly it seems that some things should not and cannot be automated if we are to benefit from them in desirable ways. Particularly, if something comes too easily, we do not enjoy it nearly as much as we would have if it had come though challenges and obstacles. We like working at things to a certain degree. Projects, games, exercise, and other activities all have to be somewhat difficult, but not too difficult, to be worthwhile and worth doing for our own satisfaction and enjoyment.
An article in the Atlantic titled "A World Without Work" highlights the fact that we, to a certain degree, enjoy our work. And we are more miserable if we aren't working. It seems that the only thing worse than having a job is not having a job. Ask any retiree who has not transitioned to doing something else after retirement. We need to have some challenge, some goal, some project in our life if we are to find meaning in it.
So what am I saying? I suppose, automation and efficiency have their place and are important, but they may not be the most important consideration in designing and implementing a solution to a problem. It just depends on the goal. Many unpleasant tasks can, should, and will be automated most of the time. But those tasks we enjoy and find satisfaction in doing ourselves, shouldn't always be. I bet most things fall somewhere in the middle. Like work, many tasks are enjoyable sometimes and not so enjoyable other times. For example, driving is a chore a lot of the time, but occasionally (on backroads) it is fun.
Automating Life Appropriately
A simple and obvious solution is to use automation and efficiency when we want to (e.g., driving the morning commute) and not when we don't want (e.g., driving country backroads). As long as we have the option and can decide how and when we do things automatically instead of manually, we can have the best of both worlds. When I want to wash the car, I can pull out the hose and scrub away. When I don't, I can use the drive through. When I want get my hands dirty and use my muscles, I can dig away in the garden and mow the lawn. When I don't, I can get yard service. In this way, we can have the advantages of automation and efficiency without being forced to give up the satisfaction of doing it ourselves.
My Sudoku solver works great, but I think I'll do it by hand and brain the next time around. It won't be nearly as fast, but it will be fun. And isn't that the point after all?
