Instagram Dev, Swift Speaker & Swift Weekly Brief: A Top Dev Interview With Jesse Squires
Check out our interview with Jesse Squires – the creator of Swift Weekly Brief, and Swift guru at Instagram. By Adam Rush.
Welcome to another installment of our Top App Dev Interview series. Each interview in this series focuses on a successful mobile app or developer and the path they took to get where they are today. Today’s special guest is Jesse Squires.
Jesse is a Swift guru, technology writer and speaker. He is best known for running the Swift Weekly Brief and is currently an iOS developer at Instagram.
When he’s not busy working at Instagram, Jesse tours the world giving talks at conferences and meetup groups, including FrenchKit, Swift Summit & Realm. Jesse also contributes to many open-source projects.
Inside Instagram
Can you please describe the process of working within Instagram, and how that compares to a similar process when you are an indie developer?
Working as an indie developer, you have to do much more than just be a developer. You’re also a product manager, beta tester, designer and everything else.
Within a company, it’s all about utilizing many people’s skills. For example, we have entire teams looking after each aspect of the build, and over 500 million monthly active users constantly using the app providing feedback. It really boils down to resources – this is key. The more resources you have the fewer hats you have to wear.
My most recent work at Instagram (that’s public) was IGListKit and more broadly incorporating the framework across the app. I have been helping Ryan Nystrom move the project forward and engage with the community on Github.
If I was to find a bug at Instagram, can you describe the process of the work? For example Elaboration, Development, Testing. How does it flow through the scrum process?
We work in a very self-driven way. There is no formal scrum process. If you find a bug, you usually just fix it right away or create a task and hand it off to whomever “owns” that area of the codebase if you aren’t familiar with it. For other bug reports, you just prioritize/triage them like you would elsewhere.
We have a similar process when adding new features it consists of ideation, design, and prototyping — with collaboration across Product, Design, and Engineering. Once we figure out what we want to build, we’ll break up the work into tasks and start building.
There’s also a strong “dog-fooding” culture at Instagram/Facebook so employees are always using the latest internal builds of the app and providing feedback.
The new Instagram offices that Jesse works in.
The new Instagram offices that Jesse works in.
I note that Instagram push releases almost every week if not more. What’s the process to be able to achieve this?
It’s a pretty straightforward process. We work on master and cut a release branch every 2 weeks. The release branch “soaks” for 2 weeks and we cherry pick commits for bug fixes as needed, then submit to the App Store. The majority of this is automated.
I think the key is that there are no exceptions — we cut and ship every 2 weeks. If your work isn’t finished, you just wait until the next cut — but we never miss or delay a cut.
We don’t use Jenkins to manage this; we use Facebook’s CI infra. But, for all intents and purposes it works the same way as something like Jenkins, Travis-CI, etc.
For source control, we use mercurial and phabricator. If you aren’t familiar with these, the analogous tools would be git and GitHub.
What’s your development workflow like?
Our development workflow is pretty common:
- Make changes.
- Submit a diff for review.
- A team member needs to approve.
- CI runs tests.
- Your diff is merged.
- A new internal build is eventually available for dog-fooders to download.
Contributing to the Community
You are highly active in the open source community. What benefits have you seen from doing that?
I attribute most of my success to open source. This definitely isn’t true for everyone, though. I was lucky enough to start a project that became really popular. And I was privileged enough to have time to get involved in open source in the first place. Not everyone has that opportunity.
In the beginning it was about everything I learned:
- How to use git better
- How to use GitHub
- How to collaborate remotely with dozens of contributors
- How to manage a large project
- How to triage issues
- How to manage branches
- How to maintain stability
- How to design open and modular APIs
- Semantic versioning
- …the list goes on and on!
With a popular open source project, you receive a ton of feedback — positive and negative. All of it is valuable and all of it helps you grow and learn.
You are well known for curating the Swift Weekly Brief, a newsletter about the latest developments on swift.org. What made you decide to start this newsletter?
This happened by accident. I was so interested in open source Swift when it was announced, and I wrote a few blog posts on my personal site. The community seemed to enjoy and appreciate them, so I decided to move it to a dedicated site and make it “a thing”.
It takes multiple hours a week to put a newsletter together, but I usually do it in small chunks as I go so it never seems like it takes too much of my time. For the blog posts, GitHub activity and mailing lists — it’s pretty much what I’m reading and interested in already. I would be doing much of this on my own, so I figured I might as well share it with the community as I go.
It’s certainly beneficial for me personally, too. I already want to stay up-to-date with everything that’s going on with Swift, so this commitment to publish the newsletter ensures that happens.
Recently you decided to open up the Swift Weekly Brief to external contributors, with the goal of making it a community newsletter, rather than your own. What made you decide to do this, and how can people contribute?
As I mentioned, open source has benefited me in numerous ways, and I want to give others an opportunity to contribute — if they want. There’s no reason a newsletter like this can’t be run and managed like a “regular” open source project, like AFNetworking. Bringing other peoples’ experiences and perspectives to any project makes it significantly better in my experience.
On the other side, part of that is me wanting a break! :] As you may expect, some weeks I’m busier than others so it’s really nice to have some help if I don’t have time to put the newsletter together. There have also been some weeks where I’m on vacation and going “off the grid”.
Luckily, Brian Gesiak, JP Simard, and Bas Broek have all stepped up numerous times to contribute and put together entire issues. It gets other people involved, it allows me to take a week off, and the community still gets their weekly dose of Swift news.
For anyone that wants to contribute, everything you need to know is here. The entire process for publishing is open source. Just open an issue on GitHub for the week that you would like to write the newsletter and we can discuss!
What advice would you give to any bloggers out there?
When I look at successful blogs, I see programmers and writers writing about the things they know about — the things they are interested in and passionate about. Don’t write what you think people want to hear, write about what you know and what you like. If you do this, the result will be good articles that people want to read (perhaps with a bit of practice, too). So that’s step 1 — good content.
Building and growing an audience is difficult, but I think it’s best for this to evolve organically. There’s no magic formula, so don’t try to force it — you’ll likely end up disappointed.
One thing that’s effective for me is conferences. Speaking at a conference is really just an extension of my blog — a conference talk is like an “in-person” blog post. When you speak at a conference, you can tell people about your blog. If you aren’t speaking at conferences yet, you should try! Start by speaking at a local meetup, then try submitting abstracts to conferences.