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:

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:

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?):

Will hilariously responded:

Will swapped out one card processing system for another:

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

Will removed a “friend” tier from the app

Roberto and Will refactored payment flows:

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

Ben removed an “optimisation”

I fixed something for stupid IE9:

Chris corrected an embarrassing error:

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

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:

@mattpointblank … tend to be more able to come to sensible solutions without hurting each other's feelings in face to face conversation. — Robert Berry (@yrrebjr) August 15, 2014

@mattpointblank I sometimes find it's helpful to remember you are reviewing their code, not telling them how you would have written it — adamnfish (@adamnfish) August 15, 2014

@mattpointblank @yrrebjr @adamnfish I've seen pull req with ~20 posts over a couple of lines of CSS. Cld've been resolved with a 5 min chat. — M O'Brien (@moschops_) August 15, 2014

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.