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.
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.
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.
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.
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.)
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.
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.
A year and a half ago I decided to become a product manager after 5 years as a software engineer. This past June, however, I decided to switch back into engineering.
What happened, and what did I learn?
Good team culture strives for cohesion. Once organizations get large enough, a tension emerges between the culture of individual teams and the culture of the larger organization. How do you achieve team cohesion across small teams and the larger organizations they comprise?
The culture at Artsy is driven by every team member, not mandated or handed down from above. This adds another level of tension, between individuals and their smaller teams. Team working agreements embrace that tension to provide a framework for converting tension into healthy culture.
Software deploys! What a concept. You have some code running somewhere, and you need to get it running somewhere else. What could possibly go wrong? While web developers have become accustom to some really slick deploy processes, iOS developers have to work within some very different constraints.
Today I want to explore the differences between deploying iOS software and front-end/back-end web software. Some of these differences are inherent to how the code gets executed, and some of the differences are incidental to choices that Apple has made. These are constraints that iOS developers need to work within. As Artsy has adopted React Native over the past four years, we have had more and more of our web engineering colleagues contributing to our iOS app. For these web engineers, getting familiar with the iOS deploy constraints is as important as getting to know Xcode and CocoaPods.