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.
I used to occasionally write before I came to Artsy, but inside the environment of Artsy’s Engineering team I could consider it “work work” and not just “things I should do, but in my own spare time.” Writing for Artsy on the blog is very similar to writing code in our repos, you assign an editor (thanks Ash for taking the lion’s share!) and request reviews. This lowered the barriers considerably.
I started working at Artsy with about 2-3 years of professional programming experience at the end of 2011. When
people ask about how career progression tends to work I TLDR it as:
Feature -> Section of Codebase -> Codebase -> Codebases -> Systems -> Businesses -> Industry
This echoes how Artsy used to handle an IC career ladder (current). At that
point I joined, I sat somewhere around
Section of Codebase. Each progression is more responsibility, and can
sometimes be about making decisions and not necessarily being the person to put the work in.
2015 - Long term iOS Software Architecture and OSS -
Dependencies, Dropped Design Patterns, Hybrid Apps, ARSwitchboard, ARRouter and Open Sourcing Energy, How we Open Source’d Eigen & Licenses for OSS Code
While I was originally expecting to be working on Ruby apps at Artsy, I very quickly ended up working on our iOS app Artsy Folio and eventually owned it post-1.0. This makes sense because I had a few years of macOS native experience and I knew the project lead (Ben Jackson.)
Over time, I grew to own the iOS team at Artsy. In doing so I became a manager with 3-4 reports and tried to really make a name for Artsy’s iOS team in the industry. We built more apps, and started to need to think through our larger I found our old job posting from just before we consolidated with web. It echoes a lot of the idea on how I framed our team’s responsibilities being in that we should build Artsy in a way that improves the industry for everyone too.
As we hired, it became important to find ways to teach each other how our native codebases work. So, we have a set of open codebase walk-throughs which explain the high level architecture and occasionally deep-dive on specific features.
As we started to adopt React Native at Artsy, we really needed a different structure for our entire team and technology stack. We had to re-think how we build apps, interact with the open community and what we were as engineers.
On our implementation of React Native, Retrospective: Swift at Artsy, Intro to React Native for an iOS Developer, React Native, 2 years later, Making a React Native Components Pod & React Native at Artsy, 3 years later
We still needed to be up-to-date with the latest tools and ideas from the native world, but mainly from “iOS as Platform” instead of features development (though my non-technical ARKit post is a great read).
Deploying your app on a weekly basis via fastlane + Travis CI, What is fastlane match?, It’s time to use Swift Package Manager, Accessing the app’s Source Code from your Simulator, Why does my team’s Podfile.lock Podspec checksums change?, Code Injection for Xcode, Artsy’s first closed source Pod, CocoaPods-Keys and CI
For Artsy, we needed to consider: What is the right tech to build for both React Native and React on web? We had a good guess back in 2016 and that slowly evolved over the course of a few years into what we now call the Artsy Omakase. Making sure that the rest of the team agreed, and that new people could go see our reasoning was important when making foundations which could last 5-10 years.
Artsy had a rich relationship with Open Source before I arrived, and I devoted a lot of time and effort to making this world-class. There is an entire blog post on how Artsy became Open Source by Default, but I made sure to make it easy for people interested in following Artsy’s footsteps. I believe the world will be a lot richer as more people work in the open.
To quote myself:
Open Source is important to me because I grew up outside of an urban center in Britain where I had very little in the way of community mentorship. Open Source gave me the ability to see how difficult things were built. I moved from being a beginner to an intermediate programmer by reading the source code that others had opened up.
→ 5 Questions with Orta Therox (open.nytimes.com)
I use Open Source, and Artsy’s leverage, to help make sure that the next generation of programmers feel like they have so much more insight into how we build hard things. I know it’s not easy getting started, so I’ve tried to take common questions and wrap them up into larger sets of documentation on how I went through those phases.
So, What Next?
If you want to keep on top of what I’m up-to, I’m starting a personal mailing list. You should join, it’ll be roughly monthly - so pretty low key.
Well, I built a system for doing guest posts in this blog, so maybe I’ll appear again on this blog now that I can’t write “we” when talking about Artsy. In the mean time there’s a lot of engineers at Artsy writing really cool things!