And the truth (or at least, an attempt at redressing the balance)

An apology

On Monday night I posted a ranty tweet which I followed up on Tuesday. In essence, I was registering my surprise that a digital journalist at an internal event admitted they didn’t know what “CMS” stood for.

There were a couple of reactions to the tweet, mostly from people arguing (skilfully) that not knowing the definition of an acronym doesn’t necessarily amount to not knowing the concept itself, which I agreed with. In casual (alcohol-influenced…) conversation with workmates this evening, though, it turns out I ruffled a few feathers with that tweet – all credit to my colleague Will Franklin for having the balls to tell me he thought I was out of line.

I wrestled with posting it: beforehand I talked it through with my partner and explained that the event where I heard this soundbite (an internal, Guardian staff-only version of the Hacks/Hackers meetup) was an inclusive space and that I didn’t want to discourage people from attending, or continue the myth that web development is a members-only domain where you have to know the specific lingo/jargon in order to make headway. The event itself is a fantastic opportunity for devs and non-devs alike to meet up and talk about digital journalism.

I don’t have a Facebook account and often use Twitter to register quick reactions and my personal thoughts on things as they happen, which have (on occasion) turned into something bigger while I slept overnight. It turned out that in this instance, the things I’d posted had caused colleagues of mine to discuss my tweet (and presumed attitude) in internal emails. When I first heard this I thought it was a bit odd that people were talking about stuff I’d said without involving me, until I realised that that was exactly what I’d done to the person whose admission I was referencing in my original tweet.

With that in mind, I’d like to apologise for coming off as exclusive and snobbish: I strive in my work and my personal life to be inclusive of others and highlight occasions when people are marginalised and ignored. In this instance I pointed to an individual (albeit without identifying information) and registered my concern that they didn’t know a technical term I thought would be commonplace. A colleague this evening pointed out that I couldn’t define the term “monad” (a technical term for a software concept… I think), despite the fact that I’ve almost certainly made use of them in my career as a developer. This is a completely fair point and one I failed to consider when making my initial complaint.

I’ll make no secret of the fact that I’m pretty unhappy in my job at the moment and feeling fairly negative towards the Guardian right now (this is another blog/rant entirely…), which I think influenced my complaining tweets during this event. This is no excuse, though, and doesn’t change the impact of my words on the person I was referring to (or those who saw it).

So: while I won’t deny I found it surprising to hear of a journalist who didn’t know the term “CMS”, I agree that the way I highlighted it and the act of drawing attention to it didn’t add anything to the problem (if indeed it is a problem) and wouldn’t have made the individual in question feel more welcome at that event.

What am I going to do about it? For one, take the person concerned for a coffee and talk about what we can do to break down boundaries between technical nerds like myself and the people on the frontlines of journalism (watch this space to see how that goes). I’d be interested in other things you think would be worth doing here, too. Let me know.

Humans and algorithms

Dick Costolo, CEO of Twitter, has made headlines this week for his admission that “we suck at dealing with abuse and trolls” as part of an internal memo. While Twitter is unclear about how they currently moderate the platform, it seems that much of the removal of questionable content is done via users reporting it, rather than by Twitter employees actively engaged in seeking out abusive content and removing it.

Google has a similar fear of policing their content. Famously, they refused to take down a racist graphic of Michelle Obama in 2009, adding a message to the results page which explained they won’t take down a link “simply because its content is unpopular or because we receive complaints concerning it”. They went on to point to their algorithms (including a nerdy boast about the “thousands of factors” they make use of), which account for the “integrity” of their search results.

Twitter’s own “rules” are explicit about their stance on this theme (emphasis mine):

We respect the ownership of the content that users share and each user is responsible for the content he or she provides. Because of these principles, we do not actively monitor and will not censor user content, except in limited circumstances described below.

The “limited circumstances” they mention are mostly around fake accounts and legal concerns, although there is one mention of “direct, specific threats against others” (which, it seems, is up to users to report or “local authorities” to bring to Twitter directly). Their use of “censor” speaks volumes about their current take on what it would mean to actively moderate the stream.

There’s a brief parallel here with the web development community. Last year, Eric Meyer, a prominent web developer and industry figure, lost his six year old daughter Rebecca to a brain tumour. In response, a set of developers and friends proposed adding the alias “rebeccapurple” (a colour she loved) to the hex color #663399 as a tribute to her life (and his work). The change was accepted, but was not without controversy: on several technical discussions, people argued against the change:

