My first year at The Times and Sunday Times
Pretty much exactly one year ago to the day, I started my current job at The Times and Sunday Times as a newsroom developer. If unfamiliar with what that actually entails, it means I work within the newsroom on quick turnaround, content-centric features for our digital platforms.
In that time, I've participated in three hackdays, reimagined how WordPress can work, helped with the creation of an insane number of amazing projects and upped my development skills by several orders of magnitude.
In reflecting, here are some of the lessons I've learned in my first year developing for national newspaper:
This phrase is generally used to argue the important of substance over flashing bells and whistles, but from a news development perspective, it really means "You won't have anything finalised until the very last minute." While my team has worked hard to educate the rest of the newsroom that moving things around in HTML is much more difficult than in InDesign, and have pushed to finalise content earlier in the development process, it's somewhat of a difficult proposition in an industry where editors have always had the ability to modify anything up to the very last minute and ultimately need final sign-off.
Given this, my team has constructed various content management systems, ranging from Tabletop.js-based Google Docs-fed endeavours to front-ends for WordPress and Django. This allows the front-end development to be done independently from content management, though it does tend to add a degree of complexity to the final project. Luckily, we've standardised our approaches somewhat in the last couple of months and using these is a progressively more straight-forward endeavour.
2. JavaScript is your friend
Although my background is primarily server-side, I've found I do far more work in JavaScript than anything else. Between D3.js (which I wrote a book chapter about in Data Journalism: Mapping the Future), Tabletop.js and Angular, I can create an astounding array of tools that are fed from the cloud and don't need separate considerations for server-side processing — which is great, because you then don't need to worry about it falling over when that initial surge of traffic hits it. Given news interactives get a big burst of traffic when they're first published, followed by a much-diminished longtail, getting this right is utterly important.
3. Introducing "Ændrew's Law of Google Analytics"
Or, "The likelihood that you forget to add analytics code to a piece before launching it is directly proportional to how long you've been working on it." Without the constant vigilance of folks like Nick Petrie and Joseph Stashko, I'd have done this at least half a dozen times by now. The sole way to combat Ændrew's Law of Google Analytics is to make adding analytics code the very first thing you do after generating the scaffolding.
4. Different languages are good for different things
There's a saying within software development, "When all you have is a hammer, the temptation is to see every problem as a nail." As a PHP developer, the extra effort required to get a Python or NodeJS-based webapp running seemed incredibly disproportionate to the benefit. Now that I've deployed a good many such webapps — and appreciate that Drupal isn't the solution to every complex web-based programming problem — I now do very little PHP development.
The reason is because some languages are just better at some things than others, and choosing the right one for a given problem is any project's first major technical challenge. Python is amazing for anything data-related, with the insane number of scientific libraries unrivalled by any other popular web-driven language. JavaScript is great on the client-side for accessing cloud resources, and great on the server-side for fast, asynchronous applications (I ♥ websockets). Meanwhile, PHP's still really great for quick drop-in-place services and tools, and Ruby's really really terrific for, uh, something, I'm sure... (Just kidding, Ruby devs.).
I love playing with *nix as much the next person, but not anticipating deployment issues (and budgeting time accordingly) is a sure-fire way to cause yourself stress close to deadline.
This goes beyond just knowing where to upload something, however. Given the aforementioned point arguing the importance of getting deployment correct the first time, knowing how your codebase will scale with increased traffic is vital. Are your REST services stateless? If so, load balance them and host the front-end code on a CDN. Can you cache responses from an API if they're similar? If so, do so. Even though my team never actually touches the main website code for thetimes.co.uk and sundaytimes.co.uk, knowing how it interacts with Akamai has been utterly instrumental in keeping everything ticking along nicely.
Finally, never assume anything in testing is consistent in production. You can't just look at your testing machine and assume everything will be the same when finally surfaced in the iPad app or within an iframe. A project is not complete until it has been tested in production on multiple devices. My team has setup a device lab for just this purpose, to ensure we have a wide array of platforms to test content on before signing it off.
Lastly and most importantly, what separates news development from simple web development is that you're dealing with the first draft of history, created by incredibly talented people who care passionately about the work they do. Being able to work with such people is, without a doubt, one of the biggest highlights of the job. No, not all of them have written HTML since age eight, and yes, you'll probably have to do some hand-holding. But the effort that takes is incredibly rewarding, and there's nothing more exciting than feeling like you're contributing to the ongoing evolution of the industry as it moves increasingly digital.
To see some of the projects I've worked on, click here. To read more about the work my team does, visit our tumblog.
dailybridgerton
romaincrisis
gummygunk
origamiaround
vaporwave
