As the Canva engineering team continues to grow, weve started to codify some of the tribal knowledge that previously went unspoken. This post is our attempt to describe the practices weve found help us work more efficiently as a team. Its been really useful so far as a survival guide for new engineers, so we thought wed share it. This isnt meant to be a prescription for every team; its just what works for us.
The important parts break down nicely into three categories:
Practices - how we get things done
People - how we get things done with others
Principles - how we approach problems
Every Monday, each feature team lays out the rough trajectory of work for the week in a JIRA sprint. Each of our deployable components has a baseline weekly release cycle synchronized with these sprints (some components release more regularly on top of that baseline). These sprint planning meetings are the primary means for communicating the latest priorities. We try not to get too hung up on the specifics of formal agile processes, but its a familiar practice to anyone whos experienced agile before.
Related trivia: We name our releases alphabetically, and were currently in the midst of CHEESES OF THE WORLD. Previous release themes include Sh*t Gen-Y Says, Muppets Characters, and Crayola Colours.
Design docs clarify domain models and implementation strategies for non-trivial things, allowing them to be communicated effectively between several people over time, and in order to put subsequent coding in context. We keep design docs in a shared Engineering folder on Google Drive, where everyone on the team can find and edit them.
To publicise these documents better, one of the Canva devs developed a Hipchat integration that publishes all public to Canva documents to a dedicated Google Drive room. Its a great way to see what your colleagues are working on.
Before code gets pushed to a master branch, it gets reviewed. Code-review culture makes or breaks an engineering team, so we follow a few principles that keep things running smoothly:
Each language we use has an internal style guide, and each guide is a living document that evolves through consensus from those on the team who use that language. We keep those guides in a github repo, and propose changes, through pull requests.
Given our pace of recruiting, at some point everyone will be involved in reviewing submissions from potential hires or interviewing candidates. During hiring periods, we expect this to take 4~5 hours a week of an engineers time.
Key points about our release cycle are:
Email is our primary tool for reliable communication. To get someones input on something, its best to send them an email. In particular, we strongly suggest not using chat software for reliable messaging1. We recommend everyone brushes up on how to use an email client effectively (e.g., keyboard navigation in Gmail) and checks their inbox regularly, at least hourly during work hours. For example, our CI system delivers notifications primarily over email. In order to push code, engineers need to be contactable by the system in the event of a break.
1 In many chat tools, notification state is not preserved across network reconnection or signout/signin. If you send someone a message, you have no way of knowing if theyre ever going to notice it.
We use HipChat for transient, short-lived group discussion. Weve found it to be an invaluable tool for having several vibrant discussions occuring concurrently, and allowing people who werent present at that time to peruse the discourse at a later time. No ones obliged to use it, but pretty much everyone does. There are more serious rooms for asking questions, and sillier rooms for posting the latest cat GIFs and memes. If everyone in the room suddenly starts laughing, its probably because of something on HipChat.
Everyones got their own preferred way of working. Contrary to the stereotype, not every engineer is an introvert. Some people get their best ideas from bouncing off others, and some work better when they can isolate themselves and fully immerse themselves in a problem. Some prefer to solve problems by doing and iterating, some prefer to solve problems by analyzing and understanding. One person might use different styles in different contexts. Rather than try to coerce people into one style or another, we just recommend common sense and politeness to enable everyone to work together constructively.
We all try to be mindful of our different styles in all aspects of how we interact day to day, but two interactions are of particular importance at Canva:
We enjoy a great amount of freedom in managing time and priorities on our own. We have flexible hours, and nobody micro-manages our day-to-day schedules. But to paraphrase Uncle Ben, with great freedom comes great responsibility to keep the rest of the team informed about what youre working on.
Checking in with the team keeps priorities and scope in mind as we build things, and offers a way for everyone to contribute via offering suggestions, lending a hand, or challenging preconceptions. Weve found from experience that when someone has been working on a project in isolation for a few days, theres a good chance that a discussion with a peer would have saved a lot of time.
We keep each other up-to-date through things like small standups, daily conversation, HipChat, code reviews, and JIRA. Sometimes its as simple as leaving a message in the teams HipChat room every few days.
All day, every day, most of us are busy doing something. Our open plan office is great for camaraderie and vibe, but it can sometimes make it difficult to focus, especially if youre working on a task that requires deep concentration. Some people hold a lot of context in their working memory at any one time, others dont. Some people welcome interruption, others dont. To work together effectively, we ensure that everyone is aware of the almost-universal-but-usually-unspoken ways that engineers work day to day.
If someones displaying the above behavior, we try not to interrupt them verbally unless its urgent; IM is preferred (which means theres a responsibility on everyone to check IM periodically, even when theyre the one trying to concentrate).
For extended conversations, its best to politely ask in advance (can we chat about X in 10mins?), so the person has enough time to context-switch out of their current task. For anything longer than that, we suggest putting a timeframe on what you want to talk about (can we chat for ~30mins about X when youre free?).
Interruptions still happen, of course. When one does, we suggest letting the person know upfront that youre concentrating on something, and asking them if its urgent. And if youre the person doing the interrupting, try not to get offended when you get asked if your needs are urgent.
Concrete floors are great for skateboarding; less great for acoustics. Extended conversations around the desks can break the concentration of everyone nearby. We often take discussions into small meeting rooms instead, or having them in HipChat so others can benefit from what was concluded afterwards.
These are not the Canva Commandments of How to be a Good Engineer, but rather just a list of principles that we have been applying consistently, and help to paint a picture of our engineering philosophy. We find this helps new people understand how decisions have been in the past (and how they continue to be made), and context for expectations when collaborating and code reviewing.
Its best to always have a clear understanding of the precise problem youre trying to solve, particularly in terms of a user story, and keep referring back to that precise problem. Try to avoid phrasing problems in ways that presuppose a solution. If you start a conversation with someone at Canva with how do I make X do Y?, theyll usually reply with what problem are you trying to solve?.
Of course, you may have already thought long and hard about how to solve the problem and youre asking advice on a specific part of the implementation. Nonetheless, its better to provide the context and rationale, giving yourself an opportunity to consider a different approach from your colleague.
Things move very quickly here. We try to aim for the smallest, simplest change that meets requirements, while keeping in mind what the bigger, better way would be if it becomes a priority. Our priorities change weekly, if not daily, so any task that takes more than a few days runs the risk of being wasted work.
Its never good to reinvent the wheel. Our default strategy for solving any problem, somewhat tongue-in-cheek, is to look for someone smart whos already solved it before and copy what they did. In particular, if theres already an overwhelming convention to solve a problem in a particular way, we err towards that convention. There are few problems that cant be solved quickly by judicious browsing of Stack Overflow. By having a solid understanding of the real problem youre trying to solve, you can use your judgement for whether theres reason to break the trend. When a trend does need to be broken, we say go for it.
Before thinking about how were going to build something, we try to be sure were building the right thing. We dont hesitate to change what were building in order to significantly simplify how it can be built, so long as it still solves the essential problem.
Sometimes, the initial conception of a feature can be pretty vague or internally inconsistent, and the details arent set in stone. We like to think we thrive on this ambiguity. Each engineer uses their understanding of the underlying business problem and customer need to massage each feature into something consistent, something that can be built quickly and simply, but something that is still faithful to the original vision.
Weve found that these practices and principles have been working well for our team at its current scale (16 engineers across our web client, ios client, and backends), but according to the rule of 3 and 10, were expecting them to evolve significantly as we grow. Well share an update with how were going once we reach a team of 30!team