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 →

We recently bade a fond farewell to two of the champions of our “open source by default” ethos, but this spirit lives on at Artsy.

Today we open-source one of our key metadata apps, and explain how it fits into Artsy’s ecosystem.

Read on →

Welcome back to my series on writing for engineers. In the last post, we discussed technical writing on the web from an individual’s perspective: how do you get started? how do you leverage the web? how do you improve? In today’s post, I want to change directions; instead of focusing on how individuals write, we’ll discuss how teams write.

Read on →