Stepping back…

As the PSF election cycle begins, I’d like to share the news that I won’t be running for re-election to the board of directors.

If you care for a fuller announcement and explanation you can find it here – https://naomiceder.tech/posts/stepping_back/

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.

Python Education Summit 2014 Call for Papers

Python Education Summit 2014 Call for Papers

Do you have a story to share on education and Python? We are actively looking for presenters for the Python Education Summit and have extended the submission deadline. Please submit a topic you would like to present on. Interested in seeing the topics others are proposing to speak on? Have a look and vote for your favorites – help us define this year’s agenda.

Need some ideas for topics you could present? Maybe one of these topics will inspire you to share your experiences:

• The joy and pain of authoring a book on Python
• Teaching Python on a shoestring budget
• Gamifying how you teach Python to strengthen engagement and return on investment
• Using the Raspberry Pi to teach Python
• Tips for developing your Python-based curriculum
• How to choose what to teach
• Educating children to program in Python
• Educating seniors to program in Python
• Helping a student transition from Learning Py to Py Employment
• How to make money teaching Python
• Developing a community program teaching Python
• Train the Trainer: teaching volunteers to teach Python
• Exploring the resources available to instructors
• Choosing the right teaching resources
• Taking a student to the next level – guiding ‘self study’

If you are interested in presenting, please submit your ideas for topics/presentations that you would like to present. We will gather feedback on the submissions to assist us in building the agenda. All submissions must be in by February 25th and decisions on speakers/presenters will be made and speakers will be notified by February 28th, 2014.

NOTE: All speakers will be offered early bird pricing for attendance at PyCon.

Quick Python Book is Manning’s Deal of the Day April 12

The Quick Python Book is Manning’s Deal of the Day April 12!

That’s right, starting at midnight EDT, April 12, my book, The Quick Python Book, 2nd ed will be Manning’s Deal of the Day. What does that mean? It means that if you click on the link at the right and buy the book or ebook using the code dotd0412au, it will be half price. This deal will only last for a day or two, but it’s a good chance to pick it up a really good price! 

And the author will thank you! 🙂

Another Quick Python Deal

Just a quick note that the Quick Python Book, 2nd edition will be Manning Publications deal of the day Saturday, May 18. 

Here’s the official scoop:

Deal of the Day : Half off my book The Quick Python Book, Second Edition. Use code dotd0518au at http://www.manning.com/ceder/.

Also on the same code is Hello! Python (http://www.manning.com/briggs/) and Extending jQuery (http://www.manning.com/wood/)

And for anyone in Europe and the Americas, you should know that the deals usually run until past the end of day everywhere in the world. So if you don’t get it done on Saturday, the code might still work on Sunday morning. Just sayin’…

Number 2 for 2012

I’ve already put this on the social networks, but I can’t resist noting that The Quick Python Book, 2nd ed, AKA my book, was the second best selling book for Manning Publications in 2012. And I can’t even complain about missing number one, since that slot was claimed by Warren and Carter Sande’s excellent Hello World! Computer Programming for Kids and Other Beginners, another Python book! Python in the top two spots! 

As I’ve mentioned elsewhere, if you use the link at the right you can pick up either title for 50% off before the end of 2012 by using the code bestof2012

As for me, I’m just blown away that QPB2e did so well.

Happy new year to all in the Python community and thank you!

A few changes

This is a completely non-Python related post, but it probably makes sense to post this here, just for the casual observer. There have been some changes in my personal life that may make things confusing for some. I’ve been pretty public about this on my social media accounts, but quite a few people haven’t heard for various reasons, so here is the news.

 
The short version is that I’m transgender and I’ve legally (and emotionally, professionally, etc) transitioned to being female. So the Naomi you see now is (in some ways at least) the same as the Vern that used to post here.

 
That is all. 🙂

Turtlelab – A Simple Environment for Teaching Python

I started teaching Python to 8th graders years ago. We were already teaching it to all of our 9th graders, so I talked the 8th grade computer teacher into it (pretty easy since a) she was as very smart woman, and b) I was sort of her boss 😉 ) so that we could build a little buzz for programming before kids made it to high school. I started them just with IDLE and some text based programs, followed by some stuff from the LiveWires lessons and it was a modest success.

However… I felt I was spending too much time on the mechanics of using the environment and not enough on the actual prorgramming. This mattered since we could only carve two weeks out of the existing curriculum for the programming unit. I’d also switched to a curriculum completely based on using Python’s built-in turlte module, which became much easier when some us added several tweaks to the library for the 2.5 release, and even easier when Gregor Lingl’s brilliant x-turtle was adopted as the replacement for the turtle library in Python 2.6.

Still, I wanted an even more supportive environment than IDLE. I wanted something that would take care of saving – kids forgetting to save was pain in the rear, and a good way to kill their enthusiasm. I also wanted something that would offer help on the commands as they were starting out. Not code completion, exactly – for novices that can more confusing, but something that would enable them to find the command they wanted easily without leaving the enviroment.

