For my CV and portfolio scroll down to the bottom of the page or click here.
What do I do for a living? I'll tell you in a minute (unless you can't wait). Before that a brief resume: When I left school I wanted to be a rock star. So I bummed around, rehearsed and gigged with various amateur bands, and worked in a local art shop and later a record shop. In 1975 I started playing professionally on the pub circuit with an Irish folk band called Country Wine and over the next few years played with the same basic core of musicians in bands like Crannog, Brahms & Liszt, Poteen, Chanter, Irish Mist, Zozimus, Mr JJ and the Joe Giltrap Band to name but a few. Some were very folky, some were very rocky, all featured the same long-haired herbert on very loud - and very good though I say it myself - bass guitar. In the late 70s I decided I needed a real job so I trained as a chef and worked for a while in Ormonds restaurant before finding myself back in the music biz doing sound engineering at the Sir George Robey. Did some more gigs as well.
Then in the mid 80s I went to work for Haringey Community Workshops, taking the arts out to the disadvantaged. They were good days but bad management meant that it collapsed, so I went to work for Wandsworth Social Services in their mental health team. For eight years I trained and practised in group and individual psychotherapy and counselling before bailing out in 1996 'cos I couldn't stand another Christmas in the drop-in cafe. I applied for all kinds of jobs and eventually was hired by Psion Software to help write the documentation for the upcoming Series 5. I stayed with Psion through their transition into Symbian and then... redundancy, in June this year. Bit of a bummer for all concerned. Unfortunately the mobile Internet wasn't happening as fast as some people thought it might and the expected huge demand for prohibitively expensive mobile devices that allow you to browse about a quarter of the Web at 40x20 resolution hasn't happened. Wonder why?
No, really though, I can't help thinking that the whole Symbian thing was a bit naive. It was great fun while it lasted though! After that I went to work for Categoric - and spent 18 months commuting 4 hours a day before finding my way to Mobile Innovation to work on a project for Nokia alongside many of the people that I used to know at Symbian. That contract ended, as contracts do, and then I went to work for IDX as a tech author and trainer on the CfH (Connecting for Health) project implementing Carecast for the NHS in London as part of NPfIT. IDX were then taken over by GE Healthcare, and it's all a bit up in the air at the moment.
Yes, so what do you do???
I'm a professional technical author, which means that I take complicated stuff - usually software - and write about it in a way that non-nuclear physicists can understand. My audiences vary from you - yes you - through real numpties like my mum who barely understand what a mouse is (and why should they, you might ask?) to computer professionals. In practice, a fair bit of the work is writing the online Help for Windows products that nobody reads! Mind you, there's a reason - or a number of reasons - for that, not the least of which is that most of it is extremely badly written (including, I might add, the Help for my own company's product. Not my fault, nor my boss's - we're both new and we both want to rewrite as much as possible when we get time). As well as the Help I also write user manuals, although these are getting less common now as companies try to cut costs by not bundling a printed document. There's also a general trend towards online documentation because it's so much easier to update and maintain.
While I've been at IDX and GE I've been a lot more involved in training as well, writing Word docs & Powerpoints and then delivering courses to people from the NHS, BT and assorted hospitals in the London area. This has been fun!
In addition to Help, user manuals (generally referred to us "user docs") and training materials I also write "user interface specifications". Basically there should be (I say "should be" because all too often the req or UI spec are omitted and the software looks awful or doesn't do anything very useful, very well) three kinds of spec when software is being developed, and they are written in the following order:
After all three of these documents have been agreed they enter a period of change control. What that means is that everybody knows, despite the agreements, that in the development lifecycle there will be changes. Features that can't be done in time for the ship date, things that don't work as planned, things that are just too difficult to use despite the best efforts of the ID people and usability researchers. But engineers can't just change things willy-nilly (or there'd be an almighty mess) so every potential change is submitted as a "change request".
The person who wants to make the change (and they can come from anywhere) submits a written proposal describing the problem and a suggested solution such as "drop this feature", "let's do it differently", "move that button over there", "delay the ship date by a month so we can do it properly", etc. Then a "core team", comprised of representatives from all the interested parties, meets once a week or so to discuss all the change requests (CRs) and agree the best way of tackling them. Some are just turned down, of course, and the engineers have to find a way of doing the impossible. A really good engineer usually can :-). With a proper CR process there are no unexpected changes and the documentation can keep up with the product. Which is my main job.
My CV and Portfolio - here's my CV in Word or HTML and here are some of the things I've done: