Your Screwdriver Is a HammerPosted: February 6, 2012 Filed under: Education | Tags: education, higher education, teaching, teaching approaches, tools Leave a comment
There’s always a temptation to start teaching tools rather than techniques, and that’s certainly true in my discipline, Computer Science. My school doesn’t teach inside a ‘standard’ Integrated Development Environment (IDE) [If you’re a non-tech person, that’s a friendly, graphical framework for writing programs]. This isn’t because we have some sort of “real programmers don’t use IDEs” nonsense going on but it’s because we want to teach techniques for designing, writing, testing and improving computer code that can be used anywhere and everywhere.
Not everyone runs the same computer hardware, operating system and applications package set-up. Almost every workspace is different. (Whether they should be or not? That’s another post.)
It’s a little like that “give a man fish…” sentiment, except that tools are notoriously short-lived and mercurial in the computing world. Today’s killer environment is tomorrow’s bad example. One group may have a semi-religious objection to the tools of another group – and both can be wrong. It’s more like “give a man a fire, he’ll be warm for one night, set him on fire, he’ll be warm for the rest of his life” and makes about as much sense, once you remove the humour.
Ultimately, if I teach someone a tool-based approach, there’s always the risk that they will think that this is the only way to solve it. To drag out another platitude, when all you have is a hammer, opening beer becomes very messy. This is why we try not to only teach one programming language, one programming paradigm (that’s an overall approach to programming) and certainly not one platform – especially if it’s an expensive or proprietary platform.
I recently purchased one of the Adobe Creative Suite full-version packages, for work, at a cost of thousands of dollars. Is it useful? Yes! Has it broadened my horizons in terms of teaching design? Yes. Would I teach with it? Oh, heck no. If what I’m teaching is programming, like the scripts in Adobe, I can do that with free products and the knowledge transfers, with a small warm-up time if you get to use this product. If what I’m teaching is graphics, then there are existing products out there that are free and in the same ball park. Yes, students can buy student licences, but at roughly the same cost as a textbook – given a choice, I’d probably rather that they bought a useful book than a heavily specialised tool. I’d be slightly terrified if someone though that all problems could be solved with CreativeSuite.
It’s a bit like using Microsoft Excel for scientific data analysis: great tool, wrong purpose, costs real money, makes bad science.
Yes, I accept that I may disadvantage a student who takes their general Bachelor of Computer Science and goes to a place that demands 6 months experience with Adobe. But I’m not part of tech training for tool use (not saying that this is bad, it’s just not what I do) so I have to focus on techniques so that, whichever package or system or language my students find themselves involved with, they can look at it through the tool and apply the techniques.
Even a well-crafted screwdriver can blind you to the other options out there and, in the worst case, have you stand there sadly banging the screws in. With an understanding of technique, well, I’d love to say we’d eliminate this, but let’s settle on we’ll probably reduce the possibility of this happening.