Last week, the Spark tech team took a break from Vancouver rain and travelled to sunny Phoenix to broaden our minds at Railsconf 2017.
Railsconf is an annual event that brings together the folks who use and contribute to Ruby on Rails, the open-source framework on which Spark and many other web technologies are built. While the event focuses many workshops around practical tools to improve your code, there were also a number of sessions dedicated to leadership, team building, and creating a healthy workplace culture. Each of the three days offered a variety of different tracks to explore and each of us took advantage of the opportunity to dive into the topics that interested us most.
Here are a few of my takeaways.
1. Communication Is Not Just An Action, But A Resource
A couple weeks ago, Richard (our customer success manager) talked about improving communication with our clients. As a growing company, we’re also constantly evolving that process within our teams. We tend to think of communication as something active and in the present, which it is — but it’s also important to consider communication as a contribution to the collective intelligence of the company. That is to say, we can think of how and what we communicate as converting our individual knowledge and experience into something that is accessible to colleagues both present and future.
This means that we should document as much as we can about what we do, how we do it, and why we do it, in as organized a way as possible. We can’t always anticipate what knowledge will be valuable to us 6 months, or 6 years down the road, but if we take the time to record the process then we save our future selves hours of detective work and blind speculation, and ensure that any new team members have a thorough understanding of the circumstances that preceded them. This is especially relevant to our engineering team, but it can apply to anyone.
2. Security Is Definitely An Action
At Spark, security is already of the highest priority, but the tools for managing security are constantly evolving, and the most recent releases of Rails (on which Spark stays current) are similarly expanding to take advantage of new security and encryption patterns to keep your information safe. The latest upgrade provides an improved pattern for maintaining security between web applications and the services they depend on, while enabling the application’s permitted engineers to share resources that are essential to development of features requiring these external services.
Additionally, as all web applications must rely on other services to some extent, we are keenly interested in strategies for minimizing the impact of service failures on our own clients. When we were a young startup, we were fairly thrifty with the data that we stored — We have always had full backups in place, but we didn’t go out of our way to store any data that our customers were not actively using. As we continue to grow, we can afford to store more meta-information that will better enable us to track and recover from any potential interruptions that may occur.
3. Data Integrity Is… A Process
As with security, we software developers have a deep reverence for the sanctity of data. We also understand the challenges involved in forcing your users to enter data that will respond perfectly to any request your application could make of it now, or at any point in the future. Just for fun, think of some data as cats. Now think about an application as a box that gets lined with a smaller box for every new feature you add. If you start shoving cats into an increasingly tiny box, sooner or later that box is going to end up with a lot of holes, and eventually, collapse.
Several speakers at Railsconf made the argument that it is unrealistic both to expect and enforce perfect data. To be clear, by ‘imperfect data’, I certainly don’t mean anything which would put the safety and security of a user’s information at risk. I just mean incomplete or oddly formatted values that may result in an error when a user attempts to perform another action on them. Even simple data structures can be mysteriously corrupted, and it’s possible that in cases where mitigating unexpected input feels like shoving cats into a box, that regular monitoring of such data (to the end of either repairing the data or discovering the usage patterns or sub-optimal code structure leading to its input) may be a more effective strategy.
4. Leadership Can Happen At Any Level
At Spark, I’m lucky to have a workplace environment where it’s obvious to me that we’re all on the same team. We’re pretty good at celebrating individual wins and supporting each other through challenges. Even so, there is always room for improvement, and the Rails community is a great model for being mindful of inclusivity, and creating leadership opportunities for folks who might not otherwise have them. An example of this is the conference itself — there was an open call for presentations earlier this year, which were then shortlisted on the basis of a blind review that excluded the speaker’s name and bio, resulting in a wider array of topics from speakers who may have had less experience.
How an individual can facilitate the success of herself and her peers (junior and senior) will depend largely on her role within the organization, but a lot of the suggestions come back to communication. Be proactive about asking for feedback, and learn to accept it graciously. If your work, or someone else’s, is going unrecognized, recognize it! Think about how your actions can directly support both those above, beside, below, and all around you.
All in all, it was an amazing 3 days at Railsconf, and I’m grateful to have had the opportunity to be in the company of the people that power the framework that powers Spark! We’ll be putting these, and many other lessons to good use over the next few months as we continue to ramp up the tech and deliver some exciting new features.
As always, feel free to email us at email@example.com if you have any questions about Spark. Thanks for reading!