# What Sudoku Can Teach Us About Learning to Program

In this special guest feature, Jesse Anderson from Cloudera writes about the similarities of programming and playing Sudoku. Jesse works at Cloudera on the Educational Services team as a Curriculum Developer and Instructor.

There have been many articles touting the merits of entrepreneurs and business people learning to program. I want to add my voice as a resounding yes: everyone should have a basic programming literacy.  The ‘buts’ and caveats of teaching yourself to program are not always addressed, so I have taken note of a few things to think about before you embark on your journey.

I have had the unique experience that I’ve never attended a college class, but I’ve been programming professionally for many years. My experience in college classrooms has been as a guest speaker, and not as a student.

Many people talk about programming as more akin to math, but I like to compare it to Sudoku puzzles. Similar to programming, Sudoku puzzles use numbers, but that doesn’t make it a math puzzle because letters can be substituted just as easily. It’s a logic puzzle with certain rules.

The above image shows a Sudoku puzzle I’ve solved … or not. If you look at the box with the red numbers you’ll notice I’ve made a mistake and the 3×3 grid has two fives, which violates the rules of Sudoku.

This means two things: I have to figure out which five to remove. Then, I have to figure out which number should go there. This process is similar to debugging a program. As you learn to program, you will spend a decent amount of your time doing this task over and over again. Your fondest – and darkest – memories will be figuring out why your program didn’t work. Think of the most frustrating experience of your life, multiple it by five and add some time pressure for good measure. Simply knowing the rules or programming syntax doesn’t guarantee a working program.

As we can see in the image above, once we’ve fixed the issue with the two fives, we have two fours to contend with. This shows another fun facet of debugging; an issue is often made up of several different factors contributing to the same error. To fix an issue completely, you may need to fix it in several systems and with a different manifestation each time.

Speaking of recursion down the rabbit hole, here’s another fun one: let’s say you want to create a website that interacts with a database. Simple. Except you need experience with several different technologies to accomplish this. You’ll need a programming language (Ruby, Python, Java), a web framework (Ruby on Rails, Django), SQL/Relational Database, HTML, CSS and maybe JavaScript. Your simple program started getting bigger with more expertise needed. The bigger and more complicated the site, the more technologies and complexities will be present.

Have you ever played a game where your character or civilization had to acquire a new technology or skill before you could acquire the one you wanted? That’s called a technology tree. If I wanted to write a book, I’d need to know about literature, writing and the alphabet, to name a few technologies. One break in this chain and I can’t write my book. Likewise, programming has many technology trees. In the previous example, I mentioned JavaScript and HTML. You normally use JavaScript in tandem with HTML. In a sense, some knowledge of HTML is a prerequisite for JavaScript. Keep this technology tree in mind as you embark on a project. Make sure you know which technologies you’ll need to learn.

The next series of advice is something to keep in the back of your mind and not to keep you from learning to program. As you start, you will be able to do the easy tasks, but the complex ones will be outside of your abilities. You will know just enough to be dangerous. Your first version of the product will need to be completely rewritten. If you wait too long to pay the piper, the process will be less like ripping off a Band-Aid and will become more like quadruple bypass surgery. This is called technical debt and by that time you’ll be swimming in VC money, right?

You can spend your entire lifetime going down this rabbit hole we call programming. The question for you is how much of your time should you dedicate to this task? Is learning every nuance of programming the best use of your time? At a minimum, you should know the basics of programming. The rest really depends on the scope of your project or ambitions. At some point, management and programming at the same time become untenable and management usually wins.

Learning to program is definitely worth it. I’ve barely scratched the surface of other perks, like being invited to A-list celebrity parties. It’s going to be difficult and you’ll need to put in a lot of effort. At certain points you will want to throw something across the room and break it (usually a keyboard). You’ll know you’ve made it you when can stand back like a proud parent and watch other engineers tell you what you did wrong.