(moderator)
We'll start shortly, 201. Hello and welcome. Our next speaker is a core maintainer for the OpenHatch project, a tutor of Python, both professionally and otherwise, and she founded
the University of Waterloo Women in Computer Science
undergraduate committee. So please help me welcome
Elana Hashman. Thank you. [applause] (Elana Hashman)
Hi everyone, I'm Elana. Some of you may know me
as E. Hashman. And I'm really excited to be here
to speak with you today about teaching Python,
specifically the hard parts. So I'll give you
a little bit of background on what motivated this talk
and how it became to be. In spring of 2014, Mako Hill
at the University of Washington put on a series of community
data science workshops based off the Boston Python
workshops curriculum. And these were aimed at individuals
with no previous programming experience, many of them graduate students
in the department of communication. The format of the workshops
was as follows. There is a setup session
on the first Friday night and then three
full-day Saturday workshops spaced two to three weeks apart,
although I believe they are now closer. I helped out as a mentor
at the inaugural first two sessions. And I thought they were super awesome
so I wanted to bring them to the University of Waterloo,
my own UW. So in fall of 2014, the Python Software
Foundation Educational Committee gave me a grant to run these workshops
at the University of Waterloo for students with no previous
programming experience. We worked with a group
of mostly undergraduate students in programs with no required
programming classes and no prior
programming experience, including some
graduate students and staff. And we held the workshops
in the same format as the community
data science workshops, with one setup night
and three Saturday workshops. And yes, that is a photo of me
doing a live coding demo. I was significantly more brave
in front of an audience of 50 people. If you're at all interested,
you can find a little bit more about these workshops on the UWaterloo
Undergrad Women in Computer Science blog. And I'll have a link
at the end of the talk. So we worked
with the initial curriculum from the community
data science workshops, which involved building enough
skills in Python to fetch data and do some basic
data science stuff. And things went really well and we had
excellent reviews from students. But that's not to say
we didn't have a number of problems. So in both of these
series of workshops, the organizers published
a reflections document on lessons that we learned
in the hopes that others would not make
some of the same mistakes. So expounding on that
and on my experience professionally mentoring
and tutoring Python at various levels, I wanted to share with you
some of the hard parts I've run into, both teaching and learning Python. So we'll start with
some problems I encounter that primarily affect
total beginners -- that is, individuals with no
previous programming experience. So in the context
of these workshops, our instructional team
consisted of a lecturer and a team of mentors, or TAs. And the first thing we noticed
at the community data science workshops was that most of the mentors
ran OS X or Linux, but the vast majority
of the students had Windows laptops. And when you're running
a bring-your-own-device workshop, you need to budget
for some setup problems. So we had scheduled that full night
for setup to try to predict and iron out any Python
installation problems so it wouldn't take away
from class time and engagement. We still ran into
a number of problems. And the mentors may not
actually have the skills to be able to diagnose
platform problems that they don't personally use. Some examples of this include
"python.exe not found" if Python was not properly installed
in the path at Windows install time. Which is really easy to solve
if you've seen it before and really difficult
if you have no idea what's going on, as finding the place
to stick this configuration value is not super obvious. String encoding for Unicode
on the Windows console. We worked with
the Python Twitter API, and one of our examples, which was
sort of a "hello, world" example, printed a real-time feed of tweets
from Twitter throughout the world. And the Windows console
could not display it because of character encoding issues, and it would throw an exception
and everything was very sad. And last, Python tries to helpfully
and quietly convert line endings automatically for Windows users,
which can cause unexpected problems, particularly when you're working
with binary files. So here's an example
of some code that we wrote at the Waterloo Python workshops
for beginners. The students are learning how
to work with the web APIs, and they're super excited
about using Python to do this programmatic stuff. So here we are downloading
this adorable placeholder image for the placekitten API,
and we open the URL, we read the data, we open a file
to write that to, we write the data to the file,
we close it. And then the students open up the file
to see the fruits of their labors. And guess what happens? So someone is like,
"My kitten is a demon!" And I'm like, "What?
What do you mean it's a demon?" And actually the kitten
that they had was indeed this demon kitten
on the left and nobody had a clue
as to what was going on there. None of us had used Python on Windows
or had this problem before. And it turns out
that if you run this code on Windows, Python helpfully tries to convert
all the line endings from DOS to UNIX, which corrupts the JPEG. So we realized
after a bit of poking around we needed to specify
the binary flag like on the right, and then this worked
totally fine. But it stumped our mentors for a bit
because only one person had worked with Python
on Windows previously. We had never seen
anything like that. So what can we
take away from this? First, you must anticipate
that you will have cross-platform issues
for your participants if you let them all
bring their own devices. Make sure you test
your examples and curriculum on Windows if you're supporting it in addition to any other platform
you intend to support. That way your students won't
encounter any unexpected surprises. So one of the first ways
we introduce students to Python is we have them fire up
the Python interpreter in a terminal. And sometimes we forget,
as instructors, that most total beginners have never
used the command line before. It's not something
they would have ever encountered. Now we were aware of this,
and we did spend some time introducing the operating system shell before talking about
this Python interpreter. But we still found
that students got confused. And we probably should have spent
more time working on this. So beginners tend to get confused
between the two shells and they'll type OS commands
into the Python shell or they'll type Python commands
into the OS shell. And a common example of this is
a student says across the room, "ls isn't defined anymore;
I don't know what's going on." And yeah,
that's because you typed it into the Python shell
and that's a problem. And of course, depending on what version
of Windows your students were using, and we did have at least one on XP
during the workshops in 2014, they will not be able to use ls;
they'll have to use dir. So you need to include that
in your OS shell curriculum as well, and be aware of
that platform diversity there. So what are our takeaways here? If your students'
first exposure to Python consists of interactive exercises
with the Python interpreter, take some time
to first get them comfortable with the operating system shell. Teach students specific
commands for each shell and how to tell them apart. So, is this the shell
with three arrows, or is this the one
that ends in a dollar sign or angle bracket on Windows? And version politics
notwithstanding, the question of Python 2
versus Python 3 is an important one
for your students. So hopefully
your students will ask you, "Which version do I install?" But more likely what will happen
is that one person will ask and the rest of the class doesn't
want to ask so they'll just guess. And so you get half of the class
that installs Python 2 and half of the class
that installs Python 3. And I don't really have a suggestion
which version of Python you should teach in workshops,
and that's totally up to you. However, there are some things
to be aware of as an instructor, depending on which version you pick. For instance, the Python 3 libraries
are incompatible with Python 2 in some cases
and have different documentation. Furthermore,
the search engine indexing is not that great
for the Python 3 doc, so you will often search
for Python whatever doc and you'll get the Python 2 doc
and it will be confusing because it will say
the wrong thing. And the beginners don't know that
until it doesn't work, and then that's frustrating,
and you get to figure that out together. So here's my takeaway from that. Trying to make everything
Python 2-3 compatible is probably going to be
a waste of your time. You should spend
your time teaching. It takes time away
from building your curriculum and may end up
confusing beginners. So just stay away from that. Pick a version of Python
that works for you and your group, proceed with that,
and make sure you are aware of Python versioning
at setup and install time. And definitely ensure that your class
is using the same version of Python and that it's the one that you've
written all of your examples for, or you might have a bad time. So those were some of
the most common examples we encountered with students
who had never programmed before -- issues that they had encountered. So let's talk about students
who are a little bit more advanced now. Maybe this is the second
or third workshop in a series, or you're teaching people Python that have some prior
programming experience. And so these are students
that are a little bit more advanced than our Python workshops
for beginners or community data science
workshops crowd. When I say "student,"
this isn't limited to the context of workshop
or classroom participants. Much of this can also
be applied to tutoring or a professional mentoring context. We are all ongoing students
of Python as far as I'm concerned. So a common question
that I've encountered is, "Why do we write foo.keys()
but range(10)? Why not keys(foo)?" And you may be tempted to answer, "Well, one is a function
and one is a method." But for a student
that doesn't have any previous object-oriented
programming experience, this sounds arcane,
isn't relevant, and doesn't really
answer their question. Because certainly in other languages
keys(foo) is totally fine. And another question you might hear is,
"Well, when do I use foo.sort() "and when do I use sorted(foo)?" And then you really
might be tempted to answer, "Well, one mutates foo
and the other doesn't." That's important,
but what is mutation? What's a function? What's a method? Trying to explain this all
to relatively junior students is overwhelming and confusing. They don't have the tools
to understand this yet. They've only been programming
for a few days or weeks and most CS programs
at the university level give their students a year
before they introduce object-oriented programming. So they just don't have
the tools to understand this yet. So what can we do about this? I would prepare
for these questions because I suspect it will be
something that you encounter. And the different syntax
with seemingly random usage can be confusing to students. Mentors should be aware of this
and ready to help out. You don't need to teach your students
object-oriented programming to help them with finding
the right syntax in different contexts. One really great thing about this
is a student may ask you, "Okay, well is it foo.len
or is it len(foo)?" And you blank out for a moment because you haven't written Python
in a few months, and then you say, "I don't know;
let's go look that up together." And this helps to reinforce that even
experienced Python programmers can get confused
or don't know everything. And it gives your students
permission to feel the same way. So as your students
get a little more mature, you want to start teaching them
the skills to ask questions and fend for themselves, and this is
a great opportunity for that. Looking up documentation
is great here. And finally,
I would strongly advise you to avoid introducing OOP
to beginners, or near beginners,
if at all possible. If you have to talk about it,
put it at the end of your curriculum. Programming is not
software engineering, and this kind of design
takes experience to motivate. In fact, I would go
so far as to say that I give you permission
to teach your students OOP, but only after you have covered
a unit on testing. So testing can be a blind spot
for some people. My university's
computer science classes didn't start requiring tests
until my second year, and then after that class
they became optional again. And the later you introduce
testing to your students, the more optional it seems
and the harder it is to get into the mindset
of doing it as a regular activity. There's a temptation
to try to cover as many cool language features
as possible. You want to focus on the shiny
and the awesome in these beginner workshops,
and testing feels a little bit like eating your vegetables,
so it's maybe harder to motivate. And I'm guilty of this. I didn't even think
of talking about testing in the Python workshops
for beginners. So I might justify that
to myself saying, "Well, these are, like,
complete beginners. "Is this really something
they need to learn right now? "It's not like a distraction."
So there's a question: Is there a place
for something like this in a curriculum
for total beginners? And I would say
I think the answer is yes. Unittest is easy
to get set up and running. And it's certainly
no harder than urllib2 or third-party libraries and APIs. I do think there is
a place for this in curriculum, even for the most
inexperienced students. Many of the students ask,
"Well, how do I know this is right?" Or they express worry
that when they write code, they're just kind of throwing stuff
at the wall until it sticks. And testing can help them build
a more disciplined mindset towards writing code,
and build their confidence in what they're writing. So my takeaway from this
is that I think you should consider including some curriculum on testing
if you're planning on teaching Python, even if it's for complete beginners. And even if you decide
you don't want to cover this as a unit, you still have the opportunity
to gently introduce testing. For instance, you could include tests
in your examples when you're lecturing, or in your sample code
that you distribute to your students. Okay, so you're proceeding
through your curriculum. Everything looks great so far. Your students are building
these awesome little programs and they're at the point where they
have enough foundational skills to put some really cool
things together. So what happens when they try
a more ambitious project? What happens when the code
gets too big to fit in one file? And where do you put all these tests
that I just told you to write, right? So you have some options here. You could maybe ask a mentor;
this is something that I often do. You could also despair. And I'm not joking about this because,
as a professional Python programmer, this is something
that I've struggled with. The documentation is poor and everything seems to be
different between versions. And it's not just different
between versions on one thing. There are various axes
that are problematic if you're dealing with absolute
versus relative imports, if you're dealing with namespaces
versus packaging, which is that packages are the same
as namespaces except when they're not, and everything is terrible. And as a bonus, as soon as you choose
to split your code out into modules, you get the added joy
of dealing with setup tools. We're obviously all
very joyous about that. So what can we do about this? First, we breathe. And then we pick
a strategy that works for the version of Python
we're using and our group. And we can offer our students
a templated solution which solves all these problems. So here's an example I put together
for my highly important cat analyzer project that I can feed
images from placekitten into. And so we've got a base directory
and a __init__.py file and our tests and the readme
and a templated setup.py, and we include code with absolute
imports as you can see on the right. And this may also be a place
for an opportunity in your curriculum to talk about circular imports
and how to avoid that problem, since students
are unlikely to be aware that that's even
going to be a problem if this is their
first time programming, and they may accidentally
get themselves in trouble when they try to split things up. So in conclusion,
if you're teaching non-beginners, or even if you're
teaching beginners and you're working
on a long series of workshops, please cover this
because it preempts what may be a large source of stress
for your learners. We can ease this documentation gap
by using our expertise. And I think maybe part of why this
is a common curriculum gap is because, as instructors, it just seems so obvious
how to structure our code. But for what it's worth,
this can be a point of frustration for new Python programmers, coming from many years
of experience in other languages. It has definitely been
a pain point for me personally. And hence, I'd like to encourage you
strongly to cover this at this level. If you don't cover it, make sure
you can provide your students with resources that they can
access in the future to help them with these things. So, on to intermediate students. In this category, I'd like to talk
about learners that come to Python with previous programming experience
who know how to write software but they just haven't
learned Python yet. So intermediate students
often ask questions about Python's scoping to learn
how to reason about their code. Is it lexical?
Is there some dynamic scoping? Is something else going on? And Python is a little special
because of the way we declare variables. So things
don't necessarily work out the way people might expect
from other languages. And this can be very frustrating. So while confusion over Python's
scoping could be a talk in itself, I'm going to stick with just one
common confusing example and we'll chat
a little bit about that. So here I have
some cat swapping code. So at the top level,
I have a cat which I've set to 'meow'. And then I define this cat changer
which sets cat to 'purr'. And I run this code
and what happens? Oh no, it didn't work;
why didn't it work? Well, it turns out
that variables in Python are local to the scope
in which we assigned to them. So the cat we assigned to
was a local cat inside of cat_changer, and not the cat
at the outer scope. There are a bunch of different ways
we can address this scenario. We can teach students
to pass in a reference so we can properly
mutate the value. We could approach the problem in a way
that doesn't require mutation. That's like a shoutout
to my closure friends there. We can even refer to cat
as a global variable. Various solutions
are going to be better suited for students of different levels,
so guide them appropriately. And another scoping problem
that relates back to building modules. Now that I've split up my code
into all these different files, how do I share variables
or state between the two? So you should do this very carefully. In some of the other talks
I imagine you've seen thus far, you might have seen
some of the problems that come from, for instance,
not using fully qualified namespaces. So please, please, please
teach your students to do this, and it will save everyone headaches. Another common problem in the space is how we might pass around
global config variables and using a single config.py module
is a great idea and considered Pythonic. This is actually a really gentle
and easy example for beginners. So here is how I might include
a config.py in my cat analyzer. So what can we take away from this? First, Python's scoping rules
can be tricky even for experienced programmers
using a language for the first time. And trust me, I wanted to put, like,
5,000 examples in here but then I restrained myself
and decided not to. What you teach your students here
will be very dependent on their level. In a classroom context,
you can try to cover some worst-case
sort of heads-up scenarios where students
will run into trouble. And if you can,
talk about scoping rules in detail. And if you can, show your students
how to share global variables and state between files
in a Pythonic way, because this helps a lot
with putting things into modules. So, packaging and deployment,
students want to ship their code. And a lot of students
will come into your workshop motivated to do a specific thing. Beginners especially want to write
a cool dynamic website or a mobile app. And a key thing to be aware of is that they're not doing it specifically
because they want to come learn Python. They're at your Python workshop
because they want to learn how to do a cool thing.
So they ask me, "How do I write a web app?
How do I write a mobile app? "How do I package and deploy
command line Python application? "How do I write a Python service?" And I promised you in my abstract
I'd cover this section. And I didn't want
to completely disappoint you, but I'm going to maybe
follow my advice here and maybe abandon hope. And if you were at either
maybe Glyph or Paul's talks earlier, you might have some idea as to why. Python packaging and deployment
is difficult even for language experts and this section probably deserves
a dozen talks all on its own. So you can go and look up
some of them on YouTube. So I'm going to skip over these slides
but I'm going to include them in what I'm uploading
to Speaker Deck and my website, and I'm just not going to talk
about this right now because it's a mess
and will make all of us very sad. You're like, "Look, look at this;
this is -- this is terrible." dh-virtual and Debian packages, sweet! Last, I'd like to close with some advice
for students of all levels, general advice that I think
really helped bring our workshop experience
to the next level for our students, and also explicitly speak
to some overall high level advice I kind of hinted at
throughout the talk. So first, be aware of your own
shortcomings as an instructor. Know your knowledge gaps. This doesn't make you
a worse instructor. It makes you more focused
and able to address unknowns. If your students need you to know
Python on Windows, then you can go and learn
Python on Windows. This doesn't have to be
a knowledge gap for you. Less is more; resist the temptation
to offer your students a sampling of the whole language in order to try
to demonstrate all these cool features that they might use later. Instead, focus on building
foundational skills. They will be more confident
and feel more secure if they grasp the material well,
and this will encourage them to pursue their studies
because they won't feel that they're proceeding
with a weak foundation. Next, make sure to bring together
a supportive educational team and don't underestimate
how much this improves both your own experience
as an organizer and your students' experience. We consistently got feedback
that the mentors at our workshops really improve the student experience, since I couldn't give all 50 students
sufficient one-on-one time. Thus we aimed for about a 1 to 5
mentor to student ratio, and this ensured that all of the students
were able to receive sufficient personalized attention. Next, make sure you seek feedback
from your mentors and from your students
and iterate on that feedback. We definitely did a lot better
by workshop three in comparison to our first workshop. Students noticed and they appreciated
that we incorporated their feedback. It made them feel heard and valued and it gave things
a more collaborative feel. As for your mentors,
you couldn't do it without them. When you value
their input and criticism, it strengthens your instructional team
and brings you all closer together. So we actually held a closing
mentor dinner after every session to talk about the good and the bad, and they were an awesome experience
for everyone involved. And they helped us
from an instructor level also improve
a lot of the student experience. Next, make sure you treat your students
with patience, empathy, and respect. And the same goes for your mentors. Sometimes we take
our knowledge for granted and forget that things
that come effortlessly to us now used to be really, really hard. So you should make sure that you set
reasonable expectations, maybe even lower than you might
have expected to begin with. And get excited about
your students' small victories. Let them know
that it's okay to be confused, and reinforce that
with your own fallibility. Create a culture in which it's safe
and okay to not know everything. Give your students brain breaks. This gives them time
to work on examples, reinforce their learning,
and socialize and make friends. And make sure
you take care of your students. One of the top pieces of feedback
we got from the students was that they really appreciated
how healthy and tasty our lunches were over the usual university free pizza, and how considerate it was
that we accommodated all their dietary restrictions. Like, at an eight-hour workshop,
this really makes a big difference. When you go out of your way to care
for your students' well-being, it makes them feel positive and valued,
and ultimately helps them learn, and motivates them
to learn even more. Last, I would encourage you to encourage your students
to build community. One of the most awesome
parts of our workshops was that we
brought together students from a lot of
very diverse backgrounds. At the University of Waterloo, we're somewhat known for our isolation
between the various faculties. So students in arts don't talk
to students in science who don't talk to students
in engineering. And it was
a really great experience for the students
to be able to make friends that they would have never
run into otherwise because of this
sort of faculty siloing. You have an opportunity
to help foster these connections. So supply your students
with the tools to do so: Give them mailing lists,
you can help them connect via social media,
set up outside meetups, organize sessions for them to work
on their homework together, etc. So, any questions? [applause] (moderator)
We have time for a few questions. Please direct your questions
to the speaker, and hold the more open-ended topics
for after the talk, thank you. (audience member)
So if I'm going to teach basic procedural programming
as the foundation, I've always got this choice
between imperative statements and data structures. So what should I start with -- the imperative statements
or the data structures? And how do I organize that? (Elana Hashman)
That's a good question. I'm not sure that I can give you
the all-encompassing one correct true answer. We certainly started
with working with some statements, showing students
how to add up numbers, and then sort of slowly eased them
into working with maps. And we found that actually maps
were pretty confusing for them, whereas doing math
in Python was not. So that worked out
for us in our group, but it may be really cool to focus on
a more data structure-driven thing. I guess it really depends on
what your students' backgrounds are, what you feel comfortable
teaching, that kind of thing. (audience member)
Hi, thanks for doing this talk. It's really helpful.
I just finished my first semester teaching Python
to undergrad non-CS majors. And I notice that you didn't
really touch on code style, and I was wondering
what are your thoughts on teaching something like PEP8
along with the curriculum? Or how much to emphasize that
for people who have no experience and it's a victory just to run
a program let alone style it. (Elana Hashman)
Mm-hmm, so one of the reasons that I did not touch on style or PEP8 was that we did not run into
a huge amount of difficulty with that. So I talked a little bit
about best practices in terms of
code structuring overall. Not so much with linting
and that kind of thing. The size of the projects
that our students were working on were relatively small,
like under 100 lines. And as long as it ran,
we were super happy. We didn't want to distract them
with the other details. So certainly in the context
of like a semester-long course, that might make sense. (audience member)
Hi, thanks for the talk. At what point would you recommend
introducing source control as a concept? (Elana Hashman)
That's a great question. So one of the reasons that we
didn't touch source control is that we were working
with total beginners. We were working on
very relatively small things. If, for instance,
they came into some mistake and they needed to blow away
all of their work and start again
from the beginning sample code, that was totally fine. I would recommend
probably teaching students Git because Git seems to be the most
popular source control right now. But Git is actually really confusing
to teach beginners, in my experience. And we did not want to take away
from the programming content by adding in source control content. So if we were doing something
which had more workshops -- We really did not have
that much time. Three workshops is not a lot
to teach total beginners. I mean, they're going
from zero to something. So if it was a longer scope thing, or if we did that
in a separate workshop, and the Women in Computer Sciences
run a number of Git workshops as well, but not in the context of both together;
maybe if the scope with a little wider. (audience member)
Thanks for your excellent talk. I got the point about save OOP
for late but get testing in early, and unit testing you said
is easy to set up. But the question there is,
isn't a unit test all about subclassing test case
and then you write methods and there's self all over the place --
so in setting up unit tests, aren't you putting OOP
right in their face at that point? And what do you do about that? (Elana Hashman)
So I guess the issue is that Python is one of those languages
where you can't really hide OOP from your beginners
at any stage in the process. Like when we do foo.keys,
that's OOP right there. Now in terms of
these sorts of examples, working with unit tests
and whatnot, I mean for the most part when you're
working with these beginners and you're providing them
with code samples that they can
play around with and modify, you're really just
giving them templates. And if you have
a sort of keener student who asks and really
wants to know more, you might want to sit them down
with a mentor. But I would try
to deflect those concepts until you start
having them organize code into larger modules
and things like that. I'm not saying that --
I certainly -- there is a sort of
chicken and the egg problem there. But it's difficult
to be able to motivate OOP if students don't know
how to program, and this is one of my pet peeves
with Python as an instructional language
is you can't hide that. (audience member)
Thank you. (audience member)
What about actually getting the students to code
and coding together? In my experience I can show them
assignment statements and say, "Now let's go
make this function "that will make
an area of a rectangle." And they seem to have gotten
the concepts when we talk about it, but then they stare at you
like they don't know what to do once you say, "Now do it yourself." (Elana Hashman)
So to be clear, is the question about the students independently
programming outside of the context of the workshop, or is it about
them working together on things? (audience member)
Working together on things in the workshop. (Elana Hashman)
Okay, great. Luckily for us, that wasn't actually much of a problem,
and I think part of that was that one of the things
that we told our mentors to do is, if a student came to them
and asked them a question, we'd maybe look around,
and often there were a lot of students
with the same question. We'd put them together
and we'd make them try to work through it
together first before the mentor came in
and kind of deus-exed their example. So that tended to work really well. And students just organically
worked together on a lot of these things,
I think because they felt comfortable doing so,
because they're like, "Well, none of us kind of know
how to do any of this stuff. "We're not from backgrounds
that we would expect "to be doing programming.
So it's cool, "we should work together
as a team, combined intellect." So, luckily,
that wasn't a problem for me. But you can definitely do stuff
to foster those collaborative interactions
in your classroom. (audience member)
So one of the hardest things for me to explain to students
is scoping, especially when you have global variables
and local variables with the same name. Are there any metaphors that you use
to explain what a scope is to students, and also to help explain
all the different rules that come into play
when you have a global variable and a local variable
with the same name? (Elana Hashman)
That's a really great question, and I feel like
I'm really poorly equipped to answer that
because I'm a math student and this is just never
something I've thought about. So why don't I give you
a rain check on that one. I'll try to think of a metaphor,
maybe I'll tweet it or something. (audience member)
Yeah, it's tough for me too. (Elana Hashman)
And I'm just going to switch over to my "thank you" slide so you don't
just get to see the cute kitten. (audience member)
I was really curious -- you mentioned a couple times now,
both in questions and else, that you don't want to explain object-oriented programming
right away to beginning students. And I mean, I struggled for my
first time teaching Python to kids. It was third graders
so it was a big challenge for me. But do you have any suggestions
or strategies -- how can you deflect those questions
but still give them some useful information,
so that they, like -- there is a difference, but like... (Elana Hashman)
Yeah, I mean, these are really hard questions. And, I don't know,
as a professional programmer myself, obviously I've developed
these excellent skills at deflecting when people ask me
really hard things. So you don't want
to deflect too much, because students may ask you
more pointed questions. But you can deflect while giving them
an answer to their question. So for instance, in the case of
"Why do we use foo.keys and not keys(foo)?"
The answer is, "Well, that's the way
it happens to work in Python." Because it's not canonically true
that it is wrong to use keys(foo) to get the keys
out of a dictionary. And in doing that,
you don't have to talk about, "Well, it turns out
that foo is a dictionary, "and dictionary is an object, and
there's iterables and blah blah blah." Yeah, you don't have to worry
about any of that stuff. (audience member)
Okay, thank you. (audience member)
Thank you. Really great talk. I really enjoyed it.
I have a question. You mentioned specifically
things like unit testing, and difficult it is sometimes to get intro students
to that kind of reasoning. Could you share some thoughts
about doc testing that you might have
experience with? (Elana Hashman)
Sorry, could you repeat the question? (audience member)
Dock testing. What are your thoughts
about dock testing? (Elana Hashman)
Not something that I've looked into, sorry. (audience member)
Sure. (audience member)
Hi, thank you for your talk. So I do a little bit of instruction
of non-programmers, non-technicals at my job, and have
very constrained time to do it in. So I just wanted
to pick your brain on, if you had only 90 minutes or less
to do a lesson, what would you do? (Elana Hashman)
Oh, that's not a fair question. [laughter] If I only had 90 minutes or less?
I don't know. I wouldn't talk about programming.
I'm a math major. [laughter] You're going to motivate it, right? (audience member)
I just wanted to say thank you for pointing out the whole thing about
even the experts have questions. Because that's a big barrier,
I think, to a lot of people to think,
"Well, I have stupid questions." But if you see people asking each other
who are supposedly teaching, then you realize that it's okay
to ask the stupid questions. So I just wanted to say thank you
for doing that and we need more of that. (Elana Hashman)
Thank you. I think this is gonna be
our last question. (audience member)
Hi, so I have a question regarding the pain points
of the whole setup process. Have you explored doing --
downloading virtualbox, giving them an image
and doing that kind of setup? Have you ventured that way? (Elana Hashman)
So the way that we dealt with this for Windows users -- so the community data science workshops
did involve some NumPy examples and so trying to get this set up
on Windows is a mess. So what we did on Mako's advice was
we got all of the students to install Anaconda on Windows and also on OS X
because that was just easiest. And on Linux we kind of knew
how to deal with the problems, so we weren't super worried
about anticipating them. So this actually
worked out super well. Now, we didn't have them
dropping into an IDE or anything for that sort of thing, but that
also comes with all that stuff. And it does come with a -- especially on a Windows environment,
it's mostly clean. So you don't have to worry about
the VirtualBox thing. That is like
a 300-meg binary to install, so we actually had problems
with wireless in the very tiny room
that we were teaching in. And so we passed it around
on USB sticks, so that's a possible solution
to this sort of thing. I have not looked into -- there's been no vagrant stuff
that I've looked into or anything like that like that;
that's maybe too complicated. (audience member)
Okay, cool, thanks. (Elana Hashman)
Awesome, so thank you everyone for coming to my talk. Thank you
to all of these awesome people that helped me
with various stages of my talk. Thank you to Rackspace
for sending me here. Thanks to the closed captioners
who I'm sure did an amazing job, and all of the conference staff
who have helped make this talk possible. If you want to find
some links or resources or the slides,
I threw them up on my website. [applause] Thank you, captioners! [applause]
