What do engineers do all day?

By Sam Killin

Have you ever thought to yourself: “What do engineers actually do?”

If you have, you’re not alone. This is a question I get asked all the time and it makes sense since so much of what we do as engineers happens behind the scenes.

So I thought it would be valuable to talk about the day-to-day work of engineers. Each startup will have their own approach to how their engineering team works, but the core details will be similar.

This is how the Canva engineers work on a week-by-week basis, and how it really all drills down to one thing: collaboration.

Below is an extended metaphor to make engineering make sense to people who don’t code. If you’re an engineer and likely to be annoyed by some of the less-than-perfect elements of the example below, maybe stop reading now.

Imagine you and ten friends are writing a book.

This book is Canva’s code. These ten friends are Canva’s engineers.

Canva’s code — organised into folders (chapters) on the left

There’s a chapter for internationalisation, a chapter for Marketplace and a chapter for Canva for Work. There’s a few pages in the Canva for Work chapter about Magic Resize, next to a few pages about Brand Kits.

At the start of the week, you and your friends go away and write a few new pages to add to the book. At the end of the week, you all meet up at a cafe to show off all the cool new stuff you’ve written. In the middle of the table sits the shared copy of your book. This copy contains everyone’s writing up until now.

This shared copy is called the master branch of Canva. A branch is a version of our code. I can create a branch by taking a snapshot of everything in Canva at a certain point in time. I can then add a new feature to that branch of Canva, completely separate to what any other engineer is working on. When I’m in my own branch, I’m in my own little world.

A peek into the Master Branch of Canva, including some work by Harley, Jim, Mitchell and Damon.

You’re in the cafe and you sit down next to your friend Toby.

“Hey Toby… I’ve written some really cool stuff about fonts this week, do you think it should go in the book?”

He umms and ahhs for a while, suggests a few changes here and there but eventually nods. “Yeah mate. Looks good to me.”

This is a Pull Request, or PR. A PR lets me tell another engineer that I’ve built something new, and that I want to add that new stuff onto the shared master branch.

That second engineer does a code review on my PR, to make sure that the new code does what it says it will, and that it doesn’t break any other features. If the reviewer is happy with my code, they send me a message saying “LGTM” (which stands for Looks Good To Me). This is permission to add my feature into the master branch.

An example of a PR. I’m asking Toby if I can add some code to launch Canva in Indonesian.

You lean into the middle of the table to slide your new pages into the master copy of the book, but… oh no! A hand darts across the table and bumps yours out of the way. Pat’s been writing about fonts this week and also wants to add his work to the same chapter. If you both cram your new pages into the book at the same time, the story might not make any sense.

You take a look at Pat’s new pages, make a few changes to your work so that the story still makes sense, and then add both of your work to the master copy in the middle of the table.

Merging. Before we add our code to the master branch, we run it through some software tools that tell us if our work clashes with anything that another engineer has been building at the same time. These tools tell us exactly which part of our code clashes, and with whom, and won’t let us add code to master until we’ve fixed the issues raised.

Once everyone has finished adding their new pages, we take the book and put it up on a shelf for the world to read. Every week a few new pages are added, and the story keeps growing.

This is the release. Every Monday we take a snapshot of what is on the master branch at that point in time, and this is what gets launched to the public.

Ok. Yes. The analogy is a bit of a stretch, but this sums up the process that the engineering team follows in order to collaborate with each other.

So to sum up, what does an engineer actually do in an average week? Well, you can be pretty sure it will look something like this:

  1. Checking out other engineer’s code on master
  2. Creating a branch for a new feature
  3. Have the code reviewed in a PR when you’re done
  4. Merge your branch onto master
  5. Release your new feature to the world