Charles Arthur (the Grauniad journalist) recently put up a blog post passing on some advice to would-be journalists to “learn to code”.
Not suprisingly, that kicked off a bit of a discussion around various other blogs: Chris Applegate, who describes himself as a “wannabe polymath” chipped in with recommendations to get involved with regular expressions, comma-separated variables and Yahoo Pipes. And Tom Armitage – who *IS* a programmer, even if he hotly denies it – suggested thinking like a programmer rather than concentrating too much on the specifics.
It struck me that here’s one debate where I am actually qualified to take part – I’m not a programmer or developer as such, but I do need to herd them on a daily basis. And I also need to sit between them – who generally prefer specific, down-to-earth codeable specifications – and clients, who instead prefer to talk about their requirements in terms of “we want it do, you know, STUFF“.
That’s partly because I originally trained as an electronics engineer, which is right at the crossover point between hardware and software, and also partly because I’ve got a bad case of ADD when it comes to all things technical and geeky. I was the kind of irritating child who liked nothing better than taking clocks to bits to see what made them work, and that’s something that’s stuck.
On reflection, this also makes me something of a pain in the ass to work FOR, because although I don’t know enough to necessarily do the development job myself, I do know enough to know when someone is trying to bullshit me on a technical level. Fortunately I work with a bunch of the finest geeks available who don’t do this kind of thing, but it’s happened plenty of times in the past.
Both Tom and Chris have got it right – you do need some specific skills, and you do need some conceptual ones. I’ve got a list of things that I think are pretty much indispensible if you want to make yourself into the kind of person who can do lots of things for lots of people – they might not be the best grounding for a pure programming career, but they’re a good starting point if you’re at that meeting ground where things just need to Get Done.
The first skill – and I’m surprised this didn’t get mentioned explicitly – is HTML and CSS.
What I emphatically DON’T mean is the kind of CSS wrangling that produces beautifully fluid works of semantically-correct markup art – that’s expert territory. But if you work from the assumption that you’re no-one unless you’re on the web, then that means having some kind of web presence.
While you can get a long way with “canned” services like Typepad and Wordpress.com, sooner or later you’re going to bump up against the limitations – and knowing enough HTML and CSS to be dangerous will be a big help in these moments. The purists may turn pale at the thought of HTML tables, but if it’s that or looking like a MySpace refugee, then go for it. And it’s easy to pick up, because the web is the ultimate open-source guide – “View Source” on a page, and you’ll be able to figure it out eventually.
The second skill – which was mentioned by everyone – is the ability to understand, and ideally manipulate, data and databases.
Pretty much every interactive site has a database of some sort behind it, and if you need to manipulate large quantities of data for any reason then a simple database will generally get you a lot further than munging it in Excel or whatever. Understanding one-to-many relationships also prepares you to ask questions about the underlying nature of the data as well, which can often be as important as the data itself.
While knowing enough SQL to be a database administrator might be overkill, at least understanding a simple “select * from table where…” statement can be the key to unlocking some real insight from otherwise overwhelming quantities of text and numbers.
And then finally – and personally, I think most importantly – is something that’s actually far less concrete than anything Charles or Chris suggested, and more along Tom’s lines. It’s the ability to have some diagramming techniques in your personal toolbox.
Words are incredibly bad at explaining complex concepts unambiguously, something that this blog is a case study for. Words are even worse at explaining relationships between concepts or stakeholders or actors – once you get beyond a simple “he knows her and she knows them”, it breaks down completely – whereas a simple diagram is something even a six year old can pick up.
There’s any number of techniques out there, from flowcharting to process flows to mindmaps to entity relationship diagrams. Some are more complex than others, and not every technique is applicable to every situation. But once you’ve started trying to reduce a situation to a diagram, you’re applying analysis to it – which means that you’re guarding against problems like doublethink and reductio ad absurdum.
It frustrates me enormously that in 10 years of full-time education, no teacher has ever taught my kids how to draw a simple mindmap, which has to be one of the most powerful techniques for controlling complex concepts that’s out there. That’s been left to me to do, with the (mixed) results you’d expect from an amateur.
I’m not pretending that this is advice from anything other than my own personal experience and perspective, and the people that know me may disagree about how well I manage to cope with complex situations and hack around with HTML and so on. But it does strike me that Charles, Chris and Tom are all onto something – that there ARE skills that would previously have been regarded as the preserve of the professional geek which are actually incredibly useful to the rest of us, if only we took the time to pick them up.
Controversy over whether time spent on social media sites is wasted or productive is nothing new – anyone who’s been around the block for long enough will remember similar discussions around email rollouts. And no doubt there will have been the same arguments about putting electric telephones on people’s desks.
