Russell Davies has taken his considerable experience of convincing people of things using slides, and distilled it into a very informative, visually interesting and funny 262 pages. He’s even made the book in the aspect ratio of 4:3, which is the first indication of the level of attention to detail which continues throughout. Russell is a friend and we share the same birthday so this is a biased review of his book from a pal and fellow piscean ♓️

The book is split into three parts - The story of how Russell came to be a PowerPoint whizz, the invention of PowerPoint & how it came to be ubiquitous, and finally a section on how to be good at PowerPoint.

Part One: PowerPoint Saved My Life

The book opens with a demonstration of Russell’s qualification to write this book, but as he says himself, it is short and full of jokes. He included some great general advice in this bit which I highlighted:

First, almost everyone can be a great presenter. You just need to talk about something you care or know about, and you need to do it to a supportive audience.

Put as much of yourself into your presentation as you can. That’s what connects. That’s why people watch. Otherwise they might as well just read your notes.

Now, you may be thinking ‘I don’t think it’s appropriate to put myself into this presentation on our OKR progress for Q3’. Well you’re wrong my love. Of course, the presentation should contain the facts you want me to understand, but I’m only going to understand them if I am paying attention, and I’m more likely to pay attention if you’re being interesting, and you can be interesting by just being you.

Russell also makes a connection between people who don’t like PowerPoint (civil servants, politicians, journalists, academics) and their strengths (giving speeches and arguing in long form writing). I think this is particularly interesting because I, uh, work with a lot of journalists…

They didn’t understand why people couldn’t just deliver a speech instead, or just write an elegantly crafted paper or article

In this part he argues that PowerPoint is a democratising tool for communication. Cool!

This section also touches upon the understated genius of PowerPoint’s inventor, Robert Gaskin:

Gaskins seems to be cut from a very different cloth [than Steve Jobs and Jeff Bezos]. He invented something pretty important. And he’s pretty proud of it. But he seems to be just as proud of the creation of http://www.concertina.com (a reference collection of documents for the study of English, Anglo and Duet concertinas)

Great software created by a nice guy!

PART TWO: PowerPoint Rules The World

This section covers how PowerPoint got to be so ubiquitous. It has a review of the different ‘types’ of PowerPoint that was really fascinating. The creative power that PowerPoint gives its users means it’s possible to get into all kinds of different aesthetic hijinks.

A slide from an NSA deck leaked by Edward Snowden. The slide shows how US security services had infiltrated big tech networks. At the infiltration point there is an arrow with the label ‘SSL added and removed here! :-)’

This is a slide used by the prosecution in a jury trial. The jury declared a guilty verdict that was later overturned because the slide was found to be ‘a calculated device employed by the prosecutor to manipulate the jury’s reasoned deliberation and impair their fact-finding function’.

It also includes a closer look at what Robert Gaskin did when he invented PowerPoint. Did you know that the technical team that built it was 46% women? Because Robert consciously tried to hire people from non-typical backgrounds. He did this in 1987, when the average make-up of software engineering teams at other companies was 10% women. Fuck yeah Robert Gaskin!

PART THREE: PowerPoint is Easy

The final section gives a series of techniques to make your presentations short and effective.

I’ve tried to pull out some good bits here but it’s all good?

On the power of dividing presentations into three parts:

You’ll find that many presentations are boring because they’re just divided into two: Problem and Solution. To maintain some interest you need three bits, crisis, struggle, resolution. Three little pigs is drama. Two little pigs is an anecdote.

There is heaps of advice on writing clearly so people understand you, and you understand yourself. When I’m not sure about something I tend to try and hide it behind more complicated words, but when I force myself to explain something in plain non-jargon language, that’s when I realise I don’t fully understand the idea and I have to go away and do some reading.

As you would expect from a writer, Russell also has great advice about making your words interesting. Just because they are clear doesn’t mean you can’t be fun with alliteration, beefy verbs, rhymes etc.

And the final part of this book is about presenting. What’s cool about this section is that it isn’t just a variation on ‘relax and don’t say “um”’ but actionable tips.

For example, he gives three ways to have a good ending:

• Finish earlier than expected.
• Sum up with a fast paced video of all the slides you’ve already shown. If you’ve designed your slides following earlier advice, showing them quickly along with some jaunty music will remind the audience all the ground you’ve covered
• Get your audience to clap. This is something Russell was fanatical about at GDS. We would clap everyone on and off. I loved it. As a presenter it made me feel welcomed, and as an audience member I felt like I was helping the presenter feel recognised and appreciated. If people clap it makes them think they enjoyed something. It’s really easy to trick people into clapping too, just start yourself.

I did this because I needed to explain a bit about it at our big team meeting (the one with product managers, delivery managers, people outside of Customer Products etc etc), but when I simply drew the diagrams and photographed them there was too much information to show on one slide and get people to look at.

It made me realise that much of the value in drawing a diagram is the actual act of drawing it. So instead of popping the finished sketch on a slide I tried to capture the act of drawing it instead.

Here is an example:

What is this format good for?

In Giles Turnbull’s Agile comms handbook he talks about the three layers of comms, and these videos are in the context layer.

These are scrappy, and that’s good

Anybody with a deep familiarity with the system is going to find a bunch of problems with these diagrams. They don’t contain all the detail; I’ve missed off everything to do with authentication, caching, logging, and some other content APIs.

Those diagrams also exist but they are the detail layer, not the context layer, where we give people “just enough” information to see if they want to know more or if they have what they need and can go on with their life.

These are hard to edit, and that’s good

Another feature of these diagrams is that they are hard to edit. This is really handy, provided they are “correct enough” at the time, anybody who comes to them later will consider them an artefact of a moment in time, rather than an ongoing living document.

We have a lot of “living documents” at the FT, detailed Miros, or Lucids, or UMLs, which are out of date and nobody knows if they are allowed to update them, or how out of date they are. This kind of impossible to edit sketch is very appealing. The format is aligned with the intent of the content. “Here is a sketch, don’t take it too seriously, if you find it in 2 years stuff might have changed”.

Hold tight for the science bit

If you’ve read this far and think you’d like to give this a go - here are some details on how I did it. I have a tripod, and I used my iPhone’s to capture me drawing and then fiddled with the speed in iMovie. It did take me a couple of goes to draw the diagrams in a way I was happy with.

Then I used iMovie to narrate over the top of the captured video. I also found it helpful to add in a title card, mainly so I could see in the movie thumbnail what the video was going to be of. I hardly ever use iMovie, which is free with my Mac, and doing this was pretty easy.

When I tested playing a video and audio in Google Meet I got an echo on the audio so for any actual meetings in which these are presented I’ve disabled the audio function.

These videos take a lot of inspiration from Vi Hart’s maths explainers from… oh god eleven years ago. I met Vi once at a conference and I asked her to say “snake snake snake” and she did it, which was very cool of her and very goofy of me to ask.

I posted this review on my (internal) work blog, with the intention of putting it here too. So here it is, too, modified a bit for a wider audience.

I’ve read a couple of books lately that I’ve really wanted to share with people so I thought I’d chat about them here.

Anyway, onto The Agile Comms Handbook. This book is great, really. Very easy to read, no bits where I was like “OK pal, we get it” which is because I think Giles, the author, has focussed on editing down his words the the minimum he needs to communicate the thing.

It has some powerful ideas I think we (at the FT) should really seriously listen to:

Three layers of comms

An early idea that Giles introduces is the three layer cake of comms.

On the top is the “lure” - this is a tweet length summation of what’s going on. It invites people to read more, but allows them to determine if they’re actually going to find the “reading more bit” interesting or useful. It should grab people’s attention because people are busy!