I don’t see why a project like Mozilla would allow an emotional response to work its way into actual code, and I think it’s dangerous precedent. We don’t need in-jokes, easter eggs, or memorials in established web standards, and I think it’s irresponsible to suggest that this is the right course of action. – Jay P

For me, this comes down to the same thing as Google’s refusal to overrule the all-powerful algorithm or Twitter’s clear desire to avoid the messy business of hiring humans to police other humans. These are technology companies (or technical standards): there’s an almost outright fear that any involvement of actual people making emotional, “logic-free” decisions is an admission that the whole system is imperfect and unworkable.

Why are we so afraid of the things that make us human accidentally making their way into our systems? As if the world we currently live in isn’t shaped by humans and our emotion in its words, its social conventions, its standardisation and its measurements?

Maybe Dick Costolo will reconsider the claim that removing questionable content is “censoring” users. He might reflect instead that he has the power to shape the experiences of an entire social group—users of the web—and that allowing human emotion, empathy and compassion to shape that group might in fact be to its benefit, rather than passing the buck to computer code.

And maybe we’re too complicated for mere algorithms, no matter how “integral” they are.

 

Book review: JavaScript & jQuery (by Jon Duckett)

I was excited to sit down and read the newly-published JavaScript & jQuery by Jon Duckett, produced by the team behind the hugely well-received HTML & CSS book. It’s a large and beautifully-designed tome aimed at newbie developers with familiarity with HTML/CSS but no experience with programming in the browser. In this post I’ll offer some thoughts and feedback on a couple of aspects of the book, but the TL;DR version is: if you’re new to front-end web development, buying this is a no-brainer.

Things that are amazing about the book:

  • It’s very thorough. It rarely rushes (it’s over 600 pages long) and builds things up logically, “linking” to future chapters where topics that are hinted at will become fleshed out. For someone new to the language it will give them a thorough grounding in many aspects of JS.
  • It’s good at answering the “why should I care?” question. Many of the code examples would be challenging to explain in purely theoretical terms, but by pairing them with screenshots of an attractively-designed mock website and using the code to manipulate the page, it’s never a challenge to work out why a particular function or property is useful for making websites.
  • It’s gorgeously designed. The image on the book website of the for-loop flow diagram is probably the money shot, but generally it’s a pleasure to read and may be the only published JavaScript book which will make you look cool while you’re reading it in a coffee shop.
  • It’s great value. I came into the jQuery plugins section thinking it’d just be a way to pad out the last hundred pages or so with cheap instructions on using lightbox or something, but in fact it broke down the concepts and the DOM structure in almost obsessive detail and really got into the idea of building things in modular, configurable way. This is probably a bit advanced for the casual reader but represents good value for money (and plenty of repeat reading value when someone’s digested the basics).
  • It works for experienced developers as well as newbies. I’ve been writing JavaScript for quite a while these days but there were things in here that were new to me (I didn’t know jQuery had a $(“:header”) selector…) and it also cleared up a few niggly things that I could never quite adequately explain to myself. In general it’d be a great reference book to have around an office or home, regardless of experience level.

Things that I found a bit weird about the book:

  • Early on in the book there are code examples where a HTML element’s class attribute is set to the string “true” or “false” depending on a Boolean. There’s a quick disclaimer that this is rarely useful but it seemed odd to me to demonstrate it all rather than using a proper, semantic string for a classname.
  • Some of the layout choices made it difficult to know what order to read things. It did sometimes feel that things had been placed on the page in order to achieve optimum symmetry or alignment rather than to aid readability. Here’s an example:IMG_20141001_223200
    Some pages have this style of text but without the numbering and it’s not always clear if you’re reading in columns or rows.
  • In the section on JavaScript’s Date object, the book explains that getMonth() will return a month number ranging from 0-11, but doesn’t flag this up enough in my opinion (or attempt to explain why this is the case, although I have no idea either…). This feature often catches out newbie developers with JS.
  • This code sample is a bit weird too. I understand the technique and why it’s mentioned but I think it’s an unhelpful and confusing thing to show to a new developer (mangling HTML to fix cross-browser issues?) and just serves to make them think browser support for fairly innocuous stuff is even worse than it is.

    IMG_20141001_223324
  • As beautiful as the pages must’ve looked on a screen during design, the all-black pages lose something by the time a sticky set of paws like mine touch them:IMG_20141001_223339
  • This page (and a few others like it) seemed a bit incongruous:IMG_20141001_223400
    Again, I can see why they felt it should be included, but why give it a whole page?
  • The Handling Exceptions section feels a bit rushed and glosses over some concepts that are fairly challenging for anyone who’s never come across try/catch blocks before (eg. most of the intended audience?). The tone of some of these pages was (to me) markedly more complex than other parts of the book.
  • This sentence:IMG_20141001_223525
    Maybe I’m just immature, but the quote marks around “closed” felt a bit melodramatic.
  • I can’t really see any reason to angle the “blurb” text on the back cover except to make it feel like decoration and not something you’d actually read:IMG_20141001_233948
  • Similarly, the angle of the text on the spine is different from all the other books I own which is mildly jarring to my OCD:IMG_20141001_234043

