Perpetual adaption: A glimpse inside our CTO’s head
My business partner Graham Tackley and I recently sat down for lunch and discussed 2018 and what we learned last year. I asked him a lot of questions about how he approaches technology, as I thought his responses would make a great blog post for people who work in news.
Graham’s approach to technology actually resembles the way a journalist looks at a story. When he sees something he wants to focus on he articulates the simplest version of the idea. Then after validating his tests he attacks it forcefully, with speed and intensity.
That process is underpinned by something bigger. This interview is my attempt to get to the bottom of what that something bigger is. Now, I couldn’t decide what to cut, so below is a nearly complete interview full of insights, paraphrased but not miles off the real thing.
Me: One of the most exciting moments of an early stage business is when the first lines of code get checked in. Ideas are fun, too, but actually putting pen to paper, as writers would call it, is really when the creativity kicks in.
As Ray Bradbury said, “You can’t try to do things. You simply must do things.”
We’ve been able to continue operating in that creative state far beyond those first lines of code for all of our projects. Even better, when you bring people into our projects you seem to onramp them into a perpetual creative state, too.
How do you do that?
Graham: The main thing is that it’s not about whether something is perfect. It’s about whether it works. There’s no single right approach to anything, so stop worrying that you have to find it. You just need a good enough answer to a question to know what to do next. That’s true for product, for architecture, and for implementation. Almost certainly, what you thought was the right approach initially turns out not to be, so you have to keep looking at whether the approach you’re taking is helping or hurting you. It’s normal to throw things away in order to keep it on track.
For other people to work this way you have to give them space to try. It’s not that you’re not managing them. You go through phases. The first thing is to demonstrate by what you’re doing that it’s ok to try.
In your working environment, you need to make it safe to try. So I always set up continuous integration and automating releases/rollback early on. You need to be able to see the impact of your work and show it to people.
Then you need to nudge people. You bounce ideas off them and talk about what you’re trying to do. Sometimes that’s writing code. Most of the time it’s just chatting. When that conversation goes well it’s not a one-way chat. It’s more of a brainstorm.
The critical thing about software is knowing when you’re digging a hole for yourself. When you have a problem you’re struggling with sometimes you just keep digging deeper and deeper.
The net effect of those conversations is to get people to jump up out of those holes and see if we can get back to a creative state. What you try and do is get to a point where your team knows the key question is noticing you’re in a hole — and then jumping out for themselves.
Me: You covered a lot of ground technically last year. What were the most interesting technologies you used?
Graham: It started with GraphQL. We had that setup at the end of 2017, so a lot of what happened in 2018 followed off the back of that.
Then in January I made our internal data explorer with React, and that proved a few things for me.
First, I knew GraphQL was going to be great for us. The combination of GraphQL and React meant it took no time to build some pretty useful tools. So, why was this important? Up until this point, we were creating REST apis to answer any question we wanted to display. Which meant that we needed a new API every time we wanted to ask a different style of question or show something different on the screen. By exposing some of the building blocks of Elasticsearch’s aggregations via GraphQL, we could ask much more interesting questions and iterate the product without constantly having to hack the API.
We initially weren’t confident about CSS so we bootstrapped it with Bootstrap. That worked well for us, but we found we were fighting it. So, we switched to using styled components with CSS in JS.
Then after that we learned some things using Google’s BigQuery and Data Studio tools to help with the News Ecosystem research we did. Those tools were really helpful for getting a sense of what the data looked like without having to build software for it.
What I really liked about BigQuery and Data Studio was giving control of the data to you so you could run whatever reports and visualisations you wanted. I’ve always preferred tooling that helps people do the stuff I can do instead of me doing it on request.
After the research report we started working on News With Friends, and that raised a lot of really interesting issues.
Me: …the biggest question being, “How do you build and deploy a native mobile app?”
Graham: Well, yeah, that, and what tools already do that for me? What’s the easiest way to make something that just works?
We started by just following the out-of-the-box examples with React Native. We got something working right away and then we had a usable app that did some of the stuff we wanted in about two weeks.
We looked at using Expo.io to jumpstart some of it, but at the time we were new to the native app development scene and we couldn’t figure out how to do some of the things we wanted to with it. So we ejected the app and started doing everything ourselves. We wasted a *lot* of time on the build toolchain! And, of course, we did come back to Expo when we wanted to deploy for Android. And Expo evolved during that period and started offering things we needed, so Expo turned out to be really helpful in the end. There’s always that risk that we’ll run up against other limitations and have to export again, but we can pay that price when we need to.
Me: What’s behind the decision to use a tool like Expo.io vs doing it yourself? I don’t mean that in a feature-by-feature kind of way. I mean, what is it about the way you look at the world that makes you think, “This is the direction I want to go.”
Graham: Some people look at what they have to learn and then worry about where they are and what work gets thrown away if they move to something else. The learning curve is never an obstacle, in my opinion, because that’s a finite problem. And I don’t care about throwing things away if it’s the right thing to do. Holding onto a technology because you’ve invested in it is just going to slow you down.
Technology changes at such a pace that there’s always going to be a better way of doing something in the future. So, it’s better to do something now fast and accept the fact that you’re going to overhaul it.
Me: Do you design the ability to update what you’re doing when you’re building something?
Graham: Sort of. In the old days what you did is you’d say I want to change this thing over here and I’ll put something in front of it that serves as its interface so I don’t have to change my old code. But that just serves to make it take longer to write the code in the first place, and you rarely can actually just swap out an implementation.
Just write the actual code now. And change it when it starts hurting you.
Me: One thing that strikes me is that you are independent of the tools you use. I mean, you don’t care what language it’s written in. You don’t care about the environment.
Graham: Well, what I actually care about is that it doesn’t force unnecessary complexity. I want the things I use to operate independently. And that’s really because I don’t want to have to remember how each separate bit works.
When I’m working on something else I want to know that any of the things it needs just do what they’re supposed to do. It’s not exactly forward-compatibility but something like that. You want the things you’re creating to be reliable for other things that are going to use them.
Me: I’ve noticed over the years how just about every industry adopts tricks that are first discovered by people who operate close to the front edge of technology’s latest advances.
In the case of Journalism, it’s going through a really interesting period where production, distribution and consumption are all kind of up in the air. They’ve all changed, and we don’t know which types of things are going to lead the news market next.
Are some of the things you’re working on relevant to the current state of things for news?
For example, we’ve found GraphQL gives us a lot of capability and makes a lot of things easy. We can ask questions in much more robust ways because of it. Does GraphQL have lessons for journalism?
Graham: Yes, absolutely. Look at the big data-driven stories like the Panama Papers and the WikiLeaks cables and the MPs Expenses. Those were one-off stories where the journalists knew what to dig for. Putting all the data into a search index and giving them a search interface was fine at the time.
What if instead of looking for a needle in the haystack you were looking for unusual objects? Maybe you don’t know what you’re looking for. Can the data just tell you what’s interesting? You’ll find the needle still, but you might get other things, too. And that’s not about computers taking over journalism, it’s about using them to scale the skill and judgement of one journalist across much much larger datasets.
Me: Explain that. Do you mean that a journalistic project should be able to do things like ping all the sources it needs to monitor constantly for new information instead of ringing them up one at a time?
Graham: Yes. And when something interesting happens you’d know it immediately.
There’s also the issue of distribution. You wonder why publishers are so overprotective about where they send their content. Tech companies are brilliant at offering the try-before-you-buy model. News should do that. Why not send some of your stories prominently branded as far and wide as possible?
Me: The argument against that is that you can’t make money from a story on Google News or whatever 3rd party distribution point.
Graham: Tech companies have gotten over that. In fact, they make it ridiculously easy to run their software in whatever environment that suits you. If I take a Docker image of something I know it will just work when I set it up.
Me: So are you saying the future of distribution is to package up stories better so they can just work wherever?
Graham: Maybe. It just seems like publishers are too fearful of distribution on platforms. You can’t give them everything, but when they have all the users it’s crazy not to build your brand there.
Me: Maybe the parallel with news is a swing of the pendulum away from volume journalism with a distribution focus toward investigative journalism that connects people with the brand.
Paul Lewis is doing that kind of thing at The Guardian. He’s getting incredible interviews with people saying incredible things and just posting them as packaged up videos on the Internet, branded as Guardian documentaries.
Graham: Yeah, and he should be building on that, tracking populism at a macro level in addition to telling one story at a time. What are the things in the world that need to be monitored that tell the story of how populism is changing? How is that information being collected and stored? Where can someone see the interesting changes in that data?
The populism story should be done at scale. The technology is all there to do that now in a way that wasn’t really ready for someone like Paul a few years ago.
Later Graham described a conversation he had with Mat Wall several years ago. Mat is a sharp developer we both worked closely with at The Guardian. At the time, all Graham cared about was writing code in Scala. The Scala programming language has a lot of benefits, but Mat believed the tool was far less important than the outcome of the project. Graham said,
“It was then that I realised I was focused too much on implementation detail. It’s what you’re trying to achieve that matters. That meant I needed to be in a constant state of adaptation. It’s too limiting to be an expert in one thing. You have to be able to learn and evolve things all the time.”
That’s when I found what I was looking for…the driving force that makes Graham successful. He’s never not learning.
It’s no surprise then that he found himself aligned with journalism. Journalists are the ultimate self-educators. They build on their knowledge with every story, and every story is a building block supporting the next level of the problem they are trying to solve.
At some point a story unfolds and becomes something bigger than itself, and I’ve seen this happen for Graham’s work, too. The most famous example was Ophan. But it’s also clear that what he learned then made it possible to build News With Friends.
He’s mastered the art of perpetual adaption.
