First class in India

I wrote this post yesterday morning, sitting in the Indira Ghandi International Airport in Delhi, India.

Where am I?

I'm in India. Some quick facts:

• Population: 1.2 billion, or 36 times Canada's
• There over 1.4 million sci/tech/engrg/math graduates every year
• In the US, there are about 420 000 such graduates
• The prestigious Indian Institutes of Technology receive dozens of applicants per place
• In contrast, the University of Oxford gets 5
• Because of this, the required mark in many subjects is 100%

I met some of these recent graduates last week, in an experimental corporate training course. Cairn India has been running a presentation skills course for several years, provided by a local trainer called Yadhav Mehra. Yadhav is a demure, soft-spoken man, right up until he stands up in front of his students. Then he becomes a versatile actor and spontaneous stand-up, swerving with the confidence of a Delhi cab driver between poignant personal stories and hilarious what-not-to-do impressions. I’ve been on the receiving end of plenty of courses before, but Yadhav really made me see ‘training’ as a profession in itself, with skills and standards of its own. I am grateful for that.

How did I end up here?

Serendipity is a wonderful thing. Last fall, Susan Eaton—whom I’d met in the pub after teaching for the first time—wrote a nice piece about my then-new writing course. One of my long-lost PhD supervisors, Stuart Burley, read this article in his office at Cairn India in Delhi, and it triggered a thought. He had Yadhav, a pro trainer, helping his super-bright geoscience and engineering grads with their presentation skills, but they also needed coaching in writing. 

Their education provides them with...

the traditional written communication vernacular employed in the physical sciences, in which exposition is lengthily embellished with extraneous verbiage, and the passivum, or passive voice in its not uncommon appellation, is unfailingly and rigorously exercised.

You get my point. Stuart’s thought was: let’s do combine the two courses!

What happened?

The great thing about Stuart is that, along with breadth of experience and penetrating geological insight, he’s practical—he gets stuff done. (Like almost everything else in my dim-witted student days, I didn’t appreciate how valuable this was at the time.) So the three of us planned a 3-day course that combined my day's worth of writing coaching with Yadhav's two-day presentation course. Yadhav brought some didactic rigour, and I brought some technical depth. Like all collectable first edition, it had some rough edges, but it went beautifully. Students wrote an extended abstract for a conference paper on Tuesday, then presented their paper on Thursday—they made a great effort, and all did brilliantly.

I hope we run the course again—I'd love to see it reach its full potential. 

In the meantime, if you're interested in exploring ways to get more people in your organization writing a little better, or a little more often, do get in touch! You can find out more here. 

Reuse and recycle

I have recently started teaching an undergraduate course at Dalhousie University in Halifax. The regular professor is on sabbatical, so this is a part-time gig, and a one-off. It's hard work, and shockingly poorly paid, but a lot of fun; I'm fortunate to have a fairly small group of bright, motivated students. 

One of the things that's surprised me is how little decent-quality and openly-licensed material there is on the internet for teaching technical courses like this. I can find images as well as the next person, and 'fair use' is acceptable for teaching I suppose, but often I'm left with a low-resolution image that doesn't quite show what I want. Thus I'm creating a lot of stuff from scratch, which is fine because I enjoy it, but it's time-consuming and, besides, I may never teach this course again.

So... I am uploading the drawings I make to SubSurfWiki.org, where you can find and download them, and use or abuse them for whatever you like without permission (they are all licensed CC-BY so you only have to give attribution). They are in Scalable Vector Graphics format, so you can edit them with a vector graphics tool like Inkscape or Adobe Illustrator. 

Note: There are some issues with displaying SVG files in some browsers. They sometimes look weird or even broken. You should be able to download the files and use them in a vector graphics tool without any trouble. The only other option is to use the Portable Network Graphics files instead, as I often upload those too; look for the same name, with a PNG extension. 

Learn to program

This is my contribution to the Accretionary Wedge geoblogfest, number 38: Back to School. You can read all about it, and see the full list of entries, over at Highly Allochthonous. To paraphrase Anne's call to words:

What do you think students should know? What should universities be doing better? What needs do you see for the rising generation of geoscientists? What skills and concepts are essential? How important are things like communication and quantitative skills versus specific knowledge about rocks/water/maps?

Learn to program

The first of doubtless many moments of envy of my kids' experience of childhood came about two years ago when my eldest daughter came home from school and said she'd been programming robots. Programming robots. In kindergarten. 

For the first time in my life, I wished I was five. 

Most people I meet and work with do not know how to make a computer do what they want. Instead, they are at the mercy of the world's programmers and—worse—their IT departments. The accident of the operating system you run, the preferences of those that came before you, and the size of your budget should not determine the analyses and visualizations you can perform on your data. When you read a paper about some interesting new method, imagine being able to pick up a keyboard and just try it, right now... or at least in an hour or two. This is how programmers think: when it comes to computers at least, their world is full of possibility, not bound by software's edges or hardwired defaults.

I want to be plain about this though: I am not suggesting that all scientists should become programmers, hacking out code, testing, debugging, and doing no science. But I am suggesting that all scientists should know how computer programs work, why they work, and how to tinker. Tinkering is an underrated skill. If you can tinker, you can play, you can model, you can prototype and, best of all, you can break things. Breaking things means learning, rebuilding, knowing, and creating. Yes: breaking things is creative.

But there's another advantage to learning to program a computer. Programming is a special kind of problem-solving, and rewards thought and ingenuity with the satisfaction of immediate and tangible results. Getting it right, even just slightly, is profoundly elating. To get these rewards more often, you break problems down, reducing them to soluble fragments. As you get into it, you appreciate the aesthetics of code creation: like equations, computer algorithms can be beautiful.

The good news for me and other non-programmers is that it's never been faster or simpler to give programming a try. There are even some amazing tools to teach children and other novices the concepts of algorithms and procedures; MIT's Scratch project is a leader in that field. Some teaching tools, like the Lego MINDSTORMS robotics systems my daughter uses, and App Inventor for Android (right), are even capable of building robust, semi-scientific applications. 

Chances are good that you don't even need to install anything to get started. If you have a Mac or a Linux machine then you already have instant access to scripting-cum-programming languages like the shell, AWK, Perl and Python. There's even a multi-language interpreter online at codepad.org. These languages are very good places to start: you can solve simple problems with them very quickly and, once you've absorbed the basics, you'll use them every day. Start on AWK now and you'll be done by lunchtime tomorrow. 

For what's it's worth, here are a few tips I'd give anyone learning to program:

• Don't do anything until you have a specific, not-too-hard problem to solve with a computer
• If you can't think of anything, the awesome Project Euler has hundreds of problems to solve
• Choose a high-level language like Python, Perl, or perhaps even Java; stay away from FORTRAN and C
• Buy no more than one single book, preferably a thick one with a friendly title from O'Reilly
• Don't do a course before you've tinkered on your own for a bit, but don't wait too long either (here's one)
• Learn to really use Google: it's the fastest way to figure out what you want to do
• Have fun brushing up on your math, especially trig, time series analysis, and inverse theory
• Share what you build: help others learn and get more open

Bust out of the shackles of other people's software: learn to program!

Update on 2011-10-02 00:38 by Matt Hall

If you have some programming or scripting skillz already, here's another codepad-like to look at. The nicely-designed repl.it can help you explore your multi-lingual side and try out a few languages you might have wondered about. Examples included.