The Red Lines Page

July 15, 2017

Crossword clues

Filed under: drwho,IBM — Peter A @ 8:16 pm

CrosswordImage.jpgThese are the clues for the crossword frame that I published previously.

There are two themed elements, each with 12 answers. One set has associations with traditional Christmas, indicated in italic and with [X]. The other set has connections with Doctor Who, indicated in bold and with [D].

Many clues are cryptic, containing a variety of anagrams, homophones, containers, substitutions, double definitions, and so on. All answers except one are single words.

Download a printable version in a PDF document from here: RED LINES PAGE – Giant Crossword

December 10, 2016

Doctor Who crossword 2016

Filed under: drwho,IBM,rednoseday,Uncategorized — Peter A @ 5:27 pm

Crossword grid 2016.pngEach year, the IBM Hursley Club publishes a giant crossword in its festive newsletter. The Club is onsite at the location where I work.
This year, their crossword setter is “Omega.” He or she has included 12 Doctor Who related answers, and the grid features four question marks. What fun!

December 5, 2016

A few comments on recognition

Filed under: Articles,IBM,ISTC,writing — Peter A @ 11:59 pm

istcThis year I was honoured by the Institute of Scientific and Technical Communicators (ISTC), which is the industry body for information development. They awarded me their Horace Hockley Award for 2016. And then they elected me as an Honorary Fellow, in recognition of outstanding service to the profession.

I was pleased to accept both, make an acceptance speech at this year’s conference, and write an article for their journal Communicator.

Here’s what I said in the article.

 

A few comments on recognition

Horace Hockley Award 2016 honoree Peter Anghelides says “thanks for the feedback”


How splendid to receive this year’s Horace Hockley Award. Major Hockley established standards for the technical communication profession, and was himself recognised with an OBE in the 1968 New Year Honours list.

We should welcome feedback about our work that’s timely, evidence-based, constructive. It’s a culture shift in our industry: to seek professional feedback instead of mere evaluation.

That’s important to us at IBM, where our mission is to deliver the right content, to the right person, in the right place, at the right time.

The feedback firehose

Communicator.jpgFeedback can be overwhelming. It may be from our peers, our editors, our engineers, our clients. And the explosion of feedback is a consequence of how we’ve slashed hardcopy entitlement, increased softcopy, integrated online information, and incorporated documentation in development environments and platforms like Eclipse or IBM Bluemix.

We get comments from IBM support, in the IBM Knowledge Center, in forums and collaborative environments like Stack Overflow, or repositories like GitHub. Not to mention the freeform firehose of Twitter and YouTube.

More than half of visitors to ibm.com go there for technical information, and a third of them use IBM Knowledge Center (millions of unique visitors, every week). IDC research (Technology Marketing Blog, October 19, 2012) revealed that vendor information is the second biggest pre-sales influence for technology buyers.

Delighted clients are advocates for our company. And our technical content reveals our company to our clients. That’s why we welcome feedback. We crave it.

Take a page out of my book

But when I first joined IBM in 1988, feedback came via the Reader’s Comment Form (RCF). This was back in the days when you might get your IBM machine delivered on one pallet and your documentation on the next two. Each of those big hardcopy manuals might have hundreds of pages, with one RCF at the back of it. We invited our clients to fill these in, with a request for assessment on Clarity, Accuracy, Completeness, Organization, Retrieval, and Readability.

What optimism! Our hope was our reader would tear this page from the back of the manual, complete it in detail, fold it neatly, and return it by pre-paid post to IBM in Mechanicsburg, PA where our product documentation was printed. IBM Mechanicsburg would then bundle up the RCFs and post them to the appropriate development lab – in my case, IBM Warwick Lab.

For years in Warwick, one client kept sending us RCFs that were completely blank. Nothing on Clarity. No insights into Accuracy or Organisation. We knew they came from one person, because each had the same postmark.

Was our mystery correspondent shy? Using invisible ink? Or a really furious client trying to bankrupt a multibillion dollar corporation one pre-paid envelope at a time?

Then the blank RCFs stopped. For months, we wondered what had happened, until they suddenly began arriving once more.

