A common suggestion for improving pull requests (PRs) is to “make your PR small and focused”. I myself gave this suggestion in a recent article on this very blog about including context in PRs.

Like most internet advice, this can feel like the “draw the rest of the owl” meme. Even if we’re in agreement that I should make a PR smaller…how do I do it? How do I avoid a big PR when there’s a lot of cross-cutting changes to make? How do I create small, focused units of work when I’m building a large feature? How can I overcome my perfectionism and submit a PR that feels incomplete to me because the edges aren’t all polished?

Read on →

I know that for many developers, especially those early in their careers, asking for help can be intimidating. I often fear wasting someone’s time or exposing myself as less skilled or smart than my team initially thought.

In my first month as a software engineer at Artsy (and barely six months into life as an engineer after transitioning from a career in communications), I was struggling through a ticket assigned to me as a “good first issue.” (The team estimated the task to be straightforward enough for someone new to the team.) After a few hours stumbling between the ticket, my code, and Google, I made very little progress.

Read on →

Available now on Apple Podcasts, Spotify, and coming soon elsewhere, is Artsy Engineering Radio!

Solving problems in the world of software engineering can mean a lot of different things, and this podcast will explore what that looks like at Artsy. If you’ve followed our blog, you can expect a podcast that sounds like it. There are a ton of amazing engineers here at Artsy and we’re excited for you to hear their voices and stories. Our hope is that this podcast will make it easy for more engineers at Artsy to contribute to the public persona of Artsy Engineering.

Read on →

In, a recent blog post, I discussed a fundamental difference between web and iOS deployments. Web software is deployed to servers that are under your control, while iOS software is deployed to users’ devices that you have no control over. This distinction really changes how you think about the code that you ship, because that code could be running indefinitely on devices that never get updated.

The previous post focused on this distinction through the lens of accidentally shipping (and then fixing) a bug. This focus on bugs is important, but focusing only on bugs left me unable to articulate an important, nuanced distinction between hosting code and shipping app binaries. So let’s dive in.

Read on →

Sharing knowledge! What a concept! In my recent blog post, I discussed “Knowledge Share” meetings (also known simply as “Knowledge Shares”, or abbreviated “KS”) and I want to dive deeper into them today. Last time, I described them as follows:

Knowledge Shares are a structured time to facilitate unstructured learning. Anyone can bring a topic to Knowledge Share, from a ticket that they’re stuck on to an idea they have to a neat trick they recently learned.

These meetings were really instrumental in ramping up the Mobile Experience team, but their history goes back a bit further. Today, we’re going to discuss the origins of Knowledge Shares at Artsy, how they’ve evolved, the value they provide us as engineers, and how I’d recommend you adopt them on your team.

Let’s go!

Read on →

It was a Wednesday, mid-summer 2019. I don’t know which Wednesday specifically, but I know that it was a Wednesday because I was attending Artsy’s weekly all-hands meeting. Two hundred colleagues were also there (many dialing in remotely) and we were all listening to Artsy’s new CEO talk about the company’s direction. Mike Steib had only been around for a few months at that point, getting to know the business. He was talking about the product direction, and I was listening intently.

With Artsy’s iOS app, I knew there were only really two directions we could go. As I listened, I reflected on how we had gotten here.

Read on →

In 2017, Artsy adopted Relay in both its front-end web and iOS codebases (using React and React Native, respectively). Generally speaking, this investment has turned out very well for us! Relay empowers product teams to quickly iterate on new features and to share common infrastructure across web and iOS codebases. However, most of the original engineers who pioneered using Relay at Artsy have since moved on to their next role; this has left a knowledge gap where Artsy engineers are comfortable using Relay, but they don’t totally understand how it works.

This is a problem as old as software engineering itself, and it has a simple solution: learn and then teach others. We’ll be driving a peer learning group centering around Relay, but today we are going to dive into the part of Relay that comes up the most in requests for pairing: getting Relay pagination to work. (Note: we’re going to use plain old Relay and not relay-hooks.)

Read on →

This blog post is going to motivate and describe Artsy’s adoption and evolution of the usage of review apps.

This first part of this post covers a couple of common problems where topic-specific servers (i.e. review apps) are useful.

The rest of the post describes Artsy’s history with review app automation via incremental problem solving and the composition of a few well-known technologies.

Read on →

Code review is an engineering process that has benefited greatly from a move toward asynchronous communication. Long ago, engineering teams would sit in a room with code on a projector to review changes together. 😱 For many teams this led to batching code reviews or even skipping them altogether. 😱😱

Today, most engineering teams use incredible tools like GitHub or GitLab to review changes through Pull Requests (PRs). The greatest advantage of PRs is that the review can happen when it’s convenient for the reviewer: asynchronously. Asynchronous communication isn’t all sunshine and unicorns, though. Notably, it lacks the ability to course-correct when context is misunderstood.

Read on →