Next on the cake is the “context” layer. This might be a blog post, or the body of an email. It tells people enough, but not so much that they don’t have time to read it all.

The final layer is the “detail”. This is the work we’re already doing. It’s tables, architecture diagrams, decision docs. This is what many of us think of as the actual work but we can’t expect stakeholders to dive into all that work, because it’s too detailed and they don’t have the time.

Any time you want to “do a comms” it can follow this format. eg - there is a technical incident that we need to email senior stakeholders about. The lure is the email subject. The context is the body of the email. It includes some digestible info about the incident and most importantly any actions the recipients need to take. The detail is linked to from the email or in an attachment.

In places we already work like this but I found the way Giles laid this all out very helpful.

Organisational presentation decks fall into two categories. The kind for presenting in front of and the kind for sharing

We (in product and tech at the FT) are so bad at confusing these. The presenting kind of deck is for standing in front of (or presenting over video). These should be low on deep detail, and act as a support for the words you’re saying. Our monthly all team update should be like this!

The other kind is also a valid form of deck, but it’s the one people read in their own time, it should stand alone as a document or record of a thing. It doesn’t work as a presentation because there’s too much detail, too many bullet points, tables of data. If you tried to present this deck you would lose the audience from what you’re saying in the details.

Giles reckons you if your slides of type 1 are going to be shared after the fact then they should be either rewritten to include all the nuanced things you’ve said alongside them, or should actually just be a blog post.

Blogging is good and easy

This is an idea I’m going to take directly to the current projects I’m overseeing at the FT. Listen folks, blogging isn’t a big deal. Be cool. Confluence has a nice workspace thing, which makes it really easy, and I want the team to share ideas early and often, adhering to the previously explained “lure”, “context”, “detail” cake of comms.

I really hope this way of working will save us the pain of that thing where detail and context is spread across a plethora of google docs that nobody can find.

I also hope this way of working will allow us to share pictures of Kevin Mcloud. This has already happened.

OK, thatssit. This book is good, and short! Really! Who wants to borrow?

Just to say that I’ve twiddled some dials and updated my local version of ruby so that the weaknotes crowd and the sewing crowd can subscribe to their own RSS feeds and not be bothered by one another.

There’s also a category called “kitchen-drawer” which is where all the bits and bobs go - the blog posts about computers, tampon club, flickr, dead batteries, an odd sock, the key which you’ve forgotten what it’s for but it’s probably important etc etc.

There’s even a yearnotes RSS if you really only want an annual dose of my writing (not sure who those people are in reality but I like the idea of being in that category for someone)

The feed you’re reading this on is the everything feed, so if you are happy with what is currently happening then take no action!

Those feeds again:

• Everything
• Weaknotes
• Yearnotes
• Sewing
• Kitchen drawer

On Monday 18th March we launched the alpha of our new career competencies framework for engineers at the Financial Times. In this blog post I’ll talk about what we did, what we learnt, and what we’re going to do next.

Our career map for engineers needed an update

In late 2017 we started looking at our career map for engineers. At that time the career map was a spreadsheet with a list of skills against some levels. Because of how Google Sheets works, there were several different versions of these sheets. The one any given engineer was looking at depended on who they had asked when they were looking for them. Initially there was a single source of truth, but over time things got a little scattered and confused.

By 2017 the career maps were in need of an overhaul; they referred to roles that had been phased out and there were at least six competing versions, not including all of the copies individuals had made to track their own progression.

Our conversations with engineers also revealed that some of the competencies in the matrix were quite vague. When it came to working out how well an engineer was meeting a specific competency it was quite open to interpretation.

What are career maps for?

There are three reasons career maps are useful.

One is to help engineers understand what is expected of them at each level, and to be able to track their progress against this map. They may want to add personal notes as they do things that demonstrate a competency. The map for them is a living document.

The second use case is for the promotions board. They need to be able to look at a career map and understand how well an engineer is meeting the competencies at the level they want to be promoted into. Where are their strengths and where do they need further support or opportunities to grow?