“What a relief,” said my manager, Roger Amis, “I was beginning to worry that something had happened to him.”

Roles and responsibilities

Roger is the man who hired me into IBM. Over the following three decades, I’ve been a technical author, project lead, talent manager, globalisation expert, and accessibility advisor. I’ve line managed information developers, human factors engineers, designers.

At one point, I even acted as IBM’s Translation Service Centre Manager for UK English (we never had a busy week).

I completed two worldwide assignments for the three IBM Corporate Directors of Documentation, Globalization, and Design. Those were wonderful opportunities to support strategy, process, and tooling for the biggest tech comms population in the world, through times of great transformation in IBM’s core businesses, and therefore great change in how we delivered product  documentation in dozens of languages.

I’ve helped my company change from IBM-specific tools and technology, like BookMaster, to establishing and sharing open standards, such as DITA. I’ve seen a company-wide renaissance in design thinking that puts user outcomes at the heart of what we do.

Technical communication is now an institutional competency within IBM. As an upline manager, the latest transformation I led was to integrate information development into the engineering squads, instead of being a separate organisation.

Multi-disciplinary teams mean that design and technical writing are no longer “add-ons,” but integrated with engineering from the outset – essential ingredients in a mix of skills for successful software development.

Staying the course

HoraceHockleyAward.pngThere have been many colleagues, managers, and mentors in the UK and around the world. But I reflect it was the IBM manager who hired me in the first place who made this all possible.

You sometimes hear it said that “people join companies, but leave managers.” Well, Roger Amis is a big reason why I stayed the course.

By happy coincidence, he also introduced me to my wife.

I’d like to recognise Roger as a role model for what it means to be a technical communicator, a manager, a collaborative colleague, and a mentor. He made it possible for me to set off on this path.

And I thank the ISTC for this much-appreciated recognition of my subsequent journey over the years.

Peter Anghelides is Outreach and Publicity Officer, IBM UK Lab Campus

E: peter_anghelides@uk.ibm.com  W: ibm.biz/knowledgecenter  T: @anghelides 

This article was originally published in ISTC Communicator, Winter 2016.

June 24, 2015

Coming out as an LGBT ally

Filed under: IBM — Peter A @ 10:44 pm
Tags: , ,

I posted a version of this in my work blog, and decided I’d like to share it more widely. The postings here on The Red Lines Page are my own and don’t necessarily represent IBM’s positions, strategies or opinions.

Once upon a time…

It’s the early 1990s. We’re three friends, early in our careers, unmarried, in our mid-twenties. On a Monday morning, we talk about our weekends. I’m dating a technical author. Paul has just returned from the Home Counties, where he’s spent time with his fiancée. Craig explains how he’s been out in Coventry with his partner.https://www.flickr.com/photos/23912576@N05/2942525739

Paul’s stories were the common currency of young employees in the office, and colleagues were at ease talking to him. Whereas some people in the office were disdainful or ill-mannered about Craig and his boyfriend. Craig didn’t care — he was an out gay man, and just as happy talking at work about his relationship as he was about programming or project management.

But that wasn’t the point. There were other gay men in the office who did not feel comfortable that people might know anything about their private life, and chose not to be out at work. It wasn’t that anyone was openly hostile; just that the business culture in the early Nineties was not so accepting. Simple things like the office rituals of congratulations on an engagement or marriage were something that applied to Paul, and not to Craig.

It wasn’t the big things that were discriminatory, but a succession of small things. Today, we’d call them “microaggressions” — brief and commonplace daily verbal, behavioural, or environmental indignities, whether intentional or unintentional, that communicate hostile, derogatory, or negative slights and insults.

Twenty years later

More than 20 years later, society and the law have changed. Marriage equality and workplace legislation have both reflected and changed attitudes. The company where I work, IBM, continues to be in Stonewall’s Top Global Employers. We have an internal community for employees who are lesbian, gay, bisexual or transgender, or who have family, friends or colleagues who are L, G, B or T.

And I am proud to say that two members of my organisation are the LGBT Location Champions for the major site where I work.

