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 →

Today is my last day at Artsy, it's been 8 years and I figured a nice way to book-end my time here is to make a post that tries to talk over the last ~90 blog posts I've shipped. My posts tell the story of a junior-ish engineering solving problems on successive larger scales, until their decisions impact whole industries.

These posts cover so many topics that the right way to give them justice is to try group them in terms of general themes and provide a larger context about why they were written.

Read on →

One of the defining cultural features of the Artsy Engineering team is that we strive to be Open Source by Default. This didn't happen over-night and was a multi-year effort from many people to push Artsy's engineering culture to the point where it was acceptable and living up to the ideals still requires on-going effort today.

I think to understand this, we need to dive into the archives of some of member's older posts to grok their intentions and ideas. Yes, this is a re-cap episode. Let's go.

Read on →

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 →