Why my emails are so short

It’s been brought up on a couple of occasions that my emails (heck, my online communication in general) are short. There’s a reason for this:1 I’ve yet to decide whether it’s a good one or not.

I’ve come to realise that in general, people don’t read entire emails. Given a two line email or a two page email, I’m more than likely to read (and follow up on) the former.

We all have busy lives, and we all get tens – if not hundreds – of emails every day. All asking for those two minutes of your time that nobody has, so we tend to be choosey on which emails we read, and respond to. And – being the selfish type – I want that email to be mine.

So, I write in short paragraphs, short sentences, and in short prose. In hope that you’re more likely to read what I have to say if I do. It probably means that I miss things out, and that things need further explaining. In which case, that’s best done over a followup email, phonecall, or face to face meeting (Speak to me face to face, and there’s a likelihood you won’t be able to shut me up).

If that sounds rude, or missing details, I’m sorry. Let me buy you a coffee as an apology?

(Of course, I’m not smart enough to come up with this myself. I learnt this from Oren Klaff, who sent out an email newsletter about this).

  1. Well, two: I’ve struggled with RSI in the past, and it’s not a nice condition to have. Ask me and I’ll tell you what I think is wrong with keyboards 

Lightning talks, August 2017

This month I gave lightning talks at PHPNW and NWDUG, “Educating Enfys”.

Slides available on Speakerdeck.

Speaking: re:develop conference 2016

I spoke at re:develop conference 2016. With thanks to the organisers for having me, and all attendees for asking some great questions, being nice people, and laughing at the right places.

So, you do code reviews, and that’s great. But there’s always more that you can check during the review. More places you can check for any potential bugs or problems before deployment, before you find yourself with technical debt. Or worse: unforeseen downtime.

In this talk Clair will be going through the things that you should be checking to ensure confidence for developers, project owners and stakeholders. We’ll be looking at documentation, commit messages, and common code problems, with examples and tips along the way.

★  A suggestion for conference organisers

Conferences are great, I really enjoy going to them. But also, I find conferences can be difficult to be at.

I suffer from anxiety, and from time to time it can be difficult to deal with. Things that I struggle with are being in a place with lots of people (especially people I don’t know), being in places where there’s a lot of chatter or a loud noise from a microphone, and learning difficult or new things. So, basically things that by design you get at conferences.

Sometimes, it isn’t a problem at all. I can usually cope for a while if it is a problem. But often I just need to get away from it all for a few moments.

So, I have a suggestion for all conference organisers. Can we have some kind of “quiet space” for people to escape to? Somewhere away from the usual hustle and bustle of the conference where I can just sit down with a cup of tea1, perhaps catching up on twitter. Being by myself where my brain can recover.

It doesn’t need to be a separate room. Just some space away from the main break area (ie. away from the sponsor hall), that’s clearly defined as “I need to take five minutes” space.

Because often, as much as I’m enjoying the talks and meeting old and new friends, all my brain wants to do is run away. And my brain will thank you for providing somewhere I can run to.

  1. Which brings me to another suggestion, this one for conference caterers: please don’t take away refreshments just because the talks are on. Not everybody goes to every talk. And no, jugs of water and small glasses don’t count as refreshments. 

★  Five years

It’s been five years since Steve Jobs was cruelly taken away from us.

In those five years, multiple biographies have been written, business books have been published promising the “Steve Jobs way”, and many anecdotes have been told from people who have been lucky enough to meet, or work with, the man.

Jobs has touched many of our lives; whether it’s through the phone we use or the way we listen to our music. But for me, he also touched my life by showing me what uncompromising looks like.

Like many, I still think about Jobs from time to time, and the things he gave the world. The technology he gave us is obvious, but it’s not what I’m the most thankful for.

What I am the most thankful for, is being shown that it’s ok to never be satisfied, and instead to think about every last detail. Because it’s the small stuff that makes the world a better place.

★  Testing, and being a tester

Gem Hill made a really interesting episode of her podcast, talking about how she became a tester, and invited people to speak about their stories.

Like almost every other tester, I kinda fell into it by accident. Like Gem (spoiler alert) I started by testing, realising I quite enjoyed doing it and had a natural talent for it, and so decided to become a tester.

Almost by coincidence, the company I worked at was both moving the platform to a language I couldn’t — and still can’t — grasp, and building up their test team. Given I did some testing previously (agile, people!) and didn’t completely suck at it, the switch was a no brainer.

The day before I was due to move team, my soon-to-be manager checked how I was. My response was a barely understandable panicked mash of worry.

The day I moved, and the subsequent days afterwards, I found myself talking with the others in the team like I’d been there forever. That all testers seem to have the same sense of humour generally helped.

It was that week I realised I was no longer testing: I was a tester. Almost two years later, I’m starting to scale back the amount of development I do.

(It was that week I was also introduced to Inside Number 9, which after a few episodes I decided was far too creepy…)

It's a bug🔗


Human beings are not interested in whether you have introduced a problem when designing your product or when coding it. They’re all just bugs.

Good to see the big companies saying this out loud. Just because your app functions correctly and to spec, doesn’t mean there isn’t an important usability problem in there.

Colour blindness and iphone🔗

Jason Snell has written an interesting article on colour blindness:

The design of Apple’s MagSafe chargers are a case in point: They contain a clever design to indicate your charging status at a glance — green means charged, amber means charging, and no light means that there’s no power or connection.

Except, well… I can’t really tell the difference between the green and the amber lights at a glance. For a long time, I didn’t even realize the light on the MagSafe connector changed color. (Apple is far from alone here — lots of electronics use subtle color shifts of an LED to indicate things in a way that I simply can’t digest.)

But I do love that Apple are trying to make things easier:

In iOS 10, Apple will let users filter their entire display, whether that’s applying grayscale, red/green filters for both protanopia and deuteranopia color blindness, and a blue/yellow filter for a very different form of color blindness called tritanopia. There’s also an option to just overlay a color tint of any hue or intensity.

I had a discussion with someone last week about how developers can, and do, keep disability and individual circumstances in mind. When asked what kind of built in features were built into the iPhone for accessibility, the list in my head was growing as I thought of more and more.

The answer I verbally gave was “gosh, loads!”.

It’s nice that Apple are growing accessibility features for iOS year after year, even though they don’t have to. I like that they see it as their social responsibility to do so.

Downgrading from iOS beta🔗

A handy Knowledgebase article which provides instructions on downgrading iOS. Ignore the title, these steps work.

At least, I was able to downgrade from iOS 10 development beta to iOS 9.3.2 by doing this.

Headphone sexism🔗

Of all things I have an opinion on, the shape of headphone jacks is perhaps one of the most benign. I prefer L-shaped jacks, as opposed to straight ones. The reasoning is simple:

Women’s jeans have stupidly small pockets, and the only way you’re going to fit a phone in there is if you put it in sideways. This means that there will be a snug fit for the headphone jack.

The cable inevitably needs to fold at around 90 degrees to go out the pocket, which inevitably stresses (and breaks) the headphones.

The L-shaped jack solves this problem by bending the cable with no stress. Perfect for women’s trousers.

CNET recently spoke with Sean Garret, VP at Bose, about the shape of a headphone jack (L-shaped vs straight), explaining why all modern jacks are straight:

You naturally slide your phone into your pocket so the cable comes straight out of your pocket first.

I see nobody in Bose’s design team wears women’s clothing.