Hacker News new | comments | show | ask | jobs | submit login
A better way to teach technical skills to a group (miriamposner.com)
171 points by mdlincoln 571 days ago | hide | past | web | 21 comments | favorite



I did the same for my classes last year - beginner/intermediate Python, SQL, web development at a part-time night school for adults. Wrote a long detailed tutorial and let the students self-pace, with a bit of an intro at the start of most classes. Then the TA and I jumped in to help when students needed it, mostly by looking over their shoulders - I like the post-it idea.

A couple of issues with this approach:

- Make sure your material is good. Bugs in the material led to me repeating myself 1:1 a lot, and having to pause the class occasionally. Which leads to:

- Pausing the class is hard! People are at different stages of the material, so it's hard to find a good stopping point, though I did it a few times when something was either not resonating, or folks were going too fast and I sensed they were copy-pasting rather than fully understanding the point.

- The solution to this is to have 'core' material and then 'extra credit' stuff, but people feel behind if they haven't done all the material; nobody's happy only doing the core. In general, fear of "not keeping up" was a big issue in my class.

- Finally, some folks do learn differently, and you have to account for that. I spent a lot of time 1:1 with a couple particular students who weren't getting the tutorial format. Another felt like class was just "doing homework" and dropped out. I got around this by sending videos in a flipped-classroom approach between classes, but my students didn't have a lot of spare time and I couldn't rely on them doing anything outside class.


In a similar vein, there's a really great talk by Eric Mazur, Physics professor at Harvard about peer instruction — https://www.youtube.com/watch?v=WwslBPj8GgI

