In early 2018, I was set to begin my fifth year working at Artsy. Something about my imminent Artsyversary had me thinking about my role within the Engineering team. Not my role as an engineer per se, but my role as a colleague. This is the longest I've ever worked for one company, and as Artsy started growing the team last year, I wanted to leverage my impact as a longtime colleague to help scale its culture.

Artsy collects quarterly, anonymous, company-wide surveys through Culture Amp to determine how everyone is doing. These are great for answering quantitative questions about the team, like "how engaged are we on average?", and I always check out the breakdown of answers in the Engineering team. But there's something unsatisfying about these reports – they're super-valuable, but they feel impersonal to me.

If I wanted to leverage my impact, I needed to play to my strengths and interests. I'm keenly interested in people – as individuals – so I decided that the best way for me to contribute to the team was to get to know everyone as individuals. To become someone the team could talk to. Someone outside the typical manager/employee structure, who could use their history at Artsy to answer questions (or at least point them in the right direction).

So, I set off on a project to meet with every member of Artsy's Engineering team for a one-on-one. With no explicit goals or expectations, but in line with Artsy's People are Paramount value, I got to know my colleagues better.

Read on →

Growth is tricky. Whether in terms of raw headcount or people's evolving career stages. As a team you want to provide ways in which members can experiment with new ideas, and provide tools to help them offer new perspectives. One of our greatest tools for instituting change at Artsy is our RFC process.

An RFC is a Request For Comments, and it is a structured document (in the form of GitHub issue normally) which offers a change to something. The format is used in large open source projects like: React (Overview, Template), Swift (Overview, Template) and Rust (Overview, Template). To give core & non-core contributors a chance to propose an idea to everyone before implementing a change.

We took this idea and applied to the process of making any cultural change in the company. Read on to find out why we needed it, how we refined it, some of the tooling we built around it, and what other options are available.

Read on →

When the mobile team at Artsy considered moving to React Native back in 2016, one of the most compelling cases for making that jump was Relay. This, it seems, is a dependency that is rarely used in the JS community and we often find ourselves re-explaining this decision to new engineers during onboarding, and to the public at large.

Which makes this a perfect blog post topic, so let's have a deep dive into what makes Relay compelling for Artsy's engineering team.

Read on →

TypeScript is a language from Microsoft which builds on JavaScript. This post is a non-technical overview of what JavaScript is, how TypeScript extends JavaScript and why we choose to adopt TypeScript at Artsy.

Read on →

For the last two years, we've used Peril to automate quite a lot of process at Artsy. You can see a full overview of what we automate in artsy/README. As a service, Peril is a bit of an iceberg of complexity, most tooling-y developers at Artsy have contributed to our user-land Dangerfiles but very few have touched the server itself.

To lower that barrier, I gave our Engineering team a run through of how the server works and how a lot of the pieces come together. Jump to YouTube for the video, or click more for a smaller inline preview.

Read on →

On Valentine's day in 2014, @alloy made our first commit moving the Artsy Mobile team to JavaScript, and paving the way to the shared Omakase JavaScript stack across web + iOS. We've done a write-up at 6 months, 1 year, 2 years and at 2.5 years we collaborated on a React Native conference with Facebook which features a very long Q&A session with the people who worked on, and with our React Native stack.

Our experience has been really positive building a single platform data-driven app. We've been able to drastically increase the number of contributors to the codebase and with minimal guidance, web-developers are able to be productive and ship features to our iOS apps.

That said, for this 3 year anniversary, I want to dive deeper into some of the less positive aspects of our transition. We think these trade-offs are worth it, and that this may be what a successful cultural transition eventually looks like for some companies.

Read on →

First of all, that's very exciting! Software engineering is pretty darn cool—you get to learn lots of new things, understand the technology you use every day better, and contribute to the mysterious maw known as "the internet".

Last February, I also decided that I wanted to pursue computer engineering. I'd been at Artsy for a bit less than two years at that point, first as a marketing intern working on SEO and then as a coordinator on the CRM (read: email) team. I'd consistently been working on small technical projects; first doing some work on a tool for SEO optimization for our Editorial team, then building emails with MJML, and a few other bits and bobs. But I didn't think of it as a serious pursuit.

Mostly, that was due to my experience programming in the past—I did about half a CS major in undergrad. At the time, I felt that programming wasn't right for me, and I dropped the major during my third year.

It was Artsy's Engineering team that convinced me that programming was something that I both wanted to and could do. Our engineers have always welcomed learners and been happy to answer questions and empower other teams to do technical work. I eventually realized that the parts of my work where I was coding were the parts I enjoyed the most, and that I would likely feel more fulfilled if I made programming my full-time occupation.

Here's what that journey looked like. Hopefully my experience proves helpful to you as you begin (or finish) yours!

Read on →

On select occasions since 2015, Artsy Editorial has created a number of custom, one-off articles featuring unique layouts, styles and experiences. After trying a number of implementations, the EditorialFeature component was introduced to the process during Artsy’s 2018 year-in-review projects.

By moving the implementation of custom articles to Artsy’s component library, we were able to remove some of the friction and time investment necessary for engineers to spin up these articles, and enable bespoke layouts to be housed in Artsy.net’s Article domain rather than a custom Express app. Acting essentially as a wrapper to accept article data, any component can be rendered as a child of the EditorialFeature component, allowing for flexible combinations of new and existing features, and for minimal or maximal interventions.

Read on →

This blog just passed the 7 year mark from our initial "Hello World" post. We've always built and hosted our own blog, initially using OctoPress but eventually migrating to just plain old Jekyll.

Artsy uses 3 separate editorial platforms now, we built our own for Artsy Magazine, use Medium for our Life at Artsy blog and Jekyll for the engineering blog. There was a healthy debate about whether we would migrate to one, or two systems, but I had pretty strong opinions on migrating the engineering blog to Medium and nipped that in the bud pretty quickly.

With Signal vs Noise being a high profile of a example of migrating to Medium and back again, I thought it's worth taking the time to examine our reasoning for doing it ourselves.

Read on →

At the beginning of January we discovered an interesting note in TypeScript's roadmap about linting:

In a survey we ran in VS Code a few months back, the most frequent theme we heard from users was that the linting experience left much to be desired. Since part of our team is dedicated to editing experiences in JavaScript, our editor team set out to add support for both TSLint and ESLint. However, we noticed that there were a few architectural issues with the way TSLint rules operate that impacted performance. Fixing TSLint to operate more efficiently would require a different API which would break existing rules (unless an interop API was built like what wotan provides).

Meanwhile, ESLint already has the more-performant architecture we're looking for from a linter. Additionally, different communities of users often have lint rules (e.g. rules for React Hooks or Vue) that are built for ESLint, but not TSLint.

Given this, our editor team will be focusing on leveraging ESLint rather than duplicating work. For scenarios that ESLint currently doesn't cover (e.g. semantic linting or program-wide linting), we'll be working on sending contributions to bring ESLint's TypeScript support to parity with TSLint. As an initial testbed of how this works in practice, we'll be switching the TypeScript repository over to using ESLint, and sending any new rules upstream.

At Artsy we've been using TSLint for a few years now; it's worked well for us, and we've even written our own custom rules. However, given the vastness of the JS ecosystem and how fast it moves, it's easy to recognize this announcement as an exciting moment for tooling simplicity.

Read on →