These are almost all minor quibbles though. There are a couple of clear code/printing errors (which the website already corrects) and one or two fonts which feel a bit large to read comfortably up close, but otherwise nothing to be worried about.

So, overall thoughts? Well, I already recommended the book to members of the HTML, CSS & JavaScript beginner’s course I teach, which should tell you something. It’s massively well-researched, works on multiple levels and has been put together in a beautiful, readable and understandable format. The team working on this have worked really hard to create something that will no doubt go down as a classic of the genre (as the HTML & CSS book has) and I’ve already had multiple people in my office eyeing up my review copy and asking to borrow it when I’m done.

If you’re new to JavaScript or need a refresher, go out and pick this up – I was really impressed.

Note: the photos above are all from my fairly rubbish camera on my phone, so if text looks weird / blurry etc, that’s almost certainly my fault. The book itself looks lovely – check out the website for more.

Full disclosure: I received a free copy of the book for review, but that’s all.

London, I love you, but you’re bringing me down

I turned 28 this week and have begun to find that my life and those of my peers seems to have come to a fork in the road. The ones who live in the general area I’m calling “not London” have taken one fork in the path, while those of us in the “London” camp are voyaging down a different route. Every now and again I get a reminder from the people on the other track that things are diverging even quicker than I thought.

I moved to London four years ago, primarily for my career – I’m a web developer with an interest in working for media organisations, and both of those industries tend to align themselves to capital cities. Likewise, my partner Maddy: she’s worked for a succession of charities who also tend to base themselves in major cities like London.

I have a bunch of friends here in London and a similarly-sized group back in Nottingham where I grew up. While both groups consist of people (mostly in couples these days) aged in their mid-to-late 20s, the differences are becoming more and more striking.

Almost all of the “serious” couples I know back home in Nottingham are already homeowners, or at least, well on the way to becoming one. Quite a few are married, and a few weeks ago, one of my closest friends revealed that he and his fiancee are expecting a child. This is the first of my best friends to enter this phase of the relationship (end?)game and won’t be the last. I can’t begin to imagine the same things happening in my London circle.

In London, my friends of my own age are almost exclusively renting, paying over the odds for small, random flatshares in a variety of areas. One or two somehow own places (I’ve always assumed this is down to improbable good fortune or simply support from their parents), but everybody else is in the same position I am: stuck in the 12 month rental contract cycle. As for pregnancy: nobody. Or at least, nobody I can think of in that mid-to-late 20s group.

Maybe that’s normal: living and working in a city like London is likely to mean that you’re more career-minded than someone living somewhere more provincial, and thus starting a family is probably lower on your agenda. But if Maddy and I decided tomorrow that we were ready to have kids, I’d still be completely unprepared to make it happen: we’re renting a flat where the landlord could boot us out on a month’s notice, and by August 2015 we’ll be out whether or not we want to be (assuming the landlord raises the rent to an unaffordable level, as has happened almost everywhere else we’ve lived in the capital). What kind of environment is that to bring up a child in?

It’s worth pointing out here that I do have a bunch of slightly older friends in London who hover around the mid-to-late 30s/early 40s mark. Quite a few of these have kids and own their own places. Here I can only conclude that they managed to do so when the housing climate in London wasn’t nearly as insane as it is in 2014, and the majority live outside London (or further out than zone 3) which tends to reduces the cost of living on its own.

The divergence between these two groups was made clear to me when my friends revealed their pregnancy: I literally can’t imagine it happening to us, or to any of our couple friends. I know there’s a cliché of “there’s never a good time to have kids” and I’m sure it’s true. But as much as I love London, I can’t see how it will figure in my future. I’m being priced out of a city I love and even if I did have a spare £40k lying around for a deposit (or the mental energy to save that much up), I’d feel morally opposed to blowing it all on a one bed flat in a shitty part of town you’d never look twice at if it didn’t have a 30 minute connection to Kings Cross.

