Motivating geoscientists to learn Python

Feb 23, 2014 • Matt Hall

I sat down to write and found I have 2 thoughts about motivation. Yes, two!

  1. How do we avoid scaring people off with the very first thing we say?
  2. If we get them to come and learn, how do we encourage them to stick at it?

Don’t call it programming

I think there’s also a general unease, even among scientists and especially among geologists, about ‘coding’. It seems hard, and intimidating, and effortful, and where do I even start, and what is C and C++ and C# and Objective C, and for goodness sake stop using nonsense like ‘API’ and ‘stack’ and ‘FOSS’ when you explain it to me. To be clear: geologists mistrust computers.

So I think it matters what we call ‘learning to program’, and that’s probably not the best thing to call it. I really like what Atul says here about coding as communication. I think it’s also about problem-solving, analysis, visualization, and creativity. Geologists generally dig that stuff, even if they’ve never heard of Python, or think ‘programming’ sounds like something only people who don’t go outside do.

Start a project

Getting student feedback after teaching a course is fine, but I worry it’s too superficial a measure of how effectively I taught. People like courses, because learning is often fun, or at least more fun than, you know, work, so on the day they rave about everything, 5 stars, Extremely Satisfied, Would Definitely Recommend. I suspect the real feedback should come 6 months later, when — in my own experience as a student — one might look back at the course more realistically. “What was that course on…?”

I think one way to reduce the risk of this sort of attrition is to get students started on a project they care about that will take them beyond the class. The main thing is to get them over the hump of starting a project they really care about — the thing that perhaps motivated them to come to the class in the first place. An hour or two planning their approach with a classmate, finding some libraries that might help, prototyping some small aspect — these are things I’d attend a class for.

One of the things that motivated me to start coding was texture analysis of 3D seismic images, which I’d read about in a paper. I wrote about where that led on my blog. A programmer friend of mine suggested that the idea of ‘coding a paper’ could be powerful, especially in applied geoscience, where the details of much of the ‘science’ is never published in a reproducible way.

So my suggestion: get students to bring a paper they’d like to reproduce the methods of, but on their own data (or some similarly tangible goal). Set aside a 90-minute ‘workshop’ near the ned of the session to get them started on this project, with some conceptual design, peer review, and instructor feedback. Then send them on their way to coding glory.

What do you think? Is it reasonable to carve out enough time to do this justice? Is it even a good idea? It’s quite possible that I just got carried away with the single malt after reading Stephen’s slides about R.