The final reason for a career map is as a recruitment tool. The abundance of engineering jobs in London mean great engineers can pick and choose between many excellent roles. Sharing our career maps can be very helpful for anyone trying to work out if the FT is for them.

These three use cases don’t coalesce into a single appropriate format. For hiring, we want a format optimised for reading. For engineers, we want something editable. For promotions we want something easy to review and compare.

Revolution not evolution

Having talked about all this stuff, we ended up doing three things:

Rewriting all of our competencies and role definitions Creating a new place for them to live, and some tooling to manage them Creating a plan for roll out This work happened over three away days, and with a lot of work in-between.

We rewrote all of our competencies and role definitions The first thing we did was to rewrite all of the competencies. This was by far the least fun part of the work, but also the most important. There is no point in having a beautiful, scalable single source of truth for these if the underlying competencies were bad.

We looked at what some other companies were doing; Monzo and Rent The Runway both have public frameworks. I had also done this exercise at the Government Digital Service so we had a look at theirs too.

We divided the competencies into four areas:

• Technical — The level of mastery someone has over the technologies they’re working with.
• Communication — How effectively does this person work with others and communicate with them?
• Delivery — How good is this person at delivering the right things and working as part of a team to deliver shared team goals?
• Leadership — How good is this person at positively influencing those around them?

We felt that although the weight of these areas would change from a Junior to a Senior, there are still nascent leadership qualities in a Junior engineer that we wanted to highlight and nurture.

Once we had those sorted we did a post-it exercise where we wrote down competencies, stuck them up and discussed them. This process was very illuminating and we had many difficult discussions about what we expect of our engineers.

For example, we had quite a long debate about whether it was important for a mid level engineer to be able to demonstrate that they could set up a continuous integration pipeline from scratch.

The two sides of the argument were that: continuous integration is an important aspect of our services and people should know how it works properly

On the other hand, setting it up from scratch is something that happens once in a project, and so is it realistic to require all mid level developers to have done it?

In the end we decided that the key thing for mid level engineers to be able to do was be able to use continuous integration pipelines, and be adaptable enough to learn new things (like setting one up from scratch) if they needed to do so.

We tried to phrase the competencies so that the requirement for evidence would be inherently met. So for example, instead of saying “Understands how to write tests” we said “Writes tests”. If you meet this competency then there will be some tests you’ve written to prove that.

It wasn’t possible to do this for all of the competencies. For example there is a competency in the leadership category that is “Acts with integrity, honesty and accountability”. These are the Financial Times’s core values, however evidence for this will probably be through testimony from colleagues, which is valuable, but subjective.

By the end of this process we had about eighty competencies across three seniority levels. The competencies were considered as a threshold for getting promoted into that level, so Junior to Mid, Mid to Senior One, Senior One to Senior Two.

We left off any competencies for being hired as a Junior Engineer because it’s the entry level position so we’re looking more at potential than a list of expectations. We also left off Senior Two to Principal. The Principal role at the FT is a “by appointment only” role, not something you can be promoted into by the promotions board. I think we should revisit both of these in due course.

Our competencies live on GitHub now

Once we had a first pass of competencies, we started thinking about where they would live and in what format. We knew that we wanted a proper canonical source for them, and we wanted it to be a place where individual competencies could be discussed and changes could be tracked.

We decided the competencies should live on GitHub and be stored as YAML. This meant we could serve the competencies as an API, and then build things to meet the needs I outlined above. A Google Sheets integration for individual tracking and note making, a website for more leisurely reading and public recruitment, something more structured for the promotions board.

GitHub is the perfect place for these engineering competencies to live as there are some built in tools that we can use to manage them:

• GitHub Issues — which will allow us to openly discuss areas where these competencies need improvement
• GitHub Pull Requests — which will allow us to make changes to the competencies
• Git tags and releases to version changes so that anyone working with an older version of the competencies can see if they need to update
• Various markdown documents as guidelines for contributing
• A Jekyll instance that will run a live site, which exposes these competencies as a JSON API so people can build their own integrations

We’re going to roll this out between now and October At the moment these competencies are in Alpha. We created them as a group of five engineers, but there are 231 people that report into the CTO at the Financial Times and this needs to work for most of them.

There is great variety in the things that an engineer at the FT might be working on. We have engineers working in Node.js, Java and Python, engineers working on infrastructure, engineers who work on greenfield projects, and those that work on much supporting and improving much older codebases.

We are also spread across three locales, London, Manila and Sofia. This framework was only developed by people in London.

So, to get to Beta, we’re going to run the competencies past a lot of people. We’ll ask them:

For your seniority, do these represent what you do?

• Is it easy to provide evidence for them?
• Are any of them too vague or too high level?
• Do any of them not apply to your role?
• We want to make sure we cover enough surface area and that the people we ask give it some proper thought, so we’ll be holding a series of hour long workshops with different groups. Of course, anybody that would like to raise issues in GitHub is also welcome to pitch in there.

Our date for launching the Beta is June. This gives us ample time to get feedback from the engineers across the FT. We will use the Beta for our September promotions board. This will be another big test for the framework. When people have to use it in anger, how will they feel about it? What will the big-wigs on the promotions board make of it?

After we have incorporated any changes from the September promotions board, we’ll launch V1.

Thanks to everyone that’s helped with this work so far. My working group pals: Mark Barnes, Rowan Manning, Laura Carvajal, Rhys Evans and Tom Kennedy. Also Jason Mackie, Lily Madar, Rob Godfrey, Tuf Gavaz, Sarah Wells, John Kundert, Karolina Gardocka, and David Edge.

If you’d like to see the Alpha, it’s on GitHub here: https://github.com/financial-times/engineering-progression

Or the website is here: https://engineering-progression.ft.com

I’ll be back with another update after we’ve launched the Beta in June.

I’m pleased that’s not going to happen but since I’ve stopped using it, I’m not going to start again.

I had a look back through all my favourites and all the photos I’m tagged in. Nearly all of the ones not taken by me are from 2011-2013 when I was at BERG. Here are some of my faves.

Baby me at Interesting 2008

I am 21 in this photo! I recall Interesting 2008 being really exciting. I made a last-minute decision to go with Roo as he had a spare ticket. I was supposed to be moving house that weekend but decided to leave it until until Sunday. Anna Pickard said the word “plinth” on stage while nearly crying with laughter and then, after, I met her and she told me she always wears special shoes on stage. An event I clearly thought was important enough to remember. And look! James Bridle is in the background. I didn’t actually meet him properly until June 2010. I know the date because there is another photo on Flickr from the last.fm bbq that I met him at. (Original)

Lots of drinking outside pubs

I think maybe 50% of these photos are taken by Timo and are of BERG and BERG-adjacent people drinking outside pubs. (Original) (Original)

Doing crosswords at BERG

Alex D-S left a Guardian cryptic crossword out at the Brig and from then on we used to do them at lunchtime. Timo really hates cryptic crosswords. (Originals are here)

Alice counting screws (quite loudly)

I remember this really clearly. God that office was grim. I was doing inventory for screws for Little Printer right next to Phil. Poor Phil. (Original by Phil here)

In Newcastle when Me and Mark Hurrell wore matching outfits

Finally we’ve made it past 2013. This photo was taken by Ben Terrett. Original with Ben’s dad’s comments is here. This was taken when I was at GDS. We were on a trip to Newcastle to hire for an HMRC centre up there. We did two days of Civil Service interviews in hotel rooms with the beds removed. My main memories were feeling a bit sweaty. I sewed that top myself.

