In 2013, Artsy shipped the first version of our iOS app. Typical for an early-day startup, the app was a “minimum viable product” (with a big emphasis on “minimum”). One of the features that didn’t make the cut was something you expect to see in most apps: a log out button.

When I joined Artsy a year later, there was still no log out button. And there would be no log out button for another six years, until today.

I want to talk about this quirk of our app, from both product and technical perspectives. Why wasn’t this already in our app? Why was it so difficult to build? These are interesting questions, and their answers shed light on how products mature over time. I also want to talk about how we finally managed to prioritize this kinda weird feature request (spoilers: it was our company-wide hackathon). Let’s go!

Read on →

This will be the first in a series of posts about how we used advanced GraphQL tooling and functionality to better handle errors occurring during query resolution, and better equip clients to reason about such errors.

The goal is to describe our current approach, but also do a deep dive into specific ways we’ve extended our GraphQL server to help us accomplish that. If you are an interested GraphQL user, you may find this useful, even if some of the larger context specifically around how we are using it to help standardize error handling doesn’t apply.

Read on →

You are a software engineer.

You consider yourself an introvert, and you really appreciate “engineering time”, where you prefer to work for extended uninterrupted periods because interruptions wreck you. You are used to being misunderstood. Ever since you can remember the people around you have been kind of baffling: they constantly fail to notice stuff that’s really obvious and important to you, and then they have the audacity to get frustrated with you for not understanding them.

But whatever, you can deal with this, right? This is just how life goes, right? Everyone’s like this, right?

Right?

Read on →

Regular readers of our blog might be familiar with Culture Amp, a tool Artsy uses to collect anonymous feedback and take action on cultural issues (we most recently discussed the tool in this blog post). At a company-wide level, Culture Amp has helped guide everything from Artsy’s evolving culture, to our physical work spaces, to our support for remote work. At an engineering-team level, we’ve also been using Culture Amp to guide our choices in technology, documentation, and training.

In this blog post I’ll be detailing a recent learning course we ran to share knowledge about how Artsy builds iOS software for our entire engineering team.

Read on →

Email! Electronic mail! What a concept! Like many companies, Artsy has built products on top of email, but this is a decision that (like many companies) Artsy periodically regrets. But overall, our email systems work well!

But what about when it doesn’t? Well that’s what today’s blog post is about: what happens when things break and you don’t know why?

Read on →

The Artsy Vanguard is an annual editorial series where we feature up-and-coming, notable, and praiseworthy artists and their contributions to the art world. 2019 was the second year that Artsy published this special feature, although we have been publishing custom editorial segments multiple times per year since 2015.

In this post, I’ll discuss my recent experience working on the 2019 Artsy Vanguard editorial feature. I’ll start by introducing the technology stack behind our articles and then discuss what I learned from both a team/organization and technical perspective.

Read on →

When I joined Artsy Engineering a few months ago, I had roughly zero knowledge of Kubernetes. I’d heard the term thrown around a few times, but had no idea how it worked or what it was used for.

Kubernetes is still a bit of a mystery to me, but I’m able to do a lot of Kubernetes operations quickly and easily thanks to an open-source tool developed at Artsy: Hokusai.

In this post, I’ll give some background on Kubernetes, a brief history of Hokusai, a description of its functionality, and some pointers for how to get started using it.

Read on →

As engineers we are constantly in the process of building new features and improving our existing ones. Nowadays, with the help of tools and processes like code reviews one could argue the quality of the code being written has risen. At Artsy a pull request normally has one Assignee and possibly one or more Reviewers, so why do we still do a lot of refactoring?

There is no means of testing which decision is better, because there is no basis for comparison. We live everything as it comes, without warning, like an actor going on cold. And what can life be worth if the first rehearsal for life is life itself?

― Milan Kundera, The Unbearable Lightness of Being

Part of me wants to end this blogpost by Kundra’s quote, but for now let’s get deeper.

Read on →

We use server-side rendering (SSR) to deliver every page you hit on artsy.net. We decided on using SSR for many reasons, amongst them performance. We wrote about this all the way back in 2013!

We’ve also built our site using responsive design, so you get a browsing experience optimized for your device.

Combining SSR and responsive design is a non-trivial problem. There are many concerns to manage, and they are sometimes in conflict with each other. We server render for performance reasons, but we also want to be sure our app is performant when your browser takes over, all while optimizing for accessibility and SEO.

This article describes the tools we use on artsy.net to combine SSR and responsive design.

Read on →

Before I joined Artsy, I worked at companies where software projects tended to have meaningful, predictable names. If we were building a system for flagging media uploads, it might be called media-review. In many cases, our code repositories’ names matched the main product’s branding or even the company’s name. Life was simple and there was no risk of ambiguity.

At Artsy, our systems have peculiar code names like Gravity, Pulse, and Vortex. There’s a persistent learning curve as you contribute to different repositories or as new services get created. Numerous times, I’ve wondered: are code names worth the trouble?

Read on →