June is recognised around the world as LGBT Pride Month — and IBM is a keen participant. Everyday business activities, such as hiring, training, compensation, promotions, social and recreational activities, should be conducted without discrimination based on race, colour, religion, gender, gender identity or expression, sexual orientation, national origin, disability or age.

What about that technical author? Reader, I married her.

Now, although I met my wife through IBM, there is very little overlap today between my work and my home life. Despite blogging this, I’m usually fairly private, but that’s my choice — there’s nothing about my work environment that would make me uncomfortable being open about my non-work life. If I wish, I can talk about my family, and I have photos of them in my office. Whereas LGBT employees may still be uncomfortable being out at work. They may feel unwilling to personalise their work place, or spend energy being ambiguous in conversation about “my partner” and what “they” are doing. It’s important that we can all be our whole selves at work.

Straight Allies

I'm an LGBT allySo it’s not enough for a company just to say it has a policy, or that it follows the law. We all have a part to play in challenging those “microaggressions.” And I’ve personally seen how effective that is when individuals at work do that for my friends and colleagues who are gay, lesbian, bisexual, or transgender.

If you’re not LGBT, you can be a Straight Ally and have a transformative effect on the workplace experience of your colleagues, both gay and straight. Every LGBT person will make a personal and conscious decision about whether they will be open about their sexual orientation at work. And it’s not simply a case of coming out once. Gay people have to decide whether, and how, they come out every time they meet new colleagues, clients, suppliers or stakeholders. That decision is made easier, however, if they believe their managers and colleagues will support them.

You can find a super guide here about coming out as a Straight Ally. And there’s an interesting workplace guide from Stonewall that I’ve referred to when writing this blog. I’ll quote some more of it in the comments below.

So here I am, coming out as a Straight Ally. And not just for June. I expect I’ll need to come out again in the future when I meet new colleagues, clients, suppliers, and stakeholders. I hope you will, too.

January 15, 2015

Sparkle

Filed under: IBM — Peter A @ 10:43 pm

There’s a website where you can “ship glitter to your enemies.” Apparently it’s the socially acceptable alternative to putting a brown bag full of dog poo in someone’s porch and setting light to it. It’s funny at someone else’s expense. Though the personal expense is about ten Australian dollars. I’m not recommending it.glitter

In contrast, earlier this week, I received a Thank You card from a colleague who left the company. She had thoughtfully written this by hand, included some specific things rather than “thanks for everything”, and ensured it got to me after she had gone. We’d talked before she went, of course. But this was a most welcome and personal thought, and one I greatly appreciate.

The card isn’t very glittery. But it has some glitter on the lettering. I took it home in my work bag, and now there’s a slightly sparkly patina on the cover of my laptop computer. At my desk in the office, earlier today, I noted the cuff of my suit jacket had a faint flicker of silver. And each time I saw that, it made me smile.

Because it reminded me of the card. And then that recalled how I felt when I first opened the envelope. It’s really nice when someone catches you doing things right, and takes the time to tell you. Buying a card. Writing something specific. Ensuring it got delivered.

There wasn’t a lot of glitter on the card. It was just enough. And it’s made me think that there are times when, instead of taking positive things for granted — people, actions, comments — it’s worth making the effort to say thanks. This is me saying thanks for that to my colleague, and passing it on. You know who you are. You may have left the company, but your influence continues to be felt.

March 8, 2014

A handle on good design

Filed under: Articles,Grumbling,IBM — Peter A @ 7:51 pm

I recently reposted a photo on Twitter that I thought neatly encapsulated poor design.

Within a few days, this was retweeted hundreds of times. With the various modified and quoted versions of it, Terry Odell’s original photo has now been retweeted over a thousand times. It seems to have caught the imagination of many, and not just technical authors.

From http://uk.reuters.com/article/2009/09/11/uk-fortis-tesco-idUKTRE58A19Y20090911

Credit: Reuters

Subsequently, Alexis Hale politely pointed out that the sign was “literally a joke from the Wayside School series.” Nevertheless, I still claim it as an example (deliberate or otherwise) of when documentation makes things worse — and when better design could avoid the need for documentation in the first place. Because obviously technical writers are like those staff in Tesco wearing a badge saying…