In February the Department for Business said that the uptake of SPL could be as low as 2% of the 285,000 couples that are eligible for it each year. I think SPL is amazing so I thought I’d write down what we did and why it was good.

In this blog post I’m going to talk about what my husband and I did. I’m an a heterosexual relationship but the policy I’m talking about is available to same sex (or queer!) couples and couples adopting. In these cases there is a “Primary” and a “Secondary” parent.

Before SPL, things were bad

Before Shared Parental Leave, I would have been entitled to a full year off work (paid at whatever my employer’s leave policy is plus statutory). My husband would have been entitled to 2 weeks off work.

This situation is a bit shit for everyone. Dads (or secondaries!) get less time with their babies. Mums (or primaries!) get less support from their partners. Women have to take a disproportionate career hit. Even in families where the dads want to pitch in equally, they’re not able to because they have to be back at work.

With Shared Parental Leave you share your parental leave

I AM NOT A HUMAN RESOURCES PROFESSIONAL so here is the explanation from https://sharedparentalleave.campaign.gov.uk/

Parents can share up to 50 weeks of leave and up to 37 weeks of pay and choose to take the leave and pay in a more flexible way (each parent can take up to 3 blocks of leave, more if their employer allows, interspersed with periods of work).

Eligible parents can be off work together for up to 6 months or alternatively stagger their leave and pay so that one of them is always at home with their baby in the first year.

One thing I found confusing to begin with was understanding the pay for shared parental leave. This is because initially I thought pay was moveable (eg I get 19 weeks full pay which I can take at any time). But actually all parental pay works by providing a rate for a specific week calculated from the when the first leave is taken.

So if I’m off during week 13, I’ll get the week 13 rate (which in my case because of the FT’s enhanced maternity policy, is full pay). If I’m off during week 20 I’ll get statutory pay (£145.18). It doesn’t matter if week 20 is my first week off, the pay for week 20 is the statutory allowance as my employer’s enhanced pay policy ends on week 19.

My parental pay is calculated based on my employer’s policy, and my partner’s parental pay rate is calculated based on his employers policy.

First we took four weeks off together

OK, enough with the poorly described legislation. What did my partner and I actually do.

My partner’s employer (Microsoft) gives six week’s paid paternity leave in the UK, and he could take it in up two chunks. The Financial Times’s policy is the same for everybody (mothers, fathers, primaries, secondaries, etc). We all get 19 weeks leave fully paid.

First, we took four weeks off together. I have no idea what we did during this time - it’s a total blur. I dimly recall lots of sleeping in? And some stumbling around? And cuddles.

Then my husband went back to work, and for seven and a half months I was the primary parent. I also took sole responsibility for all the cooking which allowed my partner to focus on work.

Being the primary parent is hard!

Some people don’t like the phrase “primary” parent. “It minimises the other parent’s role!”. Yes it does. But look. Having been both the primary and the secondary - the primary is different and a lot harder! At all times I had to be considering the needs of quite a needy small person. She can’t tell me if she’s hungry or tired or needs a nappy change. I have to remember if she’s poorly, if she’s currently refusing broccoli, what her favourite toys are, when she last pooed. Every day has to be, at a minimum, planned so that she’ll get some baby safe food and some time for naps. Sometimes it takes her an hour to eat a whole meal.

The secondary parent is still important. In the evenings being able to hand over responsibility, even just for the half hour before bed, was lovely. After a day of singing and chasing and tickling and playing and cleaning and feeding, I could have some quiet time to cook dinner. I didn’t especially like cooking until it came at the end of a day’s free play with a baby. Being able to follow a set of instructions uninterrupted and at the end have some delicious food became a real treat.

Switching roles

Despite being a fairly equitable pair, while I was on leave, I was the the person who was leading decisions about our daughter. Even when my partner was there too, I was in charge. This was because I knew what she needed because I was pretty much always with her.

When we switched I realised how much I had become accustomed to looking after a baby. How rolling with the unpredictability of a child had become how I went about the day. Seeing my partner get to grips with this challenge made me realise what a shift it is.

