No Geek Bulls**t Programming Class (Results so Far)

The Project

Create an accessible ‘learn to program’ class, using Python. Undo damage and barriers to access around geek culture, endemic sexism and racism, and models that say that “only certain people can program”.

Bits and Bites (at TC ExC0)

Choose Your Own Pyventure (Wikibook)

Results So Far

So far there have been two class sessions. The gender mix (self-identified) is about 50/50/0 male/female/(genderqueer, intersex) and we have 10 students or so. The self-identified goals of students included: building programs for work, changing careers, remedying previous bad programming class experiences, (rarer) learning python specifically (after knowing some other language).

Lessons Learned (and some Theories)

# Make the class accessible

• No alpha male bulls**t
• No pissfighting over languages, programming backgrounds, etc. remember, even experts start as newbies.
• create safer, accessible spaces (physically accessible, make childcare credits available, advertise to underserved communities. avoid gender / sexuality assumptions, respect pronouns. Enforce safer space.)

# emotions matter in the learning experience

• acknowledge the complexity of programming

• programmers are made, not born
• programming is hard to do, hard to learn
• explain that it was hard for you to learn as well.
• remind learners that making mistakes is how one learns to program

# Start far back. Go back further. Most students know little about how the computer works.

• they haven’t seen / heard of / used the command line / terminal
• they don’t know the difference between the shell and the python environment
  • they try things like ” >>> python program.py “
• there will be mac and windows users, prepare for both
• some learners will have programmed before, some will not

# Have a goal / main project for the course

• connect with students.

• build toward a full project
• lessons should iteratively replace / improve / expand on code made during previous lessons
• no math. Math algorithms are boring and irrelevant for most people. Python makes strings easy. Easy strings makes for easy to discuss, real-world data

# Don’t get bogged down in syntax. People don’t care. Python has awesome syntax, mostly.

• Gloss over warts and complexities
• Avoid jargon

# Don’t get bogged down in datatypes. Don’t mention unicode. Ignore tuples.

• Do mention strings, “numbers” (encompassing ints and floats)
• dictionaries before lists. Associating keys and values parallels associating variable names with values. After teaching dicts, lists are trivial.

# relate functions and data structures. They are intertwined and need to be taught in parallel.

• Functions exist to process data structures, and data exist to feed functions

# Ignore Objects and Object-Oriented Programming

• OO isn’t hard, but it is confusing, especially for newbies
• More importantly, it’s *irrelevant* for most early programming tasks

# Now matters more than Complete

• Use Wikibooks or Google Docs for ease in sharing materials. (if repeating, we might choose GDocs — Wikibooks is too much machinery)
• Don’t worry about getting all the details right

# POWERPOINT IS DEATH

Learning Programming: Dissecting a Turd

As mentioned in my introduction to this series, learning to program is a series of lurching steps forward, sideways, and back, leading (if all goes well) to a better holistic understanding of the process.

In many rationalist disciplines, there are learning exercises that require grokking the whole and the parts in an iterative process, until a fullness is achieved. As learning occurs, one filters out more or the irrelevant detail. Think of learning to drive, or to speak a new language, or music theory. Without knowing “the point”, the big picture, the details are just noise, and tedia. Most programming (cf: math, stats) books and courses stay focused on the details far too long. What’s missing are activities that combine the micro and macro views fluidly. Code analysis fits the bill nicely.

One of the unsung marvels of the open-source movement is that it exposes mountains of good and bad code for all to see, of every imaginable pattern and anti-pattern.  Some of the code even works, despite of (or because of) its ugliness.

Learning to read others’ code is an under-explored pedagogy tool. It’s well and good to read the sort of well-commented, rational, toy examples that one finds in books, but it’s quite another thing entirely to learn to read other peoples’ eccentric, human-created code, warts and all.

Python has some nice advantages for this sort of exercise*. It has an interactive interpreter, and even the worst python code is still pretty easy to pick apart, for most reasonable length examples, using common modules. Give me Twisted, and I can give you write-only code, but that’s my failing, not the tool.

So, as my service / penance for all the bad code I’ve unleashed, I’ve decided to comment and describe the weird mishmash of ideas and patterns existing in a first generation, but working, application I wrote.

Learning Programming: Introduction

More people should know how to program*.  More resources are available than ever to help one learn.  Pc’s are ubiquitous, and the open source movement and the internet make powerful languages of every flavour (C, Python, Haskell, R…) and difficulty easily available, along with extensive documentation.   It should be a cakewalk, right? So why aren’t there more programmers?