Teaching isn’t completely new to me—I spent the last two years researching computer science curricula for kids—but leading a class full of information designers certainly is. As the Summer 2015 Python Friday instructor, I’ve been exploring creative ways to teach high level programming to Fathomites with limited formal coding experience.

Rather than focusing on how certain projects are coded up, the Python Friday lesson series takes a “bottom up” approach with a focus on combining “powerful ideas” with “language design.”

Powerful ideas are concepts that appear in many programming languages and environments, including Python. Common paradigms like conditionals and iteration, each a powerful idea, serve as fundamental building blocks of computation.

These ideas are particularly powerful in combination. For example, say we have a list of city populations. With iteration, we can do useful things like print all of the populations, sum them, or find their average. But if we add conditionals to our computational repertoire, we can solve more specific problems like printing all the populations within a certain range, finding the average population of the cities in a specific region, or determining the two cities nearest each other out of the list’s one hundred most populous.

During lessons, when we approach a new problem with Python code, we discuss which powerful ideas will be required to arrive at a solution. We also think about the scope of what is "computable" with the set of powerful ideas we’ve covered, and how they can be brought to life with Python’s syntax and keywords. By highlighting these ideas, I hope that students can use them to break down problems into manageable parts as well as recognize which tools are necessary to solve them.

The second theme of these lessons is learning to think about a programming language as the result of many design decisions. I was particularly excited about this topic because many Python Friday students are professional designers!

One aspect of programming that can bother beginners is the equals sign. "I never saw anything like x = x + 1 in my middle school math classes!" Why use an equals sign when it already stands for something familiar?

It turns out that some programming languages actually use the notation := instead of =. From a design standpoint, the additional colon helps denote that := means something different than = and could perhaps make learning programming a bit easier for first-timers. However, from the perspective of a practitioner that writes lots of code, typing := thousands of times per day is much less efficient than simply typing =. It may also be easier to read a program without hundreds of colons on the screen.

Programming languages aren’t perfect—far from it—and they aren’t very old either. By engaging with these design tradeoffs and their history, I hope to help my students become both proficient and critical programmers that view languages as systems that can be improved with their participation.

Currently, we’re four sessions deep and the Friday crew has plenty left to learn. Despite this, some of them are already realizing Python’s immediate potential as a language for writing quick programs on the fly. In the past week I’ve been delighted to see little Python projects popping up around the office (check out the Processing sketches in Python mode above!). Who knows? Maybe a student project will inspire its own blog post down the road…