One of the most frustrating barriers to improvement is the idea that “we always did it this way.” The idea that once a problem is solved, there is no better solution has been proven wrong time and again. If that were true, then we would have stopped with a walkman and never known about an iPod. Thus, it is worth our time to revisit problems as we advance our skills. Doing so can provide better solutions or lead to addressing more complex issues.
Sudoku Patterns
The famous puzzle, Sudoku provides an excellent example of how to keep revisiting a problem. The goal of the puzzle is to enter the numbers 0-9 in a nine by nine grid. No number is repeated in a row, column, or 3 by three grid. Those smaller grids are denoted from top to bottom left to right in a manner that creates 9 of them. Some of the values have already been filled in. Thus, more straightforward problems have a lot of numbers filled in, while more complex puzzles will have fewer seed values.
The first thing we can do is look at it row by row. On each row, we look for numbers that have not been filled in. In this example, we will not be able to provide a solution just looking at rows unless almost all of the numbers have already been filled in. We can add in the ability to scan columns for duplicate numbers, and that does a lot to improve the complexity of initial puzzles that we can solve. When we add the scan of the smaller grids, we dramatically increase the types of puzzles we can solve.
We get to see another way to solve new problems as our knowledge grows in this example. We can combine approaches to a solution to create new and better solutions. In this example, we add the ability to scan rows, columns, and grids to solve harder and harder problems. For example, let’s say a grid has only the number 1 and two not filled in. If one of those rows has all but 1, 7, and nine filled in, then we know where the one needs to be placed.
A Coding Example
A simple coding example is the ability to enter data. When we start out in our career we learn how to gather data from a command line. We then learn how to take advantage of graphical user interfaces. Then we learn how to read from files. At some point, we add the ability to read and write across systems. Thus, even this simple case shows us how solving that problem once dramatically reduces the quality of the solution. We are constantly learning. This new knowledge makes it more than worth our time to regularly revisit problems rather than copying an old solution.
