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.
Career Growth
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:
</br>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.
-
2012 - Building Features -
On Grid Thumbnails & On Making It Personal in iOS with Searchbars -
2013 - Creating Libraries -
ARAnalytics - Analytics for iOS Apps & Musical Chairs -
2014 - Supporting Team Infra -
Using CocoaPods Caching with Travis CI, Building the Xcode Plugin Snapshots & Testing Core Data Migrations -
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 -
2016 - Consolidating web + iOS -
On our implementation of React Native, GraphQL for iOS Developers, Using VS Code for JavaScript & JavaScript Glossary for 2017 -
2017 - Process at Scale (OSS/All of Artsy) -
C4Q&A, Introducing Peril to the Artsy Org, Danger & Artsy’s Technology Stack, 2017 -
2018 - Cementing Artsy Culture -
JavaScriptures (React, TypeScript, Tooling, Relay, Local State, Styled Components), Engineering Highlights & Announcing: Artsy x React Native -
2019 - Archivist -
Why we added an RFC process to Artsy, Why does Artsy use Relay?, Why We Run Our Own Blog, Peril Architecture Deep Dive & this post.
iOS
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.
Dependencies, Dropped Design Patterns, Hybrid Apps, ARSwitchboard & ARRouter
I think the pinnacle of my writing in this phase comes from a collaboration with the entire iOS team the magazine obcj.io - iOS at Scale: Artsy.
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.
Code Review: Emergence, Energy, Energy Sync
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
Re-defining ourselves as native engineers who support JavaScript via our iOS silos was tricky, I think both Ash & Maxim have great write-ups on the topic. For me, the move to the JavaScript came at a perfect time: the iOS community was fragmenting because of competing dependency managers and the introduction of Swift which made infrastructure work less valuable.
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
JavaScript
To get experience in JavaScript, I took one of my large open source projects and re-create it from scratch. Which eventually turned into Peril, which solves some interesting problems at Artsy and in the rest of my OSS work.
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.
Exploration: Front-end JavaScript at Artsy in 2017, Using VS Code for JavaScript, GraphQL for iOS Developers, JavaScriptures (React, TypeScript, Tooling, Relay, Local State, Styled Components), Why does Artsy use Relay?
Open Source
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.
Open Expectations, Open Source FAQ for Engineers, Licenses for OSS Code, Open Sourcing Energy, How we Open Source’d Eigen, Helping the Web Towards OSS by Default, Open Source by Default: Docs
Teaching
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.
Interviewing, applying and getting your first job in iOS, Help! I’m becoming Post-Junior, JavaScript Glossary for 2017, C4Q&A & C4Q&A 2
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!
./orta
</br>x