“Here to help”

I was walking through the airport, and noticed a man carrying two heavy suitcases through the arrivals terminal after passport control. I could tell they were heavy from the way he was struggling, and they’d got those orange warning labels on them (an example of simple, effective design).

Ref: http://www.flickr.com/photos/45339499@N00/

Credit: Philipp Bock (youMayCallMeSheep)

As I watched him grip the handles to drag his baggage towards the taxi rank, I saw he had this fabulous-looking watch on his wrist. “Oh yeah,” he said, “it’s very clever. It tells the time in all the countries that I do business. It gives me access to my e-mail, shows me my calendar, warns me about forthcoming meetings. It’s got a built-in stills camera and a phone with a little video screen. It’s got functions for recharging via kinetic energy and solar power. It checks my pulse and skin temperature and warns me when I might be ill. It plays music from all the albums I’ve stored on my home server. So it’s OK, I suppose.”

“OK?” I told him. “It sounds fantastic! But if you don’t mind me saying, you don’t seem very happy with it.”

“Well,” he said, hefting the two heavy suitcases, “look at all this documentation you need to carry round for it.”

When I first told that gag, the iPhone and Galaxy Gear were still Star Trek technology of the future. But those of us who remember early digital watches can still recall thinking, “There are only a couple of buttons, so how difficult can it be?” And then struggling to set the alarm. And subsequently struggling to deactivate the alarm when it went off.

Minimal interface isn’t a guarantee of simplicity. But designing a product to be easy to use, rather than creating a lot of documentation, is what will succeed in the marketplace. Good design makes use obvious, and behaves the way you expect, and so you avoid providing documentation that’s not absolutely necessary.

The smarter you are about avoiding the need for documentation, the smarter the documentation is that you end up producing.

And yet, when my mum got a new watch from a famous, very reputable brand not so long ago, the instructions for setting the date told her this:

Do not set day/date between 8:30pm and 5:00 am as day/date change cycle is in progress.

It’s an admission of design failure if one of the functions of your product can’t be used properly for 8½ hours of the day.

Walk up and confuse

All too often, an interface you expect to be “walk up and use” ends up just confusing. When I talk to technical authors, it may seem heretical to assert that no-one really wants to read product documentation. Not even technical authors.  Who honestly wakes up and says, “You know what, today I really fancy reading an instruction manual. I’d like nothing better than to study how to install and configure some database software.” 

You pick up an instruction manual because you’ve got stuck attempting to do something, or don’t know where to start when trying to achieve some task. You want to find that out as quickly as possible, and go back to what you were doing. It’s all about the task and not the product, and it definitely isn’t about the manual. I don’t think “I’d like to use the iPhone interface this afternoon,” I think “I want to listen to that track by The Doors, and maybe buy it.” (Yes, I am that old.)

iPhone

My first iPhone

The iPhone is an aspiration for all consumer products: it’s almost literally walk-up-and-use. Like Doctor Who’s sonic screwdriver – a multitude of uses, but the Doctor never has to fumble around for the instruction manual. On my iPhone, I can rapidly work out how scroll, open, close, cut, copy, paste etc. all work. And it’s only got a few buttons, and they do pretty basic things that can be simply explained.

Even more interesting, my experience is that most of the documentation for the “difficult” stuff is searchable online and not written by Apple.

 

Doors to manual

http://upload.wikimedia.org/wikipedia/en/b/b4/Panel_door.jpg

Doors don’t do documentation (credit: wikimedia)

The simplest things can be overcomplicated by documentation. You wouldn’t expect to get all this specification information about how to use a door. As Don Norman pointed out in his excellent book The Design of Everyday Things, a  well-designed door is literally walk-up-and-use:

  • It will have appropriate affordances – plates that invite you to push, and handles that look like they need you to pull, which tell you all you need to know.
  • Just one word of documentation is too much, especially when those two words are look as similar as PUSH and PULL.
  • If you disagree with that, then ask yourself how much you want to read and work out if you’re trying to operate a fire door in an emergency.

