Opening Up Engineering at Vokal

6 years ago I committed the first draft of our coding style guidelines for Objective-C and Java. At the time Vokal was a mere 7 people and our client work was exclusively focused on delivering mobile applications for iOS and Android. Today our company is 10 times larger and our service offering has grown to match, capable of producing large-scale multi-platform digital experiences. The original code style repositories still exist today, but have grown and evolved to include much more - helping to define our engineering team's structure, process, and culture. We are now proud to share this documentation publicly at engineering.vokal.io.

What is it?

The original intent of defining coding style guides for each of our teams still lives on, but we now reach much further than just Java and Objective-C. Today you will find rules for how we consistently style other languages such as Javascript, Swift, Kotlin, Python and Go. We also have definition around project structures for each platform, because consistent and repeatable project layouts is not only important to us, but has a direct impact on our ability to quickly produce quality products for our clients. Procedures and guidelines for writing effective defect tickets and test plans are also clearly defined for our Quality Assurance team.

These guidelines extend far beyond defining how we code. We use this documentation as a way to communicate our team structure, outline how to perform effective code reviews, detail expectations for testing, and document how to connect with our dedicated Team Fortress 2 server. Within this documentation you’ll find out how our interview process works as well as how new engineers are on-boarded. In fact, this site is where we point all of our new hires on their first day. It has everything you need to know to be a successful member of our team.

The most important and meaningful fact is that this documentation was not written or dictated by any single individual, but instead is the culmination of ideas, input, and effort from everyone on our team. The source git repository shows 37 unique contributors since 2010, which doesn’t include team members who participated in discussions around various changes. Every member of our engineering team is free to make contributions or add content. Whenever changes are proposed they go through the same meticulous review process that we employ every day when conducting code reviews. Each component of our team’s process has been defined as a group and developed in the exact same fashion that we develop software. In this way we empower our team members to suggest and make meaningful change within the organization, always working together to build a better engineering practice.

Why share all of this?

Above all else the documentation that we’re sharing here is the amalgamation of 6 years of experiences and lessons learned. It is a guidebook for how we scaled seamlessly as a team of 2 engineers to over 50. We believe that these experiences and knowledge should not be kept secret, but shared with the larger community. This documentation has already proven valuable outside of the engineering context. Other teams within Vokal have been able to leverage and build against this foundation to outline best practices - from business development and sales, through project management. The response has been overwhelmingly positive. Our hope by making this information public is that you also can possibly learn something from how we work and potentially make your own team that much stronger.

This is one of many things we’ve built over the years that makes me immensely proud to be a part of this family. It’s been thrilling to watch our team grow and evolve time and time again. I’m completely confident that as we continue to grow in new directions, both vertically as well as horizontally, that our team will always be the best that it has ever been.