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

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.

Protected: In defence of reddit

This content is password protected. To view it please enter your password below:

Why do we think developers are special?

I teach a Guardian Masterclass as part of their “Digital Journalism Bootcamp” course. Specifically, my part of the month-long class is a 90 minute workshop aimed at journalists, outlining how developers work, what they do, and how they use process to organise work (there’s an Agile taster session). There are also some more general tips on how to get on with a type of person who’s traditionally seen as a bit grumpy, difficult to communicate with, or even hostile.

In this latter section, I found myself being challenged by one vocal member of the group who interrupted me a few times to point out that “I do that too”, particularly during a section on the cost of context-switching. I was talking through a slide which looked like this:

Digital Journalism talk

 

I was beginning to say something about the situation where a developer is juggling multiple things in their head at any one time, and how costly it can be when someone comes along and interrupts that flow. She spoke up to say that when dealing with clients, for example, she too is often juggling multiple things around. I tried to fumble an example of how a developer may be thinking about variable scope, cross-browser API implementation, an outstanding pull request to review and remembering which branch to commit on – all at the same time – but to a non-technical audience this was quite a challenge to explain.

It did get me thinking, though. I have other slides in this section dealing with the developer clichés: don’t fill their calendar with meetings; don’t disturb them when they have headphones on; keep communications brief and ideally asynchronous. But why do any of these things apply specifically to developers?

This same woman had challenged me earlier in the session when I hinted at some of these points and she suggested developers were “just being precious”. I conceded this, saying that because of their (likely) introvert personas, sometimes humouring them with this was the way to achieve results. This resulted in some challenging questions from another attendee at the end who felt I was telling them to “pander” to developers. Again, I was left wondering why we talk about things in this way.

I’ve already written here in the past about “the love affair of the tech nerd with themselves“. I wrote back in 2012:

Developers (“makers”) aren’t some special race of superhumans, whose every sensitivity and quirk needs to be preciously catered for. We’re normal people and shouldn’t be made to feel otherwise. Developers love to scoff at project managers and HR people, clogging up important coding hours with pointless meetings and busywork. Again, while there’s some truth to that, it’s also supremely arrogant to label ourselves as somehow above the systems everyone else works with (grudgingly or not).

Maybe my slides are just plain wrong and these tips just apply to people in general. But when researching the talk and reading up on other people’s top tips for productive relationships with developers, these were the kind of points being raised time and time again. Do we really think that as a profession we deserve special treatment?

The woman at the end suggested there was some give and take in both directions, which I agreed with, pointing out I was teaching a class to journalists about working with developers, and not vice-versa. Still though: why do you think we treat developers like their needs are special and different from others? How much of this is really true?

Lessons learned self-publishing for Kindle and print simultaneously

It was one of those fateful moments where you catch yourself thinking “how difficult could it be?”.

It’s been ten years (almost eleven now) since I started Scene Point Blank, the online music zine which came to define my late teens and the eventual career path I’d choose. It started out as a collective of music-loving nerds from an online messageboard writing about punk and hardcore. The website branched out and expanded and a decade later we were wondering what we could do to celebrate ten years of publishing.Since our roots were in the punk publishing world of fanzines, we talked about producing a print zine for the tenth anniversary. Eventually we rejected this due to the complexity of distribution and up-front printing costs. Scene Point Blank isn’t a profitable venture and we didn’t want to have to learn complex lessons about shipping product and fulfilling orders.

It was around this time that I remembered that Kindle books are literally a zip file containing HTML, CSS and image files. This is pretty much all the content of Scene Point Blank is. How hard could it be to just write a quick template to spit out eBook-friendly markup and publish the thing?

Quite hard in places, it turns out.

The decision to publish for e-readers was expanded by the discovery of lulu.com, a self-publishing platform. Lulu offer a print-on-demand service: you upload a PDF, your users buy it, and a single copy is printed somewhere near their location and mailed to them. It’s basically vanity publishing and the cost per unit is so high that it’s probably non-profit publishing too, but our goal wasn’t to make money, but simply to have a book of our best work that people might read.

This changed things a little. While it’s certainly possible to convert HTML into a PDF, I didn’t want to have a print edition of the book which was an afterthought. Dusting off my copy of InDesign, I decided to return to the skills of my former job as a graphic designer and actually create a proper print edition.

Next I discovered that Amazon offers an “Export to Kindle” plugin for InDesign. A few quick experiments revealed that the output of this tool was pretty decent for our needs: we weren’t using any images (mainly due to copyright concerns about things like album artwork and press photography) and it handled typography pretty well. My strategy became: design the book for print, then export a Kindle version from that.

Amazon's Kindle export plugin for InDesign
Amazon’s Kindle export plugin for InDesign

This almost worked. I reacquainted myself with InDesign and printed pages of proofs to test font families, line spacing and margins. There are a lot of things I’d forgotten about that ended up being important concerns for a well-typeset book:

1. Inside margins need to be larger than outside ones to compensate for the spine/fold:

Inside margins need to be larger than outside ones to compensate for the spine/fold

2. Hanging punctuation probably belongs on the outside of the margins otherwise justified text looks a little unusual:

Top: with punctation outside margins. Bottom: inside margins
Top: with punctation outside margins. Bottom: inside margins

3. Hard linebreaks between paragraphs look good on the web, but weird in print: the job of replacing them all was a tricky one (but luckily, InDesign supports regexes):

Hard linebreaks between paragraphs look good on the web, but weird in print: the job of replacing them all was a tricky one (but luckily, InDesign supports regexes)

4. Widows and orphans are difficult to fix automatically (eg. without actually editing text) unless you’re happy to sacrifice consistent tracking (which you shouldn’t be):

Widows and orphans are difficult to fix automatically (eg. without actually editing text) unless you're happy to sacrifice consistent tracking (which you shouldn't be)
An annoying leftover orphan from the previous page

Getting this right wasn’t impossible but took a fair bit of trial and error. It wasn’t until I received the first test print of the book from Lulu before I could find out if some of my work was usable or not. It turned out that the chapter intro pages I thought looked great onscreen looked a bit rubbish in print:

Chapter heading pages
On the left: the printed version, with text clearly too large and too close to margins. On the screen (right), though, it looked okay.

The cover was another thing I made a mess of initially: like a fool I forgot to account for the spine (perhaps because the magazine I worked for as a designer wasn’t bound with one) and so when it came to uploading the cover my design was several centimetres short. I quickly added one but the fact that its width was variable because of my page count meant I had to wait till all the book’s content was finalised to confirm its dimensions.

Generating a table of contents was also problematic: I’d used InDesign’s paragraph styles religiously, but perhaps not in the way it wanted me to: for our album reviews I typeset them like this:

Some InDesign paragraph styles

This meant that when generating the ToC I couldn’t achieve an output of “Janelle Monáe – The ArchAndroid”: InDesign would treat each entity as a separate (but duplicate) page reference. After giving up finding a smarter solution I ended up manually curating the ToC, which has left me wary of changing the page numbering (and therefore most of the content).

The Kindle aspect became more difficult at this point. The aforementioned chapter pages became more of a challenge for the e-reader. Although Amazon’s plugin didn’t attempt to recreate the shaded background or circle shape, it did do weird things to the type in terms of pagebreak locations and heading sizes. I tried playing with the export options to no avail and began to investigate InDesign’s methods of outputting different layouts.

It turns out InDesign has several different methods for varying content:

Alternate Layout, which lets you keep the content but lay it out for another device or dimension, which seemed exactly what I needed. Amazon’s plugin ignored this completely when exporting: back to the drawing board.

Next I tried Conditional Text, seeing if I could just change a variable (e.g. print=true) when exporting and supply different text fields to the Kindle edition. Again, Amazon’s plugin ignored this. I could generate PDFs happily using these techniques, but I wanted the pure . format as exported by Amazon, presuming it would be the most “correct” format.

Object States seemed like another solid option: surely I could use them to just change the visual styles for the problematic pages at export time? Nope: once again, meaningless to Amazon’s plugin.

In the end I gave up and did the thing I’d been worrying I’d have to do: duplicated the entire document, saved it as “Kindle Edition”, and made the changes manually. The whole reason for doing it this way to begin with was so I could make changes in one place and export to all platforms. That dream had died with my chapter headings.

In the end, I think it was the right call. There was a certain feeling of liberation: every time I changed things in the print edition I didn’t have to spend five minutes nervously exporting to Kindle to check I hadn’t broken something. The problematic ToC became less of an issue as I could manually edit the print one but fix the auto-generated one for Kindle without butchering the printed version. Page breaks that worked in print but felt pointless on the Kindle were removed and vice-versa. The thing I’d been worrying most about – fixing typos and editing content in multiple formats – was rarely an issue. Maybe this was down to fairly diligent spellchecking before forking the document, or just luck (or ignorance).

The finished print edition
The finished print edition

