Volunteer Feedback
Caylee Hogg
Jake Brownson
morning section when we were introducing ruby concepts. I got to work
with a lot of students individually and see a lot of "ah hah!"
moments. Very cool.
The biggest thing that I think could be covered more effectively in
the Ruby section is the difference between a class and an object. I
sat down with maybe a half a dozen students during a break in the
slides around then and had them instantiate (yes I used that word :))
multiple Counter objects (making sure to use that word) and
incrementing them separately and showing them how they behaved
independently and according to the things we defined in the Counter
class. I also used the metaphor that there is an idea called "Person"
and you and I are both instances of Person. Person is like class, I'm
like the Counter object we defined as "a" and you're like the one we
defined as "b". I used a lot of repetition and emphasis of the key
words "object", "instance", "class" backed up by examples in the
console and I think it was pretty effective. I actually heard some of
the students I worked with ask great questions later in the class
using these words.
I think as we started to get in to Koans and Rails I saw a bit of
frustration building up and much fewer "ah hah!" moments. When I went
around asking folks how it was going they started saying "eh pretty
good" rather than asking me questions. This is probably okay, but if
we made the decision that we're really not trying to teach rails, but
more demonstrate/show it so the student won't be afraid to go through
a proper tutorial at their own pace it might alter the content a bit
and make it more effective. Another option might be to add a day to
the workshop, make them shorter, go through a real quick _demo_ of
rails at the end of the first day hitting some key concepts, let ruby
and the demo sink in over night and then dig in to rails the next
morning when people are fresh again.
I thought it went really well though. All of the hard work everyone
put in to preparing their presentations, slides and the logistics
really showed through. I'm really impressed w/ the Portland tech
community and am looking forward to being involved in more things like
this!
Jake
Addie Beseda
Gabriela
helping others. It was a tricky thing to teach non-programmers about
rails in one day. And this one was a good experience for things to do
next time.
Yes, the koans were great and I think a break for lunch before them is
needed. Also I saw people (that had some programming experience)
having a hard time with the concepts of testing. Maybe for next time
we can add some concepts about testing in the ruby/programming section
in the morning. Then when we explain the koans they get a better idea
on how they work and can do them without problem at home.
I also wrote a few notes on things I think could change about the curriculum:
- hash example at the slides about data types were a little confusing.
Maybe present the hashs without "mixing" data types and then saying
later you can use anything there.
- code for the class Counter needs to be written in a file and not in
irb so people can read the whole code. Some people already forgot what
the code was before and it was hard to take track of the whole Counter
in the irb.
- local/global variables. In the morning talking about scope maybe is
a good idea to understand concepts later.
Great job everybody!
gaba
Igal Koshevoy
I'm amazed again by how successful a ragtag mob of ad hoc volunteers
was at creating something amazing. We did well and our students
learned a lot. Thanks for being a part of this!
Major things I felt needed to be improved:
* We need to foster stronger dialogs between students and their
neighbors, teachers and assistants. Those students with stronger
dialogs got more out of the class and got stuck less.
* We need a checklist to make sure all students have a complete
installation before we begin teaching the class.
* We need a computer skills tutorial before we start teaching about
programming or Ruby, because many students had never used a shell or
text editor before, and this hampered their ability to follow the
instruction.
* We need to improve our instructional materials so students can more
easily understand the commands and code they're seeing and what to do
with it.
* We need to deliver the materials at a comfortable rate that students
can consume it, rather than rushing through content at such a fevered
pace that students get nothing out of it and grow frustrated.
ON DIALOG
I felt that the most important factor of success was a student's
dialog with others.
Those students that had a healthy dialog with their neighbors had more
fun, learned more, and were more likely to ask and give help to each
others. Students that established a dialog with teachers were more
likely to ask questions that were valuable to the entire group.
Students that established a dialog with the assistants were able to
learn more and get unstuck quickly.
Ways to improve dialog:
* Let everyone -- including the students -- introduce themselves each
day so we all have a name, face and story to connect with.
* Spend more time explaining that we want students to ask each other,
the assistants, and teachers if they have issues or questions.
* Teachers should deliver materials at a comfortable pace, so that
students have time to think, experiment and ask.
* Assistants should check every student regularly to ensure they're
okay, rather than waiting for them to ask for help. Many assistants
hung out on the couches in the back, waiting for someone to fetch them
if they were needed, which rarely happened. The issue was that
students thought that all the assistants on the floor were swamped and
stopped raising their hands, waiting until one of the assistants on
the floor did their rounds to check on them individually.
* Setup the room so it's easier for roving assistants to get to the
students in the front and center of the class without interrupting
everyone.
* Have more breaks so students and assistants can catch up, understand
and relax.
* Have an optional party with food and drinks at the end to celebrate
the end of the workshop and allow people to get to know each other,
talk more about what they learned, ask about what they didn't
understand, and otherwise strengthen relationships. This could be
setup so each person pays for themselves at a nearby restaurant.
ON INSTALLATION
Many students were unable to complete their installation, but didn't
realize it. The problems didn't surface until the instruction began,
e.g. the instructor was rushing ahead explaining Ruby concepts, while
students were struggling with broken Ruby interpreters or missing
files, and waiting for an assistant to fix their installation.
We need a checklist to ensure that students have a complete, working
installation before we start teaching. For example, assistants should
check their:
- Text editor
- Git and version
- Ruby and version
- Gem and version
- Ruby Koans checkout
ON COMPUTER SKILLS
Many students were good with computers, but had never used features
that programmers rely on. The students lack familiarity with these
features meant that they spent much time fighting their computer or
lost, and missed much of the instruction.
For example, the "Ruby Koans" section didn't work because many
students lacked the computer skills required to follow along or hadn't
finished the installation. Addie was blazing through the intricacies
of the Koans, but most of the class was totally lost because they
didn't have the Koans or know how to find them on their computer, or
didn't know how to navigate directories in a shell or use a text
editor. Worse still, because this section "had" to be delivered before
we could eat lunch, it was rushed through to completion without
adequate comprehension, and many assistants and I spent most of lunch
fixing student's installations and trying to explain what they missed.
We need a tutorial that teaches at least these computer skills:
- How to start a shell
- Understand how directory hierarchies work and how to navigate them
from a shell using `pwd`, `ls`, `cd` and tab autocompletion.
- How to work effectively with multiple windows, such as switching
between them quickly, organizing a bunch of terminal windows while
still knowing what they do, putting terminals and browser-based
instructions side-by-side to make it easier to work, etc.
- How to use copy-and-paste, and warn them about accidentally copying
a bullet point in a web page will cause it to paste as a shell comment
symbol "#" that prevents execution of the command.
- How to critically read output from commands to recognize errors and
what to do about them
ON INSTRUCTIONAL MATERIALS
Students had a hard time following along with some of the
instructional materials. These problems hurt students' ability to
understand the material, and caused them to type invalid code or
commands that got them stuck.
We need to improve the instructional materials:
* Make commands and code look visually different than the
instructional text. Possibly also make Ruby code look different than
shell code.
* Show results that commands are intended to produce so the student
can see output without having to enter the commands if they're behind,
or know what to expect to see.
* Properly indent multi-line code and draw graphical lines to show how
multi-line instructions are related to each other. E.g. draw graphical
lines between the `class ...` and `end` lines, and then the `def ...`
and `end` lines within the class to make it clearer how that code is
grouped.
* Provide students with the commands and code to paste and explain how
to use these before teaching. Many students had a hard time typing all
this tricky code correctly before slides changed or weren't able to
figure out how to use the slides.
* Only give students exercises involving things they've been taught at
the time. For example, there was a particularly awful exercise asking
students to write an ActiveRecord trigger to uppercase a string --
which could only be accomplished if the student knew at least a dozen
rather complicated things that hadn't been taught yet, including a few
counter-intuitive gotchas they should avoid.
ON THE HARM OF RUSHING
Teachers tried to deliver ALL of their material during their
timeslots. The rationale for rushing was well-meaning: they wanted to
give students more information. Unfortunately, information was
delivered faster than students could consume it and this caused many
to get lost and fall behind. If it weren't for the roving assistants
helping students individually, I believe that many students would have
given up in frustration.
The worst problems came up during the "Rails" portion of the workshop.
This section was so rushed that I didn't get a moment's rest during it
because I was continuously helping students that had gotten lost and
stuck. The rushed teachers would often briefly show a slide filled
with code and begin talking rapidly about concepts. The students would
start typing in a panicked rush because bad things would happen if
they didn't finish typing it all in before the slide changed. They
often missed much of the verbal instruction because they were too busy
typing. Trying to listen and type under pressure caused many typos and
students would get stuck. Students wouldn't ask the teachers questions
because they had screenfuls of errors related to code shown many
slides back. Students stopped raising their hands for assistants
because they could tell that they were all busy and instead just
waited for an assistant to come by. Meanwhile, the teachers continued
rushing ahead, thinking students were doing fine because they weren't
asking questions or raising hands.
We need to deliver materials at a comfortable pace that students can consume it:
* Structure the workshop so that teachers do NOT need to deliver all
the material. Having materials left over at the end of the day is
fine, because students can continue working on them later.
* Structure slides featuring code and commands so they can be
displayed for as long as possible, and ask the students if they're
ready to move to the next one, rather than rushing ahead.
* Structure the instruction so that assistants are welcomed and able
to slow or halt the teachers when enough students fall behind.
* Consider structuring material in a self-paced way so that groups of
similarly skilled students can advance at different rates through the
materials.
CONCLUSION
I feel that this workshop delivered a lot of useful information about
the local tech community, programming and Ruby. Some things went well,
others didn't. I think the evident passion of the teachers and the
continuous support of the roving assistants helping individual
students was vital to helping them stay engaged. I think we did a
great job for a first effort, and now have many concrete ideas on how
to make the future workshops better for our attendees.
-igal
Jake Brownson
Sam Livingston-Gray
coherence and attention to detail. (=
Two of my coworkers attended the event. One went as an instructor;
the other went as a student.
THE INSTRUCTOR:
The coworker who went as an instructor tweeted this during the event:
"NTS: don't introduce brand-new programmers to Rails. Too much magic
before basics are understood."
(Link: https://twitter.com/#!/jwilger/status/105046376232124416 )
To be fair, I think he only came in on Saturday afternoon when some
people might have been flagging, but this does echo my concern that
Rails is probably too much for an introductory workshop. I should
probably flag the next paragraph as...
A QUICK EDITORIAL INTERLUDE:
I was thinking about this a bit yesterday, and it seems to me that, in
the amount of time available, we could offer a workshop that's an
introduction to programming in general, or an introduction to Rails in
particular. Trying for both seems like cramming several hundred
gallons of material into the proverbial five-gallon bag.
THE STUDENT:
The coworker of mine who went as a student just sent this out to our
office-wide mailing list:
> I have to admit, after a long week, I found myself wondering why I signed up to
> attend a programming workshop Friday night and all day Saturday. Once I got there, my
> attitude changed. I have only positive things to say about this workshop. The student
> teacher ratio was aboutt 1:1. The teachers were thorough when giving instructions,
> patient as we encountered issues and had a good sense of humor. I had a great time. I
> made my computer do stuff to data! Honestly though, I learned a lot and hope that I'll
> be able to perform some of the tasks (like removing certifications from the contractor
> sidebar) that I am constantly asking the devs to handle. I highly recommend attending
> an event/workshop with this group.
I just wanted to throw that in there as a reminder that, as critical
as developers can be of ourselves, at least one student had a really
great time. (=
-Sam
On Tue, Aug 23, 2011 at 1:17 AM, Igal Koshevoy <ig...@pragmaticraft.com> wrote:
Ian Dees
Thanks, everyone, for putting on such a fun workshop. It was a blast
to be a part of it. The notes from Igal and Sam capture the event
really well; I'll just add a couple more observations:
1) At least one student found the "microrant" directory name
confusing, because the name didn't convey the information that this
was an existing example Rails app that everyone was expected to run
and modify. She immediately renamed hers to something like
"rails_example" so she'd be able to find it when she was going back
and forth among the slides, text editor, and command line.
2) One student asked for fewer repetitions in the core concepts in the
morning; I wasn't there for that half, but it sounds like this comment
was referring to basic string / array / hash / variable examples.
3) One student suggested that we get the help of an adult education
specialist (perhaps by reaching out to pdx11) to bounce our curriculum
material off. Another student is an expert in a related field
(library science) and is willing to help--I'll send her the address of
our Google group and ask if she'd mind joining.
4) Here's a question that seemed to go unanswered by our material:
what problem do routes solve? A mention of the bad old days (/foo.php?
bar=baz, .htaccess, etc.) might help explain why we use routes to map
URLs to Ruby code.
5) Git, even just cloning, adds a lot of ground we have to cover for
such an introductory workshop. It means one more dependency to
install on machines--and one more concept we have to take time,
attention, and slides to explain. An alternative might be to have
everyone just download and extract a zipfile from GitHub during the
install-fest, so they already have everything they need by the day of
the workshop. Point 'em at version control at the end of the day as a
next step.
Again, great job all!
--Ian