He goes into why he started exploring the idea at first (students got 5's on their AP physics exams and had strong problem-solving skills — plug-and-chug — but poor conceptual understanding), the many iterations of the approach, and the data he collected on the way (significant increases in open-ended, conceptual problems, including at other schools that adopted the approach). Really fascinating.

I haven't watched the shorter version, but someone edited they key points down to 18 minutes: https://www.youtube.com/watch?v=rvw68sLlfF8


Minor note, but it's awesome that students outside network analysis courses are learning to use Gephi! It's such a cool and easy-to-use tool. I regretted not doing as much network theory in my CS education--I only really got into it after despite my favorite professor being a network theory researcher. Gephi makes playing around with graph datasets and transforming them into useful visual representations so easy--it's like the Excel of network theory, which is awesome. Despite the criticism often hurled at (and in many ways, rightly-deserved criticism) Excel, it is, if nothing else, accessible.


I consider this the "normal" way we learn ( one-on-one ). Since the instructor can't be one-on-one with everyone, he/she offloads the burden onto the students themselves - which is a good thing. The psychology allows them each to facilitate their own sense of "flow" instead of having it shoe horned into them by the facilitator.

This isn't to say that the other style of teaching doesn't have its place , but at its core (IMHO) resides in a more imposed tradition of social order, military influence, etc..


My alternative to the post-it system: high-fives

I teach a course introducing students to making plain webpages in HTML/CSS/JS. We haven't tried the group aspect yet, instead we have people pair program - one laptop between every two students, with them switching 'drivers' every 10 minutes or so, driver types while the other person narrates what's to be done and points out typos etc.

When a pair reaches the goal for a particular task, I ask to high-five loudly. Not only does this help them get more comfortable with each other (they're complete strangers and only come together for this single day course), but it livens up the room a bit while giving me feedback and without being too threatening to those who are still working.


Interesting. I've had exactly the reactions she talks of, and have tried all the previous methods she mentions to get students to ask questions, and nothing has worked well. I will be trying this next term, hopefully it will do the trick, as there is always someone who refuses to ask questions, but will ask a neighbour instead.


At work there's often new tools and processes being built and used and I've been noticing that many of my co-workers struggle to figure out the new stuff. Its frustrating to have them go back to old ways when we're in a time crunch too, since it means that new tool isn't taking shape. I've long abandoned the "brown-bag meeting" as a way to share with my peers, because it never seems to work. What's been much more effective has been one-on-one time with others, when I can carve it out.

Obviously this isn't very scalable to a larger group though. I'm depending on the grassroots effect to take hold at some point and for others to spread that knowledge. Its effective, but not as quickly as I'd like. I may have to try some sort of workshop style like this in the future to get us to the point faster.


Not a substitute for your suggestion but what I found one thing that spread best practices at my last job was code review. I do something, the reviewer points out I could do it more efficiently, or use some library or solution in the project that already exists, or explains how the build system works and how my new rules don't quite fit and how to make them fit. etc....


I have always felt like the conclusions I come to myself, from directed learning, stick far better than the things I'm just told. This looks like it will encourage far more of that, wish this had been commonplace during my time at school/college/university.


1. Recently I was reading how in the early public school system, students of a widely different age all sat in the same class.

The bigger kids will learn first from the teacher, and in turn, turn around and teach the younger ones.

At least according to this article, it works. Maybe high school can also benefit from this.

2. I find it intriguing that a professor say this:

> Third, it’s fun for them. They can laugh and joke with each other, rather than sit in silence as I repeat information that’s right in front of them anyway.

Usually the teacher is doing his best to get the class as quiet as possible.


Great piece. I also thing it is not a great idea to have students follow along with the demo. Just ask them to watch and ask questions first and then leave as much (if not more time) for them to go through the tutorial at their own pace. For example, when teaching Git I spend some time drawing out the workflow, then model a successful commit, and then ask everybody to follow suit at their own pace. At this time I would normally walk around and help any stragglers.


I've been reading Jane McGonigal's "Reality is Broken" this semester and think she has some great suggestions on how to get students to learn - make it an attainable goal. Videos games do this well, she argues, because the player can see that a goal (say, the end of a level) is entirely possible, given the skills you've learned and demonstrated before.

For my programming courses, I give 3 different types of assignments each week: a typing exercise, a Q/A style set of questions, then a problem. No "make a loop print the numbers 1 to 5", but something like "implement standard deviation".

I've talked about the typing exercises before on HN, give the students a picture of code and make them retype it. They can't copy-paste, which is one of the mistakes of beginners, plus it gives them a fully functioning implementation of that week's topic. It doesn't have to be huge, something like 50-100 lines (this is Java, so that isn't as much as it seems). Students have given it a positive response this past semester and I'll be adding it to some other classes as well.

The Q/A questions are traditional multiple choice/true-false/fill in the blank style questions. I won't lie, it's blatantly taken from MIT's Open edX 6.01 course, though tweaked to prevent Googling. The questions range from simple concepts like what is the end result of a conditional statement, to number of loops, to having to implement a small amount of code to determine the next integer in a seeded random. McGonigal discusses how in a game, the risk of failure is reduced by allowing the player infinite tries. If they fail, they don't get slapped with a 0, they are free to try the question set as many times until they get the 100%. You have to be careful, otherwise you'll get the person that just guesses, but overall it is a successful tool.

Finally, the problem sets are again similar to MIT's 6.01 course. This is actually my current pain point, as I need to implement an automatic grader to repeat the infinite tries from above. They are given the problem, along with some test cases of what to expect. This is the first assignment that doesn't have a clear A to B section, which is done purposely to facilitate their problem solving skills. To help, I do the same thing as the author by making my class time lab time. I do like the ideas of paired programming and Post-Its, so I might look to implement them in the future.

The big thing I'd same McGonigal's book suggests is "Make the assignment seem attainable". This helps defeat the stereotype threat. If step 1 each week is literally "retype this program", it gets harder for a student to say "I can't do this".


I teach data journalism to a class of ~20 students with no teaching assistants and it sounds like my curriculum has some overlap with the author's. I spend the first few classes focused on spreadsheets -- including formulas and pivot tables.

After that, I go full on into SQL. This was initially motivated by the fact that SQL is a pretty important skill, and it is one of the most succinct ways to describe the concept of computationally joining two datasets to find interesting insights...which is basically the core of journalism (e.g. a list of names of business owners and a list of names of political campaign contributors)...but I've found it's a great way to teach computing in general. For most of these students who have never programmed, SQL is the first time that they've had to tell a computer exactly what they want. For example, I used to think it was a pain to have to specify every column you want to see with a `SELECT` statement...but this is in perfect contrast with how Excel works. The latter by default shows everything, and this has implications with not just computer performance and dataset size limitations, but in data filtering...that is, you're forced to see all the data columns at once, even if it's far too much to consume. With SQL, it's about knowing exactly what you want to see and telling the computer to do it exactly the way you want.

On the teaching side, this makes things far easier for me. I no longer have to teach a GUI, which is a long series of me saying "Click here...unless you're on PC/on version 2011X/have a window size less than 1024px wide" and writing tedious guides of screenshots. With SQL, I just write SQL. And the exercises can be stated in plain English.

For the exams, I basically made them write out a bunch of queries on real-world datasets which I described in plain English...I gave them the expected results, and so they had to write the queries that got the answers. Very easy to grade and very easy to give them help on (they were take home exams):

Baby name data: http://2015.padjo.org/assignments/midterm-babysteps-sql/

Medicare data: http://2015.padjo.org/assignments/midterm-wsj-medicare-walkt...

And to comment on the author's experience with the "stereotype threat", in which students of traditionally minority groups hesitate to speak up because they feel they are being judged by that group, e.g. xkcd #385 http://xkcd.com/385/...this is definitely a phenomenon. Last year I had a nearly all female class and they had no problems at all speaking up/out at me. In elective programming classes with more males, they generally were more reserved.


Thanks! I'm also a big fan of your data journalism Python exercises: https://github.com/compjour/search-script-scrape/


Those baby name questions are pretty neat! Thanks for sharing this.


Yeah, I think I'm going to steal the dataset for one of my classes!


Help yourself! I find the baby name data a great scenario for teaching data...everyone has a name, everyone has assumptions and opinions about how popular and genderized their names are, and everyone is fascinated by how many/few other American babies share their name. The data is structurally simple -- 4 columns, 5 if you use the state-by-state version -- yet numbers in the hundreds of thousands of rows. Plus, even being so simple, it contains virtually all of the "dirtiness" of real world data.


Love the post it idea! Will try that with my class next time around. We typically do a hybrid approach and have the students that finish ahead circulate the room and act as TAs helping those falling behind.


Hack Reactor uses this method for all of their first 6 weeks.


I love the status by Post It Notes. Definitely going to do this in the future.

My experience lies in "quick start" technical training, largely centered on CAD software for engineers. They are generally a tough crowd, and they demonstrate many of the behaviors mentioned in this great piece.

Over time, I also centered in on not having a follow along. It just never works! People are too diverse in their skills and how they process information. Plus, there are the ones who are able to follow me perfectly, but don't seem to catch the concepts at the same time. I see them rushing through bits here and there attempting to get it their way, or at their own pace.

There are a few things I would add to this method:

1. Play foot ball coach. There is this task ahead, and it's the documented one. Show 'em the highlights and talk through "the play", setting expectations and putting them on watch for a few "gotchas" they may experience. Don't do the whole thing. Just the highlights as a mixed mode, lecture for concepts, quick demo to actualize key things they want to know. Leave the easy stuff to their own self-discovery.

2. This one may be a bit controversial, but I've had awesome results with it.

Prepare to leave the room. You will actually leave for a few minutes too. Setup a simple problem for them to solve, and lecture through the bits they need to solve it. Provide documentation on those same bits.

Just prior to leaving, tell them why and that you will be right back in 10 minutes or so.

The reason you are leaving is to get them to question. In fact, the more they question, the better it will be when you return! Instruct them to write their questions down, or queue them however they want to, and to talk among themselves, and finally, that you will demonstrate one or more solutions to the little problem they are about to attempt.

If they attempt it and have success, that's great. If they attempt it and fail, those questions are exactly the ones they need answers to, and the best way to get at them is to actualize the struggle well enough for them to pose them meaningfully.

Then just leave. It doesn't have to be long, nor should it.

Be sure and return while they are still supposed to be working. You can hand out a little help individually, and or share experiences with some of the students who did see success and are choosing to do the same.

When the time is up, it's up.

Direct their attention to your part of the room, and walk through the solutions. This will generally be an interactive experience, filled with their comments, questions, comparisons and contrasts of solution methods, etc...

Then grant them a little more time to take one of those solutions and solve with it. The ones who didn't have success will likely get some, and those that did will explore a different solution.

3. Take time to lecture on some of the best practices, and the why and how behind how things are. These can be very informative and helpful sessions. Often, there are ways to think, and there are the ways the software or system creators think. Understanding both of those can really help with intuitive discovery and solution finding.

In these, the basic ideas behind whatever it is get put into context, case studies, work experience stories, whatever makes sense.

4. Free time allowance.

Each day, make sure there is some unstructured time. People often want to explore something they discovered in class, or they just didn't have success with one or more of the lessons and concepts.

This allowance of time is for closure that day. They can get some remedial help to get past a problem area, or they can free style and apply what they learned, etc...

If appropriate, allocate a larger block of this time near the end of the course and encourage them to bring problems to class. Everyone collaborates, shares and builds, or writes, or whatever it is with you facilitating productive activity.

I have found these things to be extremely helpful and productive in adult learning scenarios of various kinds.


Even better - invert the classroom and deliver the info via computer or video, so people can pause or rewind it. Then use the groups for the "homework problems" and individual attention!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: