How can we increase gender representation in software engineering?
Our Developer Hiring Experience team analyzed this topic in a recent user-research study. The issue resonated with women engineers and a strong response enabled the team to gain deeper insight than is currently available from online research projects.
Seventy-one engineers who identified as women or non-binary responded to our request for feedback. Out of that pool, 24 answered a follow-up survey, and we carried out in-depth interviews with 14 people. This was a highly skilled group, with the majority having worked in software development for over 10 years.
While some findings aligned with our expectations, we still uncovered a few surprises.
…
Excellent research courtesy of my soon-to-be new employer about the driving factors affecting women who are experienced software engineers. Interesting (and exciting) to see that changes are already in effect, as I observed while writing about my experience of their recruitment process.
I wasn’t sure that my whiteboard at the Bodleian, which reminds my co-workers exactly how many days I’ve got left in the office, was attracting as much attention as it needed to. If I don’t know what my colleagues don’t know about how I do my job, I can’t write it into my handover notes.
Tick, tick, tick, tick, boom.So I repurposed a bit of digital signage in the office with a bit of Javascript to produce a live countdown. There’s a lot of code out there to produce countdown timers, but mine had some very specific requirements that nothing else seems to “just do”. Mine needed to:
Only count down during days that I’m expected to be in the office.
Only count down during working hours.
Carry on seamlessly after a reboot.
[insert Countdown theme song here]Naturally, I’ve open-sourced it in case anybody else needs one, ever. It’s pretty basic, of course, because I’ve only got a hundred and fifty-something hours to finish a lot of things so I only wanted to throw a half hour at this while I ate my lunch! But if you want one, just put in an array of your working dates, the time you start each day, and the number of hours in your workday, and it’ll tick away.
One of the best things about working at The Bodleian Libraries, University of Oxford? Pretending to be a PhD student for a photo shoot! Watch out for me appearing in a website near you…
My team and I do get up to some unusual stuff, it’s true. I took part in this photoshoot, too:
I’m absolutely not above selling out myself and my family for the benefit of some stock photos for the University, it seems. The sharp-eyed might even have spotted the kids in this video promoting the Ashmolean or a recent tweet by the Bodleian…
I recently announced that I’d accepted a job offer from Automattic and I’ll be starting work there in October. As I first decided to apply for the job 128 days ago – a nice round number – I thought I’d share with you my journey over the last 128 days.
Automattic conduct their entire interview process via Slack online chat. I’ve still never spoken to any of my new co-workers by phone, let alone seen them in person. This is both amazing and terrifying.
Here’s my timeline so far:
Application (days -179 to -178)
Like many geeks, I keep a list of companies that I’ve fantasised about working for some day: mine includes the Mozilla Foundation and DuckDuckGo, for example, as well as Automattic Inc. In case it’s not obvious, I like companies that I feel make the Web a better place! Just out of interest, I was taking a look at what was going on at each of them. My role at the Bodleian, I realised a while ago, is likely to evolve into something different probably in the second-half of 2020 and I’d decided that when it does, that would probably be the point at which I should start looking for a new challenge. What I’d intended to do on this day 128 days ago, which we’ll call “day -179”, was to flick through the careers pages of these and a few other companies, just to get a better understanding of what kinds of skills they were looking for. I didn’t plan on applying for new jobs yet: that was a task for next-year-Dan.
I love working here, but over the last 8 years I feel like I’ve “solved” all of the most-interesting problems.
But then, during a deep-dive into the things that make Automattic unique (now best-explained perhaps by this episode of the Distributed podcast), something clicked for me. I’d loved the creed for as long as I’d known about it, but today was the day that I finally got it, I think. That was it: I’d drunk the Kool-Aid, and it was time to send off an application.
I sat up past midnight on day -179, sending my application by email in the small hours of day -178. In addition to attaching a copy of my CV I wrote a little under 2,000 words about why I think I’m near-uniquely qualified to work for them: my experience of distributed/remote working with SmartData and (especially) Three Rings, my determination to remain a multidisciplinary full-stack developer despite increasing pressure to “pick a side”, my contributions towards (and use, since almost its beginning of) WordPress, and of course the diverse portfolio of projects large and small I’ve worked on over my last couple of decades as a software engineer.
VR experiments are among the more-unusual things I’ve worked on at the Bodleian (let’s not forget that, strictly, I’m a web developer).
At the time of my application (though no longer, as a result of changes aimed at improving gender equality) the process also insisted that I include a “secret” in my application, which could be obtained by following some instructions and with only a modest understanding of HTTP. It could probably be worked out even by a developer who didn’t, with a little of the kind of research that’s pretty common when you’re working as a coder. This was a nice and simple filtering feature which I imagine helps to reduce the number of spurious applications that must be read: cute, I thought.
Fun and simple, and yet an effective way to filter out the worst of the spurious applications.
I received an automated reply less that a minute later, and an invitation to a Slack-based initial interview about a day and a half after that. That felt like an incredibly-fast turnaround, and I was quite impressed with the responsiveness of what must necessarily be a reasonably-complex filtering and process-management process… or perhaps my idea of what counts as “fast” in HR has been warped by years in a relatively slow-moving and bureaucratic academic environment!
Initial Interview (day -158)
I’ve got experience on both sides of the interview table, and I maintain that there’s no single “right” way to recruit – all approaches suck in different ways – but the approaches used by companies like Automattic (and for example Bytemark, who I’ve shared details of before) at least show a willingness to explore, understand, and adopt a diversity of modern practices. Automattic’s recruitment process for developers is a five-step (or something like that) process, with the first two stages being the application and the initial interview.
My initial interview took place 20 days after my application: entirely over text-based chat on Slack, of course.
For all you know, your interviewer might be hanging out in the same cafe or co-working space as you. But they probably aren’t. Right?
The initial interview covered things like:
Basic/conversational questions: Why I’d applied to Automattic, what interested me about working for them, and my awareness of things that were going on at the company at the moment.
Working style/soft skills: Questions about handling competing priorities in projects, supporting co-workers, preferred working and development styles, and the like.
Technical/implementation: How to realise particular ideas, how to go about debugging a specific problem and what the most-likely causes are, understanding clients/audiences, comprehension of different kinds of stacks.
My questions/lightweight chat: I had the opportunity to ask questions of my own, and a number of mine probed my interviewer as an individual: I felt we’d “clicked” over parts of our experience as developers, and I was keen to chat about some up-and-coming web technologies and compare our experiences of them! The whole interview felt about as casual and friendly as an interview ever does, and my interviewer worked hard to put me at ease.
Skills Test (day -154)
At the end of the interview, I was immediately invited to the next stage: a “skills test”: I’d be given access to a private GitHub repository and a briefing. In my case, I was given a partially-implemented WordPress plugin to work on: I was asked to –
add a little functionality and unit tests to demonstrate it,
improve performance of an existing feature,
perform a security audit on the entire thing,
answer a technical question about it (this question was the single closest thing to a “classic programmer test question” that I experienced), and
suggest improvements for the plugin’s underlying architecture.
I was asked to spend no more than six hours on the task, and I opted to schedule this as a block of time on a day -154: a day that I’d have otherwise been doing freelance work. An alternative might have been to eat up a couple of my evenings, and I’m pretty sure my interviewer would have been fine with whatever way I chose to manage my time – after all, a distributed workforce must by necessity be managed firstly by results, not by approach.
Scheduling my code test for a period when the kids were out of the house allowed me to avoid this kind of juggling act.
My amazingly-friendly “human wrangler” (HR rep), ever-present in my Slack channel and consistently full of encouragement and joy, brought in an additional technical person who reviewed my code and provided feedback. He quite-rightly pulled me up on my coding standards (I hadn’t brushed-up on the code style guide), somewhat-monolithic commits, and a few theoretical error conditions that I hadn’t accounted for, but praised the other parts of my work.
Most-importantly, he stated that he was happy to recommend that I be moved forward to the next stage: phew!
Trial (days -147 through -98)
Of all the things that make Automattic’s hiring process especially unusual and interesting, even among hip Silicon Valley(-ish, can a 100% “distributed” company really be described in terms of its location?) startups, probably the most (in)famous is the trial contract. Starting from day -147, near the end of May, I was hired by Automattic as a contractor, given a project and a 40-hour deadline, at $25 USD per hour within which to (effectively) prove myself.
As awesome as it is to be paid to interview with a company, what’s far more-important is the experience of working this way. Automattic’s an unusual company, using an unusual workforce, in an unusual way: I’ve no doubt that many people simply aren’t a good fit for distributed working; at least not yet. (I’ve all kinds of thoughts about the future of remote and distributed working based on my varied experience with which I’ll bore you another time.) Using an extended trial as an recruitment filter provides a level of transparency that’s seen almost nowhere else. Let’s not forget that an interview is not just about a company finding the right employee for them but about a candidate finding the right company for them, and a large part of that comes down to a workplace culture that’s hard to define; instead, it needs to be experienced.
For all that a traditional bricks-and-mortar employer might balk at the notion of having to pay a prospective candidate up to $1,000 only to then reject them, in addition to normal recruitment costs, that’s a pittance compared to the costs of hiring the wrong candidate! And for a company with an unusual culture, the risks are multiplied: what if you hire somebody who simply can’t hack the distributed lifestyle?
Page 1 of 6, all written in the USA dialect of legalese, but the important part is right there at the top: the job title is “Trial Code Wrangler”. Yeah.
It was close to this point, though, that I realised that I’d made a terrible mistake. With an especially busy period at both the Bodleian and at Three Rings and deadlines looming in my masters degree, as well as an imminent planned anniversary break with Ruth, this was not the time to be taking on an additional piece of contract work! I spoke to my human wrangler and my technical supervisor in the Slack channel dedicated to that purpose and explained that I’d be spreading my up-to-40-hours over a long period, and they were very understanding. In my case, I spent a total of 31½ hours over six-and-a-bit weeks working on a project clearly selected to feel representative of the kinds of technical problems their developers face.
That’s reassuring to me: one of the single biggest arguments against using “trials” as a recruitment strategy is that they discriminate against candidates who, for whatever reason, might be unable to spare the time for such an endeavour, which in turn disproportionately discriminates against candidates with roles caring for other (e.g. with children) or who already work long hours. This is still a problem here, of course, but it is significantly mitigated by Automattic’s willingness to show significant flexibility with their candidates.
I was given wider Slack access, being “let loose” from the confines of my personal/interview channel and exposed to a handful of other communities. I was allowed to mingle amongst not only the other developers on trial (they have their own channel!) but also other full-time staff. This proved useful – early on I had a technical question and (bravely) shouted out on the relevant channel to get some tips! After every meaningful block of work I wrote up my progress via a P2 created for that purpose, and I shared my checkins with my supervisors, cumulating at about the 20-hour mark in a pull request that I felt was not-perfect-but-okay…
I’m normally more of a command-line git users, but I actually really came to appreciate the GitHub Desktop diff interface while describing my commits during this project.
…and then watched it get torn to pieces in a code review.
Everything my supervisor said was fair, but firm. The technologies I was working with during my trial were ones on which I was rusty and, moreover, on which I hadn’t enjoyed the benefit of a code review in many, many years. I’ve done a lot of work solo or as the only person in my team with experience of the languages I was working in, and I’d developed a lot of bad habits. I made a second run at the pull request but still got shot down, having failed to cover all the requirements of the project (I’d misunderstood a big one, early on, and hadn’t done a very good job of clarifying) and having used a particularly dirty hack to work-around a unit testing issue (in my defence I knew what I’d done there was bad, and my aim was to seek support about the best place to find documentation that might help me solve it).
I felt deflated, but pressed on. My third attempt at a pull request was “accepted”, but my tech supervisor expressed concerns about the to-and-fro it had taken me to get there.
Finally, in early July (day -101), my interview team went away to deliberate about me. I genuinely couldn’t tell which way it would go, and I’ve never in my life been so nervous to hear back about a job.
A large part of this is, of course, the high esteem in which I hold Automattic and the associated imposter syndrome I talked about previously, which had only been reinforced by the talented and knowledgable folks there I’d gotten to speak to during my trial. Another part was seeing their recruitment standards in action: having a shared space with other candidate developers meant that I could see other programmers who seemed, superficially, to be doing okay get eliminated from their trials – reality TV style! – as we went along. And finally, there was the fact that this remained one of my list of “dream companies”: if I didn’t cut it by this point in my career, would I ever?
Two days later, on day -99, I shared what felt like an appropriate My Little Pony: Friendship is Magic GIF with the interview team via Slack.
It took 72 hours after the completion of my trial before I heard back.
I was to be recommended for hire.
On day -98 I literally jumped for joy. This was a hugely exciting moment.
It was late in the day, but not too late to pour myself a congratulatory Caol Ila.
OMGOMGOMGOMG.
Final Interview (day -94)
A lot of blog posts about getting recruited by Automattic talk about the final interview being with CEO Matt Mullenweg himself, which I’d always thought must be an unsustainable use of his time once you get into the multiple-hundreds of employees. It looks like I’m not the only one who thought this, because somewhere along the line the policy seems to have changed and my final interview was instead with a human wrangler (another super-friendly one!).
That was a slightly-disappointing twist, because I’ve been a stalker fanboy of Matt’s for almost 15 years… but I’ll probably get to meet him at some point or other now anyway. Plus, this way seems way-more logical: despite Matt’s claims to the contrary, it’s hard to see Automattic as a “startup” any longer (by age alone: they’re two years older than Twitter and a similar age to Facebook).
The final interview felt mostly procedural: How did I find the process? Am I willing to travel for work? What could have been done differently/better?
Conveniently, I’d been so enthralled by the exotic hiring process that I’d kept copious notes throughout the process, and – appreciating the potential value of honest, contemporaneous feedback – made a point of sharing them with the Human League (that’s genuinely what Automattic’s HR department are called, I kid you not) before the decision was announced as to whether or not I was to be hired… but as close as possible to it, so that it could not influence it. My thinking was this: this way, my report couldn’t help but be honest and unbiased by the result of the process. Running an unusual recruitment strategy like theirs, I figured, makes it harder to get honest and immediate feedback: you don’t get any body language cues from your candidates, for a start. I knew that if it were my company, I’d want to know how it was working not only from those I hired (who’d be biased in favour it it) and from those who were rejected (who’d be biased against it and less-likely to be willing to provide in-depth feedback in general).
I guess I wanted to “give back” to Automattic regardless of the result: I learned a lot about myself during the process and especially during the trial, and I was grateful for it!
Show me the money!
One part of the final interview, though, was particularly challenging for me, even though my research had lead me to anticipate it. I’m talking about the big question that basically every US tech firm asks but only a minority of British ones do: what are your salary expectations?
As a Brit, that’s a fundamentally awkward question… I guess that we somehow integrated a feudalistic class system into a genetic code: we don’t expect our lords to pay us peasants, just to leave us with enough grain for the winter after the tithes are in and to protect us from the bandits from the next county over, right? Also: I’ve known for a long while that I’m chronically underpaid in my current role. The University of Oxford is a great employer in many ways but if you stay with them for any length of time then it has to be for love of their culture and their people, not for the money (indeed: it’s love of my work and colleagues that kept me there for the 8+ years I was!).
I’m pretty sure that most Brits are at least a little uncomfortable, even, when Dennis gives lip to King Arthur in Monty Python and the Holy Grail.
Were this an in-person interview, I’d have mumbled and shuffled my feet: you know, the British way. But luckily, Slack made it easy at least for me to instead awkwardly copy-paste some research I’d done on StackOverflow, without which, I wouldn’t have had a clue what I’m allegedly-worth! My human wrangler took my garbled nonsense away to do some internal research of her own and came back three hours later with an offer. Automattic’s offer was very fair to the extent that I was glad to have somewhere to sit down and process it before responding (shh… nobody tell them that I am more motivated by impact than money!): I hadn’t been emotionally prepared for the possibility that they might haggle upwards.
Three months on from writing my application, via the longest, most self-reflective, most intense, most interesting recruitment process I’ve ever experienced… I had a contract awaiting my signature. And I was sitting on the edge of the bath, trying to explain to my five year-old why I’d suddenly gone weak at the knees.
I wanted to insert another picture of the outside of my office at the Bodleian here, but a search of my photo library gave me this one and it was too adorable to not-share.
Getting Access (day -63)
A month later – a couple of weeks ago, and a month into my three-month notice period at the Bodleian – I started getting access to Auttomatic’s computer systems. The ramp-up to getting started seems to come in waves as each internal process kicks off, and this was the moment that I got the chance to introduce myself to my team-to-be.
I can see my team… and they can see me? /nervous wave/
I’d been spending occasional evenings reading bits of the Automattic Field Guide – sort-of a living staff handbook for Automatticians – and this was the moment when I discovered that a lot of the links I’d previously been unable to follow had suddenly started working. You remember that bit in $yourFavouriteHackerMovie where suddenly the screen flashes up “access granted”, probably in a green terminal font or else in the centre of a geometric shape and invariably accompanied by a computerised voice? It felt like that. I still couldn’t see everything – crucially, I still couldn’t see the plans my new colleagues were making for a team meetup in South Africa and had to rely on Slack chats with my new line manager to work out where in the world I’d be come November! – but I was getting there.
Getting Ready (day -51)
The Human League gave me a checklist of things to start doing before I started, like getting bank account details to the finance department. (Nobody’s been able to confirm nor denied this for me yet, but I’m willing to bet that, if programmers are Code Wranglers, devops are Systems Wranglers, and HR are Human Wranglers, then the finance team must refer to themselves as Money Wranglers, right?)
They also encouraged me to get set up on their email, expenses, and travel booking systems, and they gave me the password to put an order proposal in on their computer hardware ordering system. They also made sure I’d run through their Conflict of Interest checks, which I’d done early on because for various reasons I was in a more-complicated-than-most position. (Incidentally, I’ve checked and the legal team definitely don’t call themselves Law Wranglers, but that’s probably because lawyers understand that Words Have Power and must be used correctly, in their field!)
Wait wait wait… let me get this straight… you’ve never met me nor spoken to me on the phone and you’re willing to post a high-end dev box to me? A month and a half before I start working for you?
So that’s what I did this week, on day -51 of my employment with Automattic. I threw a couple of hours at setting up all the things I’d need set-up before day 0, nice and early.
I’m not saying that I’m counting down the days until I get to start working with this amazing, wildly-eccentric, offbeat, world-changing bunch… but I’m not not saying that, either.
Like Automattic (Matt’s company), Three Rings has also long been ahead of the curve from a “recruit talent from wherever it is, let people work from wherever they are” perspective. Until I was recently reading (more than I had previously) about the way that Automattic “works” I was uncertain about the scalability of Three Rings’ model. Does it work for a commercial company (rather than a volunteer-run non-profit like Three Rings)? Does it work when you make the jump from dozens of staff to hundreds? It’s reassuring to see that yes, this kind of approach certainly can work, and to get some context on how it does (in Automattic’s case, at least). Nice video, Matt!
The Bodleian has a specific remit for digital archiving… but sometimes they just like collecting stuff, too, I’m sure.
The team responsible for digital archiving had plans to spend World Digital Preservation Day running a stand in Blackwell Hall for some time before I got involved. They’d asked my department about using the Heritage Window – the Bodleian’s 15-screen video wall – to show a carousel of slides with relevant content over the course of the day. Or, they added, half-jokingly, “perhaps we could have Pong up there as it’ll be its 46th birthday?”
Free reign to play about with the Heritage Window while smarter people talk to the public about digital archives? Sure, sign me up.
But I didn’t take it as a joke. I took it as a challenge.
Emulating Pong is pretty easy. Emulating Pong perfectly is pretty hard. Indeed, a lot of the challenge in the preservation of (especially digital) archives in general is in finding the best possible compromise in situations where perfect preservation is not possible. If these 8″ disks are degrading, is is acceptable to copy them onto a different medium? If this video file is unreadable in modern devices, is it acceptable to re-encode it in a contemporary format? These are the kinds of questions that digital preservation specialists have to ask themselves all the damn time.
The JS Gamepad API lets your web browser talk to controller devices.
Emulating Pong in a way that would work on the Heritage Window but be true to the original raised all kinds of complications. (Original) Pong’s aspect ratio doesn’t fit nicely on a 16:9 widescreen, much less on a 27:80 ultrawide. Like most games of its era, the speed is tied to the clock rate of the processor. And of course, it should be controlled using a “dial”.
By the time I realised that there was no way that I could thoroughly replicate the experience of the original game, I decided to take a different track. Instead, I opted to reimplement Pong. A reimplementation could stay true to the idea of Pong but serve as a jumping-off point for discussion about how the experience of playing the game may be superficially “like Pong” but that this still wasn’t an example of digital preservation.
Bip… boop… boop… bip… boop… bip…
Here’s the skinny:
A web page, displayed full-screen, contains both a <canvas> (for the game, sized appropriately for a 3 × 3 section of the video wall) and a <div> full of “slides” of static content to carousel alongside (filling a 2 × 3 section).
Javascript writes to the canvas, simulates the movement of the ball and paddles, and accepts input from the JS Gamepad API (which is awesome, by the way). If there’s only one player, a (tough! – only three people managed to beat it over the course of the day!) AI plays the other paddle.
A pair of SNES controllers adapted for use as USB controllers which I happened to own already.
Increasingly, the Bodleian’s spaces seem to be full of screens running Javascript applications I’ve written.
I felt that the day, event, and game were a success. A few dozen people played Pong and explored the other technology on display. Some got nostalgic about punch tape, huge floppy disks, and even mechanical calculators. Many more talked to the digital archives folks and I about the challenges and importance of digital archiving. And a good time was had by all.
I’ve open-sourced the entire thing with a super-permissive license so you can deploy it yourself (you know, on your ultrawide video wall) or adapt it as you see fit. Or if you’d just like to see it for yourself on your own computer, you can (but unless you’re using a 4K monitor you’ll probably need to use your browser’s mobile/responsive design simulator set to 3200 × 1080 to make it fit your screen). If you don’t have controllers attached, use W/S to control player 1 and the cursor keys for player 2 in a 2-player game.
Some days my job… isn’t like other people’s jobs. Lately, I’ve been reimplementing Pong in Javascript for the @bodleianlibs’ video wall for an event on Thursday.
Implemented a demonstrative XSS payload targetting a CMS (as a teaching tool, to demonstrate how a series of minor security vulnerabilities can cascade into one huge one).
Gotten my ‘flu jab.
Not every day is like this. But sometimes, just sometimes, one can be.
In addition to the pension I get from my “day job” employer, I maintain a pension pot with a separate private provider which I top up with money from my freelance work. I logged in to that second pension provider’s (reliably shonky, web-standards-violating) website about a month ago and found that I couldn’t do anything because they’d added a new mandatory field to the “My Profile” page and I wasn’t allowed to do anything else until I’d filled it out. No problem, I thought: a few seconds won’t kill me.
If I’m lucky, I might be able to afford to retire this century.
The newly-added field turned out to be “Gender”, and as it was apparently unacceptable to leave this unspecified (as would be my preference: after all, I’ll certainly be retiring after November 2018, when gender will cease to have any legal bearing on retirement age), I clicked the drop-down to see what options they’d provided. “Not provided”, “Male”, and “Female” were the options: fine, I thought, I’ll just pick “Not provided” and be done with it. And for a while, everything seemed fine.
Leaving the field as the undefined “Select One” option wasn’t valid (I tried!) so I changed the value.
Over three weeks later I received a message from them saying that they hadn’t yet been able to action the changes to my profile because they hadn’t yet received hard-copy documentary evidence from me. By this point, I’d forgotten about the minor not-really-a-change change I’d made and assumed that whatever they were on about must probably be related to my unusual name. I sent a message back to them to ask exactly what kind of evidence they needed to see. And that’s when things got weird.
I received a message back – very-definitely from a human – to say that what they needed to see what evidence of my gender change. That is, my change of gender from “not specified” to “not provided”.
Fluttershy gets it.
They went on to suggest that I could get my doctor to certify a letter verifying my gender change. Needless to say, I haven’t made an appointment to try to get my GP to sign a document that confirms that my gender is “not provided”. Instead, I’ve emailed back to ask them to read what they just asked me for again, and perhaps this time they’ll engage both brain cells and try to think about what they’re actually asking, rather than getting tied up in knots in their own bureaucratic process. Let’s see how that goes.
Programmers in our startup usually put 8 hours and go home. I keep reading stories about 80+ hour weeks. How do you make them work longer hours? Do we have to pay overtime? We gave few of them some equity, but it doesn’t seem to work.
My Answer:
I’m going to tell you a secret, so please listen closely.
No programmers really work 60-80 hours a week, especially in a 5 day span. That is a 12-16 hour day, 5 days a week.
I promise you that any company that has programmers “working” that many hours is really only getting 2-4 hours of real work out of them each day. The rest of the time will be filled with pointless meetings, a fair amount of web browsing, and then a whole lot of looking busy…
This is the second in a series of four blog posts which ought to have been published during January 2013, but ran late because I didn’t want to publish any of them before the first one.
I spent the weekend of my birthday working in London, alongside the Squiz team, who make the CMS that forms the foundation of most of the public-facing websites of the Bodleian Libraries. We’d originally scheduled this visit for a different week, but – in that way that projects sometimes do – the project got juggled about a bit and so I found myself spending the week of my birthday away from home.
The team at Squiz’s London office, debriefing over drinks at the end of a crazy week.
But on Tuesday – my second day working on-site at Squiz’s office, and coincidentally my birthday – disaster struck! Our first clue was when the lights went out. And then, a minute or so later, when the fire alarm started going off. No big deal, we all thought, as we gathered our possessions and prepared to leave the office – it’s probably just that the fire alarm sounds as a precaution if it’s electricity supply is disrupted… but as we started to go down the stairs and smelled the smoke, we realised that there really was a fire.
My tweet, from outside the Squiz offices.
The first two fire engines arrived within minutes. Apparently, they don’t mess about when a city centre office block catches light. The smoke was very visible from the street: thick grey plumes pouring out from the basement windows. Theories about the cause of the fire were whispered around the assembled crowd, and the consensus seemed to be that the substation in the basement had overheated and set alight its room.
People were still filing out of the building when the first of the fire engines arrived.
A third fire engine arrived, and – after about a quarter hour of assessing the situation and controlling the crowd – we were told that we wouldn’t be able to get back into our building for “at least an hour, probably more.” So, being British, we therefore decamped to one of the nearby bars for networking and a round of gin & tonic. After I texted some friends to say that I hadn’t expected to spend the afternoon of my birthday in the pub, but that it wasn’t an entirely unwelcome experience, a few of them had the cheek to ask once again how the fire had actually started.
Before long, the fire brigade had established a cordon some distance back from the fire, and were pouring water into the basement.
By the time we were allowed to return to the building, it was already getting dark, and we quickly discovered a new problem that faced us: with the power still well and truly out, the electronic door locks that secured the offices had become completely unusable. Not willing to abandon my laptop, keys, and other personal possessions overnight in an unfamiliar office, I waited around until a locksmith had been summoned and had drilled his way through the cylinder and allowed us into the building.
Without power, it turns out that these things can be pretty useless. At least they “fail secure”, keeping the door locked (from the outside) in the event of a problem, rather than the alternative…
It being my birthday, I’d arranged that Ruth would come and spend the night down in London, and that we’d go out to Dans le Noir, a restaurant that I’d heard about from news articles and via friends some years prior, and always wanted to try. The restaurant has a distinct and quite remarkable theme that you probably won’t find anywhere else: that theme is that you eat unidentified food in pitch blackness.
Don’t be fooled: this picture of the tip of a candle wasn’t taken at Dans le Noir, but at Squiz.
As our (blind!) waiter, Gao, led Ruth and I by touch to our table, we suddenly realised that we’d all but forgotten exactly how dark pitch blackness actually is. When you stumble over your coffee table in the dark on a morning, that’s not truly black: there’s that sliver of light coming from underneath the curtains, or the faint glow of the LED light on the stereo. Real, complete darkness is disorienting and confusing, and to sit around in it – not even able to see whether your eyes are open or closed – for hours at a time is quite remarkable.
Now this is more like what it looks like at Dans le Noir!
It took us a little while to learn the new skills required to survive in this environment, but Gao was incredibly helpful. We worked out mechanisms for pouring drinks, for checking whether our plates were empty, and for communicating our relative movements (being geeks, as we are, Ruth and I quickly developed a three-dimensional coordinate-based system for navigating relative to an agreed centre-point: the tip of the bottle of our mystery wine). We also learned that there’s something truly humbling about being dependent upon the aid of a blind person to do something that you’d normally be quite capable of doing alone: simple things, like finding where your glass is.
My tweets after coming out of Ruth and I’s remarkable experience of Dans le Noir.
But the bigger lesson that we learned was about how darkness changes the way that we operate on a social level. Ruth and I were sat alongside another couple, and – deprived of body language, the judgement of sight, and the scrutiny of eye contact – we quickly entered into a conversation that was far deeper and more real than I would have anticipated having with total strangers. It was particularly strange to see Ruth, who’s usually so shy around new people, really come out as confident and open. I theorise that (in normally-signted people) eye contact – that is, being able to see that others can see you – serves as a regulator of our willingness to be transparent. Depriving it for long enough that its lack begins to feel natural makes us more frank and honest. Strange.
Live updates, primarily for the benefit of the people back at my usual workplace, on progress at Squiz.
Back at Squiz the following day, there was still no electricity. Credit is due to the team there, though, who quickly put in to effect their emergency plans and literally “moved office” to a handful of conference rooms and meeting spaces around Shoreditch. “Runners” were nominated to help relay messages and equipment between disparate groups of people, and virtualised networks were established across the city. I laughed when I discovered that Squiz’s old offices had been in an old fire station.
Team members at Squiz, in their unlit, unheated office, begin to put their emergency plan into place, picking up computers and transporting them to alternative venues.
Before long, the folks I’d been working with and I were settled into a basement meeting room in a nearby café, running a stack of Mac desktops and laptops from a monumental string of power strips, and juggling an Internet connection between the café’s WiFi and a stack of Mifi-like devices. We were able to get on with our work, and the day was saved, all thanks to some smart emergency planning. Later in the week, a generator was deployed outside the building and we were able to return to normal desks, but the quick-thinking of the management ensured that a minimum of disruption was caused in the meantime.
My tweet about seeing comedy with Bryn and about returning to the office (now powered by a huge generator).
Not one to waste the opportunity to make the most of being in London for a week, I spent another of my evenings out with Bryn. He and I went out to the Free Fringe Fundraiser, which – despite a notable absence of Peter Buckley Hill, who had caught a case of the then-dominating norovirus – was still a great deal of fun. It was particularly pleasing to get to see Norman Lovett in the flesh: his particular brand of surrealist anti-humour tickles me mercilessly.
So what could have been “just another business trip” turned into quite the adventure, between fires and birthdays and eating-in-the-dark and comedy. If only it hadn’t taken me two months to finish writing about it…
A strange package appeared outside of the door to my office, some time this morning, wrapped as a gift and accompanied by a card.
A card, bottle of wine, and box of chocolates!
It turns out to have been my colleagues at the Bodleian Shop, whose newly-relaunched e-commerce site I was drafted into at the last minute to iron out a few technical hitches in time for them to start making online sales before the Christmas rush. There were a few somewhat-stressful moments as technical folk from disparate providers worked together to link-up all of the parts of the site (warehouse and stock level systems, order and payment processing, content management, and of course the web front end), but it all came together in the end… and I think a lot of lessons were learned from the experience.
My bottle of wine, chilling amidst the anti-bird-wire on the window ledge of the building.
So that was a very sweet surprise. I knew that they’d appreciated my “hopping department” in order to firefight the various problems that came up during their deployment, but it was still really awesome to get an alcoholic, chocolatey thank-you and a cute card signed by their team, to boot.
From an elevated position in the exhibition room, I run a few tests of the technical infrastructure whilst other staff set up, below.
In particular, something I’ve been working on are the QR codes. This experiment – very progressive for a sometimes old-fashioned establishment like the Bodleian – involves small two-dimensional barcodes being placed with the exhibits. The barcodes are embedded with web addresses for each exhibit’s page on the exhibition website. Visitors who scan them – using a tablet computer, smartphone, or whatever – are directed to a web page where they can learn more about the item in front of them and can there discuss it with other visitors or can “vote” on it: another exciting new feature in this exhibition is that we’re trying quite hard to engage academics and the public in debate about the nature of “treasures”: what is a treasure?
A QR code in place at the Treasures of the Bodleian exhibition.
In order to improve the perceived “connection” between the QR code and the objects, to try to encourage visitors to scan the codes despite perhaps having little or no instruction, we opted to embed images in the QR codes relating to the objects they related to. By cranking up the error-correction level of a QR code, it’s possible to “damage” them quite significantly and still have them scan perfectly well.
One of my "damaged" QR codes. This one corresponds to The Laxton Map, a 17th Century map of common farming land near Newark on Trent.
We hope that the visual association between each artefact and its QR code will help to make it clear that the code is related to the item (and isn’t, for example, some kind of asset tag for the display case or something). We’re going to be monitoring usage of the codes, so hopefully we’ll get some meaningful results that could be valuable for future exhibitions: or for other libraries and museums.
Rolling Your Own
If you’re interested in making your own QR codes with artistic embellishment (and I’m sure a graphic designer could do a far better job than I did!), here’s my approach:
I used Google Infographics (part of Chart Tools) to produce my QR codes. It’s fast, free, simple, and – crucially – allows control over the level of error correction used in the resulting code. Here’s a sample URL to generate the QR code above:
500×500 is the size of the QR code. I was ultimately producing 5cm codes because our experiments showed that this was about the right size for our exhibition cabinets, the distance from which people would be scanning them, etc. For laziness, then, I produced codes 500 pixels square at a resolution of 100 pixels per centimetre.
H specifies that we want to have an error-correction level of 30%, the maximum possible. In theory, at least, this allows us to do the maximum amount of “damage” to our QR code, by manipulating it, and still have it work; you could try lower levels if you wanted, and possibly get less-complex-looking codes.
0 is the width of the border around the QR code. I didn’t want a border (as I was going to manipulate the code in Photoshop anyway), so I use a width of 0.
The URL – HTTP://TREASURES.BODLEIAN.OX.AC.UK/T7 – is presented entirely in capitals. This is because capital letters use fewer bits when encoded as QR codes. “http” and domain names are case-insensitive anyway, and we selected our QR code path names to be in capitals. We also shortened the URL as far as possible: owing to some complicated technical and political limitations, we weren’t able to lean on URL-shortening services like bit.ly, so we had to roll our own. In hindsight, it’d have been nice to have set up the subdomain “t.bodleian.ox.ac.uk”, but this wasn’t possible within the time available. Remember: the shorter the web address, the simpler the code, and simpler codes are easier and faster to read.
Our short URLs redirect to the actual web pages of each exhibit, along with an identifying token that gets picked up by Google Analytics to track how widely the QR codes are being used (and which ones are most-popular amongst visitors).
By now, you'll have a QR code that looks a little like this.
Load that code up in Photoshop, along with the image you’d like to superimpose into it. Many of the images I’ve had to work with are disturbingly “square”, so I’ve simply taken them, given them a white or black border (depending on whether they’re dark or light-coloured). With others, though, I’ve been able to cut around some of the more-attractive parts of the image in order to produce something with a nicer shape to it. In any case, put your image in as a layer on top of your QR code.
Move the image around until you have something that’s aesthetically-appealing. With most of my square images, I’ve just plonked them in the middle and resized them to cover a whole number of “squares” of the QR code. With the unusually-shaped ones, I’ve positioned them such that they fit in with the pattern of the QR code, somewhat, then I’ve inserted another layer in-between the two and used it to “white out” the QR codes squares that intersect with my image, giving a jagged, “cut out” feel.
Test! Scan the QR code from your screen, and again later from paper, to make sure that it’s intact and functional. If it’s not, adjust your overlay so that it covers less of the QR code. Test in a variety of devices. In theory, it should be possible to calculate how much damage you can cause to a QR code before it stops working (and where it’s safe to cause the damage), but in practice it’s faster to use trial-and-error. After a while, you get a knack for it, and you almost feel as though you can see where you need to put the images so that they just-barely don’t break the codes. Good luck!
Another of my "damaged" QR codes. I'm reasonably pleased with this one.
Give it a go! Make some QR codes that represent your content (web addresses, text, vCards, or whatever) and embed your own images into them to make them stand out with a style of their own.
Is this a chronogoldfish? I don't know. And neither do you. I just made them up.
You see: the thing that goldfish are famous for – except for their allegedly very short memory, which is actually a myth – is that they grow to fill the available space. That is: if you keep a goldfish in a smaller tank, it’ll grow to a full-size that is smaller than if you kept it in a larger tank or even a pond. I’m not certain that’s actually true either, and I’m sure that Kit will correct me pretty soon if it’s not, but it’s part of my analogy and I’m sticking with it.
A chronogoldfish, then, is somebody who grows to fill the available time. That is: the more free time you give them, the more they’ll work at filling it up. This is a mixed blessing, which is a euphemism for “usually pretty bad.” You’ll almost never catch me bored, for example – I’ve no idea how I’d find time to be bored! – but conversely it’s reasonably rare to find me with free time in which I don’t have something scheduled (or, at least: in which I don’t have something I ought to be doing).
Earlier this year, I started working for the Bodleian, and this – along with a couple of other changes going on in my life, suddenly thrust upon me several hours extra in each week than I’d had previously. It was like being transplanted from a tank… into a pond and – once I’d stopped checking for herons – I found myself sitting around, wondering what to do with my sudden surge of extra free time. But then, because I’m a chronogoldfish, I grew.
The activities that I already did became bigger – I took on more responsibilities in my voluntary work, took more opportunities to socialise with people I spend time with, and expanded my efforts to develop a variety of “side project” software projects. I’ve even lined myself up for a return to (part-time) education, later this year (more on that in another blog post, little doubt). And so, only a few months later, I’m a big, fat chronogoldfish, and I’ve once again got just about as little “free” time – unplanned time – as I had before.
But that’s not a bad thing. As Seth Godin says, wasting time (properly) is a good thing. And there’s little doubt that my growth into “new” timesinks is productive (education, voluntary work), experimental (side-projects, education), and joyful (socialising, everything else). I’d like to think I use time well, even if I do sometimes wonder: where did it all go?
I suppose the opposite of a chronogoldfish might be a chronomidget: somebody who doesn’t grow to consume any more time than they have to. The test, I suppose, would be to ask yourself: what would you do if there was an extra half-hour in the day? If your brain immediately rushes to fill that space with an answer (a genuine answer: something you’d actually do – there’s no point lying to yourself and saying you’d spend it at the gym if you wouldn’t!), you’re probably a goldfish. If not, you’re probably a midget.
I think I can name people among my friends who are goldfish, and people who are midgets. But I do wonder what type they would say that they are…
![You have [20] work days left to ask Dan that awkward question.](https://danq.me/wp-content/uploads/2019/09/20190903_152221.jpg)