And yet we still encounter poorly designed doors. What hope do we have for easy-to-use software if we can’t do doors?

Hursley doors

IBM has a renewed focus on Design Thinking that is transforming the way software and solutions are created. And although office doors aren’t something IBM designs and builds, I like to use the example of doors at IBM Hursley (installed in the 1980s) as how not to design simple things things simply.

These doors are one of the first things our visiting clients encounter when they arrive, and one of the last things they use before they leave. In comparison with them, the self-flushing cisterns and soap dispensers in our on-site toilets are a miracle of modern technology.

All IBM buildings are badge-controlled for security. There are two ways to enter IBM Hursley from our Main Reception. The first question is: which set of doors to choose?

ReceptionArrows

There is a pair of doors to either side of the welcome desk. The receptionist or your IBM host can tell you which pair to choose, I suppose – though some visitors are from other IBM sites, and they do not need to “sign in” or speak to the receptionists. (You should do, even if just to say hello – they’re lovely. Not everyone does, but people are strange.)

Perhaps you decide to try and to work it out for yourself.

Reception doors

   More doors

When you approach your chosen set of doors, you’ll find there is some documentation:

  • Policy rules about having to wear a badge, and having to use your ID card in the door’s badge reader.
  • An image on the badge reader showing you how to orient your magstripe.
  • A red PUSH printed into the upper part of a long metal handle that looks like it’s designed to pull.
  • But there are also two metal plates (which stop the door swinging beyond the frame) that look like push plates.
  • And finally, because the latch tends to stick and you therefore need to “rattle” the door a bit to disengage it, there’s a further sign in a different font that tells you to “PULL and then PUSH door” with a sad little coda that says “thank you.”

DoorCloseUpArrows

Now you’ve decided which order to read these signs in, and chosen which of the two doors to use. You may have a confusing moment if someone comes through one of the doors, because they’re designed as unique “in” and “out” doors, like those for a restaurant kitchen. And depending whether you choose the left pair or the right pair, the “in” door is different. 

Once you get through the door, you’ll find yourself in a through corridor – and realise that it didn’t matter which pair of doors you chose, because both sets lead in here.

Corridor

On your way out, you will probably remember that it doesn’t matter which doors you choose for leaving the building. Unless you forget, or you came into the building via a different route. There’s no clear indication that these doors lead to Reception and the exit. Perhaps you’ll recognise the distinctive furniture through the non-opaque parts of the door.

But even if you do remember, the way you get out through the same pair of doors is different from the way you get in. That’s because you don’t need badge access to get into Reception, and so the sequence is:

  • Press a button, and wait for the light to go green
  • Choose the correct door, rattle the handle, and then push.

The way out

It will reassure you to know that this design was not the handiwork of the IBM documentation teams responsible for products, nor were the doors designed by IBM. Now that they are installed, it’s admittedly a bit harder to redesign and replace the doors. And perhaps those of us who have worked at IBM Hursley for a while have simply got used to them.

But then perhaps we’d assume that people would get used to knowing how to use stairs. Which is where this blog post started. And that’s even before we take into account that not everyone finds it easy to use stairs. 

Ref: http://blog.globalstreetart.com/post/56326649910/for-some-people-stairs-are-mountains-a-very

Source: Global Street Art Blog

April 14, 2013

Hursley history

Filed under: Articles,IBM — Peter A @ 2:00 pm

Hursley A BlockI’ve been sorting out an old office in Hursley House. The current house is getting on for 300 years old. IBM bought it 50 years ago, and has added to the site ever since, as you can see here (on jazz.net).

The newest significant extension was A Block, shown here (from Wikimedia) opened two decades ago. During my clearance, I uncovered a large fold-out brochure that explained to IBMers what was happening on-site during the construction.

It was created and published by the in-house for employees by the Communications and External Programmes group based at the IBM site. Literally “in-house” if I remember correctly, because the team were located in Hursley House.

I’ve sent the original to the IBM Hursley Museum, which is also now in the basement of Hursley House. But here are some photos of the brochure.

March 24, 2013

Good companions

