Intro to Programming should just be logic puzzles - Steven Sawtelle

Intro to Programming Should Just Be Logic Puzzles

Ask a programmer what language they think that a newcomer’s first programming class should be taught in and you’ll have nearly as many different answers as there are programming languages. The reality is that we’re still not that good at knowing how to teach people how to code. Python gets out of your way and reads almost like English, Java has more industry adoption and forces you to learn types, C++ lets you get intimate with memory management. Every language has its sell. The legendary Edsger Dijkstra once wrote a plea to the budget council of UT Austin on why Haskell should be kept over Java, which he viewed a “mess”. In it, he made one important point that I want to focus on here:

“It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits.”

It is this emphasis on “thinking habits” that almost all of what being a “good” programmer boils down to, in my view. You can spend years learning to code, but if you have a fundamentally poor set of tackling new problems, you will still find yourself ineffective. This fact is what has driven the highly controversial rise of Leetcode-style interviews, where toy problems are given to candidates in an attempt to suss out in one hour their fundamental ability to solve problems.

With how clear it is that having your brain set up to tackle problems effectively is important, I find it incorrect to argue Haskell vs Java or C++ vs Python. Instead, I propose that we start programmers out with no programming at all, and instead give them logic puzzles as their intro.

While not limited to only Japanese creators, the name “Japanese logic puzzle” is commonly used for a specific type of grid-based puzzle that tickle the brain in almost the exact way that a good programming problem does. While I won’t go into detail on it here, a really solid example I would give for this type of puzzle is one called Slitherlink. Popularized by the same company that brought sudoku to the masses, Slitherlink is a relatively simple game: create one contiguous loop that fills a board with all of the numbered squares adjacent to the corresponding number of line segments of the loop. It takes less than 10 minutes to explain the rules an go through an example.

See here for the rules and here for some strategies to start solving puzzles. Play the puzzle directly online here!

While it may seem to just be a game at first glance, any programmer who does the puzzle will find themselves feeling almost as if they are programming. One part of the puzzle forms, another part of the puzzle forms, you synthesize your mental model of how different parts interact, and the lines blur on whether you’re solving a Slitherlink or optimizing a sorting algorithm. When I do a Slitherlink, the corners of my brain that are satisfyingly itched are identical to what happens I solve a good coding section at work.

I think there are a number of benefits that starting students with puzzles would provide, but the single biggest advantage I would argue is the increase in accessibility it would give our field. I cannot tell you how many times I have told people I am a programmer and they tell me “Oh I hated math, I could never!” (It’s also a reason I generally dislike the term software engineer over programmer, as equating what I do with the work of something like a civil engineer feels extremely disingenuous to both parties). This is made even worse by the fact that our field has a special problem with diversity, and the type of student to say they didn’t like math is often the exact type of representation that would make our whole field stronger for being included. If we were to be honest about how little math is needed for 99% of us (I rarely use anything more than basic geometry/algebra) and instead focus on the absolute thrill of working through a difficult problem piece by piece until crescendoing it into a beautiful solution, we would surely do a much better job of hooking in students who would otherwise give up on the monotony of dealing with compiler errors that read like gibberish to them.

There are plenty of programmers all too happy to gatekeep the field (looking at you, Stack Overflow), and in the absence of a strong counter impulse, they will win by default. Not only would puzzles be an awesome way to start your first programming class, they would show you that this big daunting major is actually fundamentally easy at its core. Just like with a Slitherlink puzzle, take the code logically and piece by piece, and you’ll find a beautiful solution in no time. In fact, why not make your first big project an automatic solver for the logic puzzle you started your course working on manually?

Remember, the violinist is altered by their choice of violin. A professional’s mind is unable to be altered by the tools they use. Rather than nitpick the specific language we start students on (which matters just a little bit), let’s get them addicted to, and very good at, solving tricky problems (which matters a lot bit).