Finally, it was time to actually publish the things. Lulu provides you with an ISBN for free when using their service, which was nice and helped me feel like the process was legitimate. They also allow you to set the book price, but it must be above a minimum, which is their printing costs + their own cut of profits, I assume. Our minimum for a ~350 page book was £9.20, which is fairly steep for a paperback, but we set it at £9.50 and on we went. Once the PDF was uploaded it was available to buy: vanity publishing, no question.

Amazon was interesting: I thought it’d take a while for it to be approved for sale. As it turned out it took less than a day. An automated scan came back after I uploaded the .mobi file, which pointed out typos I’d missed. These fixed, I resubmitted and suddenly there it was, on Amazon. I had to fill out some lengthy tax information for the US taxman, despite my bank account being a UK one, which meant I had to guess at some of the values and acronyms used in this form. I also had to create a separate author profile for each country Amazon operates in: this seemed sensible, in that you may wish to tailor these to each market/language, but it would’ve been helpful to have an “Import from Amazon.com” option when editing the UK profile.

All in all, the process was more complex than I naïvely expected. I think I would have ultimately saved time if I’d forked the book earlier and avoided trying to reach the “purity” of a single input with multiple outputs. I suppose I could’ve simply published the Kindle edition as HTML/CSS and hand-tweaked it, but life’s too short when the content is 115,000 words long.

For all the vanity publishing jokes, Lulu is a great service. The price is fairly competitive given that it’s printed on demand, and the quality was fairly good (I could’ve picked more expensive paper stocks and dimensions but was aiming for a sub-£10 product). Getting an ISBN helped make it feel more “real” (Amazon doesn’t require these for Kindle self-publishing) and although I found them slow, their tools for uploading and managing content were pretty usable.

If I was to do it all again I’d have accepted that publishing multiple formats is too different to expect one tool to process them all. That said though, it’s almost trivially simple to get something online and for sale. It’s easier than ever to publish your stuff, so why aren’t you doing it too?

Tech half-life: it’s okay to be wrong

Note: this blog entry is taken from the first print issue of the experimental “algorithmic newspaper”, The Long Good Read. You can find more about that project on the official site.

A developer I work with has been at the company for a decade. His argument for that longevity? He says it takes five years for code you wrote to come back and bite you once it needs replacing. This reminder of our role in the half-life of technology is something I find fascinating: what does it mean that we’re not futureproof?

Every developer has a legacy system they work with (willingly or otherwise). Likewise, every developer will curse that system daily and point out with glee to newbie developers how awfully-implemented the search feature is; how laughably broken the application looks in Firefox; how many disparate JavaScript libraries are jumbled into the page. But these decisions weren’t made by idiots, cobbling together rushed web products. They were made by you – or your peers half a decade ago.

It’s a humbling experience to have that realisation, that moment of clarity. To know that your decisions which were once sound, best practice, are today the examples shown to fledgling hackers to scare them into avoiding monolithic codebases or teach them why modular programming is important. But if it takes five years for this process to happen, why bother building things for the future in the first place?

We’re taught as software developers to architect our work with an eye on scalability: not just in terms of traffic and speed, but in terms of feature growth and expansion. Every simple problem becomes a complex challenge to solve: it’s smart to be multiple steps ahead of what your users want today.

Why bother with any of this? We’re building systems trying to anticipate every problem or change and then throwing them all away again a couple of years later. How many projects have you been involved with where the agreed solution is to chuck out the old, legacy code, and start afresh? All those architectural decisions have been learned from, updated, but ultimately dropped. Five years.

The first company I worked for was a small magazine with a dozen staff. The owner had a bit of a tech background and had gone all-out when preparing the company’s IT systems. In a dedicated room in the basement there was an enormous server rack complete with multiple RAID setups and copious air conditioning. There was a six-way monitor switch allowing you to view output from any of the machines and a steel cupboard full of cables, accessories and tools.

The office was running Windows 2000. In 2010.

Sometimes it’s easier to focus on futureproofing things and building with flexibility in mind than it is to work out what’s valuable and how to get there quickly. In practical terms, nobody at that company cared how many redundant disk backups there were, they were annoyed that they were still stuck using IE6.

Do I really believe we should code by the seat of our pants? Perhaps not quite. Anyone can hack together a quick PHP/MySQL fix which solves a problem temporarily, but the skill of analysing the problem domain and being several steps ahead of it is one that takes real practice – and adds real value. But perhaps there’s something in the idea of accepting the length of your tech half-life – and embracing it. You’re going to be wrong, one day. And that’s fine.