Filed under: Audios,Blake's 7,drwho,Ferril's Folly,Four Doctors,IBM,writing — Peter A @ 4:39 pm

What a splendid day I had yesterday at the Big Finish Day 3 event in Barking.

ImageI also was pleased to chat with Kenny Smith, whose labour of love has just been published. It’s the Big Finish Companion Volume 2, and I commend it to you.

It quotes hundreds of people, including almost every writer, several Doctors, many companions, and loads of musicians, directors, sound designers, and cover artists.

Kenny was interviewed about it himself.

Here’s the full interview that I did with Kenny last year. To see how he has skilfully woven this into the book, and enjoy loads more fantastic stuff, go to the Big Finish website and buy the book.

 

Kenny Smith: How much did Ferril’s Folly change between your initial pitch for it, and the finished storyline?

Peter Anghelides: Quite a bit, and hardly at all! There was a long delay between it being pitched and then the final version that was produced. It was only in the latter stages that it was actually under contract for a Companion Chronicles FerrilAt one stage, I was one of the authors invited to pitch for the BBC Audio series that became “Hornet’s Nest”, which at the time had the rather splendid code name “Felt Hat”. So I worked up a version of “Ferril’s Folly” (possibly called “The Iron Lady” at that stage. Commissioning Editor Michael Stevens eventually went with Paul Magrs for all of those audio readings, which also turned out to be a sort of halfway thing between Companion Chronicles and full-cast audios. And in any case, Michael also recognised the origins of “The Iron Lady” because he gets to see Big Finish’s prospective storylines in his role at BBC Audio (now AudioGO). That version would have had the Doctor as the principal narrator, rather than Romana.

After that, Big Finish was making one of its occasional attempts to tempt Tom Baker to do their full-cast audios, and I re-jigged things as one of my suggestions for that. Alas, that came to nothing, either.

Some years after I’d first got the thumbs up for the Companion Chronicles version, I asked Big Finish whether they still wanted it, because I had some time free up to write it. And they said “oh, yes please” in a way that suggested they’d never thought otherwise. So we finally signed contracts, and I delivered it as originally planned – and in very much the same form that I had originally proposed.

Can you briefly explain why it was delayed after it was first announced?

I had agreed with Big Finish that the outline was what they wanted. But before we signed contracts, they also asked me to write the finale for their Key 2 Time audio plays trilogy, a story that became “The Chaos Pool”. As that was a full-cast audio, not to mention too good an opportunity to miss, I agreed. I was also contracted to write a Torchwood novel with BBC Books, and there was a wodge of other non-Who stuff I was working on at the same time.

I explained to Big Finish that I wouldn’t have time for everything, and did not want to commit that I would deliver scripts only to let them down. I asked them which they wanted more – the Companion Chronicles or “The Chaos Pool”. They chose the latter, so that’s what I was contracted for. There was also some consideration that a story based during the first Key to Time sequence was a bit too close to their Key 2 Time stories. So as well as deferring my audio, and because they had already lined up Mary Tamm to participate, they commissioned a replacement “first Romana” story from Nigel Fairs called “The Stealers from Saiph”, and set it after “the Armageddon Factor”.

And as I mentioned earlier, other work and alternative versions of the story meant I didn’t get around to writing the script for several years.

Was finding a Key to Time device hard to include, and to explain away its lack of being found in the story?

I rather liked the idea of them not quite succeeding in a mid-season story, so I knew that I wanted them to find the segment and then have it slip from their grasp at the last minute. I then worked in a reason why they would have to let that happen – it’s a conscious decision, not a careless oversight.

I also decided on a distinctively different item for the segment’s disguise. We already knew it could be as varied as jewellery or a planet or a religious totem, and influenced other items around it. Plus there’s a lovely bit of dialogue in Jonathan Clements’ Key 2 Time script “The Destroyer of Delights” that suggests segments could be a grain of sand, or a leopard’s tooth, or a blob of molten lava, or even an atom of snot. That speech inspired me to make my segment something in a distant part of the galaxy that had then “infected” the meteoroid that brought it to Earth.

How did you find writing for the first Romana, having written for her second incarnation before?

I love that original “Key to Time” season. Much as I also enjoy Lalla Ward’s performance, I always wanted more stories with Mary Tamm’s incarnation… and this was a great excuse to do one. With another Riomana also in “The Ancestor Cell”, I suppose I’ve written rather a lot for the character now. There’s probably a collective noun: “A snoot of Romanas”, perhaps.

What did you think of the finished play, given its lengthy gestation period?

It’s wonderful to hear the final version, because it’s the application of acting and directing and sound and music and editing talent to my original script. Plus, I got to attend the recording in the studio, and that’s always great fun.

Any assorted bits of trivia, like origins of character names, etc?

Ferrill is obviously derived from “ferrous”, because of her affinity for iron. I originally called the scientist Öpik after an Estonian astronomer called Ernst Öpik. I found out about him because his son Lembit was, until recently, a Member of Parliament who spoke up about the dangers of asteroids striking the Earth – which in a way sadly typical of modern politics earned him derision rather than a thought that he might have an informed view. The script uses the phonetic spelling “Erpik” because there’s no point making life unnecessarily difficult for the actors.

I smuggled in other characters called “Clark”, “Stanford”, and “Andrews”, so that I had the excuse at one point to have a sentence that read: “The Doctor, Andrews, Stanford, Clark, and the others all raced out of the pub.” Because I knew that would make one of my colleagues who listens to the audios, an IBM Distinguished Engineer called Dr Andy Stanford-Clark, leap out of his chair in surprise when he heard it.

There’s also a vintage car joke in the dialogue somewhere. It was the sort of thing I imagined Tom Baker would have introduced as an ad lib during Season 16 rehearsals. See if you can spot it.

Any idea where in their timelines “The Four Doctors” story takes place for each of the Doctors, continuity-wise?

I have no idea. Any suggestions? I certainly didn’t worry about it when I wrote the script, and it doesn’t affect the narrative.

One imaginative reviewer suggested where they would each fit in, based on all sorts of things I didn’t even think – or wouldn’t even have known about, such as the costume worn by Sylvester McCoy on the front cover.

The first draft featured a reference to Charley Pollard being elsewhere in the TARDIS while the Doctor is gallivanting about. I don’t know whether that counts.

December 4, 2010

Snowy Hursley

Filed under: Articles,IBM — Peter A @ 7:45 pm

I am very lucky to work in a wonderful location at IBM Hursley.  And even luckier that my current job means that I have an office on the top floor of the splendid Queen Anne House that forms the centrepiece of this magnificent Hampshire location. You can take a virtual tour of the location. But that shows it in the summer sun. So this week, I’ve taken some photos of Hursley in the snow.

The full set is here in Flickr.

PS: One of these is actually my back garden. Not quite as grand as Hursley Park, but I love it anyway.

March 25, 2010

No Lovelace lost

Filed under: IBM,Technology — Peter A @ 12:01 am

As I type this, it’s still Ada Lovelace Day. I intended to write more, but alas have time only to say this: computing and IT companies want to hire more women. IBM UK (where I work) want to see substantially more women applicants for their hundreds of graduate trainee vacancies.File:Ada lovelace.jpg

While I don’t represent the company on this blog, I’m happy to point people to a recruitment site that talks about what it’s like to work in the IBM UK Ideas Lab. The hope is that many more modern-day Ada Lovelaces will apply — not favouritism, just encouragement.

(Men can apply too!)

It’s also worth noting that these vacancies are for a training scheme. So while applicants, men or women, may have a computing or IT degree, they do not have to — a good degree in any discipline is acceptable.

I have blogged a bit more about this on eightbar.

Ideally, I would have blogged about the achievements of a woman in technology and science. So I’m going to cheat and post a link to a blog by Laura Cowen, who is herself a splendid example of a woman in The Ideas Lab, but who has also helpfully linked to blogs by women who inpired her: Laura Czajkowski and Ana Nelson.

Pass it on!

Edited to add: I pressed “save” at one-minute-past-Lovelace! Tsk!

Next Page »

Blog at WordPress.com.