So… I created my own. I used it and thought it worked pretty well, but never really got around to promoting it. Then Simón Ruiz started using it to teach our 9th grade class. Simón polished and refined the interface based on his experience and testing, and the result, if I do say so, is worth a look if you want to teach Python to kids using the turtle. It has the great advantage of being a single file, so installation is easy, and its only dependency is that it requires Tkinter and IDLE.

At the moment Turtlelab isn’t really under active development – I’ve since left teaching and Simón has other assignments, but I believe he’s considering a blog post or two in the near future focussing on it. 

Rather than explain it in great detail, I’m sharing the link to the BitBucket repository and you can go play with it yourself. And if you really like it and want to use it, please do. If you like it even more and want to take it over, please let us know – we love to have it in use and under development.

Get Turltelab here.

How Not to Get a (Python) Job – a rant

How Not to Get a (Python) Job – a rant

At PyCon 2011, Brian Moloney (of Imaginary Landscape here in Chicago) gave a talk titled “How to Get A Python Job”. It wasn’t really so much about getting specifically a Python job as about how to land any job. It was the same sort of advice you can find in a lot places – hints on how (not) to apply, how (not) to present yourself, how (not) to interview, how (not) to impress interviewers, and so on. If you’re looking for a job, go watch it and take his advice very seriously.

I went to Brian’s talk because I had just found my own Python job and I was curious about his perspective. I had started my own job search with my fair share of negatives – the economy was in the toilet, I was over 50, I didn’t have much formal training, my experience (in private education) wasn’t exactly mainstream, etc. And yet within 3 months of sending out my first resumé I had a job, and even had to turn down other offers. Even as I settled into my new job, I was frequently contacted by recruiters looking for Python programming help. And yet, I’ve heard many people complaining quite vocally about how difficult it was (and is) to find programming jobs in general and Python jobs in particular.

As the IT director and lead developer at a startup trying to grow its tech staff, I’ve been heavily involved in searching for and interviewing developers. In that process I’ve seen people of all ages and backgrounds painfully ignore the basics of getting a job. So the idea behind this post is to put one more voice out there, sharing some of the things that make me not want to hire an applicant.

Here are the things that make crazy. Take from them what you will.

Not knowing the market. Several candidates have said, “it seems like no one is looking for Python people.” Say what? I get called regularly by recruiters looking for Python developers. We’ve been searching for a Python dev for months. Admittedly, the market is better for more experienced people and you might need to relocate, but even junior Python dev positions are going begging. Ask any recruiter, we’re a hot commodity. When someone tells me that no one is hiring for Python, that tells me one of two things… either that person doesn’t know the job market (at least around here), or they aren’t really a Python developer. In the first case, I’m a pretty firm believer that the responsibility for finding jobs lies with the job seeker and not having done research on the market it a bad sign. If you don’t care enough to do research to find your own career, why should I expect that you’ll have the initiative to solve problems and help our team move forward? And the alternative is worse – in a market where knowing how to spell the word “Python” (at least on a resumé) should get you at least a few calls, not getting any traction is a red flag.

Not knowing the craft. This is so obvious that it shouldn’t need saying… except for the fact that it needs saying. “If you’re applying for a Python programming job, you should know as much as you can about Python and programming.” That means a basic understanding of the language, some basic knowledge of programming, some familiarity with the common or hot tools and technologies, etc. Obviously the depth of that understanding will vary depending on your experience, and for junior positions, particularly, you’re not expected to know everything, but you still should have some idea of the field.

I’ve interviewed candidates who couldn’t tell me how they would approach a problem, or what libraries they would use (or even have used), who’ve never even heard of Django, and so on. I’m no fan of springing little programming puzzles on candidates, since to my mind that mostly tests the ability to solve little puzzles, and I don’t expect lengthy dissertations on advanced programming topics, but I do expect you to be able to know the basics of coding and Python syntax, to have at least a nodding familiarity with current technologies, and to be able to discuss the approaches, tools and pitfalls involved in some of the coding you’ve done.

And speaking of the coding you’ve done, particularly for junior developers, you may not have done that much professionally. However, if you haven’t done anything outside of classwork, I’m going to be pretty skeptical. There are tons of opportunities to get involved in open source projects, to create your own web site, to help with something for a business, a club, or even just scratch your own personal software “itch.” It doesn’t matter how big or how successful your projects were, what matters to me is that you’re interested enough to be in the game on your own time.

Not knowing us (and the job). It’s been said before, but if you don’t care enough to do some research and thinking about us and the position before you come in for an interview, why should we think you’ll care once you’re hired? You’ve got the job description, probably some names of people at the company, and the entire Internet as resources. Even if you don’t have absolutely all the information, you should be able to find out enough to ask questions and maybe even float trial solutions. Why do you do x? How do you deal with issue y? Have you ever thought of trying z to solve this problem? Even if you’re completely wrong about your assumptions, the very fact that you’re thinking about our business is very compelling. If you want to be really sneaky talk about how “we” might solve some of those problems together.

And speaking of sneaky (not really, since it’s clear if you’ve done it or not), if you know who you’ll be interviewing with, look the people up online. Google and LinkedIn are your friends here. At worst you’ll have a feeling of control during the interview and at best you can work in a comment or question relevant to the interviewer’s background, which is almost always good. I’m not going to support hiring you just because you looked at my LinkedIN profile, but it does tell me you cared enough to do some research, and that’s a good thing.

