I. Developing is the future.

This was—without a doubt—the message I heard the most from the NYTimes graphics staff. Regardless of the type of work they did most, all of them knew (at least) enough HTML, CSS and Javascript to visualize and build the pieces they had in mind.

It was clear to me that this was a skill that was not only important to a company such as the NYTimes, but a skill that employers of the future will highly value. In an increasingly digital age, the ability to mold the web around you seems absolutely key. In fact, one of the quotes I wrote down from my day at the New York Times added a key point too:

Even if you don’t build your own projects, just knowing how the computer processes and displays the work you give it is essential in today’s world.

I think regardless of the field my generation is going/goes into, the ability to navigate the web will be a skill that’s valued and emphasized.

II. Design for the piece.

One of the biggest shocks to me was the lack of a style guide from any of the departments. They explained—of course—that there were common practices, but because folks there were good at their job, they never faced designs that were too catastrophic. For the most part they didn’t use a style guide; with a selection of a palette and a few fonts, the rest of the piece was up to the designer. Here’s another misquote from someone whom I don’t quite remember the name of (sorry):

You could compare bar graphs from various different projects in the New York Times, and they wouldn’t look necessarily consistent with each other. But on a piece to piece basis, they fit the writing they belonged to.

And they 100 percent did fit the writing they supported. From maps to graphs to straight up statistic visualization, there was no doubt that the projects were cohesive. I really appreciated that.

Coming from a high school publication, I’m not sure there’s quite room for complete exploration given to the writers and designers of the magazine (and rightly so, they’re not paid professionals). But when specialists took control of their work themselves, it turned out in only the most outstanding ways.

III. Write, design, build.

While talking to Larry, he mentioned that roughly 70 percent of the articles the graphics department (and co.) work on are their own stories. The interviews and the writing are completely done within the department, by people who develop and design.

I saw that creating the work you design and develop for allows you to create pieces that are fully suitable for the project. There was this sense of complete maturity to the pieces they showed me, mostly because the same person or group of people had carried through the entire process.

This is—of course—mostly just relevant to the journalism interested part of the world, but I found it incredible that the people who designed such a prestigious magazine were also such excellent journalists.

IV. Collaboration is key.

Like how the graphics department worked on pieces together, collaboration between the various design departments seemed to be really important. It was explained to me like this:

The way we work [is that] we don’t ship our pieces from one department to another. It’s not like the project goes here, and then here, etc. We all openly seek criticism and contact each other about pieces.

And I saw just that. Interactive design would contact video, or graphics would contact the coding geniuses (they weren’t called coding geniuses, but I can’t remember what they were. They were great at backend though).

V. Other stuff that was neat as heck.

Throughout the day, I saw so many aspects of the company that had me drooling, and although they didn’t fit into any of the above lessons, it would kill me if I didn’t share some of the stuff that I saw.

A COLLABORATIVE BACKEND

One of the sweetest things I got to see was the backend of the graphic department’s process (called the previewer). Almost set up like GitHub, they were able to push changes to each piece, in a way that all the other department members could review and tweek. Other options included restoring previous versions (a lot like how Google Doc’s revision history works) and creating branches off of the main piece to test changes.

THE CODE-Y BITS

JavaScript and Node.js are the talk of the town at the NYTimes. Any graphic that wasn’t static was built with JavaScript, and extensive libraries used by the NYTimes staff keep the website consistent and smooth. A lot of charts, graphs, and tables are built dynamically with cleverly optimized code in order to display statistics in the best way possible (using a Node library called D3).

AUTOMATED ARTICLES

I was a little surprised to see how in-depth the New York Times covered election night. Available on the website were election results, ranging from national titles all the way down to local. I had no idea how they had done it.

This isn’t actually how the code even remotely works. I just wanted to visualize the idea.

Using code, they were able to create scripts that would create self-writing articles. Drawing information from a database like who was running, who won, etc., they created code that formed sentences that would create an article.

THE INSULT DICTIONARY

One of my all time favorite NYTimes pieces, The 307 People, Places and Things Donald Trump Has Insulted on Twitter: A Complete List, runs using a Google Spreadsheet that collects every single tweet that Donald Trump’s account publishes. Staff are then able to scroll through the sheet and tag various tweets that are insults, allowing the tweets to be published to the live page whenever.