Stepping back from the board

The time has come...

As we head into the PSF election cycle, I'd like to let everyone know that I will not be running for re-election to the PSF Board of Directors and consequently from mid June I will no longer be serving as chair of the PSF.

Announcements like this always strike me as awkward, since they make two rather unlikely assumptions: that people will even notice, and that they will care if they do. But in the interests of transparency I'm going to go ahead as if both were true and share my reasons for this decision.

FIrst of all, I truly do believe that limited terms are good for the sustainability of an organization like ours. If someone is in a key role for too long, their inevitable departure and replacement can be unnecessarily disruptive and difficult, even with the best intentions. Of course "too long" can be hard to define, but I think it's safer to err on the side of leaving sooner rather than later. I also think it will be good for the PSF to practice handing off board leadership.

My other reason is that it's just time to move on. After five years on the board and 3 as chair, it seems like it's time to step out of that role and find something different to do, some other way to work for the Python community.

This isn't a dramatic change - I will be available to the next board as an advisor, and of course I will remain a passionate supporter of the PSF and Python communities around the world. So no, you're not getting rid of me that easily. :-D

I do hope that the PSF will continue to work on electing a diverse board, in all of the endless possible dimensions. For one target, I would love to see more representation on the board from Latin America, southern Europe, Africa, and Asia, as well as LGBTQ folks, racial and religious diversity, neurodiversity, and the rest.

If you're one of those people would help make the board more diverse but you're thinking, "yes, but there's no way that someone like me could be elected," well... I was thinking exactly the same thing when I ran for the board 5 years ago. There are no guarantees, but I believe it's worth a try, both for what you might bring and for the experience you will gain. So if that's you, get in touch - I'd be happy to talk about the board and what it involves, and offer any support I can.

It's been a privilege to work with so many amazing people on the board - we may not always have agreed on every point, but you would be hard pressed to find a group of people more dedicated to the success of the PSF and the Python community.

I'm also honored to have worked with the PSF staff as it's grown. They are truly amazing - smart, hardworking, and dedicated. I've seen their work up close, and believe me when I say that we're lucky to have them and they deserve all of the support we can give them.

As we move forward into the changes that the current crisis will bring, I have no doubt that the PSF and its board and staff will be more than up to the challenges ahead.

My time as chair of the PSF has been a lot of things for me - sometimes a challenge, often a learning experience, always an honor and a wonderful opportunity to get to know so many Python communities and their members. But above all it has been a rare and ridiculously improbable gift, something to be treasured, but also to be held lightly, and then passed on.

So long, and thanks for all the fish...

Notes on Teaching Python – Mental Models

Notes on Teaching Python – Mental Models

I admit it – I’m just an old, cranky teacher. As much I love seeing so many people all around me teaching Python, as much as I love the notion of spreading the joy of Python to various masses, there are things… things that give me pause. No, worse than pause, they give me a serious case of teacher twitch.

I start feeling the overwhelming urge to offer constructive criticism and helpful advice where none is wanted. I usually fight these urges, not wanting to be shunned by everyone as “that woman” (or something worse).

However, I also don’t want to end up in the corner muttering something like “get offa my lawn”. So I’m going to rant gently about some of these twinge inducers here.

What are we teaching, really?

I think one issue arises from a failure to ask ourselves what we really are trying to teach when we are teaching “Python”. It seems like a silly question, or a redundant one, but humor me. What are we trying to teach? Syntax? Best practices? Problem solving? TDD? OOP? What is Pythonic? Coding? Critical thinking? Computer science concepts? All of the above?

I’m pretty sure I’ve heard all of those answers at one point or another, and even given some of them. Yet I’m equally sure that something vital is missing when we talk about what we need to teach when teaching Python. And this something really holds everything else together.

The importance of a mental models

The missing “somethings” I’m thinking of (since in fact there are many of them) are mental models. We may not know every detail of how a thing works, but if we have an accurate mental model how it works, we can form some reasonable expectations about how it might work in different situations.

If I have a sound mental model of how AC current works and see that the lamp has a frayed cord, I can pretty confidently unplug it and deal with the problem. On the other hand, if I have an inaccurate mental model of how AC current works, I might either run from the room expecting the lamp to explode, or reach down and grab the bare wire. Neither is a desirable result, but yes, I’ve actually known people who fall into both categories.

The same is true in Python and coding. If we have an accurate way of thinking about a feature of the language, we stand a much better chance of getting code that works as desired. If we have faulty mental models, then the coding equivalent of electrocution or irrational avoidance awaits.

Take “variables,” please

For example what about “variables”? Yes, I agree that the term “variable” is questionable in Python. Yes, I prefer either “name” or “label”. However, it seems pretty much everyone calls them variables at some time or another, which may well be part of the problem. Several times now I’ve seen newcomers to coding being taught that about “variables” in Python. And many of those times I’ve seen the explanation that a variable is a “container that holds a value.” Or, as I used to say when I taught C, they’re told that a variable is like a bucket.

For C this makes some sense. And while no one should argue too much with the notion that the contents of a variable must go somewhere, in fact thinking of Python variables as containers is an inaccurate model – names in Python are more like post-its than buckets. But what makes the notion of variables as buckets even more insidious is that it seems to work well enough at first that people get used to thinking this way, and then pass it along.

Consider the following mindless code:

    a = 1
    b = a
    c = b
    print(a, b, c)

So far, so mindless. If you ask people what you get, they will not have a problem saying 1 1 1.

But suppose you then add the line

   b = 2

and ask about print(a, b, c)?

The followers of the bucket camp will usually (and correctly) say that the result is 1 2 1. In fact, there may be some confusion about what the “contents” of c are, but if you are thinking buckets, the answer makes sense.

But what about a mutable object? Suppose we have this:

    a = [1, 2, 3]
    b = a
    c = b
    b[1] = 5
    print(a, b, c)

Here the members of the bucket brigade are often stumped. In my experience I have been stunned at how many beginning (even intermediate) Python coders are surprised by the actual output of [1, 5, 3] [1, 5, 3] [1, 5, 3]. If variables are containers, how on earth can changing the contents of one change the others?

But if instead they are names that point to objects, the right answer makes sense. Once they have a better mental model of how names work in Python, such surprises (and the attendant bugs) become much rarer.

Let me be clear, this example isn’t the only case of poor mental models in teaching Python. I’ve picked on this example because it’s so fundamental and, in my experience at least, so common.

The question is not if our students will create mental models or not – we all form mental models as we learn. It’s our job as teachers to be thoughtful and help our students form useful and accurate ones.