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.
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.
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.
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.
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.
Love for Swift
What’s the best feature you love in Swift 3.0 and how do you see the future of Swift going?
The huge collection of API and syntax refinements has made a huge difference. Once you get over the painful migration, these improvements really make Swift a pleasure to use.
As far as features, pretty much everything you need to know is on GitHub. But more broadly, I think Swift is on its way to being the dominant language on Apple’s platforms. It will take years, but eventually I think Objective-C will begin declining more rapidly. The day that Apple releases a pure Swift framework — that will be the turning point. I’m not sure when that will happen, but we know that Apple isn’t shy about abandoning old technologies.
For other platforms, it’s difficult to predict. IBM is pushing for Swift on the server, and there’s now an official Sever APIs Project. Once server-side Swift matures, my bet is that it will take off. There’s so much enthusiasm for Swift on the server.
As far as Android goes, I doubt Swift will ever be a first-class language. For that to happen, Google would need to invest in it and I don’t see that happening.
You have now ported most of your open source libraries to Swift, how did you go about doing this?
I migrated to Swift 3 in two distinct steps:
- I first migrated projects to Swift 2.3 and released major version updates.
- Then, I turned around and migrated to Swift 3 and released another major version update.
I did this so anyone using my projects could stay on Swift 2.3 if needed while allowing the projects to continue moving forward. I made the decision not to maintain any older versions of Swift for any projects because I simply don’t have time.
What advice would you give to somebody who wants to start building with Swift?
I would definitely say do it! Personally, I think I write code faster and better with Swift.
However, you should be aware that large apps have some large pain points. Uber, Lyft, LinkedIn and others have written posts and given talks about this, so check those out and decide if it’s worth the trade-off.
Especially if you are starting with Swift 3, I think there’s a strong argument to use Swift despite the current shortcomings in tooling. The Swift team are aware and working hard on solving these problems.
Where To Go From Here?
And that concludes our Top App Dev Interview with Jesse Squires. Huge thanks to Jesse for sharing his work at Instagram, his love for Swift and finally running a successful blog.
We hope you enjoyed this inspiring interview and if you’re thinking of starting your own blog or wanting to start talking at conferences to take Jesse’s advice to heart.
If you are an app developer with a hit app or game in the top 100 in the App store, we’d love to hear from you. Please drop us a line anytime. If you have a request for any particular developer you’d like to hear from, please post your suggestion below!