Not selling yourself. Don’t go into your shell – there is a job open and somehow you’ve gotten an interview. So take advantage of it! You may be an introvert, it may be hard to talk about yourself, or maybe you just don’t think you should have to “market” yourself. Whatever… but in this situation you’ve really got to go for it. Show us how interesting you are, how much you care about the work, how cool you think the job is, how much you would bring to the team. If we hire you, we’ll have to work with you every day, so why should we look forward to that? (In a business sense, of course – promising to keep everyone loose with dirty jokes is probably not be the way to go here.)

We can only hire a few people and we need to get a lot of stuff done. We have lots of problems crying out for solutions so we want someone who is eager to tackle those problems and has some chance of succeeding. As Joel Spolsky succently put it, “smart and gets things done.” You may not have the exact sklls to fix every problem at this moment, but that’s not the entire point – as a startup none of us had the exact skillset for this business when we started. But all of us were ready to dig in, we figured it out fast, and we got the job done. And that’s the sort of person we need.

Note: this is not the same as emphasizing how good this job would be for you. I understand that you want to move from that old job to a new, more interesting area. I applaud the fact that you just love to learn new things. I’m totally on board with how wonderful this opportunity would be for you… but we need to move and scrub a ton of data, polish the UI, analyze customer behavior, and keep thinking of new ways to stay ahead of the game. How are you going to help us do that?

Please feel free to ping me with comments or questions: comments are not automatically published, so if you have a question or comment, please feel free to leave a comment and indicate if you want it to remain private.

Edit: If you’re looking for Python jobs you might try the Python Job Board, which as it happens is where I found my current position, or the PyCoder’s Jobs site (I have no direct experience with this one, this is not meant to be an endorsement), which is dedicated to Python jobs and run by the same people who do the Python Weekly newsletter (which I do find very useful, actually.)

[edited to add company name and contact info]

ISTE, Python and Robots

Monday I was at the ISTE (International Society for Technology in Education) conference in Philadelphia to give a version of the same talk I gave at PyCon in March, talking about my experiences teaching Python using the combination of Scribbler robot and Fluke bluetooth board developed by Georgia Tech and Bryn Mawr. I think the talk went reasonably well – 50 or so attended, and they laughed in the right places, which is my main criterion for success. I also got to say hi to a few old acquaintances and even meet a couple of new faces with Python edu-sig connections.

Although I was talking about a class I’d taught, and combining robots with Python, the other point that I hope the audience also got was the need to make programming classes relevant, real, interesting, and above all, darned cool. As anyone who’s heard me talk about it knows, I’m happiest teaching project based courses where we’re free to pursue interesting topics as they come up. Writing a chat bot in Python, plotting the Mandelbrot set in Java, or trying to crack passwords in C, it’s the joy of tackling a hard problem and doing something really exciting that has driven all of my best classes.

It doesn’t have to be robots, or necessarily Python, but if kids don’t leave a programming class feeling they’ve truly done something pretty amazing, I think we’ve missed the boat. That feeling I think is key to getting a more diverse group of kids into the field (yes, I mean girls, but others as well) and it should be within reach – there’s so much amazing stuff they can do.

I’m not alone in this thinking, of course. Many of the edu-sig gang have done great work in this regard, including Jeff Elkner, Kirby Urner and Brian Brumley, and many others. But we’re too few, and too spread out. In general, the state of secondary and middle school programming instruction in this country reminds me of the old Woody Allen joke about the Jewish ladies at the resort, “The food is so awful here…”  “Yes! And such small portions!” We have to keep working on that from all sides.

I was also surprised to find that I was the only Python related talk at all of ISTE. I’m afraid the joke is right – if it doesn’t cost money, it gets no traction at ISTE. Similarly, there were only a few other open source related talks, a sad decline from my first couple of years at ISTE (then NECC) as the Python presenter at the start of the Open Source Pavilion. Then it looked like open source software might make a real dent in one of the most commercialized conferences I’ve ever attended. I could seriously say that I went to preach Python and open source at NECC because that’s where the unconverted were. Well, the unconverted are still there, and more numerous than ever, I’m afraid.

Still, there were some encouraging notes. Out of the 50 or so who attended my talk there was one gentleman who was trying to get programming classes offered by his school, and who thought that Python and robots might actually be the way to persuade his administration to try it. Another was reworking an established program to include more Python as the capstone language, because, as he put it, “all the colleges are switching to it”. I truly hope he’s right on that one.

Finally, thanks to my employer Zoro Tools (http://www.zorotools.com) for giving me the time to go make the presentation – go buy something
from us – we sell nearly everything. 😉

And even greater thanks go to the Python Software Foundation Board for supporting my trip. My rather quick departure from Canterbury for Zorotools.com had left my travel to ISTE unfunded, and the PSF stepped in to help me for the second time. That’s probably something that the PSF should brag about somewhere – what other open source programming language’s foundation has cared enough about education to send someone to speak at big conferences like ISTE? If others have, good for them, but I’m thinking it’s pretty rare.