Going back to work at nine months was pretty easy, especially as I knew our daughter was with her dad. We chose a nine/three split because I wanted my partner to have a good chunk of time to get into being the primary. It took him a while to settle into the role so I’m glad we picked three months.

I chose to express milk at work for three months when I went back. This was an awful experience to be honest. I’m somewhat on the fence about if I would recommend doing that to anyone else.

Tips for anyone wanting to take SPL

• Engage your HR rep. My contact in the FT’s HR team described SPL as the most complicated piece of legislation they have to deal with. There are a huge number of ways to take SPL so talking through them with an expert is a really good idea.
• Try and have it so you both have some solo time. I gained so much empathy for what it was like being the secondary parent when I had to do it, and I know my husband learnt heaps from being the primary. Our daughter also got a lot from having a different parent running the show.
• Get yourself a spreadsheet. Organising maternity leave, paternity leave, shared parental leave, the annual leave you will still accrue while being on leave, all across multiple financial years is a logistical nightmare. I’m not going to share my spreadsheet because I think it probably only makes sense to me, but it was essential in working out what I was going to be paid, when I should return to work, etc.

OK - that’s it. I hope more people will take Shared Parental Leave. I must state again that I AM NOT A HUMAN RESOURCES PROFESSIONAL, but if you have any questions about what we did that I haven’t covered here, just pop me an email.

You can read the full post over here on the FT’s engineering blog.

I was looking for it the other day; the interesting technical and design bits are all over the place so I thought I’d write it up here.

Research

We shipped the first version of the date input in public beta and then iterated on it with lab based user research and by examining the logs of search queries.

The first version of this date input was pretty sketchy. It used ruby’s Date.parse function and some regex to work around a ‘feature’ whereby 11/11/90 is parsed as 2090. This worked OKish but it didn’t accept dates like “July” or “2010”.

Research uncovered a second problem too. We had some help text under the input: ‘for example 21/11/2014’. But this text didn’t really align with how people wanted to search for dates. In research users revealed that they’d prefer much fuzzier matching like “June” or “06/2010” but thought that the date input wouldn’t accept that date because of that label. When we looked at the logs, it confirmed that the majority of people were putting in dates according to the label text suggestion.

You can see the raw data over on the GDS design hackpad.

Fixing it

The first thing to do was open up the date label to imply a broader range of date formats. We went with “For example 2008 or 21/11/2014”. This isn’t perfect but an improvement.

The second thing was to write some code. This is the other thing I feel good about. Using the raw logs and some regex, we were able to construct a test suite for all the dates we would accept. Here’s the Pull request that fixes that all up.

In the end we swapped out reliance on Ruby’s Date parsing and used a gem called Chronic instead. The app now accepts any date and passes it to the Chronic gem. Chronic is great but we did have to work around the following problems:

1. Interpreted ‘2008’ to be 20:08 hrs.
2. Barfed on strings like “20 11 16” and 20.11.16
3. Barfed on strings like “20112016”. This is probably the right call for chronic, which has to be general purpose. For our use though, we were able to make some more useful assumptions with these kinds of inputs. Once the date has been parsed we return the full unambiguous date to the screen so if users get this wrong they can see.

And so

This one of the things GDS does extremely well. User research, design and code working together to create something boring but very well formed. They also publish everything with varying levels of certainty and formality on their hackpad or in their service manual.

I prefer “tech lead” but that doesn’t cover some of the other things I have to do in the role which are less about tech decisions and more about reporting upwards.

Anyway. This post isn’t about that. It’s to say that I’ve written a blog post about Origami over on the Financial Times’ tech blog. There will be some more posts in the future about what we’re doing with Origami and why, but first I needed to lay some ground-work about the Financial Times.

If you’re working on something similar, especially if you’re working in publishing, I’d love to hear from you.