Culture - the "pass the salt" incident

I was incredibly fortunate to go to lunch last week with Kate Falanga, Parimala Hariprasad, and Stephen Janaway who were all in town for the amazing WeTest conference.

As you can imagine, there was an incredible amount of "shop talk" about testing, but a small incident, which proved to be thought provoking.  Food arrived.  I needed salt.  It was on the other side of the table.  Controversial!

So I asked Kate if she'd pass the salt, immediately wishing I hadn't.  For a moment, she waited for me to take it from her hand, before putting it down on the table.  I realised me waiting for her to put it down might have seemed a little rude, so explained myself.

"In England", then eyed up Stephen, who's from a different part, "or at least in the North of England, it's considered to be bad manners to take the salt from someone's hand".  I thought back to being childed by my grandmother (we called her "Grandee"), a veritable clone of the Dowager Countess from Downton Abbey, right down to the rules of serving tea.  [By the way, even workmen were served tea in china cups, due to her strict NO MUGS rule]

Supposedly salt was linked to warding off the devil, so to take it from someone's hand invited ill fortune.

This intrigued Parimala, where in India it's considered polite to put either salt or a knife down, rather than to pass directly.  Similar to me, she's raised up to consider how spilling salt is considered to be ... well she called it "inauspicious", I went "doom".

Representing as we did America, India, the UK and New Zealand, this led to a lot of discussion about culture, and how as a international community we need to not take lightly or assume someone from another part of the rules has our same values.

When something as trivial as passing the salt has different rules of ettiquette for different parts of the world, it's a reminder to take nothing for granted.  When talking internationally, it's always good to talk about our relative cultures - what's considered rude, what's considered polite - to avoid misunderstandings.  This is something we should be doing, whether we're talking about ourselves in a multinational setting, or about ourselves within a cross-discipline setting.  Sharing of our values, helps to form a common understanding of core values.

You don't always need a justification for a test ...

I was just listening to a Neil Degrasse Tyson lecture whilst out in my garden stargazing, and he had this amazing story I knew needed to be added here.

As you can imagine - there's huge competition for time on the space-based Hubble telescope.  Not just anyone can use time on it - and typically you need to put forward a business case for it, something like,

• We want to observe the following nebula, to look for any stars which might be in the process of forming
• We want to look at this star over the following days to look for exoplanets
• We want to get a better view of the following supernova remnant

Obviously the director in charge has to queue up these requests as best they can, but they're also allowed a small about of time, that they can allocate for any whimsical reason they want.

So the director tried something radical - they'd pick an area of the sky and stare at it for 10 days.  And for something even more daring, they're try to point away from the spiral of the Milky Way (our galaxy), away from any star clusters, or galactic clusters.

They'd try to find the most boring part of the sky, and just see what's there.

The area they looked at represents the amount of sky you can see through a narrow eyehole in a needle ... at arms length.

And what did they find?  Galaxies ... thousands of them ...

This went on to become known as the Hubble deep field, and for some is considered one of the most important discoveries in the lifetime of the telescope.  It confirmed and made real what we'd suspected about the sheer size of the cosmos in which we live in.  Every one of those points of light is a galaxy, comparable to our own of hundreds of billions of stars.  So many thousands of galaxies, all seen through the eye of a far away needle.

And this discovery wasn't one that you could have been able to justify the business case for.  It was whimsical, but NASA allowed it, because they know sometimes you find amazing things, just giving some time for curiosity.

It reminds me of something James Bach told me earlier in the year, you don't always need a justification for a test.  Indeed sometimes if you're about to try something and someone says "what problems are you expecting", it's easy to talk yourself out of it.  But it's important to give ourselves a little bit of time to try things out.

As long as it's not an unmanageable portion of your day, there's always time for a "I just wonder if..." experiment.


Now Playing: "The Universal", Blur

Practice what you preach!

I think sometimes life has a weird symmetry - this week had an excellent example of this.

My son is in his first year at Victoria University in Wellington - he's done well, but not sure if he wants to do a second year without a considerable rethink.

He recently had an essay for Classics returned to him with some comments, for which he was allowed to make changes and resubmit.  He got a C-, but as he pointed out "it's still a pass", and wasn't so keen to redo it.

I had a chat with him - it's so rare to get useful feedback on something we've done.  Of course we all really want to be "done with" projects like essays or documents so we can just move on with our lives.  But applying those comments would help him think about what he's written, how to present a better argument, how to do it better.

Without feedback, we keep doing what we're currently doing, but it's unlikely to get any better.  We read through the comments together, he formed a plan of what to do, and resubmitted it yesterday.


During the week, one of our lead developers emailed me about my blog series looking at Java basics.  There were a few things I'd done which whilst not big things, would be considered bad practice in the team.  Would I be interested in the feedback?

My stomach turned - it might mean a lot of rewrites, and I'm working on my astronomy series right now.  And yet, although that series is meant only as an introduction to some key concepts, I wanted it to be as good as I can get it, without compromising the "sense of fun" I like to include in most of my writing.  [Although of course, this wasn't much "fun"]

So of course I wanted to know.  His comments were useful, because it made be think about some aspects I'd not thought about in detail,

• Class names should be Capitalised, this makes it easier to tell them apart when declaring.
• All code blocks should use braces "{...}" to contain statements, even if just one line.  I'd not used them in a few  DiceClass methods just to show that they're not mandatory (if you have a single line).  I changed all bar on, just to prove this, added a comment to the relevant blog, then never missed the braces afterwards
• Some methods such as diceOnOrOver returned an integer, but should return a boolean.  I'd cheated there, because I knew I'd wanted to add the integer returned at a later date, but he was right, it should return true or false.  I know it's tempting to go "but I just need ...", but it can be a bit of a slippery slope.
• I was using ArrayList, but I should declare them as a List not ArrayList, because ArrayList is a kind of List, and you want to keep the List interface.  StackOverflow discusses this here.

All told, with changes, retesting, committing to GitHub and blog modifications it took a few hours, but it did reinforce those points.  I don't think I'll ever forget to use a capital for a class name ever again now.

It's also a reminder to hold ourselves to the advice that we council others - and yes it's so rare to get good feedback, it's always useful to apply it so we learn from it and make the best essay/document/code we can.


Now playing: "River deep, mountain high", Ike & Tina Turner