What’s the answer? Clearly people can and do bring up children in London and buy homes and I’m fortunate enough to be better off than many of the people struggling to do just that. But while I’m feeling smug about London’s cultural heritage and career opportunities compared to other UK cities, my homebody friends back in the north are settling down and starting families while I feel like my development on that front is on pause as long as I live here. I have no idea what I’m going to do next.

How animated gif selfies fixed our team’s morale

Lately I’ve been thinking a lot about software team morale. I’ve switched teams a couple of times so far this year at work and have had a fairly different experience on each one. Some were large (10+ people), some small (3 people, one on a different continent) and each has had its own mix of positives and negatives. Morale varied: some were doing well, others had issues on and off. The team I’m currently on seems to have found a way to make sure the positives outweigh everything else. How have they managed this? Selfies.

I’m being entirely serious: the majority of GitHub pull requests on the team feature animated gif selfies, recorded via webcams using the ingenious GitHub Selfies browser plugin. Here’s an example:

will-run

When I first joined the team, someone explained that it was semi-mandatory to include a mildly-relevant gif along with a pull request or comment. Here’s my nervous first foray into GitHub selfies:

matt

Initially I was bemused. This was just a bit of fun, a sort of initiation ceremony for a new member on an established team. But as time wore on I noticed that the team (and gradually, me) were putting in a good amount of effort into producing stuff that was entertaining, clever and endearing. Here are some of my favourites, along with the contents of the code changes:

I made a pull request making some changes to the footer (get it?):

matt-footer

Will hilariously responded:

will-footer

Will swapped out one card processing system for another:

swap-card

Jenny and Will did some work to swap over user credentials (this one took some serious co-ordination):

swap-2 swap-1

Will removed a “friend” tier from the app

remove-friend-tier

Roberto and Will refactored payment flows:

refactor-payment-flows

I did a few quick fixes; Will gave his approval:

quick-fixes

Ben removed an “optimisation”

optimisation

I fixed something for stupid IE9:

ie9

Chris corrected an embarrassing error:

chris-remove-stupid-thing

Will playing a ukulele (I don’t think there was a good reason for this):

uke

The key impact here for me is that I now actively look forward to pull requests, and put some thought into how I can present mine to the rest of my team. Obviously there’s a risk that you end up spending more time thinking about funny animated gif selfies than you do about the actual code, but in practice it doesn’t work like that for us – we’re on quite a strict deadline and I genuinely believe if we didn’t have something like this to lighten the mood then we’d all be tense and snapping at each other.

On previous teams I’d come to dread code reviews: developers can sometimes (often, even) be terrible communicators. The whole “asynchronous communication” thing makes total sense when working in private on something difficult, but when it comes to collaboration, the situation where somebody sat three feet away from you is tearing apart your code can be quite difficult to manage. Sometimes it becomes easy to forget that the person producing the code is a human being with needs and emotions, rather than just a factory producing code that either is or isn’t up to scratch.

These animations and jokes have really helped my team bond: there’s a camaraderie, a sense of playfulness: it’s impossible to forget that a person is at the other end of these things and is submitting their work (and therefore, themselves) for your judgement. Making it a little more friendly and personable is so, so crucial. The web is playful at its very core: it’s a creative, experimental medium. This kind of thing is part of the whimsy and humanness that sits atop the whole thing: it’s silly, but it really works.

Mostly to avoid this post being solely comprised of gifs (good though they are), I asked some developer friends for their thoughts and got some smart tweets back:

There was also a great recommendation from Jonathan Kahn, who pointed to Alice Bartlett’s great blog post about her new role at GDS. Specifically, Alice said (emphasis mine):

I put stuff in pull requests that I know isn’t perfect, because nothing is perfect. Really what you’re aiming for is some collective level of OK-ness. Someone told me “think of the pull request comments as a to-do list” rather than a list of every single thing you cocked up, with which to flagellate yourself. This helps me now, but it took a long time to sink in. As a result, if I’m giving feedback on a pull request, I always go find the person first and check how they’d best like the feedback, sometimes I’ll offer to pair with them on it, or email them feedback privately. I think it’s polite to give people options.

This kind of thing, too, is so crucial. It all comes down to the same thing, I think: treating people like human beings, who make mistakes, have mostly good intentions, and are your friends (or, at least, colleagues…). Sometimes it’s easy to just treat someone as though they are their code. When there’s an animated gif of them playing the ukulele, you’re reminded right away that there’s more to them than that.