Working on the PlanGrid iOS Team
Regular job postings mostly don’t reveal a lot about team or company culture. This is an attempt to describe what it’s like to work on the PlanGrid iOS team — and why you might want to join.
Building the digital foundation for the construction industry
PlanGrid’s goal is to improve productivity of construction projects by providing a mobile first solution for running them. We’re helping the construction industry shift from paper focused processes to being able to view and edit the entire construction record set on their mobile devices.
There are many parallels in the way construction and software projects are run, but the construction industry is lacking a lot of the tooling that is available in the software world. We’ve started building this toolset step-by-step: sheet viewing (the equivalent of viewing a software spec), issue tracking (yes, buildings can have bugs too), sheet compare (similar to git diff) but we have a long way to go and there are many tools that need to be added and improved.
Whatever we build serves the productivity of the construction industry. This means more infrastructure is getting built and our users can save precious hours from their very long work days.
Solving interesting technical & design challenges
PlanGrid is a mobile first product. Our challenges live at the intersection of dealing with huge amounts of data, providing all the features required to run incredibly complex construction projects (such as Hudson Yards in NYC) and making the entire app work offline (connectivity on construction sites is often spotty). In the last six months we’ve worked on features ranging from graphics programming (with some Metal) to full text search on SQLite.
At the same time our features need to be simple & intuitive. Many of our users are not eager adopters of technology. Unless our features are easy to learn and make our users significantly more productive, they will not be used.
Learning alongside extremely talented team members
Over the last two years we have built an extremely talented iOS team. It includes frequent open source contributors, speakers and other very talented folks that keep a lower profile. Ben Asher is a contributor to CocoaPods and an occasional conference speaker (I first met him at iOSConf Singapore) as well as a frequent filer of Swift bugs. Jesse Squires is an extremely active member of the Swift community, both through his Swift Weekly Brief newsletter and his various open source projects and contributions. I myself ocassionally speak at conferences and work on open source projects (many which inspired architecture & tools we use at PlanGrid). Our summer intern Julia Geist is eager to share her knowledge too and Arjun Nayini recently landed a contribution to the Swift programming language, after many months of PR discussions.
What unites us all is a strong interested in learning new skills and applying them to build a great product while sharing what worked for us with others.
Reinventing wheels when we need to
We’re happy to take controlled technical risks, when we believe they promise huge benefits.
PlanGrid was a very early adopter of the Swift programming language. For an app like PlanGrid, which is a complex system with various types of business data and workflows, a language with a powerful type system promised immediate benefits. Today 2/3 of our codebase is Swift code.
We invested a large amount of time re-implementing the core of our persistence and sync layer in Swift. This core has ~80% unit test coverage, mostly implemented in Quick and Nimble, which has served us as both as documentation and safeguard against shipping bugs that hurt our user’s productivity. We were also an early adopter of the XCUITest framework and after filing numerous radars we are delighted with the stability of the UI tests and the amount of bugs they were able to catch in the last year. Currently we spend every Friday on “Fix-It-Friday”, resolving technical debt and minor user-facing issues.
As part of the core architecture of our app we have adopted Flux alongside with lightweight wrappers around some UIKit components. Since we introduced these APIs 1.5 years ago we’ve been able to share a lot of code between features and ship significantly faster. We’re constantly looking for technical leverage within and outside of the bounds of platform conventions.
A focus on impact, not on form
Our team is strictly focused on results. We have very few processes in place (e.g. no Scrum) as we do not feel they add value at this point.
We also don’t want team members to be solely focused on coding. We encourage folks to get involved in shaping product decisions & roadmaps.
We also feature a no bullshit interview process. As much as possible we want to see how you would work as a future team mate; that involves a lot of Xcode and collaboration!
Interested?
If this sounds compelling, we would love to hear from you. We’re looking for engineers with various different focus areas. We aim to strike a good balance of technology and product-focused team members, as of now we can use both! We’re also specifically looking for folks with a graphics programming background to deliver prototypes and perform research for some of our forward looking projects (think ARKit).
You can reach me at benji@plangrid.com.
