This story looks at the opportunity Dev Degree gave me, the challenges I overcame, and the weaknesses that turned out to be strengths. If you’re thinking about a career in tech, but don’t think you have the stuff for it, this story is for you. 

Continue reading

Good documentation has many benefits, but first and foremost it boosts engineers’ productivity. Here are a few tips to encourage a strong writing culture.

Continue reading

It’s been around two and a half years since Shopify became a fully remote-first company. James Stanier shares three big learnings that are essential to succeeding remotely.

Continue reading

What do you do with a finite amount of time to deal with an infinite number of things that can go wrong? This post breaks down a high-level risk mitigation process into four questions that can be applied to nearly any scenario in order to help you make the best use of your time and resources available.

Continue reading

A few tips to make asynchronous communication across time zones a positive experience

Continue reading

If you see something wrong in a codebase or architecture, and you don’t say something, you will suffer the consequences. Jack teaches how to give feedback that matters to get positive results.

Continue reading

Pair programming is one of the most important tools we use while mentoring early talent in the Dev Degree program. It’s an agile software development technique where two people work together, either to share context, solve a problem, or learn from one another. Pairing builds technical and communication skills, encourages curiosity and creative problem-solving, and brings people closer together as teammates.

In my role as a Technical Educator, I’m focused on setting new interns joining the Dev Degree program up for success in their first 8 months at Shopify. Because pair programming is a method we use so frequently in onboarding, I saw an opportunity to streamline the process to make it more approachable for people who might not have experienced it before. I developed this framework during a live workshop I hosted at RenderATL. I hope it helps you structure your next pair programming session!

Pair Programming in Dev Degree

“Pair programming was my favorite weekly activity while on the Training Path. When I first joined my team, I was constantly pairing with my teammates. My experiences on the Training Path made these new situations manageable and incredibly fun! It was also a great way to socialize and work technically with peers outside of my school cohort that I wouldn't talk to often. I've made some good friends just working on a little project for the weekly module.” - Mikail Karimi, Dev Degree Intern

In the Dev Degree program, we use mentorship to build up the interns’ technical and soft skills. As interns are usually early in their career journey, having recently graduated from high school or switched careers, their needs differ from someone with more career experience. Mentorship from experienced developers is crucial to prepare interns for their first development team placement. It shortens the time it takes to start making a positive impact with their work by developing their technical and soft skills like problem solving and communication. This is especially important now that Shopify is digital by design, as learning and working remotely is a completely new experience to many interns. 

All first year Dev Degree interns at Shopify go through an eight-month period known as the Training Path. During this period, we deliver a set of courses designed to teach them all about Shopify-specific development. They’re mentored by Student Success Specialists, who coach them on building their soft skills like communication, and Technical Instructors , who focus on the technical aspects of the training. Pair programming with a peer or mentor is a great way to support both of these areas of development.

Each week, we allocate two to three hours for interns to pair program with each other on a problem. We don’t expect them to solve the problem completely, but they should use the concepts they learned from the week to hone their technical craft.

We also set up a bi-weekly 30 minute pair programming sessions with each intern. The purpose of these sessions is to provide dedicated one-on-one time to learn and work directly with an instructor. They can share what they are having trouble with, and we help them work through it.

“When I’m switching teams and disciplines, pair programming with my new team is extremely helpful to see what resources people use to debug, the internal tools they use to find information and how they approach a problem. On my current placement, I got better at resolving problems independently when I saw how my mentor handled a new problem neither of us had seen.” Sanaa Syed, Dev Degree Intern

As we scale up the program, there are some important questions I keep returning to:

• How do we track their progress most effectively?
• How do we know what they want to pair on each day?
• How can we provide a safe space?
• What are some best practices for communicating?

I started working on a framework to help solve these issues. I know I’m not the only one on my team who may be asking themselves this. Along the way, an opportunity arose to do a workshop at RenderATL. At Shopify, we are encouraged to learn as part of our professional development. Wanting to level up my public speaking skills, I decided to talk about mentorship through a pair programming lens. As the framework was nearly completed, I decided to crowdsource and finish the framework together with the RenderATL attendees.

Crowdsourcing a Framework for All

On June 1st, 2022, Shopify hosted free all-day workshops at RenderATL called Heavy Hitting React at Shopify Engineering. It contained five different workshops, covering a range of topics from specific technical skills like React Native to broader skills like communication. We received a lot of positive feedback, met many amazing folks, and made sure those who attended gained new knowledge or skills they could walk away with.

For my workshop, Let’s Pair Program a Framework Together, we pair programmed a pair programming framework. The goal was to crowdsource and finish the pair programming framework I was working on based on the questions I mentioned above. We had over 30 attendees, and the session was structured to be interactive. I walked the audience through the framework and got their suggestions on the unfinished parts of the framework. At the end, the attendees paired up and used the framework to work together and draw a picture they both wanted to draw.

Before the workshop, I sent a survey internally asking developers a few questions about pair programming. Here are the results:

• 62.5% had over 10 years of programming experience
• 78.1% had pair programmed before joining Shopify
• 50% of the surveyor pair once or twice a week at Shopify

When asked “What is one important trait to have when pair programming?”, this is what Shopify developers had to say:

Communication

• Expressing thought processes (what you’re doing, why you’re making this change, etc.)
• Sharing context to help others get a thorough understanding
• Use of visual aids to assist with explanation

Empathy

• Being aware of energy levels
• Not being judgemental to others

Open-mindedness

• Curious to learn
• Willingness to take feedback and improve
• Don’t adhere to just one’s opinion

Patience

• Providing time to allow your partner to think and formulate opinions
• Encourage repetition of steps, instructions to encourage question asking and learn by doing

Now, let’s walk through the crowdsourced framework we finished at RenderATL.

Note: For those who attended the workshop, the framework below is the same framework that you walked away with, but with more details and resources.

The Framework

Pair programming can be used for more than just writing code. Try pairing on other problems and using tools like a whiteboard to work through ideas together.

This framework covers everything you need to run a successful pair programming session, including: roles, structure, agenda, environment, and communication. You can pick and choose within each section to design your session based on your needs.

1a. Pair Programming Styles

There are many different ways to run a pair programming session. Here are the ones we found to be the most useful, and when you may want to use each depending on your preferences and goals.

Driver and Navigator

Think about this style like a long road trip. One person is focused on driving to get from point A to B. While the other person is providing directions, looking for future pit stops for breaks, and just observing the surroundings. As driving can be taxing, it’s a good idea to switch roles frequently.

The driver is the person leading the session and typing on the keyboard. As they are typing, they’re explaining their thought process. The navigator, also known as the observer, is the person observing, reviewing code that’s being written, and making suggestions along the way. For example, suggesting refactoring code and thinking about potential edge cases.

If you’re an experienced person pairing with an intern or junior developer, I recommend using this style after you paired together a few sessions. They’re likely still gaining context and getting comfortable with the code base in the first few sessions.

Tour Guide

This style is like giving someone a personal tour of the city. The experienced person drives most of the session, hence the title tour guide. While the partner is just observing and asking questions along the way.

I suggest using this style when working with someone new on your team. It’s a great way to give them a personal tour to how your team’s application works and share context along the way. You can also flip it, where the least experienced person is the tour guide. I like to do this with the Dev Degree interns who are a bit further into their training when I pair with them. I find it helps bring out their communication skills once they’ve started to gain some confidence in their technical abilities.

Unstructured

The unstructured style is more of a freestyle way to work on something together, like learning a new language or concept. The benefit of the unstructured style is the team building and creative solutions that can come from two people hacking away and figuring things out. This is useful when a junior developer or intern pairs with someone at their level. The only downside is that without a mentor overseeing them, there’s a risk of missteps or bad habits going unchecked. This can be solved after the session by having them share their findings with a mentor for discussion.

We allocated time for the interns to pair together. This is the style the interns typically go with, figuring things out using the concepts they learned.

1b. Activities

When people think of pair programming, they often strictly think of coding. But pair programming can be effective for a range of activities. Here are some we suggest.

Code Reviews

I remember when I first started reviewing code, I wasn’t sure what exactly I was meant to be looking for. Having an experienced mentor support with code reviews helps early talent pick up context and catch things that they might not otherwise know to look for. Interns also bring a fresh perspective, which can benefit mentors as well by prompting them to unpack why they might make certain decisions.

Technical Design and Documentation

Working together to design a new feature or go through team documents. If you put yourself in a junior developer’s shoes, what would that look like? It could look like a whiteboarding session mapping out logic for the new feature or improving the team’s onboarding documentation. This could be an incredibly impactful session for them. You’ll be helping broaden their technical depth, helping future teammates onboard faster, and sharing your expertise along the way.

Writing Test Cases Only

Imagine you’re a junior developer working on your very first task. You have finished writing the functionality, but haven’t written any tests for it. You tested it manually and know it works. One thing you’re trying to figure out is how to write a test for it now. This is where a pair programming session with an experienced developer is beneficial. You work together to extend testing coverage and learn team-specific styles when writing tests.

Onboarding

Pairing is a great way to help onboard someone new onto your team. It helps the new person joining your team ramp up quicker with your wealth of knowledge. Together you explore the codebase, documentation, and team-specific rituals.

Hunting Bugs

Put yourselves in your users’ shoes and go on a bug hunt together. As you test functionalities on production, you'll gain context on the product and reduce the number of bugs on your application. A win-win!

2. Set an Agenda

Setting an agenda beforehand is key to making sure your session is successful.

Before the session, work with your partner to align on the style, activity, and goals for your pair programming session. This way you can hit the ground running while pairing and work together to achieve a common goal. Here are some questions you can use to set your agenda: 

• What do you want to pair on today?
• How do you want the session to go? You drive? I drive? Or both?
• Where should we be by the end of the session?
• Is there a specific skill you want to work on?
• What’s blocking you?

3. Set the Rules of Engagement

 

"After years of frequent pair programming, my teammates and I have established patterns that give the impression that we are always right next to each other, which makes context sharing and learning from peers much simpler." -Olakitan Bello, Developer

Now that your agenda is set, it’s time to think about the environment you want to have during the session. Imagine yourself as a teacher. If this was a classroom, how would you provide the best learning environment?

Be Inclusive

Everyone should feel welcomed and invited to collaborate with others. One way we can set the tone is to establish that “There are no wrong answers here” or “There are no dumb questions.” If you’re a senior colleague, saying “I don’t know” to your partner is a very powerful thing. It shows that you’re a human too! Keep accessibility in mind as well. There are tools and styles available to tailor pair programming sessions to the needs of you and your partner. For example, there are alternatives to verbal communication, like using a digital whiteboard or even sending messages over a communication platform. Invite people to be open about how they work best and support each other to create the right environment.

Remember That Silence Isn’t Always Golden

If it gets very quiet as you’re pairing together, it’s usually not a good sign. When you pair program with someone, communication is very important to both parties. Without it, it’s hard for one person to perceive the other person’s thoughts and feelings. Make a habit of explaining your thought process out loud as you work. If you need a moment to gather your thoughts, simply let your partner know instead of going silent on them without explanation.

Respect Each Other

Treat them like how you want to be treated, and value all opinions. Someone's opinions can help lead to an even greater solution. Everyone should be able to contribute and express their opinions.

Be Empathic Not Apathetic

If you’re pair programming remotely, displaying empathy goes a long way. As you’re pair programming with them, read the room. Do they feel flustered with you driving too fast? Are you aware of their emotional needs at the moment?

As you’re working together, listen attentively and provide them space to contribute and formulate opinions.

Mistakes Are Learning Opportunities

If you made a mistake while pair programming, don’t be embarrassed about it. Mistakes happen, and are actually opportunities to learn. If you notice your partner make a mistake, point it out politely—no need to make a big deal of it.

4. Communicate Well

Pair programming is all about communication. For two people to work together to build something, both need to be on the same page. Remote work can introduce unique communication challenges, since you don’t have the benefit of things like body language or gestures that come with being in the same physical room. Fortunately, there’s great tooling available, like Tuple, to solve these challenges and even enhance the pair programming experience. It’s a MacOS only application which allows people to pair program with each other remotely. Users can share their screen and either can take control to drive. The best part is that it’s a seamless experience without any additional UI taking up space on your screen.

During your session, use these tips to make sure you’re communicating with intention. 

Use Open-ended Questions

Open-ended questions lead to longer dialogues and provide a moment for someone to think critically. Even if they don’t know, it lets them learn something new that they will take away from the session. With closed questions, it’s usually a “yes” or a “no” only. Let’s say we’re working together on building a grouped React component of buttons, which one sounds more inviting for a discussion:

• Is ButtonGroup a good name for the component? (Close-ended question)
• What do you think of the name ButtonGroup? (Open-ended question)

Other examples of open-ended questions:

• What are some approaches you took to solving this issue?
• Before we try this approach, what do you think will happen?
• What do you think this block of code is doing?

Give Positive Affirmations

Encouragement goes a long way, especially when folks are finding their footing early in their career. After all, knowing what’s gone right can be just as important as knowing what’s gone wrong. Throughout the session, pause and celebrate progress by noting when you see your partner do something well.

For example, you and your partner are building a new endpoint that’s part of a new feature your team is implementing. Instead of waiting until the feature is released, celebrate the small win.

Here are a few example messages you can give:

• It looks like we marked everything off the agenda. Awesome session today.
• Great work on catching the error. This is why I love pair programming because we work together as a team.
• Huge win today! The PR we worked together is going to help not only our team, but others as well.

Communication Pitfalls to Avoid

No matter how it was intended, a rude or condescending comment made in passing can throw off the vibe of a pair programming session and quickly erode trust between partners. Remember that programming in front of someone can be a vulnerable experience, especially for someone just starting out. While it might seem obvious, we all need a reminder sometimes to be mindful of what we say. Here are some things to watch out for.

Passive-Aggressive (Or Just-Plain-Aggressive) Comments

Passive-aggressive behavior is when someone expresses anger or negative feelings in an indirect way. If you’re feeling frustrated during a session, avoid slipping into this behavior. Instead, communicate your feelings directly in a constructive way. When negative feelings are expressed in a hostile or outwardly rude way, this is aggressive behavior and should be avoided completely. 

Passive-aggressive behavior examples:

• Giving your partner the silent treatment
• Eye-rolling or sighing in frustration when your partner makes a mistake
• Sarcastic comments like “Could you possibly code any slower?” 
• Subtle digs like “Well…that’s an interesting idea.”

Aggressive behavior examples

• “Typical intern mistake, rookie.”
• “This is NOT how someone at your level should be working.”
• “I thought you knew how to do this.”

Absolute Words Like Always and Never

Absolute words means you are 100 percent certain. In oral communication, depending on the use of the absolute word, it can sound condescending. Programming is also a world full of nuance, so overgeneralizing solutions as right or wrong is often misleading. Instead, use these scenarios as a teaching opportunity. If something is usually true, explain the scenarios where there might be exceptions. If a solution rarely works, explain when it might. Edge cases can open some really interesting and valuable conversations.

For example:

• “You never write perfect code”
• “I always review code”
• “That would never work”

Use alternative terms instead:

• For always, you can use usually
• For never, you can use rarely

“When you join Shopify, I think it's overwhelming given the amount of resources to explore even for experienced people. Pair programming is the best way to gain context and learn. In this digital by design world, pair programming really helped me to connect with team members and gain context and learn how things work here in Shopify which helped me with faster onboarding.” -Nikita Acharya, Developer

I want to thank everyone at RenderATL who helped me finish this pair programming framework. If you’re early on in your career as a developer, pair programming is a great way to get to know your teammates and build your skills. And if you’re an experienced developer, I hope you’ll consider mentoring newer developers using pair programming. Either way, this framework should give you a starting point to give it a try.

In the pilot we’ve run so far with this framework, we’ve received positive feedback from our interns about how it allowed them to achieve their learning goals in a flexible format. We’re still experimenting and iterating with it, so we’d love to hear your feedback if you give it a try! Happy pairing!

---

Wherever you are, your next journey starts here! If building systems from the ground up to solve real-world problems interests you, our Engineering blog has stories about other challenges we have encountered. Intrigued? Visit our Engineering career page to find out about our open positions and learn about Digital by Design.

Continue reading

When we understand each other’s cultural context, the emphasis in code reviews can shift from confrontation to collaboration.

Continue reading

Here's what’s on my mind as a technical leader: How do I gain the credibility of the smart people on my team who are far more technical and detailed than I am, in order to lead them?

Continue reading

Ebun breaks down how she used a not-so-great performance review to set clear development goals for herself and increase alignment with her lead, ultimately leading to a successful next review.

Continue reading

The interview process can be one of the most daunting aspects of finding a new gig—but it doesn’t have to be. This guide pulls back the curtain on what to expect during the interview process for technical roles at Shopify and sets you up for success with tips for each stage.

Continue reading

I had been in the same engineering org for seven years before the pandemic hit. We were a highly collaborative and co-located company and the team were very used to brainstorming and working on physical whiteboards and workspaces. When it did, we moved pretty seamlessly from working together from our office to working from our homes. We didn’t pay too much attention to designing a Digital First culture and neither did we alter our ways of working dramatically. 

It was only when I joined Shopify last September that I began to realize that working remotely in a company where you have already established trust is very different from starting in a fully remote space and building trust from the ground up. 

What Is Different About Starting Remotely?

So, what changes? The one word that comes to mind is intentionality. I would define intentionality as “the act of thoughtfully designing interactions or processes.” A lot of things that happen seamlessly and organically in a real-life setting takes more intentionality in a remote setting. If you deconstruct the process of building trust, you’ll find that in a physical setting trust is built in active ways (words you speak, your actions, and your expertise), but also in passive ways (your body language, demeanor, and casual water cooler talk). In a remote setting, it’s much more difficult to observe, but also build casual, non-transactional relationships with people unless you’re intentional about it. 

Also, since you’re represented a lot more through your active voice, it’s important to work on setting up a new way of working and gaining mastery over the set of tools and skills that will help build trust and create success in your new environment.

The 90-Day Plan

The 90-Day Plan is named after the famous book The First 90 Days written by Michael D. Watkins. Essentially, it breaks down your onboarding journey into three steps:

1. First 30 days: focus on your environment
2. First 60 days: focus on your team
3. 90 days and beyond: focus on yourself.

First 30 Days: Focus on Your Environment

Take the time out to think about what kind of workplace you want to create and also to reach out and understand the tone of the wider organization that you are part of.

Study the Building 

When you start a new job in a physical location, it’s common to study the office and understand the layout of, not only the building, but also  the company itself. When beginning work remotely, I suggest you start with a metaphorical study of the building. Try and understand the wider context of the organization and the people in it. You can do this with a mix of pairing sessions, one-on-ones, and peer group sessions. These processes help you in gaining technical and organizational context and also build relationships with peers. 

Set Up the Right Tools

In an office, many details of workplace setup are abstracted away from you. In a fully digital environment, you need to pay attention to set your workplace up for success. There are plenty of materials available on how to set up your home office (like on lifehack.org and nextplane.net). Ensure that you take the time to set up your remote tools to your taste. 

Build Relationships 

If you’re remote, it’s easy to be transactional with people outside of your immediate organization. However, it’s much more fun and rewarding to take the time to build relationships with people from different backgrounds across the company. It gives you a wider context of what the company is doing and the different challenges and opportunities.

First 60 Days: Focus on Your Team

Use asynchronous communication for productivity and synchronous for connection.

Establish Connection and Trust

When you start leading a remote team, the first thing to do is establish connection and trust. You do this by spending a lot of your time in the initial days meeting your team members and understanding their aspirations and expectations. You should also, if possible, attempt to meet the team once in real life within a few months of starting. 

Meet in Real Life

Meeting in real life will help you form deep human relationships and understand them beyond the limited scope of workplace transactions. Once you’ve done this, ensure that you create a mix of synchronous and asynchronous processes within your time. Examples of asynchronous processes are automated dailies, code reviews, receiving feedback, and collaboration on technical design documents. We use synchronous meetings for team retros, coffee sessions, demos, and planning sessions. We try to maximize async productivity and being intentional about the times that you do come together as a team.

Establishing Psychological Safety

The important thing about leading a team remotely is to firmly establish a strong culture of psychological safety. Psychological safety in the workplace is important, not only for teams to feel engaged, but also for members to thrive. While it might be trickier to establish psychological safety remotely, it’s definitely possible. Some of the ways to do it:

1. Default to open communication wherever possible.
2. Engage people to speak about issues openly during retros and all-hands meetings.
3. Be transparent about things that have not worked well for you. Setting this example will help people open themselves up to be vulnerable with their teams.

First 90 Days - Focus on Yourself

How do you manage and moderate your own emotions as you find your way in a new organization with this new way of working?

FOMO Is Real

Starting in a new place is nerve wracking. Starting while fully remote can be a lonely exercise. Working in a global company like Shopify means that you need to get used to the fact that work is always happening in some part of the globe. It’s easy to get overwhelmed and be always on. While FOMO can be very real, be aware of all the new information that you’re ingesting and take the time to reflect upon it.

Design Your Workday

Remote work means you’re not chained to your nine-to-five routine anymore. Reflect on the possibilities this offers you and think about how you want to design your workday. Maybe you want meeting free times to walk the dog, hit the gym, or take a power nap. Ensure you think about how to structure the day in a way that suits your life and plan your agenda accordingly.

Try New Things

It’s pretty intense in the first few months as you try ways to establish trust and build a strong team together. Not everything you try will take and not everything will work. The important thing is to be clear with what you’re setting out to achieve, collect feedback on what works and doesn’t, learn from the experience, and move forward.

Being able to work in a remote work environment is both rewarding and fun. It’s definitely a new superpower that, if used well, leads to rich and absorbing experiences. The first 90 days are just the beginning of this journey. Sit back, tighten your seatbelt and get ready for a joyride of learning and growth.

---

Wherever you are, your next journey starts here! If building systems from the ground up to solve real-world problems interests you, our Engineering blog has stories about other challenges we have encountered. Intrigued? Visit our Engineering career page to find out about our open positions and learn about Digital by Design.

Continue reading

What’s it really like for new engineering leaders at Shopify? I asked Avanti Ketkar and Maria Robledo, who both joined the team this past year, to spill the tea about their first few months. They share their perspectives on how the onboarding experience helped them build context, relationships, and trust.

Continue reading

The Rails community gathered in Portland for the first in-person RailsConf in two years. Shopify developers recap a few highlights from the three-day event.

Continue reading

In March 2020—the early days of the pandemic—Shopify transitioned to become a remote first- company. We call it being Digital by Design. We are now proud to employ Shopifolk around the world.

Not only has being Digital by Design allowed our staff the flexibility to work from wherever they work best, it has also increased the amount of time that they are able to spend with their families, friends, or social circles. In the pre-remote world, many of us had to move far away from our hometowns in order to get ahead in our careers. However, recently, my own family has been negotiating with the reality of aging parents, and remote working has allowed us to move back closer to home so we are always there for them whilst still doing the jobs we love.

However, being remote isn’t without its challenges. Much of the technology industry has spent decades working in colocated office space. This has formed habits in all of us that aren’t compatible with effective remote work. We’re now on a journey of mindfully unraveling these default behaviors and replacing them with remote-focused ways of working.

If you’ve worked in an office before, you’ll be familiar with synchronous communication and how it forms strong bonds between colleagues: a brief chat in the kitchen whilst getting a coffee, a discussion at your desk that was prompted by a recent code change, or a conversation over lunch.

With the layout of physical office spaces encouraging spontaneous interactions, context could be gathered and shared through osmosis with little specific effort—it just happened.

There are many challenges that you face in engineering when working on a globally distributed team. Not everyone is online at the same time of the day, meaning that it can be harder to get immediate answers to questions. You might not even know who to ask when you can’t stick your head up and look around to see who is at their desks. You may worry about ensuring that the architectural direction that you’re about to take in the codebase is the right one when building for the long term—how can you decide when you’re sitting at home on your own?

Teams have had to shift to using a different toolbox of skills now that everyone is remote. One such skill is the shift to more asynchronous communication: an essential glue that holds a distributed workforce together. It’s inclusive of teams in different time zones, it leaves an audit trail of communication and decision making, encourages us to communicate concisely, and enables everybody the same window into the company, regardless of where they are in the world.

However, an unstructured approach can be challenging, especially when teams are working on establishing their communication norms. It helps to have a model with which to reason about how best to communicate for a given purpose and to understand what side-effects of that communication might be.

The Spectrum of Synchronousness

When working remotely, we have to adapt to a different landscape. The increased flexibility of working hours, the ability to find flow and do deep work, and the fact that our colleagues are in different places means we can’t rely on the synchronous, impromptu interactions of the office anymore. We have to navigate a continuum of communication choices between synchronous and asynchronous, choosing the right way to communicate for the right group at the right time.

It’s possible to represent different types of communication on a spectrum, as seen in the diagram below.

Let’s walk the spectrum from left to right—from synchronous to asynchronous—to understand the kinds of choices that we need to make when communicating in a remote environment.

• Video calls and pair programming are completely synchronous: all participants need to be online at the same time.
• Chats are written and can be read later, but due to their temporal nature have a short half-life. Usually there’s an expectation that they’ll be read or replied to fairly quickly, else they’re gone.
• Recorded video is more asynchronous, however they’re typically used as a way of broadcasting some information or complimenting a longer document, and their relevance can fade rapidly.
• Email is archival and permanent and is typically used for important communication. People may take many days to reply or not reply at all.
• Written documents are used for technical designs, in-depth analysis, or cornerstones of projects. They may be read many years after they were written but need to be maintained and often represent a snapshot in time.
• Wikis and READMEs are completely asynchronous, and if well-maintained, can last and be useful forever.

Shifting to Asynchronous

When being Digital by Design, we have to be intentionally more asynchronous. It’s a big relearning of how to work collaboratively. In offices, we could get by synchronously, but there was a catch: colleagues at home, on vacation, or in different offices would have no idea what was going on. Now we’re all in that position, we have to adapt in order to harness all of the benefits of working with a global workforce.

By treating everyone as remote, we typically write as a primary form of communication so that all employees can have access to the same information wherever they are. We replace meetings with asynchronous interactions where possible so that staff have more flexibility over their time. We record and rebroadcast town halls so that staff in other timezones can experience the feeling of watching them together. We document our decisions so that others can understand the archeology of codebases and projects. We put effort into editing and maintaining our company-wide documentation in all departments, so that all employees have the same source of truth about teams, the organization chart, and projects.

This shift is challenging, but it’s worthwhile: effective asynchronous collaboration is how engineers solve hard problems for our merchants at scale, collaborating as part of a global team. Whiteboarding sessions have been replaced with the creation of collaborative documents in tools such as Miro. In-person Town Halls have been replaced with live streamed events that are rebroadcast on different time zones with commentary and interactions taking place in Slack. The information that we all have in our heads has needed to be written, recorded, and documented. Even with all of the tools provided, it requires a total mindset shift to use them effectively.

We’re continually investing in our developer tools and build systems to enable our engineers to contribute to our codebases and ship to production any time, no matter where they are. We’re also investing in internal learning resources and courses so that new hires can autonomously level up their skills and understand how we ship software. We have regular broadcasts of show and tell and demo sessions so that we can all gather context on what our colleagues are building around the world. And most importantly, we take time to write regular project and mission updates so that everyone in the company can feel the pulse of the organization.

Asynchronous communication is the great leveler: it connects everyone together and treats everyone equally.

Permanence in Engineering

In addition to giving each employee the same window into our culture, asynchronous communication also has the benefit of producing permanent artifacts. These could be written documents, pull requests, emails, or videos. As per our diagram, the more asynchronous the communication, the more permanent the artifact. Therefore, shifting to asynchronous communication means that not only are teams able to be effective remotely, but they also produce archives and audit trails for their work.

The whole of Shopify uses a single source of truth—an internal archive of information called the Vault. Here, Shopifolk can find all of the information that they need to get their work done: information on teams, projects, the latest news and video streams, internal podcasts and blog posts. Engineers can quickly find architecture diagrams and design documents for active projects.

When writing design documents for major changes to the codebase, a team produces an archive of their decisions and actions through time. By producing written updates to projects every week, anyone in the company can capture the current context and where it has been derived from. By recording team meetings and making detailed minutes, those that were unable to attend can catch up later on-demand. A shift to asynchronous communication means a shift to implied shift to permanence of communication, which is beneficial for discovery[g][h][i], reflection and understanding.

For example, when designing new features and architecture, we collaborate asynchronously on design documents via GitHub. New designs are raised as issues in our technical designs repository, which means that all significant changes to our codebase are reviewed, ratified and archived publicly. This mirrors how global collaboration works on the open source projects we know and love. Working so visibly can be intimidating for those that haven’t done it before, so we ensure that we mentor and pair with those that are doing it for the first time.

Establishing Norms and Boundaries

Yet, multiple mediums of communication incur many choices in how to use them effectively. When you have the option to communicate via chat, email, collaborative document or GitHub issue, picking the right one can become overwhelming and frustrating. Therefore we encourage our teams to establish their preferred norms and to write them down. For example:

• What are the response time expectations within a team for chat versus email?
• How are online working hours clearly discoverable for each team member?
• How is consensus reached on important decisions?
• Is a synchronous meeting ever necessary?
• What is the correct etiquette for “raising your hand” in video calls?
• Where are design documents stored so they’re easily accessible in the future?

By agreeing upon the right medium to use for given situations, teams can work out what’s right for them in a way that supports flexibility, autonomy, and clarity. If you’ve never done this in your team, give it a go. You’ll be surprised how much easier it makes your day to day work.

The norms that our teams define bridge both synchronous and asynchronous expectations. At Shopify, my team members ensure that they make the most of the windows of overlap that they have each day, setting aside time to be interruptible for pair programming, impromptu chats and meetings, and collaborative design sessions. Conversely, the times of the day when teams have less overlap are equally important. Individuals are encouraged to block out time in the calendar, turn on their “do not disturb” status, and find the space and time to get into a flow state and be productive

A natural extension of the communication norms cover when writing and shipping code. Given that our global distribution of staff can potentially incur delays when it comes to reviewing, merging, and deploying, teams are encouraged to explore and define how they reach alignment and get things shipped. This can happen by raising the priority of reviewing pull requests created in other timezones first thing in the morning before getting on with your own work, through to finding additional engineers that may be external to the team but on the same timezone to lean in and offer support, review, and pairing.

Maintaining Connectivity

Once you get more comfortable with working ever more asynchronously, it can be tempting to want to make everything asynchronous: stand-ups on Slack, planning in Miro, all without needing anyone to be on a video call at all. However, if we look back at the diagram one more time, we’ll see that there’s an important third category: connectivity. Humans are social beings, and feeling connected to other, real humans—not just avatars—is critical to our wellbeing. This means that when shifting to asynchronous work we also need to ensure that we maintain that connection. Sometimes having a synchronous meeting can be a great thing, even if it’s less efficient—the ability to see other faces, and to chat, can’t be taken for granted.

We actively work to ensure that we remain connected to each other at Shopify. Pair programming is a core part of our engineering culture, and we love using Tuple to solve problems collaboratively, share context about our codebases, and provide an environment to help hundreds of new engineers onboard and gain confidence working together with us.

We also strongly advocate for plenty of time to get together and have fun. And no, I’m not talking about generic, awkward corporate fun. I’m talking about hanging out with colleagues and throwing things at them in our very own video game: Shopify Party (our internal virtual world for employees to play games or meet up). I’m talking about your team spending Friday afternoon playing board games together remotely. And most importantly, I’m talking about at least twice a year, we encourage teams to come together in spaces we’ve invested in around the world for meaningful and intentional moments for brainstorming, team building, planning, and establishing connections offline.

Asynchronous brings efficiency, and synchronous brings connectivity. We’ve got both covered at Shopify.

---

Wherever you are, your next journey starts here! If building systems from the ground up to solve real-world problems interests you, our Engineering blog has stories about other challenges we have encountered. Intrigued? Visit our Engineering career page to find out about our open positions and learn about Digital by Design.

Continue reading

We asked our tech talent which podcasts they’re tuning into and curated a list of their favorites. Whether you’re in the mood for something quick and informative, or witty and conversational, we think you’ll find something on this list you’ll enjoy.

Continue reading

How we think, absorb information, and maximize time—these are the topics Shopify developers and engineers are reading up on.

We have a book bar of the company’s favorite reads and make sure any employee who wants a copy of any title can get one. So we thought we’d flip the script and ask 10 of our technical minds to tell us the books they think everyone in tech should read this year.

Many of their choices were timeless, suggesting a clear desire to level up beyond hard skills. There are a couple deep dives into software design and computing systems, but many of the titles on this reading list are guides for reframing personal habits and patterns: taking notes, receiving feedback, sharing knowledge, and staying focused amid myriad distractions.

The 5 Elements of Effective Thinking by Edward B. Burger and Michael Starbird

(Princeton University Press)

I’ve always followed the adage of “work smarter, not harder,” but in knowledge work, how do we “think smarter, not harder”? The 5 Elements of Effective Thinking presents an answer, packaged in a framework that’s applicable in work and life more broadly. The book is short and pithy. I keep it near my desk. The elements of the book include how to understand a topic, how to think about failure, how to generate good questions, and how to follow those questions. I won’t spoil the fifth element for you, you’ll have to read about it yourself!

Ash Furrow, Senior Staff Developer

How to Take Smart Notes by Sönke Ahrens

(Self-published)

Occasionally there are books that will totally flip how you think about doing something. How to Take Smart Notes is one of those. The title is about notes, but the book is about taking a totally different approach to learning and digesting information. Even if you choose not to follow the exact note taking technique it describes, the real value is in teaching you how to think about your own methods of absorbing and integrating new information. It’s completely changed the approach I take to studying nonfiction books.

Rose Wiegley, Staff Software Engineer

The Elements of Computing Systems: Building a Modern Computer from First Principles by Noam Nisan and Shimon Schocken

(The MIT Press)

Curious how tiny hardware chips become the computers we work on? I highly recommend The Elements of Computing Systems for any software developer wanting a more well-rounded understanding of a computer’s abstraction layers—not just at the level you’re most comfortable with, but even deeper. This workbook guides you through building your own computer from the ground up: hardware chip specifications, assembly language, programming language, and operating system. The authors did a great job of including the right amount of knowledge to not overwhelm readers. This book has given me a stronger foundation in computing systems while working at Shopify. Don’t like technical books? The authors also have lectures on Coursera available for free.

Maple Ong, Senior Developer

Living Documentation by Cyrille Martraire

(Addison-Wesley Professional)

Living Documentation isn’t so much about writing good documentation than about transmitting knowledge, which is the real purpose of documentation. In the tech world where the code is the source of truth, we often rely on direct interactions when sharing context, but this is a fragile process as knowledge can be diluted from one person to another and even lost when people leave a company. On the other side of the spectrum lies traditional documentation. It’s more perennial but requires significant effort to keep relevant, and that’s the main reason why documentation is the most overlooked task in the tech world. Living Documentation is an attempt at bridging the gap between these two extremes by applying development tools and methods to documentation in an incremental way, ensuring knowledge transmission in a 100-year company.

Frédéric Bonnet, Staff Developer

---

If building systems from the ground up to solve real-world problems interests you, our Engineering blog has stories about other challenges we have encountered. Visit our Engineering career page to find out about our open positions. Join our remote team and work (almost) anywhere. Learn about how we’re hiring to design the future together—a future that is digital by default.

Continue reading

An important component of being an engineer is getting hands-on experience in the real world, which internships can provide. This is especially true for engineering internships, which are critical for helping students develop real-life skills they can’t learn in the classroom. Sadly the internship market has suffered heavily since the pandemic with internship opportunities dropping by 52%, according to Glassdoor.

The silver lining is that many companies are now transitioning to incorporate virtual internships like we did. Whether you are a student, recent graduate, career switcher, bootcamp graduate, or another type of candidate, our virtual engineering internships are designed to kickstart your career and impact how entrepreneurs around the world do business.

What is it like to be a Shopify intern? During our latest intern satisfaction survey, 98% of respondents said they would recommend the program to friends. There are many opportunities to build your career, make an impact, and gain real-world experience at Shopify. But don’t just take our word for it! Keep reading to see what our interns had to say about their experience and learn how you can apply.

How to Get an Internship at Shopify

If you’re looking to jumpstart your personal growth and start an internship that can help lay the foundation for a successful career, we can help. Interning at Shopify allows you to work on real projects, solve hard problems, and gain practical feedback along the way. We provide the tools you need to succeed and trust you to take ownership and make great decisions. Here’s the steps to getting started.

Step 1: Review Available Opportunities

At Shopify, our engineering internships vary in length from three to eight months, with disciplines such as front-end and back-end development, infrastructure engineering, data engineering, mobile development, and more. Currently we run three intern application cycles a year. Applicants for the Fall 2022 cohort will be able to apply in May of 2022. Join our Shopify Early Talent Community, and we'll notify you. We also list available internships on our Early Careers page, these include a variety of three, four, and eight-month paid programs.

Step 2: Apply Online

Getting a Shopify engineering internship starts with an online application. We'll ask you for your resume, cover letter, contact information, education status, LinkedIn profile, and personal website. You will also be asked to complete an Intern Challenge to demonstrate your interest in the internship topic. This is a great place to show off your love for engineering. Perhaps you have your site using Ruby on Rails. We’d love to hear about it!

Step 3: Get Ready for the Skills Challenge

Depending on your specialization, you may be asked to submit a personal project like a GitHub link so that the recruiter can test your skills. Challenges differ by category, but you might be asked to design a Shopify store or to use a coding language like Python or Ruby on Rails to solve a problem. We want to see that you care about the subject, so be specific and put effort into your challenges to make your skills stand out.

Step 4: Prepare for the Interview Process

Shopify's interview process is divided into two phases. Our first stage allows us to get to know you better. Our conversation is called the Life Story, and it's a two-sided conversation that presents both your professional and personal experiences so far. Our second stage is used to assess your technical skills. A challenge will be presented to you, and you will be asked to propose a technical solution.

Top Skills for Engineering Interns

In a series of recent Twitter discussions from August and January, we asked about the most important skills for an engineering intern. More than 100 hiring managers, engineering professionals, and thought leaders responded. Here’s a summary of the skills they look for, along with how our very own interns have learned and applied them.

Collaboration

When you are working with a team, as most interns do, you need to be able to work together smoothly and effectively. Collaboration can encompass several characteristics, including communication, group brainstorming, emotional intelligence, and more. According to one follower on Twitter: “tech is a small part of software engineering, the valuable part is working well in teams.”

Our interns collaborate with talented people around the world. Emily Liu, a former intern and upcoming UX designer at Shopify, said the core team was spread out across five countries. The time differences didn’t hinder them from collaborating together to achieve a common goal. “Teamwork makes the dream work,” says Emily.

Lifelong Learning

Being a constant learner is one of Shopify's values and is considered a measure of success. As one Twitter follower pointed out, this is especially important in engineering since you should "always be willing to learn, to adapt, and to accept help" and that “even the most senior staff developer can learn something from an intern.”

This is echoed by former intern Andrea Herscovich, who says “if you are looking to intern at a company which values impact over everything, lifelong learning, and entrepreneurship, apply to Shopify!”

Curiosity

Without curiosity, an intern might become stagnant and not stay on top of the latest tools and technologies. Lack of curiosity can hinder an intern's career in engineering, where technological developments are rapid. In a response given by a hiring manager, curiosity is one of the key things he looks for among engineering interns, but says it's hard to find.

Andrea Herscovich also says she was encouraged to "be curious." This curiosity allowed her to build her own path for the internship. A particularly memorable project involved contributing to Polaris, Shopify's open-source design system, says Andrea. When working on adding a feature to a component in Polaris, Andrea learned how to develop for a more general audience.   

GitHub Experience

GitHub is an essential tool for collaborating with other developers in most engineering environments. As one Twitter user says: “I don't care if you got an A+ or C- in compilers; I'm going to look at your GitHub (or other public work) to see if you've been applying what you learned.” At Shopify, GitHub plays an important role in collaboration.

Using GitHub, former Shopify intern Kelly Ma says that her mentor provided a list of challenges instead of clearly-defined work for her to solve. During this time, Kelly had a chance to ask questions and learn more about the work of her team. As a result, she interacted with Shopifolk outside of her team and forged new relationships.

Remote Work Experience

A growing number of engineers are now working remotely. The trend is likely to continue well into the future due to COVID-19. As an intern, you will have the opportunity to gain experience working remotely, which can prepare you for the growing virtual workforce. Perhaps you're wondering if a remote internship can deliver the same experience as an in-person internship?

One former Shopify intern, Alex Montague, was anxious about how a remote internship would work. After completing the program, he told us, "working from home was pretty typical for a normal day at work" and that the tools he used made remote work easy, and he was "just as productive, if not more so, than if I was in the office." Alex is now a front-end developer on our App Developer Experience team, which provides insights and tools to help partners and merchants build and maintain apps.

Communication 

Today, communication is one of the most important skills engineers can have—and one that they sometimes lack. As one Twitter follower puts it: "nothing in CS you learn will be more important than how to communicate with humans." Fortunately, as an intern, you get the chance to improve on these skills even before you enter the workforce.

Meeting over Google Hangouts, pair programming on Tuple, brainstorming together on Figma, communicating through Slack, and discussing on GitHub are just a few ways that Shopify interns communicate, says Alex Montague. Interns can take advantage of these opportunities to develop core communication skills such as visual communication, written communication, and nonverbal communication.

Interviewing

“Practice interviewing. This is a skill,” one Twitter follower advises. Interviewing well is key to a successful internship search, and it can set you apart from other candidates. At Shopify, the interview process is divided into two different phases. We begin with a Life Story to learn more about you, what motivates you, and how we can help you grow. Our later rounds delve into your technical skills.

As part of his preparation for his Life Story internship interview, Elio Hasrouni noted all the crucial events in his life that have shaped who he is today, starting from his childhood. Among other things, he mentioned his first job, his first coding experience, and what led him into Software Engineering. Elio is now a full-time developer within our Retail and Applications division, which helps power our omnichannel commerce.

Accountability

Accountability involves taking responsibility for actions, decisions, and failures. For an engineering intern, accountability might mean accepting responsibility for your mistakes (and you’ll make plenty of them) and figuring out how to improve. Acknowledging your mistakes helps you demonstrate self-awareness that enables you to identify the problem, address it, and avoid repeating it.

How do you keep yourself accountable? Kelly Ma credits stretch goals, which are targets that are designed to be difficult to achieve, as a way to remain accountable. Other ways she keeps accountable include exploring new technological frontiers and taking on new challenges. One way that Shopify challenged her to be accountable was by asking her to own a project goal for an entire cycle (six weeks). This process included bringing stakeholders together via ad hoc meetings, updating GitHub issues to convey the state of the goal, and learning how to find the right context.

Tips to Help You Succeed

As you might expect, great internship opportunities like this are highly competitive. Applicants must stand out in order to increase their chances of being selected. In addition to the core skills discussed above, there are a few other things that can make you stand out from the crowd.

Practice Our Sample Intern Challenges

It is likely that we will ask you to participate in an Intern Challenge to showcase your skills and help us better understand your knowledge. To help you prepare, you can practice some of our current and previous intern challenges below.

• Backend Developer Intern Challenge
• Developer Intern Challenge Question
• UX Developer Intern & Web Developer Challenge

Showcase Your Past Projects

You don’t need prior experience to apply as a Shopify intern, but if you compile all your previous projects relevant to the position you're applying for, your profile will certainly stand out. Your portfolio is the perfect place to show us what you can do. 

Research the Company

It's a good idea to familiarize yourself with Shopify before applying. Take the time to learn about our product, values, mission, vision, and find a connection with them. In order to achieve success, our goals and values should align with your own. 

Additional Resources

Want to learn more about Shopify's Engineering intern program? Check out these posts:

• How We Enable Our Interns to Make an Impact
• Shopify Interns Share Their Tips for Success
• How We Support Intern Growth through Challenge and Practice

Want to learn more about the projects our interns work on? Check out these posts:

• A New Kubectl Plugin for Kubernetes Ingress Controller ingress-nginx
• How an Intern Released 3 Terabytes Worth of Storage Before BFCM
• Writing Better, Type-safe Code with Sorbet
• Iterating Towards a More Scalable Ingress
• Dynamic ProxySQL Query Rules

---

If building systems from the ground up to solve real-world problems interests you, our Engineering blog has stories about other challenges we have encountered. Visit our Engineering career page to find out about our open positions. Join our remote team and work (almost) anywhere. Learn about how we’re hiring to design the future together—a future that is digital by default.

Continue reading

Update (March 11, 2022): The reader survey is now closed. Thanks to all who provided feedback. Keep in touch with us on Twitter at @ShopifyEng.

 

Hello Shopify Engineering readers,

We’re conducting a survey so we can get a better sense of the stories you’re interested in reading. We want to learn more about you, your likes and dislikes, so we can create the best content possible, from deeply technical guides to pieces on developer culture.

The survey will take five minutes to complete. Your responses will be used for the purpose of improving our content and tailoring newsletters to better reflect your interests.*

Thank you for your feedback—and for reading!

Sincerely,

Anita Clarke
Senior Managing Editor

*Your responses will be analyzed in aggregate and used for research purposes; some aggregated data may be shared externally. Your data will be treated in accordance with Shopify’s privacy policy, which can be found here.

Continue reading

Shopify engineers not only work on challenging and impactful projects, but they also take the time to share their craft expertise at events and on the blog. As we close out the year, here are ten of our favorite posts of 2021, a curated selection spanning technologies and engineering disciplines, as well as a few from previous years that many of you still love, read, and share. 

While pulling this list together, the song My Favorite Things kept repeating in my mind. And with that, I apologize in advance for my cringeworthy poetic interpretation. It isn’t easy to rhyme with CRuby.

Building apps with and without Rails libraries
GraphQL how-tos not one but a series
Upgrading MySQL makes your heart sing
These are a few of your favorite things

Building a JIT compiler for CRuby
Making apps faster with caching is groovy
Hydrogen-powered storefronts give you wings
These are a few of your favorite things

1. How to Build a Web App With and Without Rails Libraries

Maple Ong, Senior Developer, wrote our most-read post of 2021, an in-depth tutorial that asks you to forget that Rails exists for a minute (whaaaat?!) and takes you on a journey to build a web application only using the standard Ruby libraries.

“With just a little bit of familiarity with the Rails framework, you’re able to build a web application—that’s the magic of Rails. Building your own Ruby web application from scratch, however, isn’t only educational—I’d argue that it’s also a rite of passage in a Ruby and Rails developer’s career!”

Want to learn more about Maple? Follow her on Twitter.

2. Building Blocks of High Performance Hydrogen-powered Storefronts

Shopify Unite created a lot of buzz around Hydrogen, a React-based framework for building custom and creative storefronts. Ilya Grigorik, Principal Engineer at Shopify, takes us behind the scenes and shares how Hydrogen is built and optimized to power personalized, contextual, and dynamic commerce.

Fun fact: Hydrogen is in developer preview in case you want to take it out for a spin.

3. YJIT: Building a New JIT Compiler for CRuby

Shopify engineers worked on many cool and impactful projects in 2021. Exhibit A: YJIT. Created by a small team led by Staff Engineer Maxime Chevalier-Boisvert, YJIT is a new JIT (just-in-time) compiler built inside CRuby that has now been merged upstream and is part of the Ruby 3.1.0 release. In this post, Maxime writes about the importance of the project to Shopify and Ruby developers worldwide.

For extra credit and additional reading, check out Noah Gibbs’ YJIT posts:

• Try Out YJIT for Faster Rubying
• GitHub Does My Operations Homework: A Ruby Speed Story

4. A Five-Step Guide for Conducting Exploratory Data Analysis

 

Cody Mazza-Anthony, Shopify Data Scientist, explains how to use exploratory data analysis (EDA) for answering important business questions and walks through five tips for performing an effective EDA. Here are the key takeaways:

• Missing values can plague your data
• Provide a basic description of your features and categorize them
• Understand your data by visualizing its distribution
• Your features have relationships! Make note of them
• Outliers can dampen your fun only if you don’t know about them

5. Upgrading MySQL at Shopify

Yi Qing Sim, Senior Production Engineer, shares how the Database Platform team performed the most recent MySQL upgrade at Shopify. She also discusses the roadblocks they encountered during rollback testing, the internal tooling built to aid in upgrading and scaling our fleet in general, and guidelines for approaching upgrades going forward.

6. Apache Beam for Search: Getting Started by Hacking Time

You might know Doug Turnbull, Senior Staff Engineer, for writing the book “Relevant Search”, contributing to “AI-Powered Search”, and creating relevance tooling for Solr and Elasticsearch like Splainer, Quepid, and the Elasticsearch Learning to Rank plugin. We also know him as the author of this excellent post about using Apache Beam for search at Shopify.

7. Understanding GraphQL for Beginners

OK, I might be cheating here because this is a three-part series, but it’s been a top read in 2021, prompting our team to refer to these tutorials as the “Everybody Loves Raymond” series. In this hands-on tutorial, Raymond Chung, Technical Educator on the Dev Degree team, teaches you all about GraphQL and digs into the difference between REST and GraphQL.

8. Keeping Developers Happy with a Fast CI

Christian Bruckmayer, Senior Production Engineer, is part of the Test Infrastructure team responsible for ensuring Shopify’s CI systems are scalable, robust, and usable. In this post, Christian shares how the team reduced the p95 of Shopify’s core monolith from 45 minutes to 18, allowing developers to spend less time waiting and ship faster.

9. Rate Limiting GraphQL APIs by Calculating Query Complexity

Guilherme Vieira, Senior Developer on the API Patterns team, explores Shopify’s rate-limiting system for the GraphQL Admin API and how it addresses some limitations of methods commonly used in REST APIs. He also describes how we calculate query costs that adapt to the data that clients need while providing a more predictable load on servers.

10. Building an App Clip with React Native

Sebastian Ekström, Senior Developer on the Shop team, recounts what it was like being the first to build an App Clip in React Native that would be surfaced to millions of users each day. 

“We approached this project with a lot of unknowns—the technology was new and new to us. We were trying to build an App Clip with React Native, which isn’t typical! Our approach (to fail fast and iterate) worked well. Having a developer with native iOS development was very helpful because App Clips—even ones written in React Native—involve a lot of Apple’s tooling.”

Bonus: Older Posts You Still Love

The following posts are still very popular on the blog, so it felt wrong to leave them off the list just because they are a couple of years old. Considering the number of people who have read Building a Data Table Component in React, I’m assuming there are thousands of data table components built with React out there, thanks to this post.

1. Building a Data Table Component in React
2. Under Deconstruction: The State of Shopify’s Monolith
3. How to Write Fast Code in Ruby on Rails

---

If you’re passionate about solving complex problems at scale, and you’re eager to learn more, we're always hiring! Reach out to us or apply on our careers page.

Continue reading

The beginning stages of a career in engineering can be daunting. You’re trying to make the most of the opportunity at your new job and learning as much as you can, and as a result, it can be hard to find time and energy to focus on growth. Here are five practical tips that can help you grow as you navigate your engineering career.

Continue reading

Being always-on means we don’t wait to reach alignment around expectations and performance at the end of a review period. We’re always calibrating and aligning. This removes any sort of surprise in how an individual on the team is doing and recognizes the specific impact they had on the business. It’s also for us to find and perform specific just-in-time growth opportunities for each individual. 

Today, continuous deployment is an accepted and common best practice when it comes to building and releasing software. But, where’s the continuous deployment for the individuals? Just like the software we write, we’re iterating on ourselves and deploying new versions all the time. We learn, grow, and try new ideas, concepts, and approaches in our work and interactions. But how are we supposed to iterate and grow when, generally, we calibrate so infrequently? Take a minute and think about your experiences:

• What do calibrations look like for you? 
• When was the last time you got feedback? 
• How often do you have performance conversations? Do you have them at all? 
• Do you always know how your work connects to your job expectations? Do you know how your work contributes to the organizational goals?
• Are you ever surprised by your performance evaluation? 
• Were you able to remember, in detail, all of your contributions for the performance review window? 

If you receive feedback, have performance reviews, and answer "no" or "I don’t know" to any of the above questions, then unfortunately, you’re not alone. I’ve answered "no" and "I don’t know" to each of these questions at one point in time or another in my career. I went years without any sort of feedback or review. I have also worked on teams where performance reviews were yearly, and only at the end of the year did we try and collect a list of the feedback and contributions made over that year.

I have found great value in performance reviews with my team, if and only if, they are continuous, and always-on. Anything short of always-on leads to surprises, missed opportunities for growth and for corrective feedback to be effective, as well as an incomplete view on individuals' contributions. This culminates in missed opportunities for the individual when it comes to their performance, promotion, and compensation reviews and conversations.

Ye Old Performance Review

Ye Old performance reviews are plagued by the same problems which surrounded software development before continuous deployments. Once every X number of months, we’d get all the latest features and build release candidates, and try to ship our code to production. These infrequent releases never worked out and were always plagued with issues. Knowing that this didn’t work so well for software deployments, why are so many still applying the same thinking to the individuals in their company and on their team?

The Goal of Performance Reviews 

Performance reviews intend to calibrate (meaning to capture and align) with an individual on the impact they had on the business over a given period, reward them for that impact, provide feedback, and stretch them into new opportunities (when they’re ready).

Some Problems with Ye Old Performance Reviews 

I don’t know about you, but I can’t recall what I had for dinner a week ago, let alone what I worked on months ago. Sure, I can give you the high-level details just like I can for that dinner I had last week. I probably had protein and some vegetables. Which one? Who knows. The same applies with impact conversations. How are we supposed to have a meaningful impact conversation if we can’t recall what we did and the impact it had? How are we supposed to provide feedback, so you can do better next time on that meal, if we don’t even recall what we ate? The specifics around those contributions are important, and those specifics are available now. 

An always-on calibration reduces: surprises and disconnects. It helps ensure the presence of specificity when reviewing contributions, and individuals grow into better versions of themselves. What if after that meal I made last week, I got feedback right away from my partner. That meal was good, but it could have used a little more spice. Great. Now the next time I make that meal, I can add some extra spice. If she didn’t tell me for a year, then every time I made it this year, it would be lacking that spice. I would have missed the opportunity to refine my palate and grow. Let’s look more closely at some of the problems which arise with these infrequent calibrations.

Contributions

When reviews are infrequent or non-existent, we’re unable to know the full scope and impact of the work performed by the individual. Their work isn’t fully realized, captured, and rewarded. If we do try to capture these contributions at the end of a review window, we run into a few problems:

• Our memory fades and we forget our contributions and the impact we had. 
• Our contributions often end up taking the form of general statements that lack specificity.
• We suffer from a recency bias that colours how we see the contributions over the entire review period. This results in more weight being given to recent contributions and less to those which happened closer to the start of the review period. 
• Managers and individuals can have a different or an incomplete view of the contributions made.

If we are unable to see the full scope of work contributed by the individual, we’re missing opportunities to reward them for this effort and grow them towards their long-term goals.

Growth

When reviews are infrequent, we’re missing out on the opportunity to grow the individuals on our team. With reviews come calibration, feedback, and alignment. This leads to areas for growth in terms of new opportunities and feedback as to where they can improve. If we try to capture these things at the end of review windows, we have a few problems:

• We’re unable to grow in our careers as quickly because 
• We can’t quickly try out new things and receive early and frequent feedback.
• We’re infrequently looking for new opportunities that benefit our career growth. 
• We won’t be able to provide early feedback or support when something isn’t working. 
• There’s a lack of specificity on how team members can achieve the next level in their careers.
• Individuals can overstay on a team when there’s a clear growth opportunity for them elsewhere in the organization.

Frequent calibrations allow individuals to grow faster as they can find opportunities when they are ready, iterate on their current skills, and pivot towards a more successful development and contribution path. 

The Quarterly Calibration Document

Every quarter, each member of my team makes a copy of this quarterly objectives template. At present, this template consists of six sections:

1. Intended Outcomes: what they intend to accomplish going into this quarter?
2. Top Accomplishments: what are their most impactful accomplishments this quarter? Other Accomplishments: what other impactful work did they deliver this quarter?
3. Opportunities for the next three to six months: what opportunities have we identified for them that aren’t yet available to work on but will be available in the upcoming quarters?
4. Feedback: what feedback did we receive from coworkers?
5. Quarterly Review: a table that connects the individual’s specific impact for a given quarter to the organization’s expectations for their role and level.

As you can probably guess by looking at these sections, this is a living document, and it’ll be updated over a given quarter. Each individual creates a new one at the start of the quarter and outlines their intended outcomes for the quarter. After this is done, we discuss and align on those intended outcomes during our first one-on-one of the quarter. After we have aligned, the individual updates this document every week before our one-on-one to ensure it contains their accomplishments and any feedback they’ve received from their coworkers. With this document and the organizations' role expectations, we can calibrate and state where they’re meeting, exceeding, or missing our expectations of them in their role weekly. We can also call out areas for development and look for opportunities in the current and upcoming work for them to develop. There’s never any surprise as to how they are performing and what opportunities are upcoming for their growth.

A Few Key Points

There are a few details I’ve learned to pay close attention to with these calibrations. 

Review Weekly During Your One-on-one

I’m just going to assume you are doing weekly one-on-ones. These are a great opportunity for coaching and mentorship. For always-on calibrations to be successful, you need to include and dedicate time as part of these weekly meetings. Calibrating weekly lets you:

• Provide feedback on their work and its impact
• Recognize their contributions regularly
• Show them the growth opportunity available to them that connects to their development plan
• Identify deviations from the agreed upon intended outcomes and take early action to ensure they have a successful quarter

Who Drives and Owns the Quarterly Calibration Document?

These calibration documents are driven by the individual as they’re mentored and coached by their manager. Putting the ownership of this document on the individual means they see how their objectives align with the expectations your organization has for someone in this role and level. They know what work they completed and the impact around that work. They also have a development plan and know what they’re working towards. Now that’s not to say their manager doesn’t have a place in this document. We’re there to mentor and coach them. If the intended outcomes aren’t appropriate for their level or are unrealistic for the provided period, we provide them with this feedback and help them craft appropriate intended outcomes and objectives. We also know about upcoming work, and how it might interest or grow them towards their long-term goals. 

Always Incorporate Team Feedback

Waiting to collect and share feedback on an infrequent basis results in vague, non-actionable, and non-specific feedback that hinders the growth of the team. Infrequently collected feedback often takes the form of "She did great on this project," "They're a pleasure to work with." This isn’t helpful to anyone's growth. Feedback needs to be candid, specific, timely, and focused on the behaviour. Most importantly, it needs to come from a place of caring. By discussing feedback in the quarterly document and during weekly one-on-ones, you can:

• Collect highly specific and timely feedback.
• Identify timely growth opportunities.
• Provide a reminder to each individual on the importance of feedback to everyone’s growth. 

During our weekly one-on-ones, we discuss any feedback that we’ve received during the previous week from their coworkers. I also solicit feedback for teammates at this time that they may or may not have shared with their coworkers. We take time to break down this feedback together and discuss the specifics. If the feedback is positive, we’ll make sure to note it as it’s useful in future promotion and compensation conversations. If the feedback is constructive, we discuss the specifics and highlight future opportunities where we can apply what was learned. Where appropriate, we also incorporate new intended outcomes into our quarterly calibration document. 

What Managers Can Do when Things Aren’t on Track.

This topic deserves its own post but short of it is: hard conversations don’t get easier with time, they get more difficult. Let’s say we don’t appear to be on track for reaching our intended outcomes and the reason is performance-related. This is where we need to act immediately. Don’t wait. Do it now. The longer you wait, the harder it is to have these difficult conversations. For me, this is akin to howlers in Harry Potter. For those who don’t know Harry Potter, these are letters written to seemingly misbehaving students from parents for which the letter yells at the student for some misbehaving that occurred. If you don’t open these letters right away and get the yelling over with, they get worse and worse. They smoke in the corner, and eventually the yelling from the letter is far worse when you eventually do open it. To me, this is what I think of whenever I have difficult feedback I need to provide. I know it’s going to be difficult, but all parties should provide this early and give the recipient a chance to course correct. The good news is that you’re having weekly calibration sessions and not yearly, so the individual has plenty of time to correct any performance issues before it becomes a serious problem. But only if the manager jumps in.

What Happens When We Aren’t Hitting Our Intended Outcomes and Objectives 

First, it’s important to be clear as to which intended outcomes aren’t being hit. Are they specific to personal development or their current role and level?

Personal Development Intended Outcomes

In addition to achieving the expectations of the role and level, they’re hopefully working towards their long-term aims. (See The AWARE Development Plan for more on this topic). Working with your Development Plan, you’ve worked back from your long-term aims to set a series of the short-term intended outcomes that move you towards these goals. Missing these intended outcomes results in a delay in reaching your long-term aim, but this doesn’t affect your performance in your current role and level. When personal development aims are missed, we should reaffirm the value in these intended outcomes, and if they’re still appropriate, prioritize them in the future. We need to discuss and acknowledge the delay that missing these outcomes have on their long-term aims, so all parties remain aligned on development goals. 

Role or Level Intended Outcomes

At the start of a review period, we’ve agreed to a set of intended outcomes for an individual based on the role and level. Once we learn that the intended outcomes for the role or level aren’t going to be achieved, we need to understand why. If the reason is that priorities have changed, we need to refocus our efforts elsewhere. We acknowledge the work and impact they’ve had to date and set new intended outcomes that are appropriate for the time that remains in the review period. If, on the other hand, they’re unable to meet the intended outcomes because they aren’t up to the task, we may need to set up a performance improvement plan to help them gain the skills needed to execute at the level expected of them.

The Quarterly Review

We roll up and calibrate our impact every quarter. This period can be adjusted to work for your organization, but I’d recommend something less than a year but more than a month. Waiting a year is too long and there’s too much data for you to work within creating your evaluation. Breaking down these yearly reviews into smaller windows has a few advantages, it:

• Allows you to highlight impactful windows of contribution (you may have a great quarter and just an ok year, breaking it down by quarter gives you the chance to celebrate that great period).
• Allows you to snapshot smaller windows (this is your highlight reel for a given period and when looking back over the year you can look at these snapshots).
• Allows you to assign a performance rating for this period and course correct early.

If we want to be sure we have a true representation of each individual's contributions to an organization, ensure those contributions are meeting your organizations' expectations for their role and level, and provide the right opportunities for growth for each individual, then we need to be constantly tracking and discussing the specifics of their work, its impact, and where they can grow. It’s not enough to look back at the end of the year and collect feedback and a list of accomplishments. Your list will, at best, be incomplete, but more importantly you’ll have missed out on magnifying the growth of each individual. Worse yet, that yearly missed growth opportunity compounds, so the impact you are missing out on by not continuously calibrating with your team is huge.

---

Wherever you are, your next journey starts here! If building systems from the ground up to solve real-world problems interests you, our Engineering blog has stories about other challenges we have encountered. Intrigued? Visit our Engineering career page to find out about our open positions and learn about Digital by Default.

Continue reading

A development plan helps everyone aim for and achieve their long-term goals in an intentional manner. Wherever you are in your career, there’s room for growth and a goal for you to work towards. Maybe your goal is a promotion? Maybe your goal is to acquire a given proficiency in a language or framework? Maybe your goal is to start your own company? Whatever it is, the development plan is your roadmap to that goal. Once you have that long-term goal, create a development plan to achieve it. Now I’m assuming there won’t be one single thing you can do to make it happen, if there was you wouldn’t need a plan. When picking a long-term goal, make sure you pick one that’s far enough out to make the goal ambitious but not so far out that you can’t define a sequence of steps to reach that goal. If you can’t define the steps to reach the goal then talk with a mentor or set a goal that you feel is along a path that you can define the steps to reach. After you have that goal, you'll iterate towards it with the AWARE Development Plan. 

Today, my job is that of an Engineering Manager at Shopify. Outside of this position I've always been a planner: an individual iterating towards one long-term goal or another. I didn’t refine or articulate my process for how I iterate towards my long-term goals until I saw members of my team struggling to define their own paths. In an effort to help and accelerate their growth, I started breaking down and articulating how I’ve iterated towards the goals in my life. The result of this work is this AWARE Development plan.

Having a goal means we have an aim or purpose.

Once you have a goal, you need to create a plan to understand how to reach those goals. Setting off towards your goal without a plan is akin to setting off on a road trip without a GPS or a clear sense of how to get to your destination. You don’t know what route you’ll take, nor when you’ll arrive. You may get to your destination, but it’s much more likely that you’ll get lost along the way. On route to your destination, you’ll undoubtedly have reference points along the way that you’ll take note of. These reference points are akin to our short and medium-term goals. Our plan has these reference points built-in, so we can constantly check-in to make sure we’re still on course. If we’re off course then we want to know sooner than later, so we can adjust, ask for directions and update the plan. The short- and medium-term goals created in your AWARE plan provide regular checkpoints along the way to your long-term goals. If we are unable to achieve short and medium-term goals we have the opportunity to lean in and course correct. Failing to course correct in these moments will result in at the very least substantial detours on the way to our goals. 

Iterating Towards My Long-Term Goals

When I grow up I want to be a… Well, what did you want to be? I wanted to be a: fighter jet pilot, police officer, lawyer, and then when things got serious, a developer. For me, long-term goal setting started with a career goal when I was younger. I set a long-term goal, figured out what goals needed to be achieved along the way, achieved those goals, reflected on them, and then looked for the next goal.

I was 12 years old when I got serious about wanting a career with computers. I had spent a bunch of time on my dad’s computer and I was hooked. But the question was: how do I make this happen? To figure this out, I started with the long-term goal of becoming a computer programmer and worked my way back. I took what I knew about my goals and figured out what I needed to do along the way to reach them. I made a plan.

A summary of my 12-year-old self’s plan:

I looked ahead and set a long-term goal. I wanted a career as a computer programmer and to attend the University of Waterloo. I worked back from that goal to set various shorter-term goals. I needed to get good grades, get my computer, and earn some money to pay for this. I had a specific long-term goal and a set of medium and short-term goals. These medium and short-term goals moved me closer to the long-term goal one step at a time. New goals such as the purchase of a computer weren’t immediately on this plan, but this goal was added once its value became apparent to the long-term goal.

Helping Others Reach their Goals

I’ve always been interested in setting and reaching long-term goals. I’ve set and reached long-term goals in: education, software engineering career, and dance career. In my career, working both as an Engineering Manager and a dance instructor I’ve had the opportunity to work with and help individuals set and achieve their goals. What I’ve learned is that the process to achieve those goals is the same irrespective of the area of interest. The AWARE process works just as well for Dance as it does for Software Development. I’m sharing this with you because you’re the one who’s in control of you reaching your long-term goals, and yes, you can reach them. 

As a manager and instructor in both dance and Software Development, I’ve heard questions like: “What do I need to get to the next level” or “What do I need to do to get better at this” more times than I can count. In either case, my answer is the same. 

• Start by building your development plan and work backwards from that goal to figure out what must be true for you to reach that goal. 
• Sit down and critically think about the goal as well as the goals you must achieve along the way. 
• Sit down and critically think about the result of your short-term goals after you achieve them.

In my experience, these are the concepts which are often not as clear-cut with other approaches one may take to reach their long-term goals. With the AWARE Development plan we are:

• Putting the individual in the driver's seat and making them accountable for their long-term goals is key for them taking responsibility and achieving their goals. 
• Having the individual develop an understanding of what it means to achieve their goal helps them understand where they need to grow and what opportunities they need to seek out. 
• Creating a clear set of areas of development for which both they and I continuously look for opportunities where they can develop. 
• Creating a clear answer to the “What’s Next?” question. We know what’s next as we can just consult our Development Plan
• Provides (to an extent) the individual control over the speed at which they achieve their goals.

If you are an individual who is unsure of what’s next or unsure how you can reach your long-term goal I’d encourage you to give this a shot. Sit down and write a Development Plan for yourself. Once you're done, share it with your lead/manager and ask them for feedback and their opinion. They are your partner. They can work with you to find opportunities and provide feedback as you work towards your goal. 

AWARE: Aim, Work Back, Achieve, Reflect, Encore

AWARE is a way for each of us to iterate towards our long-term goals. It’s strength comes from breaking down long-term goals into actionable steps as well as reflecting on completed steps in order to provide confidence that you are on track. How does it work? Start at the end and imagine you achieved your goal. This is your long-term Aim. Now, work your way back and define what steps you need to take along the way to that outcome. You are unlikely to be able to achieve all of these Aims right away and they are often too big to achieve all at once. When you find these, break them down into smaller Aims. From here start Achieving your Aims. As you complete your Aims take time to Reflect. What did you learn? What new goals did you uncover? Was that Aim valuable? Now take your next Aim and do it all over again. Let’s dig into each step a little more.

 

Aim

At this stage, you’ll write down your aim aka your goal. When writing your aim make sure:

• You time box this aim appropriately.
• That there’s a clear definition of success.
• You have a clear set of objectives.
• You have a clear way to measure this aim.  

Work Back

Can the current aim be broken down into smaller aims or can you immediately execute towards it? If you can’t immediately execute towards it then identify smaller aims that will lead to it. A goal is seldom achieved through the accomplishment of a single aim. Write down the aim and then work back from there to identify other aims you can perform as you iterate and move towards this larger aim. Each of these aims should:

• have clear objectives
• be measurable
• be time-boxed
• be reflected upon once it’s completed.

Achieve

Now that you have a time-boxed aim, with a clear objective, and a way to measure success we’ll execute and accomplish this aim.

Reflect

After you have completed your aim, it’s important to reflect upon the aim and its outcomes:

• Did this provide the value we expected it to? 
• What did we learn? 
• What new aims are we now aware of that should we add to our Development Plan?
• What would you do differently next time if you were to do it again?

Encore

Now that you have completed an aim, repeat the process. Aim again and continue to work towards your long-term goal.

Aim and Work Back Example

I recently had a team member who expressed that their goal was to run their own software company one day. Awesome! They have a long-term goal. One specific worry they had was onboarding new developers to this company. Specifically, they wanted to know how to have them be impactful in a “timely manner.”  They identified that having impactful developers for their startup was important early on and could be the difference between success and failure for their company. What a great insight! So working back from their long-term goal we’ve identified “being able to onboard new developers in an organization promptly” to be an aim in the plan. In breaking down this aim, we were able to find two aims they could execute over the next eight months to grow this skill set:

1. One area we identified right away was mentoring an intern and new hires, so we added this to their plan. This aim was easy to set up: you'll onboard an intern in one of the upcoming terms and be responsible for onboarding them to the team and mentoring them while they’re here. 
2. This team member presented the idea of taking four months away from our team to join an onboarding group that was working to decrease the onboarding time for new developers joining Shopify. This opportunity was perfect. You can practice onboarding developers to our company. You can see firsthand what works and what doesn’t while helping develop the process here.

With this individual we have :

• A long-term goal: start your own software company.
• A medium-term aim working towards that long-term goal: learn how to accelerate the onboarding of new hires.
• Two short-term aims that work towards the medium-term aim:
• Buddy an intern or new hire to the team. 
• Mentor for four months as part of the company’s onboarding program.

By setting the long-term goal and working back, we were able to work together to find opportunities in the short term that would grow this individual towards their long-term goal. Once they complete any one of these aims they’ll reflect on how it went, what was learned and then decide if there’s anything to add to the Development Plan as we continue on their path towards the long-term goal. In the provided example we think we have all of the shorter-term Aims required to reach the longer-term goals flushed out from the start. This won’t be the case and may not be true. That’s ok. Take it step-by-step and execute on the things you know and append the plan when you reflect.

Bonus Tip: Sharing

Once you have an aim. Share it! Share it with your lead/manager, and if you're comfortable with the idea, your colleagues. Sharing your goals with others will help ensure the right growth opportunities are available when you are ready for them. What follows when you share your plan:

1. New opportunities will present themselves because others are aware of your goals and can therefore share relevant opportunities with you.
2. You will see opportunities for growth that may not have initially been obvious to you.

Sharing your aim will enable you to proceed to your goals at a faster rate than if you were working at this alone.

Tips for Using the AWARE Development Plan

I provide this development plan template to team members when they join my team. I also ask them to write down their long-term goals and to time box this long-term goal to at most five years. This is usually far enough out that there’s some uncertainty but doesn’t prevent developing a plan. We then work back from that long-term goal and identify shorter-term aims (usually over the next one to two years) that moves them towards this goal. The work of identifying these aims can be done together, but I also encourage them to drive this plan as much as possible. They have to do some thinking and bring ideas to the table as well. 

Aim

To help with their aim I ask questions like: 

• What does success look like for you in these time frames? 
• What do we need to do to achieve this aim?
• How will we know if we’ve achieved this aim? 
• What opportunities are available today to start progressing towards this aim?
• How does some of the current work you’re doing tie into this aim?

Work Back

Once we have an aim, we need to ask: is this something I can achieve now? If yes, you can move on to Achieve. If it’s a no, not at this time, the situation should be one that you and your lead/manager agree that you’re ready for this aim, but you’re unable to locate an opportunity to achieve it. Finally, if it’s ano, you’re unable to achieve this aim at this precise moment, you’ll need to work back from it to find other aims that are along the right path. For instance, this aim may require me to have a certain degree or set of experiences that I’m missing. If this is the situation, simply work back until you find the aims that are achievable. Document all discovered aims in your development plan so you and your lead can pursue them in due time.

Achieve 

You have an aim that you can execute now. It has a clear set of objectives, and its success is measurable. Do it!

Reflect

You completed your aim. Amazing! Once you’ve completed an aim, it’s important to take some time to reflect on it. This is a step most folks want to skip as they don’t see the value but it’s the most important. Don’t skip it! Ask yourself: 

• What did we learn? 
• Did we get what we thought we would out of it?
• What would we do differently next time?
• What new aims should we add to our plan based on what we know now?

Maybe there’s a follow-up aim that you didn’t know about before you started this aim. Maybe you learned something and you want or need to pivot your aim or long-term goal? This is your chance to get feedback and course correct should you need or want to detour. Going back to our driving example from earlier. When we are driving towards a destination and aren’t paying attention to our surroundings, or checking on our route, we’re far more likely to get lost. So take a minute when you complete an aim and check in on your surroundings. Am I still on course? Did I take a wrong turn? Is there another route available to me now?

Encore: Maintenance of the Development Plan

We have to maintain this Development Plan after we create it. Aims can change and opportunities arise. When they do, we need to adjust. My team and I check in on our plan during our weekly one on ones. At these meetings, we ask:

• If an aim has been completed, what’s the next aim that you will work on?
• What opportunities have come up, and how do they tie into your plan? 
• Is there something in another task that came up that contributes to an aim? 
• Are we still on track to reach our aims in the timeframe we set?
• Did we complete an aim? Let’s make sure we reflect.

If the answer is yes to any of these that’s great! Call it out! Be explicit about it. Learning opportunities are magnified when you are intentional about them. 

The Path to Success Doesn’t Have to Be Complicated

The path to success is often said to look something like this:

But it doesn’t have to be quite as complex a ride. Get a mentor, some directions, and form a plan. Make sure this plan iterates towards your goal and has signposts along the way so you can check in to know you’re on track. This way If you miss a turn, it’s no big deal. It’ll happen. The difference for you is that you’ll know sooner than later that you’re off track and thus you’ll be able to course-correct earlier. At the end of the day your path to success may look like this:

If you haven’t already done so: sit down with your lead or manager, write a plan, figure out what is needed for you to reach your long-term goal. Then start iterating towards it.

---

Wherever you are, your next journey starts here! If building systems from the ground up to solve real-world problems interests you, our Engineering blog has stories about other challenges we have encountered. Intrigued? Visit our Engineering career page to find out about our open positions and learn about Digital by Default.

Continue reading

This past April, I completed my first placement as a Dev Degree student. I was a back-end developer working on the Docs & API Libraries team. The team’s mission is to create libraries, tools, and documentation that help developers build on top of Shopify. Throughout my time on the team, I had many opportunities to solve problems, and in taking them, I learned not only technical skills, but life lessons I hope to carry with me. I’ll share with you how I learned to appreciate the stages of learning, dispel the myth of the “real developer,” combat imposter syndrome by asking for help, and the power of valuing representation.

Joining the Dev Degree Program

In February of 2019, I received an email from York University. Apply for Dev Degree! it read. As a high school student with disabilities, I’d been advised to look for a program that would support me until I graduated. With small cohorts and a team of supportive folks from both Shopify and York University, I felt I could be well-accommodated in Dev Degree. Getting work experience, I reasoned, would also help me learn to navigate the workplace, putting me at an advantage once I graduated. With nothing to lose and absolutely no expectations, I hit Apply.

Much to my surprise, I made it through the application and interview process. What followed were eight months of learning: 25 hours a week in a classroom at Shopify and 20 hours a week at York University. Alongside nine other students, I discovered Ruby, databases, front-end development, and much more with a group of knowledgeable instructors at Shopify. In May 2020, we moved on to the next exciting stage of the Dev Degree program: starting our first placement on a real Shopify team! It would be 12 months long, followed by three additional eight-month long placements, all on teams of varying disciplines. During those 12 months, I learned lessons I’ll carry throughout my career.

What We Consider “Foundational Knowledge” Gets Distorted the More We Learn

When I first joined the Docs & API Libraries team, there was a steep learning curve. This was expected. Months into the placement, however, I still felt as though I was stagnant in my learning and would never know enough to become impactful. Upon mentioning this to my lead, he suggested we create an Achievement Log—a list of the victories I’d had, large and small, during my time on the team.

Looking back on my Achievement Log, I see many victories I would now consider rather small, but had been a big deal at the time. To feel this way is a reminder that I have progressed. My bar for what to consider “basic knowledge” moved upward as I learned more, leading to a feeling of never having progressed. One good way of putting these achievements into perspective is to share them with others. So, let’s journey through some highlights from my Achievement Log together!

I remember being very frustrated while attempting my first pull request (PR). I was still learning about the Shopify CLI (a command-line tool to help developers create Shopify apps) and kept falling down the wrong rabbit holes. The task: allow the Shopify CLI to take all Rails flags when scaffolding a Rails project; for example, using --db=DB to change the database type. It took a lot of guidance, learning, and mistakes to solve the issue, so when I finally shipped my first PR, it felt like a massive victory!

Mentoring was another good way to see how far I’d come. When pairing with first-year Dev Degree students on similar tasks, I’d realize I was answering their questions—questions I myself had asked when working on that first PR—and guiding them toward their own solutions. It reminds me of the fact that we all start in the same place: with no context, little knowledge, and much curiosity. I have made progress.

The Myth of the “Real” Developer Is, Well, a Myth

After familiarizing myself with the tool through tasks similar to my first PR, I began working on a project that added themes as a project type to the Shopify CLI. The first feature I added was the command to scaffold a theme, followed by a task I always dreaded: testing. I understood what my code did, and what situations needed to have unit tests, but could not figure out how to write the tests.

My lead gave a very simple suggestion: why not mimic the tests from the Rails project type? I was more familiar with the Rails project type, and the code being tested was very similar between the two test files. This had never occurred to me before, as it didn’t feel like something a “real” developer would do.

Maybe “real” developers program in their free time, are really into video games, or have a bunch of world-changing side projects going at all times. Or maybe they only use the terminal— never the GUI—and always dark mode. I spoke to a few developer interns about what notions they used to have of a “real” developer, and those were some of their thoughts. My own contribution was that “real” developers can solve problems in their own creative ways and didn’t need help; it felt like I needed to be able to implement unique solutions without referring to any examples. So, following existing code felt like cheating at first. However, the more I applied the strategy, the more I realized it was helpful and entirely valid.

For one, observational learning is a good way of building confidence toward being able to attempt something. My first pairing sessions on this team, before I felt comfortable driving, involved watching an experienced developer work through the problem on their screen. Looking at old code also gives a starting point for what questions to ask or keywords to search. By better understanding the existing tests, and changing them to fit what I needed to test, I was learning to write unrelated tests one bite-sized piece at a time.

At the end of the day, developers are problem solvers coming from all different walks of life, all with ways of learning that fit them. There’s no need to play into dated stereotypes!

Imposter Syndrome Is Real, But It’s Only Part of the Picture

As I was closing out the Shopify CLI project, I was added to my first team project: the Shopify Admin API Library for Node. This is a library written in Typescript with support for authentication, GraphQL and REST requests, and webhook handling. It’s used in accelerating Node app development.

With this being my first time working on a team at Shopify, I found it far too easy to nod along and pretend I knew more than I did. Figuring it would be a relatively simple feature to implement, a teammate suggested I add GraphQL proxy functionality to the library; but, for a very junior developer like me, it wasn’t all that simple. It was difficult to communicate the level of help I needed. Instead, I often seemed to require encouragement, which my team gave readily. I kept being told I was doing a good job, even though I felt I had hardly done anything, and whenever I mentioned to a friend that I felt I had no idea what I was doing, the response was often that they were sure I was doing great. That I needed to have more confidence in my abilities.

I puzzled over the task for several weeks without admitting I had no idea what I was doing. In the end, my lead had to help me a lot. It wasn’t a matter of simply feeling like I knew nothing; I had been genuinely lost and successful at hiding it. Being surrounded by smart people, imposter syndrome is nearly inevitable. I’m still looking for ways to overcome this. Yet, there are moments when it is not simply a matter of underestimating myself; rather, it’s more about acknowledging how much I have to learn. To attribute the lack of confidence entirely to imposter syndrome would only work to isolate me more.

Imposter syndrome or not, I still had to work through it. I had to ask for help; a vital challenge in the journey of learning. Throughout my placement, I was told repeatedly, by many team members, that they would like to hear me ask for help more often. And I’ve gotten better at that. Not only does it help me learn for the next time, it gives the team context into the problem I am solving and how. It may slow down progress for a little while, but in the larger picture, it moves the entire project forward. Plus, asking a senior developer for their time isn’t unreasonable, but normal. What would be unreasonable is expecting an intern to know enough not to ask!

Learning Will Never Feel Fast

My next project after the Node library was the Shopify Admin API Library for PHP (similar functionality as the Shopify Admin API Library for Node but a different language). The first feature I added was the Context class, comparable to a backpack of important information about the user’s app and shop being carried and used across the rest of the library’s functionality. I had never used PHP before and was excited to learn. That is, until I started to fall behind. Then I began to feel frustrated. Since I’d had experience building the previous library, shouldn’t I have been able to hit the ground running with this one?

As a Dev Degree student, I work approximately half the hours of everyone else on my team, and my inexperience means I take longer to grasp certain concepts. Even knowing this, I tend to compare myself to others on my team, so I often feel very behind when it comes to how much I’ve accomplished. And any time I’m told that I’m a quick learner, it’s as if I’ve successfully fooled everyone.

Determined to practice the lesson I had learned from trying to implement the GraphQL proxy in the Node library, I asked for help. I asked my teammates to review the draft PR occasionally while it was still a work-in-progress. The idea was that, if I strayed from the proper implementation, my mistake would be caught earlier on. Not only did this keep me on track, getting my teammates’ approval throughout the process also helped me realize I was less behind than I’d thought. It made learning a collaborative process. My inexperience and part-time hours didn’t matter, because I had a team to learn alongside.

Even when I was on track, learning felt like a slow process—and that’s because that is the nature of learning. Not knowing or understanding things can be frustrating in the moment, especially when others seem to understand. But the perspective others have of me is different from mine. It’s not that I’ve fooled them; rather, they’re acknowledging my progress relative to only itself. They’re celebrating my learning for what it is.

Valuing Representation Isn’t a Weakness

As a kid, I couldn’t understand why representation mattered; if no one like you had achieved what you wanted to achieve before, then you’d be the first! Yet, this was the same kid who felt she could never become a teacher because her last name “didn’t sound like a teacher’s.” This internalized requirement to appear unbothered by my differences followed me as I got older, applying itself to other facets of me—gender, disability, ethnicity, age. I later faced covert sexism and ableism in high school, making it harder for me to remain unfazed. Consequently, when I first started working on an open source repository, I’d get nervous about how prejudiced a stranger could be just from looking at my GitHub profile picture.

This nervousness has since died down. I haven’t been in any predicament of that sort on the team, and on top of that, I’ve been encouraged by everyone I interact with regularly to tell them if they aren’t being properly accommodating. I always have the right to be supported and included, but it’s my responsibility to share how others can help. We even have an autism support Slack channel at Shopify that gives me a space to see people like myself doing all sorts of amazing things and to seek out advice.

Looking back on all the highlights of my achievement log, there’s a story that snakes through the entries. Not just one of learning and achievement, which I’ve shared, but one that’s best encapsulated by one last story.

My lead sent out feedback forms to each of the team members to fill out about those they worked with. The last question was “Anything else to add?” Hesitantly, I messaged one of my teammates, asking if I could mention how appreciative I was of her openness about her neurodiversity. It was nice to have someone like me on the team, I told her. Imagine my surprise when she told me she’d meant to write the same thing for me!

Valuing representation isn’t a weakness. It isn’t petty. There’s no need to appear unbothered. Valuing representation helps us value and empower one another—for who we are, what we represent, and the positive impact we have.

There you have it, a recap of my first placement as a Dev Degree intern, some problems I solved, and some lessons I learned. Of course, I still have much to learn. There’s no quick fix to any challenges that come with learning. However, if I were to take only one lesson with me to my next placement, it would be this: there is so much learning involved, so get comfortable being uncomfortable! Face this challenge head-on, but always remember: learning is a collaborative activity.

Having heard my story, you may be interested in learning more about Dev Degree, and possibly experiencing this journey for yourself. Applications for the Fall 2022 program are open until February 13, 2022.

Continue reading

In every business, regardless of industry, it is important to keep an open communication line between the consumer and the producer. In the tech world, this line of communication comes in the form of customer support, chatbots, or contact forms. There’s often no direct line of communication between the developers who build these products and the end users, especially as a company grows. Developers receive requirements of the products to build, focus on shipping their projects, and, if need be, fixing bugs that surface after the end users have interacted with the product.

This creates a situation where developers become out of touch with the products and who they’re building for. As with most things in life, when you’re out of touch with something, it can often result in a lack of empathy for people whose lives involve using the said thing. This lack of empathy can affect the quality of products that are subsequently built.

This is why at Shopify, we have developed a program to make sure our customers (our merchants) and their problems are accessible to everyone at Shopify. Communicating and connecting with customers provides multiple benefits for developers, including:

• Providing perspective on how customers interact with products
• Creating new experiences from customer workarounds
• Expanding domain knowledge
• Developing valuable interpersonal skills

Providing Perspective on How Customers Interact with Products

“Listening to customers describe their problems helps me as a developer relate to them and build more context.”

The development process doesn’t usually have room for interaction between the developers and customers. As a result, developers might ultimately deliver the requirements list they are given for a product, but in the end, the customers might interact with the product in a different way than expected. Developers must fully understand how and why these differences arise, which might not be accurately articulated by Support Advisors (think of the game of telephone where messages get misunderstood and passed along). By somehow interacting with the end users, developers will be able to see the products they have built in a new light and the customers’ fresh eyes. More importantly, developers will get to see that their customers are human too, and in the case of Shopify, more than just shop IDs or accounts.

Creating New Experiences from Customer Workarounds

As developers interact with the customers, they can see how they use the products and create workarounds like this to get the desired functionality. This is very important in informing developers about what the customers really need and what to build next. Before you know it, you start to roll out bug fixes, newer product versions, and possibly new products that address these workarounds and make customers’ workflow a little more seamless.

Expanding Domain Knowledge

End users have limited knowledge of the different parts that make up the product, so they tend to ask an array of questions when they contact support advisors. Support Advisors are trained to be generalists, having a lot of knowledge on different (if not all) parts of the company’s product. While interacting with customers, a developer may get curious about new domains that are totally out of their regular workflow. This curiosity is very beneficial because it fosters the growth of more T-shaped developers, that is, developers who are specialists in a particular area but have general knowledge about a lot of other areas. After listening in on a support phone call, one developer said that it forced them out of their comfort zone to explore new product parts.

Developing Interpersonal Skills

Technical Support Advisors encounter different people and temperaments all the time. They’re trained and experienced to listen, communicate and help customers resolve their issues. Patience and empathy are required when dealing with frustrated customers. Developers can foster growth and improve their craft by listening more, communicating effectively, and setting realistic expectations. These skills are important to build because sometimes, the solution to a problem might not be immediately apparent or fixable. A frustrated customer wants a solution, and they want it immediately. When this happens, you shouldn’t make false promises to appease the customer; instead, you should navigate the situation to realistically set expectations to put the customer at ease.

Given these advantages listed above, there is a case to be made for companies to develop a system where the distance between the developers and customers is reduced. This will help build empathy in the developers as they begin to see the actual users of their products, as human as they come, rather than the ideal personas created during the development process.

How We Build Empathy at Shopify

At Shopify, we have found an effective system of getting developers (and non-developers) closer to our merchants, appropriately called Bridge the Gap.

We launched the Bridge the Gap program in 2014 to connect Shopify employees to Shopify merchants via the Support teams. The mission of this program is to ensure that everyone working at Shopify has the opportunity to connect to our merchants in a human way. There are three channels in this program:

• Workshops
• Internal Podcast
• Shadowing Sessions

Workshops

Workshops are organized around specific topics and areas of our platform where we take a deep dive and learn more about our merchants’ experience in these areas.. Participants can ask questions throughout to gain context and clarity about how merchants use our products.

Internal Podcast

Our internal podcast focuses on merchant experiences, an insightful channel for allowing everyone to learn more asynchronously and at their own pace. It contains clips from a support call and a discussion between the Support Advisor who took the call and the podcast host.

Shadowing Sessions

In these sessions, you shadow a Support Advisor for one hour as they take questions in real-time from merchants through chat, phone or email. These sessions may be for a broad audience or focus on a specific part of the platform like marketplaces, partners, Plus merchants, etc. Participation in these shadowing sessions is voluntary but strongly encouraged.

Our mission at Shopify is to make commerce better for everyone. Regardless of the discipline you’re working in, our mission remains to have the end user in mind, and Bridge the Gap gives us all the opportunity to build awareness and empathy.

---

Wherever you are, your next journey starts here! If building systems from the ground up to solve real-world problems interests you, our Engineering blog has stories about other challenges we have encountered. Intrigued? Visit our Engineering career page to find out about our open positions and learn about Digital by Default.

Continue reading

To do your best work as a developer, you need context. A development community thrives when its members share context as a habit. That's why Shopify Engineering believes that sharing context is vital to our growth and success—as a company, as a team, and as individuals.

Context is an abstract term, and we use it to refer to the why, what, and how of our development philosophies, approaches, and choices. Although sharing context comes in a myriad of forms, three of the ways we do it at Shopify are through:

• Our in-house Development Handbook
• A vibrant developer presentation program, called Dev Talks
• Podcasts that go deep on technical subjects.

Each of these programs is by and for developers at Shopify, and each has strong support from leadership. Let's take a brief look at each of these ways that we share context and how they benefit our development community.

Shopify Development Handbook

Managing content is always a challenge. In hi-tech organizations, where tools and technologies change frequently, products ship quickly, and projects can pivot from day to day, having access to up-to-date and relevant information is critical. In a whirlwind of change and information volatility, we try to keep a central core of context in our Development Handbook.

Origins

The origins of the Handbook go back to 2015, when Jean-Michel Lemieux (JML), our current Chief Technology Officer, joined Shopify. In his first role at the company, he needed to learn about the Shopify platform—quickly. The company and the product were both growing rapidly, and the documentation that existed was scattered. Much of the knowledge and expertise was only in the heads of Shopifolk, not written down anywhere.

So he started a simple Google Doc to try to get a grip on Shopify both technically and architecturally. As the doc got longer, it was clear that the content was valuable not just to him—this was a resource that every developer could contribute to and benefit from.

Soon, the doc took shape. It contained a history of Shopify development, an overview of the architecture, our development philosophy, and the technology stack we had chosen. It also included information about our production environment and guidance on how we handled incidents.

Becoming a Website

The next logical step was to evolve that document into an internal website that could be more easily searched and navigated, better maintained, and more visible across the whole engineering organization. A small team was formed to build the site, and in 2018 the Development Handbook site went live.

Since then, developers from all disciplines across Shopify have contributed hundreds of topics to the Handbook. Now, it also contains information about our development cultures and practices, using our key technologies, our principles of development, and a wealth of detailed content on how we deploy, manage, and monitor our code.

The process for adding content is developer-friendly, using the same GitHub processes of pull requests and reviews that developers use while coding. We use Markdown for easy content entry and formatting. The site runs on Middleman, and developers contribute to operations of the site itself, like a recent design refresh (including dark mode), improvements to search, and even adding client-side rendering of KaTeX equations.

Handling Oversight and Challenges

The Handbook is essentially crowd-sourced, but it's also overseen, edited, and curated by the small but mighty Developer Context team. This team defines the site's information architecture, evangelizes the Handbook, and works with developers to assist them as they contribute and update content.

The Development Handbook allows our team to push knowledge about Sorbet, static-typing in Ruby, and our best practices to the rest of the company. It's a necessary resource for all our newcomers and a good one even for our experts. A must read.

Despite its success as a central repository for technical content and context in Shopify’s Engineering org, the Handbook always faces challenges. Some content is better off residing in other locations, like GitHub, where it's closest to the code. Some content that has a limited audience might be better off in a standalone site. There’s constant and opposing pressures to either add content to the Handbook or to move content from the Handbook to elsewhere.

Keeping content fresh and up-to-date is also a never-ending job. To try to ensure content isn't created and then forgotten about, we have an ownership model that asks teams to be responsible for any topics that are closely related to their mandates and projects. However, this isn't sufficient, as engineering teams are prone to being reorganized and refocused on new areas.

We haven't found the sweet spot yet for addressing these governance challenges. However, sharing is in the DNA of Shopify developers, and we have a great community of contributors who update content proactively, while others update anything they encounter that needs to change. We're exploring a more comprehensive proactive approach to content maintenance, but we're not sure what final form that will take yet.

In all likelihood, there won't be a one-time fix. Just like the rest of the company, we'll adapt and change as needed to ensure that the Handbook continues to help Shopify developers get up to speed quickly and understand how and why we do the things we do.

Dev Talks

Similar to the Development Handbook, the Dev Talks program has a long history at Shopify. It started in 2014 as a weekly open stage to present demos, prototypes, experiments, technical findings, or any other idea that might resonate with fellow developers.

Although the team managing this program has changed over the years, and its name has gone through several iterations, the primary goals remain the same: it's a place for developers to share their leading-edge work, technology explorations, wins, or occasional failures, with their peers. The side benefits are the opportunity for developers to build their presentation skills and to be recognized and celebrated for their work. The Developer Context team took over responsibility for the program in 2018.

Before Shopify shifted to a fully remote work model, talks were usually presented in our large cafeteria spaces, which lent an informal and casual atmosphere to the proceedings, and where big screens were used to show off one's work. Most presenters used slides as a way of organizing their thoughts, but many talks were off the cuff, or purely demos.

With the company's shift to Digital by Design in 2020, we had to change the model and decided on an on-demand approach. Now, developers record their presentations so they can be watched at any time by their colleagues. Talks don't have prescribed time limits, but most tend to be about 15 to 20 minutes long.

To ensure we get eyes on the talks, the Developer Context team promotes the presentations via email and Slack. The team set up a process to simplify signing up to do a talk and get it promoted, and created branding like a Dev Talks logo and presentation template. Dev Talks is a channel on the internal Shopify TV platform helping ensure the talks have a consistent home and are easy to find.

Dev Talks have given me the opportunity to share my excitement about the projects I've worked on with other developers. They have helped me develop confidence and improve my public speaking skills while also enabling me to build my personal brand at Shopify.

Our on-demand model is still very new, so we'll monitor how it goes and determine if we need to change things up again. What's certain is that the desire for developers to share their technical context is strong, and the appetite to learn from colleagues is equally solid.

Internal Podcasts

The third way we share context is through podcasts. Podcasts aren't new, but they have surged in popularity in recent years. In fact, the founder and CEO of Shopify, Tobi Lütke, has hosted his own internal podcast, called Context, since 2017. This podcast has a wide thematic scope. Most of them, as we might expect from our CEO, have a technology spin, but they’re geared for a Shopify-wide audience.

To provide an outlet for technical conversations focused squarely on our developer community, the Technical Leadership Team (TLT)—a group of senior developers who help to ensure that Shopify makes great technical decisions—recently launched their own internal podcast, Shift. The goal of these in-depth conversations is to unpack technical decisions and dig deep into the context around them.

The Shift podcast is where we talk about ideas that are worth reinforcing in Shopify Engineering. All systems degrade over time, so this forum lets us ensure that the best parts are properly oiled.

About once a month, several members of the TLT sit down virtually with a senior engineering leadership member to probe for specifics around technologies or technical concepts. And the leaders who are interviewed are in the hot seat for a while—these recorded podcasts can last up to an hour. Recent episodes have focused on conversations about machine learning and artificial intelligence at Shopify, the resiliency of our systems, and how we approach extensibility.

To ensure everyone can take advantage of the podcasts, they're made available in both audio and video formats, and a full transcript is provided. Because they’re lengthy deep dives, developers can listen to partial segments at the time of their choosing. The on-demand nature of these podcasts is valuable, and the data shows that uptake on them is strong.

We'll continue to measure the appetite for this type of detailed podcast format to make sure it's resonating with the developer community over the long run.

Context Matters

The three approaches covered here are just a sample of how we share context at Shopify Engineering. We use many other techniques including traditional sharing of information through email newsletters, Slack announcement channels, organization town halls with ask me anything (AMA) segments, video messages from executives, and team demos—not to mention good old-fashioned meetings.

We expect post-pandemic that we’ll reintroduce in-person gatherings where technical teams can come together for brief but intense periods of context sharing hand-in-hand with prototyping, team-building, and deep development explorations.

Our programs are always iterating and evolving to target what works best, and new ideas spring up regularly to complement our more formal programs like the Development Handbook, Dev Talks, and the Shift podcast. What matters most is that an environment is in place to promote, recognize, and celebrate the benefits of sharing knowledge and expertise, with solid buy-in from leadership.

---

We're planning to DOUBLE our engineering team in 2021 by hiring 2,021 new technical roles (see what we did there?). Our platform handled record-breaking sales over BFCM and commerce isn't slowing down. Help us scale & make commerce better for everyone.

Continue reading

There’s a way to build a model for your life and the other demands on you. It doesn’t have to be 100 hours a week. It might not even be 40 hours a week. Whatever sustainable model you come up with, prioritize fiercely and communicate expectations accordingly. I’ve worked this way for three decades through different phases of my life. The hours have changed, but the basic model and principles remain the same: Define the time, prioritize the work, and communicate those two effectively.

Continue reading

Authors: Sarah Naqvi and Steve Lounsbury

Struggling with a concept and frantically trying to find the answers online? Are you thinking: I should just ping a teammate or Is this something I should already know? That’s fine, I’ll ask anyway. And then you do ask and get an answer and are feeling pretty darn proud of yourself and move forward. But wait, now I have about 25 follow-up questions. Sound familiar?

Or how about the career growth questions that can be sometimes too uncomfortable asking your lead or manager? Oh, I know, I’ll take them to reddit. But wait, they have no company context. Yeah, also familiar. I know. I should get a mentor! But darn. I’ve heard so many stories… Who do I approach? Will they be interested? What if they reject me? And what if it’s not working out?

Shopify is a collaborative place. We traditionally pair with other developers and conduct code reviews to level up. This approach is great for just-in-time feedback and unblocking us on immediate problems. We wanted to continue this trend and also look at how we can support developers in growing themselves through longer term conversations.

We surveyed our developers at Shopify and learned that they:

• Love to learn from others at Shopify
• Are busy people and find it challenging to make dedicated time for learning
• Want to grow in their technical and leadership skills.

These findings birthed the idea of building a mentorship program targeted at solving these exact problems. Enter Shopify’s Engineering Mentorship Program. Shopify’s RnD Learning Team partnered with developers across the company to design a unique mentorship program and this guide walks readers through the structure, components, value-adds, and lessons we’ve had over the past year.

Gathering Participants

Once a quarter developers get an email inviting them to join the upcoming cycle of the program and sign up to be a mentee, mentor, or both. In addition to the email that is sent out, updates are posted in a few prominent Slack channels to remind folks that the signup window for the upcoming cycle is now open.

When signing up to participate in the program, mentees are asked to select their areas of interest and mentors are asked to select their areas of expertise. The current selections include:

• Back-end
• Data
• Datastores
• Front-end
• Infrastructure
• Mobile - Android
• Mobile - iOS
• Mobile - React Native
• Non-technical (leadership, management).

Mentors are also prompted to choose if they are interested in supporting one or two mentees for the current cycle.

Matching Mentors and Mentees

Once the signup period wraps up, we run an automated matching script to pair mentees and mentors. Pairs are matched based on a few criteria:

• Mentor isn’t mentee's current lead
• Mentor and mentee don’t report to same lead
• Aligned areas of interest and expertise based on selections in sign-up forms
• Mentee job level is less than or equal to mentor job level.

The matching system intentionally avoids matching based upon criteria such as geographic location or department to broaden the developer’s network and gain company context they would have otherwise not been exposed to.

Pairs are notified by email of their match and invited to a kickoff meeting where organizers welcome participants, explain the program model and value that they will receive as a mentor or mentee, and answer any questions.

Running the Six Week Program Cycle

Each program cycle runs for six weeks and pairs are expected to meet for approximately one hour per week.

The time bound nature of the program enables developers to try out the program and see if it’s a good fit for them. They can connect with someone new and still feel comfortable knowing that they can walk away, no strings attached.

The voluntary signup process ensures that developers who sign up to be a mentor are committed to supporting a mentee for the six week duration and mentees can rest assured that their mentor is keen on supporting them with their professional growth. The sign-up emails as well as the sign-up form reiterate the importance of only signing up as a mentor or mentee if you can dedicate at minimum an hour per week for the six week cycle.

Setting Goals

In advance of the first meeting, mentees are asked to identify technical skills gaps they want to improve. During their first meeting, mentees and mentors work together building a tangible goal that they can work towards over the course of the six weeks. Goals often change and that’s expected.

Through the initial kickoff meeting and weekly check-ins via Slack, we reinforce and reiterate throughout the program that the goal itself is never the goal, but an opportunity to work towards a moving target.

Defining the goal is often the most challenging part for mentees. Mentors take an active role in supporting them craft this—the program team also provides tons of real examples from past mentees.

Staying Connected as a Group

Outside of the one on one weekly meetings between each pairing of mentor and mentee, the broader mentorship community stays connected on Slack. Two Slack channels are used to manage the program and connect participants with one another and with the program team.

The first Slack channel is a public space for all participants as well as anyone at the company who is curious about the program. This channel serves the purpose to advertise the program and keep participants connected to each other as well as to the program team. This is done by regularly asking questions and continuously sharing their experiences of what’s working well, how they’ve pivoted (or not) from their initial goals, and any general tips to support fellow mentors and mentees throughout the program.

The second Slack channel is a private space that is used exclusively by the program team and mentors. This channel is a space for mentors to be vulnerable and lean on fellow mentors for suggestions and resources.

Preparing the Participants with a Guidebook

Beyond the Slack channels, the other primary resource our participants use is a mentorship guidebook that curates tips and resources for added structure. The program team felt that a guidebook was an important aspect to include for participants who were craving more support. While it is entirely an optional resource to use, many first time mentors and mentees find it to be a helpful tool in navigating an otherwise open ended relationship between themselves and their match. It includes tips on sample agendas for your first meeting, example goals, and ways to support your mentee. For example, invite them to one of your meetings and debrief afterwards, pair, or do a code review.

Growing Mentor’s Skills Too

Naturally teaching someone else a technical concept helps reinforce it in our own minds. Our mentors constantly share how they’ve found the program helps refine their craft skills as well:

“Taking a step back from my day-to-day work to meet with [them] and chatting about career goals at a higher level, gave me more insight into what I personally want from my career path as well.”

The ability to mentor others in their technical acumen and craft is a skill that’s valued at Shopify. As engineers progress in their career here, being an effective mentor becomes a bigger piece of what’s expected in the role. The program gives folks a place to improve both their mentorship and leadership skills through iteration.

Throughout the program, mentors receive tips and resources from engineering leaders at the company that are curated by the program team and shared via Slack, but the most valuable piece ends up being the support they provide each other through a closed channel dedicated to mentors.

Here’s an actual example of how mentors help unblock each other:

Gathering Program Feedback

At the end of the six weeks mentees and mentors are asked to provide constructive feedback to one another and the program officially comes to a close. 

Program participants receive a feedback survey that helps organizers understand what’s working well and what to revise for future cycles. Participants share

• Whether they would recommend the program to someone else or not
• What the best part of the program was for them
• What they would like to see improved for future cycles.

Tweaks are made within a short month or so and the next cycle begins. A new opportunity to connect with someone else, grow your skills, and do it in a time-bound and supportive environment.

What We’ve Learned in 2020

Overall, it’s been working well. The type of feedback we receive from participants is definitely share-worthy:

“was phenomenal to learn more about Production Engineering and our infrastructure. Answered hundreds of mind-numbing questions with extreme patience and detail; he put in so much time to write and share resources—and we wrapped up with a live exercise too! I always look forward to our sessions and it was like walking into a different, fantasy-like universe each time. Hands down the best mentoring experience of my professional career thus far.” - Senior Developer

• We’ve had 300+ developers participate as mentees and 200+ as mentors.
• 98% of survey respondents indicated that they would recommend the program to someone else.
• The demand is there. Each cycle of the program we have to turn away potential mentees because we can’t meet the demand due to limited mentors. We are working on strategies to attract more mentors to better support the program in 2021.

The themes that emerged in terms of where participants found the most value are around:

• Building relationships: getting to know people is hard. Getting to know colleagues in a fully remote world is near impossible. This program helps.
• Having dedicated time for learning set aside each week: we’ve all got a lot to do. We know that making time for learning is important, but it can easily fall on the back burner. This program helps with that too.
• Developing technical craft skills: growing your technical chops? Say no more.
• Developing skills as a teacher and mentor: getting better at supporting peers can be tricky. You need experience and a safe space to learn with real people.
• Gaining broader Shopify context: being a T-shaped developer is an asset. By T-shaped we are referring to the vertical bar of the “T” as the areas the developer is an expert in, while the horizontal bar refers to areas where the developer has some breadth and less depth of knowledge. Getting outside of our silos and learning about how different parts of Shopify work helps build stronger developers and a stronger team.

Reinvesting in the developers at Shopify is one way that we help individuals grow in their careers and increase the effectiveness of our teams.

Some great resources that inspired us:

• On Being A Senior Engineer
• The Senior Engineer’s Guide to Helping Others Make Decisions
• How To Be A Good Software Engineer Mentor
• Developers mentoring other developers: practices I’ve seen work well

---

We're planning to DOUBLE our engineering team in 2021 by hiring 2,021 new technical roles (see what we did there?). Our platform handled record-breaking sales over BFCM and commerce isn't slowing down. Help us scale & make commerce better for everyone.

Continue reading

On April 24th, 2020, we proudly celebrated the graduation of our first Dev Degree program cohort. This milestone holds a special place in Shopify history because it’s a day born out of trial and error, experimentation, iteration, and hustle. The 2016 cohort had the honor and challenge of being our first class, lived through the churn and pivots of a newly designed program, and completed their education during a worldwide pandemic, thrust into remote learning and work. The students’ success is a testament to their dedication, adaptability, and grit. It’s also the product of a thoughtfully designed program and a high-functioning Dev Degree team.

What does it take to create an environment where students can thrive and develop into work-ready employees in four years?

We’ve achieved this mission with the Dev Degree program. The key to our success is our learning structure and multidisciplinary team. With our model, students master development skills faster than traditional methods.

The Dev Degree Program Structure

When we set out to shake-up software education in 2016, we had no prescriptive blueprint to guide us and no tried-and-true best practices. Still, we embraced the opportunity to forge a new path in partnership with trusted university advisors and experienced internal educators at Shopify.

Our vision was to create an alternative to the traditional co-op model that alternates between university studies and work placements. In Dev Degree, students receive four years of continual hands-on developer experience at Shopify, through skills training and team placements, in parallel to attending university classes. This model accelerates understanding and allows students to apply classroom theory to real-life product development across a breadth of technology.

Dev Degree Timeline

While computer science and technology are at the core of our learning model, what elevates the program is the focus on personal growth, actionable feedback loops, and the opportunity to make an impact on the company, coworkers, and merchants.

University Course Curriculum

The Dev Degree program leads to an accredited Computer Science degree, which is a deciding factor for many students and their families exploring post-secondary education opportunities. All required core theoretical concepts, computer science courses, math courses, and electives are defined by and taught at the universities. Students take three university courses per semester while working 25 hours per week at Shopify throughout the four-year program. All formal assessments, grading, and final exams for university courses are carried out by the universities.

Dev Degree Structure

While the universities set the requirements for the courses, we work collaboratively to define the course sequencing to ensure the students are exposed to computer science content as early as possible in their program before they start work on team placements at Shopify.

In addition to the core university courses, there are internship courses that teach software development concepts applicable to the technology industry. The universities assess the learning outcomes of the internship courses through practicum reports and meetings with university supervisors or advisors.

The courses and concepts taught at Shopify build on the university courses and teach students hands-on development skills, communication skills, developer tools training, and how to contribute to a real-world product development team effectively.

Developer Skills Training: Building a Strong Foundation

One of the lessons we learned early in the program was that students need a solid foundation of developer skills before being placed on development teams to feel confident and ready to contribute. The first year at Shopify sets the Dev Degree program apart from other work-integrated learning programs because we immerse the students in our Shopify-led developer skills training.

In the first year, we introduce the students to skills and tools that form the foundation for how they work at Shopify and other companies. They need to develop certain skills before moving into teams, such as working with code repositories and committing code, using a command line, front-end development, working with data, and more.

The breadth of technical skills that students learn in their first year in Dev Degree goes beyond the traditional university curriculum. This foundation allows students to confidently join their first placement team and have an immediate impact.

We teach this way on purpose. Universities often chose a bottom-up learning model by front-loading theory and concepts. We designed our program to immerse students somewhere in the middle of top-down and bottom-up, allowing them to gradually discover the fundamentals after they develop base skills and code a bit every day.

Due to the ever-evolving nature of software development, we update the developer skills training path often. Our current courses include the following technologies:

• Command Line Interface (CLI)
• Git & GitHub
• Ruby
• HTML, CSS, JavaScript
• Databases
• Ruby on Rails
• React
• TypeScript
• GraphQL

Team Placements: Working on Merchant-Facing Projects

After they’ve completed their developer skills training courses, students spend the next three years on team placements. This is a big deal. On team placements, students get to apply what they learn in their developer skills training at Shopify and from their university courses to meaningful, real-world software development work. Our placements are purposefully designed to expose students to a wide range of disciplines and teams to make them well-rounded developers, give them new perspectives, and introduce them to new people.

Working with their placement specialist, students interview with teams from back-end, front-end, data, security, and production engineering disciplines.

Over the course of the Dev Degree program, each student receives:

• One 12-month team placement
• Three 8-month team placements
• Four different technical mentors
• A dedicated Life@Shopify mentor
• Twenty hours per week working on a Shopify team
• Five hours per week of personal development
• Actionable feedback on a regular cadence
• Evaluations from mentors and leads
• High-touch support from the Dev Degree team
• Access to new people and workplace culture

By the time students complete the program, they’ve been on four back-to-back team placements in their final three years at Shopify. This experience makes them a valuable asset to their future company. It also allows students to launch their careers confident that they are well-prepared to make a positive contribution.

It Takes a Village: Building an Impactful Program Team

Creating a successful work-integrated learning program requires a significant commitment of time and resources from a team that spans multiple disciplines and functions. While the Dev Degree program team is responsible for the bulk of the heavy-lifting, including logistics, mentorship, and support, the program doesn’t happen without expertise and time from other Shopify subject matter experts and university stakeholders.

Dev Degree Program Team

The Dev Degree team are the most actively involved in all aspects of the program and with the students from onboarding to graduation. They are responsible for ensuring that the program meets the needs of the students, the university, and Shopify.

Student Success Specialists

Many of the Dev Degree students come to Shopify straight from high school, which can be daunting. In traditional co-op programs, students have a couple of years of university experience before starting their internships and being dropped into a professional workplace setting. To ease the transition to Shopify, our student success specialists are responsible for supporting students’ well-being, connecting them with other mentors, helping them learn how to become effective communicators, and being the voice of the students at Shopify. This nurturing environment helps protect first-year students from being overwhelmed and underprepared for team placements.

Placement Specialists

Team placements are an integral part of the applied learning in the Dev Degree program. Placement specialists are responsible for coordinating and overseeing all placements for each cohort. This high-touch role requires extensive relationship-building with development teams and a deep understanding of the goals and interests of the students to ensure appropriate compatibility. To ensure that development teams get the return on investment (ROI) from investing in mentorship, placement specialists place students on teams where they can be impactful. They also support the leads and mentors on the development teams and play an active role in advocating for an influential culture of mentorship within Shopify.

Educators

The courses we teach at Shopify are foundational for students to prepare them for their team placements. Dev Degree educators have an extensive background in education and computer science and are responsible for building out the curriculum for all the developer skills training courses taught at Shopify. They design and deliver the course material and evaluate the students on technical expertise and subject knowledge. The instructors create courses for a wide range of development skills relevant to development at Shopify and other companies.

Recruitment Team

As with all recruitment at Shopify, we aim to recruit a diverse mix of students to the Dev Degree program. Our talent team is actively involved in helping us create a recruitment strategy to engage and attract top talent from a variety of schools and programs, including university meetups and mentorship in youth programs like Technovation.

Mentors

After four years of having Dev Degree students on teams across twelve disciplines, the program is woven into the Shopify culture, and mentorship plays a big role.

Development Team Mentors

Development team mentors are critical to helping students build confidence, technical skills, and gain the experience needed to become an asset to the team. Mentors are responsible for guiding, evaluating, and providing actionable feedback to students throughout their 8-month placements. Mentorship requires a strong commitment and takes up about 10% of a developer’s time. We feel it’s worth the investment to build mentors and invest in a culture of mentorship. It’s a challenging but rewarding role, and especially helpful to developers looking to grow leadership skills and level up in their roles.

Life@Shopify Mentors

In addition to placement mentors, we also have experienced Shopify employees who volunteer to mentor students as they navigate through the program, their placements, and the company on the whole. These Life@Shopify mentors act as a trusted guide and help round out the mentorship experience at Shopify.

University Stakeholders

Close relationships between the universities and Shopify help integrate the theory and development practices and deepen both the understanding of concepts and work experience. We’re fortunate to have both Carleton and York University as part of the Dev Degree program and fully engaged in the model that we’ve built. The faculty advisors play an active role in working with the students to guide them on their course selections, navigate the program, and evaluate their internship courses and practicums. Without university buy-in and support, a program like Dev Degree doesn’t happen.

Dev Degree is Worth the Investment

Building a new work-integrated learning program requires a big commitment of company time, resources, and cost, but we are reaping the benefits of our gamble.

• Graduates are well-rounded developers with a rich development experience across a range of teams and disciplines.
• 100% of graduates have accepted full-time positions within six months of graduation.
• Students who accept positions at Shopify have already built four years of relationships and have acquired vast knowledge and skills that will help them make an immediate impact on their teams.
• We are building future leaders through mentorship. 

While we are excited about how far we’ve come, we still have room to grow. We are looking at metrics and data to help us quantify the success of the program and to drive program improvements to take computer science education to a new level. When we started this ambitious endeavor, we wanted to mature it to a point where we could create a blueprint of the Dev Degree program for other companies and universities to adopt it and evolve it. There’s interest in what we’re doing here. It’s just a matter of time before we help make the Dev Degree model of computer science education the norm rather than the exception.

The Future of Dev Degree

In 2020, Shopify made the shift to become a fully remote company, opening the doors to potential software engineers from almost anywhere in the world. However, while Dev Degree students have been leveraging remote work for their Shopify-led developer skills training and team placements, they still need to live in the same city as their university campus for their in-person learning. So, starting in September 2021, we’re growing the Dev Degree program to welcome fully remote students from across North America in collaboration with our new educational partner, Make School. Our new remote 3-year program with Make School will provide students with the same hands-on learning and work experience at Shopify that our current students enjoy. Instead of attending in-person classes, the Make School students will attend classes remotely with Make School to attain a Bachelor's Degree in Applied Computer Science.

In September of 2021, we are launching a small pilot program with Make School before opening the program to general admission for September 2022. The main differences for students enrolled in Make School are that they will earn a 3-year Applied Computer Science degree instead of a 4-year Bachelor of Science/Computer Science and will participate in three work placements instead of four. Students will have the same Developer Skills training, mentorships, and team support as those in the 4-year Dev Degree program, as support and mentorship are keys to student success. Stay tuned for more information later this summer on applying for Dev Degree programs for September 2022.

Additional Information

• Dev Degree website
• Learn about the contributions our graduates made:
• Refactoring Legacy Code with the Strangler Fig Pattern
• Ruby on Rails podcast: 313: Strangler Fig Pattern & God Objects with Adrianna Chang

---

We're planning to DOUBLE our engineering team in 2021 by hiring 2,021 new technical roles (see what we did there?). Our platform handled record-breaking sales over BFCM and commerce isn't slowing down. Help us scale & make commerce better for everyone.

Continue reading

As technical leaders and managers, our job is to make the right decision most of the time. Hiring, firing, technology choices, software architecture, and project prioritization are examples of high impact decisions that we need to make right if our teams are to be successful.

This is hard. As humans, we're naturally bad at making those types of decisions. I’ll show you how you can consistently make great decisions quickly using a simple framework called TOMASP. I made up the acronym for the purpose of this blog post but it’s inspired from many great books (see resources) as well as my personal experience of leading engineering teams for almost 15 years.

Let’s start with a concrete real world example:

Michelle, a technical lead for a popular mobile app is agonizing about whether or not she should direct her team to rewrite the app using Flutter, a new technology for building mobile apps.

Flutter has an elegant architecture that should make development much faster without compromising quality. It was created by Google and is already in use by several other reputable companies. If Flutter delivers on its promises, Michelle’s team has a good chance of achieving their goals which seem highly unlikely with the current tech stack.

But starting a big rewrite now will be hard. It’s going to be difficult to get buy-in from senior leadership, no one on the team has experience with Flutter and Mike, one of the senior developers on the team is really not interested in trying something new and will probably quit if she decides to more forward with Flutter.

Before reading further ask yourself, what is the right decision here? What would you advise Michelle to do? Should she rewrite the app using Flutter or not?

I have asked this question many times and I bet most of you have an opinion on the matter. Now think about it, how much do you really know about Michelle and her team? How much do you know about the app and the problem they’re trying to solve? We will get back to Michelle and her difficult decision by the end of this post but first a little bit of theory.

How We Make the Wrong Decisions

“The normal state of your mind is that you have feelings and opinions about almost everything that comes your way”

Daniel Kahneman - Thinking, Fast and Slow

This ability of our mind to form opinions very quickly and automatically is what enables us to make thousands of decisions every day, but it can get in the way of making the best decision when the decision is complex and the impact is high. This is just one of the ways our brain can trick us into making the wrong decision.

Here are some other examples:

• We are highly susceptible to cognitive biases
• We put too much weight on short term emotion
• We are over confident about how the future will unfold (when was the last time your project finished sooner than you anticipated?)

The good news here is that it’s possible, through deliberate practice, to counteract those biases and make great decisions quickly even in complex high impact situations.

“We can’t turn off our biases, but we can counteract them”

Chip Heath, Dan Heath - Decisive

What is a Great Decision?

Before I show you how to counteract your biases using TOMASP, we need to get on the same page as to what is a great decision. Let’s go through a couple of examples.

An example of a good decision:

In 2017 Shopify started to migrate its production infrastructure to Google Cloud ... 

Scaling up for BFCM used to take months, now it only takes a few days✌️.

In my experience this image is the mental model that most people have when they think of great decisions:

A decision has a direct link to the impact

In the previous example the decision is to move to google cloud and the impact is the reduced effort to prep for BFCM.

Now let’s look at an example of a bad decision:

In 2017 Shopify started to migrate its production infrastructure to Google Cloud… 2 years later, Shopify is down for all merchants due to an outage in Google Cloud 😞.

Do you notice how the previous mental model is too simplistic? The same decision often leads to multiple outcomes.

Here is a better mental model for decisions:

A decision leads to execution which leads to multiple impacts. Moreover, things outside of our control will also affect the outcomes

Some things are outside of our control and a single decision often has multiple outcomes. Moreover, we never know the alternative outcomes (i.e. what would have happened if we had taken a different decision).

Considering this, we have to recognize that a great decision is NOT about the outcomes. A great decision is about how the decision is made & implemented. More specifically a great decision is timely, considers many alternatives, recognizes biases and uncertainty.

TOMASP

To put that in practice think TOMASP. TOMASP is an acronym to remember those specific behaviour you can take to counteract your biases and make better decisions.

Timebox (T) the Decision

Define ahead of time how much time is this decision worth.

You Need This If…

It’s unclear when the decision should be made and how much time you should spend on it.

How to Do It

If the decision is hard to reverse, aim to make it the same week, otherwise aim for same day. One week for a “hard to reverse” decision might sound too little time, and it probably is. The intent here is to focus the attention and to prioritize. In my experience this can lead to a few different outcomes:

1. Most likely, this is actually not a hard to reverse decision and aiming to make it on the same week will lead you to focus on risk management and identify how you can reverse the decision if needed
2. This is truly a hard to reverse decision and it shouldn’t be made this week, however there are aspects that can be decided this week, such as how to go about making the decision (e.g who are the key stakeholders, what needs to be explored)

Multiple decisions are often made at the same time, whenever this happens make sure you’re spending the most time on the most impactful decision.

This Helps Avoid

• Analysis Paralysis: over-analyzing (or over-thinking) a situation so that a decision or action is never taken, in effect paralyzing the outcome
• Bikeshedding: spending a disproportionate amount of time and effort on a trivial or unimportant detail of a system, such as the color of a bikeshed for a nuclear plant

Generate More Options (O)

Expand the number of alternative you’re considering.

You Need This If…

You’re considering “whether or not” to do something.

How to Do It

Aim to generate at least 3 reasonable options.

Do the Vanishing Option Test: if you couldn’t do what you’re currently considering, what else would you do.

Describe the problem, not the solutions, and ask diverse people for ideas, not for feedback (yet).

This Helps Avoid

• Narrow framing: making a decision without considering the whole context
• Taking it personally: by truly considering more than 2 options you will become less personally attached to a particular course of action

Meta (M) Decision

Decide on how you want to make the decision

You Need This If…

It’s hard to build alignment with your team or your stakeholders on what is the right decision.

How to Do It

Ask what should we be optimizing for?

Define team values or principles first and then use them to inform the decision.

Look for heuristics. For instance at Shopify we have the following heuristic to quickly choose a programming language: if it’s server side business logic we default to ruby, if it’s performance critical or needs to be highly concurrent we use Go.

This Helps Avoid

• Mis-alignment with your team or stakeholders: I have found it easier to agree on the criteria to make the decision and the criteria can then be leveraged to quickly align on many decisions.

• Poor implementation: having explicit decision-making criteria will make it a lot easier to articulate the rationale and to give the proper context for anyone executing on it.

Analyze (A) Your Options

Make a table to brainstorm and compare the “pros” and “cons” of each options.

You Need This If…

There is consensus very quickly or (if you’re making a decision on your own) you have very weak “pros” for all but one option.

How to Do It

Make your proposal look like a rough draft to make it easier for people to disagree.

Nominate a devil’s advocate, someone whose role is to argue for the opposite of what most people are leaning towards.

Make sure you have a diverse set of people analysing the options. I’ve gotten in trouble before when there were only developers in the room and we completely missed the UX trade-off of our decision.

For each option that you are considering, ask yourself what would have to be true for this to be the right choice.

This Helps Avoid

• Groupthink

• Confirmation bias

• Status-quo bias

• Blind spots

Step (S) Back

Hold off on making the decision until the conditions are more favorable.

You Need This If…

It’s the end of the day or the end of the week and emotions are high or energy is low.

How to Do It

Go have lunch, sleep on it, wait until Monday (or until after your next break if you don’t work Monday to Friday).

Do 10/10/10 analysis: this is another trick I learned from the book Decisive (see resources). Ask yourself how you would feel about the decisions 10 mins later, 10 months later and 10 years later. The long term perspective is not necessarily the right one but thinking about those different timescales help put the short term emotion in perspective.

Ask yourself these two questions:

1. What would you advise your best friend?
2. What would your replacement do?

This Helps Avoid

• Putting too much weight on short term emotions

• Irrational decision making due to low energy or fatigue

Prepare (P) to be Wrong

Chances are, you’re over-confident about how the future will unfold.

You Need This If…

Always do this :-)

How to Do It

Set “tripwires”: systems that will snap you to attention when a decision is needed. For example a development project can be split into multiple phases with clear target dates and deliverable. At Shopify, we typically split project into think, explore, build and release phases. The transition between each phase acts as a tripwire. For example, before moving to build the team and stakeholders review the technical design (the deliverable for that phase) and have to make a conscious decision to continue the project or pause it.

Whenever a phase is expected to be over 4 weeks, I like to break it down further into milestones. Again, it’s essential that each milestone has a clear target date and deliverable (e.g 50% of the tasks are completed by Oct 10th) so that it can act as a tripwire.

You can setup additional tripwires by doing a pre-mortem analysis: imagine the worst case scenario, now brainstorm potential root causes. You now have leading indicators that you can monitor and use as tripwires.

This Helps Avoid

• Reacting too slowly: setting tripwires will help you detect early when things are going off the rails.

TOMASP in Action

At the beginning of this post, I gave the following example:

Michelle, a technical lead for a popular mobile app is agonizing about whether or not she should direct her team to rewrite the app using Flutter, a new technology for building mobile apps.

Flutter has an elegant architecture that should make development much faster without compromising quality. It was created by Google and is already in use by several other reputable companies. If Flutter delivers on its promises, Michelle’s team has a good chance of achieving their goals which seem highly unlikely with the current tech stack.

But starting a big rewrite now will be hard. It’s going to be hard to get buy-in from senior leadership, no one on the team has experience with Flutter and Mike, one of the senior developers on the team is really not interested in trying something new and will probably quit if she decides to more forward with Flutter.

Here is how Michelle can use TOMASP to make a Great Decision Quickly:

• Timebox (T):
• This feels like a hard to reverse decision, so Michelle aims to make it by the end of the week.
• Generate More Options (O):
• Michelle uses the Vanishing Option Test to think of alternatives. If she couldn’t rewrite the whole app using Flutter what could she do?
• Use a hybrid approach and only rewrite a section of the app in Flutter.
• Have the iOS and Android developers systematically pair-program when implementing features.
• Use another cross-platform framework such as React Native or Xamarin.
• Meta (M) Decision:
• What should Michelle optimize for? She comes up with the following hierarchy: 1) cross-platform consistency 2) performance 3) development speed
• Analyze (A) Options:
• Michelle concludes that for Flutter to be the right choice, a developer should be able to deliver the same level of quality in 50% or less of the time (to account for the risk and learning time of using a new technology).
• Step (S) Back:
• Michelle decides to make the decision first thing Friday morning and do a 10/10/10 analysis to ensure she’s not putting too much weight on short term emotion.
• Prepare (P) to be Wrong:
• Michelle decides to timebox a prototype: over the next 2 weeks she will pair with a developer on her team to build a section of the app using Flutter. She will then ask her team members to do a blind test and see if they can guess which part of the app has been rebuilt using Flutter.

That’s it! Even if Michelle ends up making the same decision, notice how much better she’s prepared to execute on it.

Thanks for reading, I hope you find this decision framework useful. I would be very interested in hearing how you’ve put TOMASP to use, please let me know by posting a comment below.

Some great resources:

• Decisive by Chip Heath and Dan Heath
• Thinking Fast & Slow by Daniel Kahneman
• When by Daniel Pink
• Who is in the Room? by Bob Frisch

---

We’re always looking for awesome people of all backgrounds and experiences to join our team. Visit our Engineering career page to find out what we’re working on.

Continue reading

Have you clicked on this article because you’re interested in how Shopify scales its development teams and the lessons we’re learning along the way? Well, cool, you’ve come to the right place. But first, a question.

Are you sure you need to scale your team?

Really, really sure?

Are You Ready to Scale Your Team?

Hiring people is relatively straightforward, but growing effective teams is difficult. And no matter how well you do it, there will be a short-term price to pay in terms of a dip in productivity before, hopefully, you realize a gain in output. So before embarking on this journey you need to make sure your current team is operating well. Would you say that your team:

1. Ruthlessly prioritizes its work in line with a product vision so it concentrates on the most impactful features?
2. Maximizes the time it spends developing product, and so minimizes the time it spends on supporting activities like documentation and debates?
3. Has the tools and methods to ship code within minutes and uncover bugs quickly?

If you can’t answer these questions positively then you can get a lot more from your current team. Maybe you don’t need to add new folks after all.

But let’s assume you’re in a good place with all of these. As we consider how to scale up a development organization, it’s fundamentally important to remember that hiring new people, no matter how brilliant they are, is a means to an end. We are striving to have more teams, each working effectively towards clear goals. So scaling up is partly about hiring great people, but mostly about building effective teams.

Hiring Great People

At Shopify we build a product that is both broad and deep to meet the needs of entrepreneurs who run many different types of business. We’ve deconstructed this domain into problem spaces and mapped them to product areas. Then we’ve broken these down into product development teams of five to nine folks, each team equipped with the skills it needs to achieve its product goals. This means a team generally consists of a product manager, back-end developers, web developers, data specialists and UX designers.

Develop Close Relationships with Your Talent Acquisition Team

Software development at scale is a social activity. That’s a fact that’s often underappreciated by inexperienced developers and leaders. When hiring, evaluating the technical abilities of candidates is a given, but evaluating their fit with your culture and their ability to work harmoniously with their teammates is as important. At Shopify we have a well-defined multi-step hiring process that we continually review based on its results. Technical abilities are evaluated by having the candidate participate in problem-solving and pair-programming exercises with experienced developers, and cultural fit is assessed by having them meet with their prospective teammates and leaders. These steps are time consuming, so we need to filter the candidates to ensure that only the most likely hires reach this stage. To do that, we have built close working relationships between our developers and our Talent Acquisition (TA) specialists.

I can’t overemphasize how important it is to have TA specialists who understand the company culture and the needs of each team. They make sure we meet the best candidates, making effective use of the time our leads and developers. So when scaling up, the first folks to recruit are the recruiters themselves, specialists who know your market. You must spend enough time with them so that they deeply understand what it takes to be a successful developer in your teams. They will be the face of your company to candidates. Even candidates whom you do not ultimately hire (in fact, especially those ones) should feel positive about the hiring experience. If they don’t you may find the word gets around in your market and your talent pipeline dries up.

Aim for Diversity of Experience on Teams

We aim to have teams that are diverse in many dimensions, including experience. We’ve learned that on average it takes about a year at Shopify before folks have fully on-boarded and have the business context, product knowledge and development knowhow to make great decisions quickly. So, our rule-of-thumb is that in any team the number of on-boarded folks should be greater than or equal to the number of those still onboarding. We know that the old software development model where a single subject matter expert communicates product requirements to developers leads to poor designs. Instead, we seek to have every team member empathize with entrepreneurs and for the team to have a deep understanding of the business problem they are solving. Scaling up is about creating more of these balanced and effective teams, each with ownership of a well-defined product area or business problem.

Building Effective Teams

Let’s move on from hiring and consider some other aspects of building effective teams. When talking about software development effectiveness, it’s hard to avoid talking about process. So, process! Right, with that out of the way, let’s talk about setting high standards for the craft of coding, and the tools of the craft.

Start With a Baseline

For teams to be effective quickly, they need to have a solid starting point for how they will work, how they will plan their work and track their progress, and for the tools and technologies they will use. We have established many of these starting points based on our experience so having every new team start again from first principles would be a tremendous waste of time. That doesn’t prevent folks from innovating in these areas, but the starting baseline is clear.

Be Open About Technical Design and Code Changes

I mentioned previously about having the right mix of onboarded vs. still onboarding folks and that’s partly about ensuring that in every team there is a deep empathy for our merchants and for what it means to ship code at Shopify scale. But more, we seek to share that context across teams by being extremely open about technical designs and code changes. Our norm is that teams are completely transparent about what they are doing and what they are intending to do, and they can expect to receive feedback from almost anyone in the company who has context in their area. With this approach, there’s a risk that we have longer debates and yeah, that has been known to happen here, but we also have a shared set of values that help to prevent this. Specifically we encourage behaviors that support “making good decisions quickly” and “building for the long term.” In this way, our standards are set by what we do and not by following a process.

Use Tooling to Codify Best Practices

Tooling is another effective way to codify best practices for teams, so we have folks who are dedicated to building a development pipeline for everyone with dashboards, so we can see how every team is doing. This infrastructure work is of great importance when scaling. Standards for code quality and testing are embedded in the toolset, so teams don’t waste time relearning the lessons of others—rather they can concentrate on the job of building great products. Once you start to scale up beyond a single team, you’ll need to dedicate some folks to build and maintain this infrastructure. (I use the plural deliberately because you’ll never have just one developer assigned to anything critical, right?)

You can read more about our tooling here on this blog. The Merge Queue and our Deprecation Toolkit are great examples of codified best practices, and you can read about how we combine these in to a development pipeline in Shopify’s Tech Stack.

As the new team begins its work, we must have feedback loops to re-enforce the behaviors that produce the best outcomes. From a software perspective, this is why the tooling is so important so that a team can ship quickly and respond to the feedback of stakeholders and users.

 

Use Pairing to Share Experiences

Which brings me to pairing. The absolute best way for onboarded developers to share their experience with new folks is by coding together. Pairing is optional but actively encouraged in Shopify. We have pairing rooms in all our offices, and we hold retrospectives on the results to ensure it adds value. There’s an excellent article on our blog by Mihai Popescu that describes our approach: Pair Programming Explained.

Conduct Frequent Retrospectives

From a team effectiveness perspective, frequent retrospectives allow us to step back from the ongoing tasks to get a wider perspective on how well the team is doing. At Shopify, we encourage teams to have their retrospectives facilitated by someone outside the team to bring fresh eyes and ideas. In this way, a team is driven to continually improve its effectiveness.

At Shopify we understand that hiring is only a small step towards the goal of scaling up. Ultimately, we’re trying to create more teams and have them work more effectively. We’ve found that to scale development teams you need to have a baseline to build from, an openness around technical design, effective tooling, pair programming and frequent retrospectives.

---

Continue reading

For my entire engineering management career, I’ve managed remote teams. At Shopify, I manage Developer Acceleration, a department with both colocated and remote teams with members spread across four Canadian offices and in six countries.

You may think that managing remote teams is hard, and it is, but there are real benefits that you can achieve by being open to remote employees and building a remote team. Let’s talk about the benefits of a remote team, how to build your remote team, and how to set your people up to succeed.

The Benefits of Remote

It’s not a matter of right and wrong with colocated and remote. Either configuration can work and both provide benefits.

Some advantages of a remote team are: 

• expanding to a global hiring pool
• supporting a more diverse workforce
• improving your ability to retain top employees
• adding a location-based team capability

Expanding to a Global Hiring Pool

Hiring well is difficult and time consuming. Recruiters and hiring managers talk about filling the top of the funnel, which means finding suitable candidates to apply or to approach about your role. For specialized roles, like a mobile tooling developer, it can be hard to fill the funnel. A challenge with colocated teams is that your hiring pool is limited to those people who live in the same city as your office and those willing to relocate. A larger pool gives you access to more talent. On my team we’ve hired people in Cyprus, Germany, and the UK, none of whom could relocate to one of our offices in Canada.

More Diverse Workforce

A willingness to hire anywhere also gives access to a more diverse talent pool. There are people who are unwilling or unable to relocate. There are also those who need to work from home. I’ve hired people with mobility issues, people with dependents, such as young children or older parents, and people with strong ties to their communities. They are highly skilled and are excellent additions to our team but wouldn’t have been options had we required them to work out of one of our offices.

Ability to Retain Top Employees

A company invests in each employee that is hired and you want to retain good employees. By being a on remote team, I have retained people who decided to relocate for personal reasons, often out of their direct control. In one case, a spouse had a location-dependent job opportunity that the family had decided to follow. In another, the person needed to be closer to their family for health reasons. I’ve successfully relocated people to Canada, France, the Netherlands, Poland, and the USA. Relocating these high-performing employees is much less expensive than it is to hire and train replacements.

Location-Based Team Capability

A team may also have specific requirements, like 24/7 support, that make it advantageous to distribute people rather than centralize them. My release engineering team supports our build and deploy pipeline for Shopify developers around the world and benefits from having a 24/7 on call schedule without needing people to be on call in the middle of the night.

Building a Remote Team

An engineering manager’s job is to create an effective team. They do this by assembling the right people, defining the problem to solve, and focusing on execution. There’s a key piece in “effective team” that’s often overlooked. A collection of people isn’t a team. A team functions well together and is more than the sum of its parts. This is one of the reasons we don’t hire jerks. Building a team requires the establishment of relationships and trust, which relies on really good communication. Neither relationships nor trust can be mandated. To build the team you need to create an environment and opportunity for people to interact with one another on more than a superficial level.

Shopify has two key cultural values that support remote work:

1. Default to open internally 
2. Charge your trust battery

Default to Open Internally

Defaulting to open is about inclusion both in decisions and in results. At Shopify we encourage sharing investment plans, roadmaps, project updates, and tasks. This means writing a lot down, and making information discoverable, which provides a facility to transfer knowledge to remote workers. It also means being deliberate about when to use asynchronous and synchronous communication for discussions and decisions.

Asynchronous Communication

Asynchronous communication is a best practice and should be your default method of interaction as it decouples each person’s availability with their ability to participate in discussions and decisions. People need to be able to disconnect without missing out on key decisions. Asynchronous communication frees people by giving them time to focus on their work and on their personal life. My team has discussions via email or GitHub issues. Longer-form ideas and technical design documents are written and reviewed in Google Docs. Once we start building, day-to-day tasks are kept in GitHub issues and Project Boards. Project updates and related decisions are captured in our internal project management system. I’ve listed a number of tools and that we use, but tools won’t solve this problem for you. Your team needs to choose communication conventions and then support those conventions with tools.

Synchronous Communication

When building teams there is also a place for synchronous communication. My teams each run a weekly check-in meeting on Google Hangouts. The structure of these meetings varies but typically includes demos or highlights of what was accomplished in the last week, short planning for the next week, and a team discussion about topics relevant that week. When managing a team across multiple time zones, common advice is to share the pain by moving the meeting time around. In my experience the result is confusion and people regularly missing the meeting. Just pick one time that is acceptable to the people on the team. Set attendance as a requirement of being on the team with new people before they join even if the meeting time is outside of their regular hours.

My teams are generally built so that everyone will be working at the same time during some portion of the day. These core working hours are an opportunity to have synchronous conversations on Slack or ad hoc video meetings as needed.

Charge Your Trust Battery

Shopify is a relationship-driven company. The Trust Battery is a concept that models the health of your relationships with your co-workers. Positive interactions, like open conversations, listening to others, and following through on commitments, charge the battery. Negative interactions, like being insensitive, demanding, or doing poor work, discharge the battery. This concept brings focus to developing relationships and pushes everyone to revisit their relationships on a regular basis.

Trusted relationships don’t just happen, but they can be given a push. Be open about yourself and encourage people to share details about themselves that you’d typically get with “water cooler” conversation. To facilitate this sharing, I set up Geekbot to prompt everyone on my team in Slack each Monday to answer an optional short list of questions such as

• What did you do this weekend?
• What’s something that you’ve read in the last week?
• Any upcoming travel/vacation/conferences planned?

Participation is pretty high, and I’ve learned quite a lot about the people I work with through this short list of questions. Personal details humanize the people on the other end of your chat window and give you a better, multidimensional view of the people on your team.

Lastly, get people together in person. Use this sparingly as it can be a big request for people to travel. Pick the times when your team will get together. If you have a head office, that is typically a good anchor point. If not, consider selecting different places to share the travel burden. Support people who need it to make these in person sessions possible. For example, if a support person is required for a team member to travel, the cost of their trip should include the cost of the support person. Respect people’s time and schedule by being clear about the outcome of the onsite. Relationship building should be a component of the trip but not the only component. On our team we use our two yearly onsites for alignment and to leave people inspired, appreciated, and recognized. We also carve out time that teams can use to plan and code together in person.

Setting People Up for Success

Remote workers benefit from support from their managers and company. Work with them to set up a healthy work environment, give them regular attention and information, and champion them whenever you can.

Healthy Work Environment

You want your people to be effective and do their best work, so work with them to ensure that they have a healthy working environment. Reinforce the benefits of having a good desk, chair, monitor, mouse and keyboard, and a reliable internet connection. Speak with them about identifying a place that they can designate as their “office” and how to create a separation between work and personal time when their office is in their home. Some people are good at separating these parts of their life. Others need a ritual, like walking around the block, as the separator. Establish their regular working hours so that you are both in agreement about the hours that they are working and when they are not.

Connection Through Communication

People outside of an office need help to maintain their connection to the company and to you. They’ll miss out on any hallway chatter at an office and other in-person conversations like those that happen at lunch. I have a weekly one-on-one with my employees to provide them with a steady stream of information to keep them informed. I try to bring relevant information to all of my one-on-ones by preparing in a shared agenda in advance. I also ping people regularly on Slack with more timely information about the people on their teams, updates about our shared work, and to keep in touch throughout the week. If you do have an office, discuss whether spending some time there each year makes sense for them and seems like a worthwhile investment for you both. One person requested to be in the office for three weeks a year. To me, saying yes to this request was an investment in them and their future with the company.

Champion Your People

Remote people can fall into the trap of being out of sight and out of mind. Be a champion for your people. Ensure you use their name and highlight good work to your manager, your peers, and to your team. Give them credit, recommend them for relevant opportunities, and speak up on their behalf. Coach them on how to be more visible. Building relationships and working with others takes time and effort. Ultimately, their visibility depends on them and you and is important for their career progression and long-term retention.

Remote Is Worth the Effort

Building and managing a remote team takes effort to keep your team engaged, provide opportunity, and ensure that each person and the team is set up for success. You need to define your methods of communication, and deliberately stay in touch throughout the week. If you’re willing to put in the work, you can benefit from the hiring, composition, retention, and strategic benefits that a remote team provides.

---

We’re always looking for awesome people of all backgrounds and experiences to join our team. Visit our Engineering career page to find out what we’re working on.

Continue reading

Meet Kirsten Westeinde, she’s a Development Manager based in San Francisco, California. She’s been working at Shopify for just over five years now and has seen the ebbs and flows of the company as it’s continued to scale dramatically over the years.

Continue reading

Behind The Code is an ongoing series where we share the stories of Shopify developers and how they’re solving meaningful problems at Shopify and beyond.

In celebration of International Women’s Day, we’re featuring three female developers from various backgrounds sharing their experiences navigating a career in the tech industry and as well as their work and accomplishments at Shopify.

Developer Stella Lee on The Importance of Female Mentorship and Dealing with Adversity in the Technology Industry

Stella Lee is a developer working on the Shopify Checkout Experience team. The team is responsible for converting a merchants customer’s intent to purchase a product into a successful purchase, and making the buying experience as smooth as possible. She primarily works on building features aiming to eliminate friction for the buyer by allowing them to reuse their information and reduce the number of fields they need to fill out manually, using Typescript and Ruby. When she’s not busy writing code, she’s the founder and co-lead for Shopify’s internal women’s Employee Resource Group (ERG), f(empower), which is supported by our Employee Experience, Diversity and Belonging team and has an executive sponsor. The group works with teams across the business to enable a work environment with equal access to opportunity and supports women to achieve their full potential. The ERG is open to all employees of Shopify and allows a safe space to vocalize the collective experiences and difficulties women in tech face.

When asked what does International Women’s Day mean to her, Stella mentions she never saw the value of needing a specific day to celebrate what should be celebrated every day, but she’s warmed up to it. “The reality is, we still have a long way to go and days like today give people the opportunity to celebrate and learn how each of us can make a positive impact for women. This year, I want to take the opportunity to celebrate the achievements of my fellow ladies in tech, reflect on the current state of gender parity in the industry, and outline concrete ways to advocate for women.”

Dealing with Imposter Syndrome and Learning the Importance of Self-Advocacy

One of the reasons Stella feels so strongly about empowering other women is because she grew up with a mother who she describes as a true inspiration. After leaving behind a great education and career, her mother uprooted the family from their native home in South Korea to Canada in hopes of providing a better life for her family. “She’s the most selfless, strong and caring person that I’ve ever met. She’s the only person I’ve ever met that acts in the best interest of her children without ever expecting anything (not even an ounce of recognition in return). Her unrelenting positivity and resilience in the face of adversity time and time again is truly inspiring.”

Growing up with such a strong role model has played a part in her development and ability to navigate the workplace. She expresses the importance of women advocating for themselves in a way where they can achieve their career goals. “You can't expect anyone else to take charge of your professional development, so you need to own that and figure out what it is you need to grow.” She believes the best way to do this is to ask for the opportunities needed to develop your skills like asking to own a feature of a project, or even to champion one.

Aside from learning how to advocate for herself, Stella has had to learn how to maneuver through her feelings of imposter syndrome, an inability to internalize accomplishments and a persistent fear of being exposed as a fraud.  Imposter syndrome is something that countless people face in many different professions, no matter how far one is in their career. For Stella, these feelings began when she switched to computer science halfway through completing her Bachelor degree. “I didn’t have the full educational background nor the internship experiences that many of my colleagues or other developers had and with the emphasis of gender parity and the importance of diversity in tech, there are times when I’ve wondered if the only reason I’ve occupied a space filled with male developers was because I was a woman.” She goes on further to describe her experience attending various external engineering events where people assume she’s in a non-engineering role or comment that she doesn’t look like a developer. “Previously, I would just internalize these experiences as validation that I didn’t belong within this space. I definitely still struggle with imposter syndrome, but the consistent practice of recognizing and transforming my negative thinking patterns through thought work has helped immensely for my confidence.”

Transforming “Stupid” Questions into Good Questions

Learning how to ask good questions has been her bread and butter since working as a developer, but she believes you can only do this by asking stupid questions first because they’ll eventually become better questions. “Figure out what you don’t know by asking yourself what questions you have, set a timebox, and then take a stab at asking them to yourself or researching the question. I’m a very independent person and I find it hard to ask for help when I know that I’ll eventually find the answer, but I learned later on that doing this wasn’t the best use of my time.” A key to asking questions is to start by stating what you already know, then diving deeper into investigating how to solve that problem. “This shows you’ve done your homework, and it helps the person formulate a more intentional response that isn’t too basic or too advanced.”

Remote Developer Lead Helen Lin on Effective Ways to Manage People and Teams

Helen Lin works remotely in Vancouver, BC as a Lead Web Developer on the Themes team for the Shopify Online Store. The Themes team is responsible for helping our product lines to integrate features into the online store, using Javascript, Nodejs, Liquid, Ruby, and SQL. Aside from providing free themes for our merchants, her team also establishes proper standards for making features more accessible and improving web performance.

Managing People Through Alignment and Stakeholder Management

As one of the few remote technical leads at Shopify, Helen shares with us some insights into how she manages her team, “I think the makings of a good lead mainly lies on your ability to understand your different reports and effectively give direction as to how a project needs to be run. If you don’t understand the long term vision of your company and don’t know how to map out what tasks need to be accomplished, then misalignment can occur leading to low team morale and poor communication.” She periodically flies down to see her team and connect and with all of her reports and stakeholders on the current project she’s working on, allowing her to build strong relationships with the people she works with. She also explained that managing people is one of the most challenging things she’s ever done but she finds it very rewarding. “ I won’t say it hasn’t come with some difficulties, because it definitely has, but learning how to empower people and communicate with people with different personalities and disciplines, has taught me the importance of staying connected and aligned.”

Self-Advocacy and Sharing Accomplishments

Some people struggle with getting aligned with their managers about their personal development and career goals; advocating for themselves is a struggle. For someone like Helen, who’s been working for a number of years now, she feels when advocating for yourself it’s important to directly ask for what it is that you want. For her, self-advocacy is when she can push past her boundaries and do things she thought impossible. “Fighting through that internal fear and challenge is far more powerful than anything I have ever experienced. Now, I take that experience and find ways to help others to advocate themselves through sharing my stories of perseverance in the face of adversity.” She also invests time helping people narrow down their aspirations and figure out what they’re passionate about. “When there is a clear vision of what you want then self-advocacy becomes easy because it's what you want to do and not what other people want you to do.”

Asking Questions and Staying Curious

For those interested in pursuing a career as a developer, she stresses how important it is to understand that asking questions and staying curious is a positive thing. “ One of the best advice I’ve gotten was that I should understand that as human beings we all make mistakes, period. Regardless of if you’re a junior or senior developer, you're bound to mess up at some time. It’s not about trying not to make mistakes, but about how you can fix the mistake and move forward from it.” Building resiliency is a great muscle to flex and not being afraid to ask questions and make mistakes are only going to make you a better developer, so don’t be afraid to speak up.

Web Developer Cathryn Griffiths on Making Career Pivots and Creating an Inclusive Space in The Technology Industry

Cathryn is a web developer working on the Checkout Experience team, which is responsible for making a customer’s purchase experience as smooth as possible. She’s currently acting as a champion on a project and is in charge of making sure decisions are made, deadlines get met, and work gets done. This is her first time championing a technical project, so it comes with certain challenges, but she has a strong network within her team to help her navigate this new experience.

As someone who has pivoted careers a number of times, Cathryn knows all about how difficult it can be to switch careers and find what you’re passionate about. She’s gone from pursuing a career in academia to working in the private sector as a clinical trial project manager. “After realizing I didn’t have a passion for working in health sciences, I decided to go back to school and gave programming a shot after hearing about the exciting and challenging work that a programmer does. I enrolled in a Bachelor of Computer Science at Concordia University and by my third semester, I had secured a role as a Front-End Developer so I stopped pursuing my BCompSc and started working full-time.”

Finding Her Passion and Changing Careers

Maneuvering through different industries was not an easy thing to do, but she managed by always being open to discovering what work she actually enjoyed doing. However,  making the switch to the technology industry specifically comes with its own challenges, especially as a woman pursuing a career in a male-dominated field. “When I left my first programming job to go to my second one, I hesitated a lot about moving on to the new job because I was afraid I might get stuck in a toxic work environment where my gender would be a problem. That same feeling, that reluctance, hesitation, and nervousness happened again when I thought about leaving my previous job for Shopify. Luckily, in both cases, I ended up in fantastic, supportive work environments.”

We also asked Cathryn how the technology industry can make this space more inclusive for all especially with her experience with making the switch into tech. “On a larger scale: the more diverse our industry can be, the more inclusive it can be too. We have to hire more minorities, and have a workforce with a diverse array of races, ages, genders, sexualities, and ethnicities.” Diversity in the workplace has been proven to be very beneficial to companies, and various companies have initiatives in place to promote a more inclusive workplace and have a more diverse workforce. When asked what companies can do on a day-to-day basis to promote inclusivity, she said “On a smaller scale, something I love that Shopify does is that every meeting room has a paper pyramid, that sits right on the meeting table to help guide a more inclusive discussion. Each face of the pyramid poses a question or statement to ensure people’s voices are being heard during meetings, whether online or in person. For example, ‘Overtalking is real. Go back to the person who was interrupted and let them finish.’” These pyramids are about cultivating a space where people feel comfortable speaking up and people become mindful of speaking too much. So for someone like Cathryn who is newer to the company, she feels included in the conversation and supported by her fellow coworkers.

Advice for People Looking to Switch Careers

As someone who spent years establishing herself in different career paths, she began asking herself questions like, “What are my goals?”, “What do I want to accomplish at the end of the day?” and “I’m I enjoying my work?”. Asking herself these types of questions were pivotal in helping to discover which career she was the most passionate about.

Final Thoughts

“Work hard and embrace feedback. Own your accomplishments, be proud of them, and don’t be afraid to tell others about them. Additionally, own your failures and don’t be afraid to acknowledge them — it’s only by acknowledging them that you can grow from them.”

---

At Shopify, we’re committed to designing a workplace that challenges and supports employees to hone their craft and make meaningful impact for entrepreneurs around the world. We know that in order to build a platform that will ‘make commerce better for everyone’, we need to have a diverse team building that product and are committed to fostering an inclusive work environment that harnesses differences and brings the best out of each and every individual.  

We’re always looking for awesome people of all backgrounds and experiences to join our team. Visit our Engineering career page to find out what we’re working on.

Continue reading

Shopify is a commerce platform that serves over 600,000+ merchants and employs over 3000 people across the globe. We’re always on the lookout for highly skilled individuals with diverse backgrounds to join our team, and that requires us to connect with them outside traditional recruitment channels. That’s why last year we ran the “Build Things, Show Shopify” initiative inviting developers outside of Shopify to build an app and showcase their finished product to a multidisciplinary panel of Shopify employees as well as in front of hiring managers and VCs. The outcome? Not only did we build a local developer community in Ottawa, but we added a number of potential hires to our recruiting pipeline.

Continue reading

Lawrence Mandel is a Director of Production Engineering leading Shopify’s Developer Acceleration team and has been at Shopify for over a year. He previously worked at IBM and Mozilla where he started as a software developer before transitioning into leadership roles. Through all his work experience, he’s learned to understand the meaning of time management and to prioritize the most important things in his life, which are his family, health, and work.  

Continue reading

Mohammed’s feature is part of our series called Behind The Code, where we share the stories of our employees and how they’re solving meaningful problems at Shopify and beyond.

Mohammed Ridwanul is a software engineer on the Eventscale team and joined Shopify a year and a half ago.

Mohammed grew up in Dubai but was born in Noakhali, a small village in Bangladesh before moving when he was five. The village was far-removed from technology — most of the areas had no electricity, and you could count the number of TVs with one hand. The people of Noakhali were extremely practical and had ingenious solutions to the problems that would arise. Adults who had an engineering education or background were highly-regarded for how they improved the quality of life in the village. This inspired and motivated Mohammed to pursue a career in engineering, and he hopes eventually, to impact communities the way those individuals did to his.

What has your career path looked like?
I’ve had the opportunity to work in different industries including sales, advertising, and design. Also, I’m an avid musician and love making my own music and doing shows with my band. With all these different skills, I thought perhaps I could make my own game. While trying to learn everything I could about game development, I wrote my first line of code which was in C#.

All my experiences have one thing in common; I love to face tough challenges and see a rapid manifestation of the things I do or build. So, I studied engineering and got an internship working at Shopify during my undergrad which turned into my current full-time role.

What type of Engineering did you study?
I went to the University of Waterloo and took a Bachelor of Applied Sciences in Electrical Engineering.

What does your team do at Shopify?
The Eventscale team is part of the Data Platform Engineering organization. Shopify receives an immense amount of data. Acquiring such large amounts of data so that we can clean, process, reliably store, and provide easy access for analysis, requires highly performant specialized tools and infrastructure. The Data Platform Engineering team are responsible for building these tools.

The Eventscale team builds the tools, libraries, and infrastructure to collect event-oriented streaming data. This data is used for both internal and merchant analytics and other operational needs. We build for all platforms at Shopify including web, backend, and mobile.

What was something difficult for you to learn, and how did you go about acquiring it?
During my first time leading a team project, I had some challenges learning useful team management principles. Like understanding the needs of each team member, aligning everyone to a shared vision and goal to get the work done, required a different set of skills which took time and experience to learn. Luckily my senior co-workers consistently mentored me and taught me concepts such as project cost estimates, team management strategies, success metrics, and other fundamental project management principles. My team lead also guided me towards several books and whitepapers from other companies which have helped me develop strong opinions related to project management and strategy. Check out my Goodreads profile for a list of those books and read Ben Thomson's work on Stratechery.com.

How does your daily routine help you cultivate a good work ethic?

Habits, in my opinion, are useful in navigating life. I believe humans are creatures of habits; it’s challenging to have a constant cognitive load to tell yourself to do x, y and z tasks that are good for you. Instead, by building a habit, you reduce the load as your body and mind start to realize that this is a way of life. My daily routine helped me achieve this habit formation.

What’s your favorite dev tool?
VIM. It has a learning curve, but you can have so much fun with it once you learn it. VIM is an editor you can mold into your own little product; personalized for you with custom configurations using dotfiles. You can pretty much make it behave however you want. I love it! If you’re interested, feel free to check out my custom VIM settings.

What’s your favorite language and why?
Java, mostly because it’s a strongly typed language, and to this day I prefer explicitly defining types without having the language make assumptions on types.

Are you working on any side projects?
Yes, I’m working on an enterprise project management software that can be used by a consulting team to manage a large number of projects in parallel. Essentially, it’s a centralized repository for all the current projects that the consultants are handling, along with the cost breakdown and timeline details. Also, it allows the user to dig into each project further and keep records of how human resources are applied. The software tries to enforce a framework of thinking about resource management and project strategy which I have developed over the years.

What are some ways you think through challenging work?
Writing things down on paper has been my go-to method to work through challenging things. I don’t start writing code until I’ve designed the overall larger components on paper. Similarly, for any other situations in life, writing has always helped me tackle challenges.

What book(s) are you currently reading?
Designing Data-Intensive Applications by Martin Kleppmann and The Essential Rumi by Rumi.

What is the best career advice you’ve gotten?
It doesn’t matter what you do as long as it meets two criteria: 1. It positively impacts society and is aligned with your values, and 2. It allows you to push and grow yourself by doing work to the best of your abilities.

What kind of advice would you give to someone trying to break into the technology industry?
I’m a big fan of the “T” model of learning, which essentially states that you should try and be competent in a few different things (small horizontal line), but you should strive to be the authoritative figure for at least one thing (longer vertical line). Programming might be the tool used to solve tough engineering problems, but the ability to solve problems is the more critical skill. So focus on chiseling that ability which comes with exposure and specialization in one specific area.

If you’d like to get in touch with Mohammed, check out his website www.mohammedri.com.

We’re hiring! If you’re interested in joining our team, check out our Engineering career page for available opportunities.

Continue reading

When I decided to study computer science at university, my parents were skeptical. They didn’t know anyone who had chosen this as a career. Computer science was, and still is, in its infancy. Software development isn’t pure science or pure engineering — it’s a combination of the two, mixed with a remarkable amount of artistic flare. It's a profession where you grow by learning the theory and then doing. A lot of doing. It’s a profession that’s increasingly in demand. And it’s a profession so new that schools are still learning how to teach it. The supply isn’t matching the demand; not even close.

Our industry is fraught with critical shortages of skills and diversity — software developers are more valuable to companies than money [1]. It’s pretty obvious, we have to aggressively invest in growing and developing software professionals more than ever.

Shopify has figured out an important part of how to solve these problems. We call it Dev Degree — a work-integrated learning (WIL) program that combines an accredited university degree with double the experience of a traditional co-op. The program is already in its 3rd year, and it’s time to talk about why it’s a big deal to us.

The Beginnings of Dev Degree

While living and working in Australia, my company invested in hiring hundreds of graduate developers. The graduates were intelligent and knew their theory, but they lacked the fundamental skills and experience required for software development. This held them back in making quick impacts to our small but growing company.

To fill in the gaps, we developed an internal training program for new graduates. It helped them level up faster and transitioned best practices they learned in school into practical skills for the world of software development. It wasn’t long before I recognized that this knowledge gap wasn't an isolated incident. There wasn’t just one university churning out students ill-prepared for the workforce, it was a systemic issue.

I decided to tour Australian universities and talk to their Computer Science departments. I pitched the idea of adding pieces of our training program to their curriculum to better prepare students for their careers. My company even offered to pay to develop the program. The universities loved the idea, but they didn't know how to make it a reality within their academic frameworks. I saw many nods of agreement on that tour, but no action.

Dev Degree started, in earnest, when I returned to Canada and joined Shopify. The main lesson I learned from Australia was that universities couldn’t implement a WIL curriculum without industry partners in a true long-term arrangement. Shopify seemed born to step into that role. When I approached Tobi with this embryo of an idea, he was on board to make it a reality. Tobi had his own positive experience with apprenticeships in Germany. Our shared passion for software development and Canada motivated us to give this idea another shot, and we started searching for a university partner.

Canadian universities were eager to get involved, but again, most weren’t sure how to make it happen. For many, the question was: how is this different from our co-op program?

The co-op model is straightforward. Students alternate between a school term and a work term throughout their program. In this structure, students are thrown over the wall of academia into an industry with no connection to their curriculum. WIL, on the other hand, requires a structural change to the education system that creates a fully integrated and deep learning experience for the students. To do this properly, we needed to make changes to the curriculum and assessments, fully integrate universities and companies, launch new learning programs, and provide additional student support. This was a multi-dimensional problem.

Carleton University rose to the challenge, becoming the first and founding university partner of Dev Degree. Their team understood the value of WIL and were already exploring ways to incorporate this style of learning when we met. It was clear to both sides that we had found the perfect partner to make WIL a successful reality. We were both eager to innovate and weren’t afraid to make huge structural changes to our operations.

Carleton didn’t just talk about being involved, they developed an entirely separate stream of their Bachelor of Computer Science program that allocated over 20% of credits to student practicums. This required Carleton’s Senate approval, which was granted after thoughtful debate. Our first strong partnership was formed and we were ready to get started.

Inside Dev Degree

The core of the Dev Degree model is building tighter feedback loops between theory and practice while layering programming and personal growth skills early on. Each semester students take 3 courses at University and spend 25 hours a week at Shopify.

Because K-12 software education is lacking, we wanted to turbo-boost students to be able to write and deploy production software, solving real problems, before they even graduate. Our bet was that this model would better engage a more diverse set of students, empower deeper understanding, and foster more critical thought when building software.

These types of challenges are not part of the university curriculum — students can only get this experience in an industry setting. Thomas Edison said innovation is 1% inspiration and 99% perspiration. By that measure, Dev Degree is a real-time training program in experimental perspiration.

But there’s also a strong link to validating that competencies are acquired. The partner university allocates at least 20% of the degrees credits for their work done with Shopify development teams. Students write a practicum report at the end of every term (every four months) and submit the practicum report to the university. In the practicum, the student describes how they have achieved specific learning outcomes. The learning outcomes used in the Dev Degree program were influenced by standards from the Association for Computing Machinery (ACM) and the IEEE Computer Society.

During the first two years, we learned a lot. It wasn’t a smooth ride as we ironed out how best to deliver this program with the University, Students, and teams in Shopify. Here are some of the most important lessons we’ve learned.

Key Lesson #1: Re-Learn True Collaboration

During our school career, we learn that the final mark is most important. We strive to deliver the perfect assignment to get that A+. This is the complete opposite of how to get good results in the real world. The best students, and the most successful people, are the ones who share their ideas early, get feedback, experiment, explore, re-compose, and iterate. They embrace failure and keep trying.

The end result is important, but you have to cheat to get the best version of it. Sounds counterintuitive, I know. But by “cheating,” I mean asking people for help and incorporating the lessons they teach you into your own work. Collaboration is a prerequisite for true learning and growth. The Lone Wolf mentality instilled in students from years of schooling is more difficult to change than we anticipated, but working directly alongside other developers, pairing regularly, allowed us to break down those habits over time.

Key Lesson #2: Start with Development Skills

Our first cohort joined Shopify after three months of Developer Skills Training, based on the ACM framework I mentioned. This was quite ambitious on our end, but we hoped it was enough time to prepare them for the real-world work they would do with our teams.

It wasn’t. After the three months, our students still didn’t have enough knowledge to make a strong impact at Shopify. To better support them, our Dev Degree team hosted additional workshops on various developer tools and technologies to get them up to speed, but we knew there was more to be done.

It was clear that we needed to pivot the first year of our program to focus more heavily on Developer Skills Training. Our students needed to be better prepared to enter a fast-paced team building impactful products. Now, Dev Degree students participate in Developer Skills Training for their entire first year at Shopify. By tripling the amount of time they spend in training, we’ve seen Dev Degree students create earlier and more positive impacts on Shopify teams.

Key Lesson #3: Mentorship Comes in Many Forms

In 2016, students were paired with technical mentors once they joined a development team. The technical mentor is a software developer who guides their mentee on a daily basis by giving direction, reviewing work, offering feedback, and answering questions. While this was successful, we identified a gap where we weren’t equipping students with the tools and support they needed to transition into the workforce. We were giving them tons of technical support, but that didn’t necessarily help them conquer the social aspects of the job.

Now, Dev Degree students receive an additional layer of mentorship. Each student is paired with two people: a technical mentor and a Life@Shopify mentor. The Life@Shopify mentor is a trusted supporter, friend, and guide who provides a listening ear and supports the student’s growth. It’s a big leap to go from high school to being a trusted member of a company. We’ve found that this combination provides students with a diverse range of support throughout their time at Shopify.

The Results

To put it bluntly, the Dev Degree model works.

We see above average retention rates compared to traditional academia. Generally, 20-50% of students dropout of their initial program or from postsecondary programs completely. In Dev Degree, our retention rate is 95%. We’ve increased gender diversity in the program, with women accounting for over 50% of Shopify Dev Degree students — a dramatic rise from the 19% of women graduating with a computer science degree.

Companies have been focusing 66% of their philanthropic tech education on K-12 programs, with only 3% on post-secondary programs. But we need to look at the entire education system to solve the skills shortage and lack of diversity in STEM programs. And it needs to happen faster.

Traditionally, new graduates hired at Shopify take anywhere from six months to two years to fully complete onboarding and start making an impact on development teams. Skill acquisition in our WIL program happens three times faster than the average developer education: Dev Degree students become productive members of their teams after only nine months into the program, instead of up to two years after graduation.

We have a lot more to learn, and we’re not done yet. While we’re excited by our early results, a true measure of success will be seeing more universities and industry partners adopt this model. We’re working to scale the program with our partners so that the Dev Degree model starts popping up all over Canada.

That’s why we’re excited to announce the expansion of our Dev Degree program to York University’s Lassonde School of Engineering! Our first Toronto-based students have started their journey with Dev Degree, and we’re excited to see what challenging problems they’ll solve.

None of this would be possible without our academic partners at Carleton and York who worked relentlessly to get Senate approval for new WIL computer science streams and design the model itself. We truly believe that if more universities worked hand-in-hand with industry to better prepare students for the workforce, Canada would become the leader in talent development for years to come.

Continue reading

Behind the Code is an initiative with the purpose of sharing the various career stories of our engineers at Shopify, to show that the path to development is non-linear and quite interesting. The features will showcase people just starting their careers, those who made career switches, and those who've been in the industry for many years. Enjoy!

Continue reading

At Shopify, we pride ourselves on our people. Shopifolk come from all kinds of backgrounds and experiences — our interns are no exception. So, we gathered some of our current and past interns to chat with them about their careers so far. They share insights about work, education, and tips for interviewing and succeeding at Shopify.

Natalie Dunbar (Backend Developer Intern, Marketing Technology)

Office: Toronto

Education: University of Toronto

Get to know Natalie:

• Studied as a philosophy major for three years, then switched to Computer Science
• Former camp counselor and sailing instructor
• Best tip when stuck on a problem? Pair programming.

What does your day-to-day look like?
Once I get to work I immediately open GitHub and Slack. Our team does a daily stand-up through Slack to review our tasks from yesterday and today. My morning is usually responding to PR comments, Slack messages, and working on my assigned tasks. After lunch, I work on projects and usually try to merge my work from earlier in the afternoon to monitor it in production. Finally, before I leave I try to update my PRs so that our team in San Francisco can view them before the end of their day.

What do you feel was the hardest part of your interview?
I've done many technical interviews before, and the “Life Story” step in the Shopify interview process is unique from other companies. I was unsure what to expect. Looking back, I realize it’s not something to worry about because it's an incredibly comfortable conversation with your recruiter that gave them the knowledge to place me on a team that was the best possible fit.

Dream career if you weren’t working in tech?
Philosophy professor (specializing in either logic, philosophy of language, or continental philosophy).

Best piece of advice you’ve ever gotten?
Always be open with your mentor/lead. They want to make your internship experience great so always help them do this for you. This means both requesting and giving feedback frequently.

What are your tips for future Shopify applicants?
Be yourself! And if you are applying for a role that requires a personal project, show one that is targeted at what you’re interested in working on. I made a completely new project over the few days before my internship, which is in no way necessary, and my interviewer (and now lead) was able to determine my technical fit from that.

Gurpreet Gill (Developer Intern, Products)

Office: Ottawa

Education: University of Waterloo

Get to know Gurpreet:

• No experience of technical stack used at Shopify when hired
• Can move ears on command
• Best tip when stuck on a problem? Take a break.

What does your day-to-day look like?
I’m usually in the office by 8:30, and I try not to miss breakfast. I typically avoid coding in the morning. Instead, I review and address feedback on my PRs; read emails; and catch up on work. My team and I head to lunch, then I start coding in the afternoon. I like taking a coffee break in the afternoon at Cody’s Cafe (yes, Ottawa has its own cafe) and make myself a latte with terrible latte art. I also like to play ping-pong as a break!

Dream career if you weren’t in tech?
A chef, or police officer.

Best piece of advice you’ve ever gotten?
Asking for help is okay - it doesn’t make you look weaker, and it’s never too late to reach out for it.

What are your tips for future Shopify applicants?
I believe Shopify is a unique company. Having “people skills” is as important as having technical skills here. So just be yourself during interviews. Don’t pretend to be someone you are not. Be passionate about what you do. Ask questions, don’t be afraid to crack jokes, and be ready to meet some dope people.

Joyce Lee (Solutions Engineering Intern, Shopify Plus)

Office: Waterloo

Education: University of Western Ontario

Get to know Joyce:

• Started interning at Shopify in September 2017
• Spent 8 months at Shopify in a sales-focused role, but will spend next 4 in a technical one
• Once tried to sell composting worms online, but inventory sourcing and fulfilment ended up being really complicated.

What’s your day to day like?
Grab a bottle of cold-pressed juice, then go to a full day of meetings selling Shopify Plus to prospective merchants. On days with fewer meetings, I’m building proofs-of-concept for merchants, and working on small projects to level up the revenue organization.

The hardest part of your interview?
I had a slightly different technical interview than other engineers. I was given a business problem and asked to propose a technical solution for it. Then explain it twice to two different audiences: a CEO and a developer.

Any tips for future Shopify applicants?
Complete every part of the application. For interns, it’s typically quite long so start early, but the application actually helps you know Shopify better, which is a great experience. Shopify is worth the long application process, trust me.

How do you succeed within Shopify?
Ask dumb questions, and ask them quickly. The more you ask, the less dumb they’ll get.

Yash Mathur (Developer Intern, Shopify Exchange)

Office: Toronto

Education: University of Waterloo

Get to know Yash:

• Has done two work terms with Shopify
• Demoed an Android app when interviewing for a front-end developer role at Shopify (Spoiler alert: it all worked out!)
• Favourite language is C++ but has learned to love Ruby for its simplicity (and because Shopify has great Ruby on Rails developers to learn from!)

What does your day-to-day look like?
I come in to the office around 10am. I prefer that because I like to spend my mornings running or swimming, and the rest of my team usually comes in around then too. I start off the day by grabbing breakfast and going through emails and messages. Our team does a daily stand-up where we review what we’ll be working on that day. Then, I like to grab lunch with my team or the other interns. Each day is a mix of coding and meetings to discuss projects or pair-programming. During my breaks, I love playing FIFA or ping pong with others.

Dream career if you weren’t in tech?
Astronaut.

Any tips for future Shopify applicants?
Shopify looks for people who are passionate and willing to expand their skill set. Make sure you bring that point across each phase of the interview.

How do you succeed within Shopify?
Take initiative. Shopify has a startup culture - people won’t tell you what to do, so you have to look for ways to contribute and be valuable. Also, talk to people outside your team. It’s important to understand how your team fits within the rest of the company.

Jenna Blumenthal (Developer, Channels Apps)

Office: Toronto
Education: McGill University

Get to know Jenna:

• Former Shopify intern
• Started as an intern in January 2017, and was hired full-time in May 2017
• Studied Physics and Physiology in undergrad, later completing a master’s degree in Industrial Engineering

What’s your day-to-day look like?
Most of the day is spent working on net-new code that will contribute to whatever feature or project we are building. The rest is spent on reviewing other team member’s code, investigating bugs that come in through support and pairing with others (devs or not) on issues.

Any tips for future Shopify applicants?
Play up your non-traditional background. Whoever you meet with, explain why your experiences have shaped the person you are and the way you work. Shopify thrives on people with diverse skills and opinions.

How do you succeed within Shopify?
One of the core tenets you hear a lot at Shopify is, “strong opinions, weakly held.” Don’t think that because you’re just an intern, or new, that you don’t have a valuable opinion. Sometimes fresh eyes see the root of a problem the fastest. Be confident, but also be willing to drive consensus even if it doesn’t turn out your way.

Jack McCracken (Developer Intern, Application Security)

Office: Ottawa
Education: Carleton University

Get to know Jack:
Has a red-belt-black-stripe in Taekwondo. Almost a black belt!
Sells snacks and drinks to students at Carleton using Shopify’s POS system
Has worked at Shopify consistently since May 2015 and as of April 2018 is now full time...that’s six internships!

The hardest part of your interview?
The hardest part of my interview was admitting what I didn’t know. When I got to my second interview, I was so nervous that I completely blanked! After a while of trying to graciously “fake it till I made it, ”I worked up the courage to tell the person I was interviewing with that I totally had no idea. That was hard, but I still believe it got me the job to this day.

Dream career if you weren’t in tech?
If I wasn’t working in tech, I like to think I’d be an author. I love writing stories and explaining complex things to people.

Best piece of advice you’ve ever gotten?
If you ask a question that saves you an hour of hard work and takes the person you’re asking 5 minutes to explain, you just saved your company 55 minutes in development time.

How do you succeed at Shopify?
Succeeding at Shopify is slightly different than your average tech company. It’s very self-driven, so you need to ask questions. It’s hard to succeed (actually pretty much impossible) in a large organization without any context, and it’s much easier to learn by talking to your team lead, a mentor, or some random person you found on Slack than to laboriously read through code or wiki pages.

Ariel Scott-Dicker (iOS Developer, Mobile Foundations)

Office: Ottawa 

Education: Flatiron School

Get to know Ariel:

• Was doing a degree in Cultural Anthropology, with a minor in Music. He didn’t finish the university degree but did a software development bootcamp and developer internship, before coming to Shopify
• Never wrote in Swift before coming to Shopify. Now, it’s his favourite programming language!

What’s your day-to-day like?
We release new versions and updates to our iOS app every three weeks. This makes our day-to-day consist of working our way through various tasks that we’ve designated for the current three week period. Sometimes for me, that’s one large task or several smaller ones.

The hardest part of your interview?
I didn’t progress past Life Story the first time. I think it was because I didn’t relate the course of my life thus far to how I could be successful at Shopify. Other than that, the hardest part (which I thought was really fun) was solving conceptual problems verbally, not through coding terms.

Any tips for future Shopify applicants?
During your interview, be yourself, stay calm and confident, and breathe. Make sure whatever you mention speaks for itself, and that it demonstrates how you can succeed at and contribute to Shopify.

Dream career if not in tech?
Working in a big cat sanctuary or experimental agriculture.

How do you succeed at Shopify?
For me, a huge tip for succeeding at Shopify is being selfish with your education and development. This means, asking questions, using the smart people around you as resources, and taking the time to understand something practically or theoretically.

A huge thanks to our Winter 2018 interns for all they have contributed this term. We’re so proud of the work you’ve done and can’t wait to see what’s next for all of you! Think you can see yourself as one of our interns? We’re currently hiring for the Fall 2018 term. Find the application at shopify.com/careers/interns and make sure you apply before the deadline on May 11, 2018 at 9:00 AM EST.

Want to learn more about Shopify's Engineering intern program? Check out these posts:

• How We Enable Our Interns to Make an Impact
• How We Support Intern Growth through Challenge and Practice

Continue reading

6 minute read

The mobile team knew they needed developers, particularly Android developers. A few years ago, Shopify pivoted to mobile-first, which led to the launches of Shopify Mobile, Shopify Pay, Frenzy, and others. To maintain momentum, Shopify had to keep building up its mobile talent.

Back when Shopify's mobile teams spun up, many of our then-early mobile developers never did any mobile development before, instead teaching themselves how to do it on the job. From this observation, we had an insight: what if we could teach developers how to build an Android app, via a Shopify-hosted workshop?

The benefits were obvious: this educational initiative could help our local developer community pick up some new skills, while potentially allowing us to meet exciting new talent. The idea for Android Bootcamp was born.

Continue reading

Making an Impact

When interns join Shopify for their internship term, they work on projects that will impact our merchants, partners, and even their fellow developers. Some of these projects will alleviate a merchant's pain points, like the ability to sell their products on different channels, or simplify a complicated process for our developers. We want interns to leave knowing they worked on real projects with real impact.

Continue reading

In early 2016, we faced a problem at Shopify. We were growing quickly, and decisions could no longer be made across the room, so to speak. Four offices became five, accommodating that growth raised interesting questions like: how would new people know the history of the company, and how could existing Shopifolk keep up with new developments? In addition to sharing knowledge inside the company, we also wanted to let people outside Shopify know what we were working on to give back to the community and to support recruitment efforts.

Engineering communications was born to solve a specific problem. A valued saying here is “do things, tell people,” but, while we’re very good at the first part, we weren’t living up to expectations on the second. Ad hoc worked when we were smaller, but with technical stories now coming from teams as varied as production engineering, mobile, front-end development, and data engineering, we needed something more formalized. Strong communications inside the engineering team could help prevent the overlap of work by different teams or the duplication of mistakes, and it could support cross-pollination of ideas.

Continue reading

4 minute read

An essential part of working as a developer is getting practical experience in the real world, of which internships can play a meaningful part. The Shopify internship program, which started back in 2011, runs for four months during the summer, fall, and winter terms. Interns can work from one of our offices in Waterloo, Toronto, Ottawa, and Montreal. 

Continue reading

Our engineering blog is home to our stories sharing technical knowledge and lessons learned. But that's only part of the story: we hire passionate people who love what they do and are invested in mastering their craft. Today we launch "The Side Hustle," an occasional series highlighting some side projects from our devs while off the Shopify clock.

When Gabriel O'Flaherty-Chan noticed quadcopter controllers on mobile mostly translated analog controls to digital, he took it upon himself to find a better design.

7 minute read

For under $50, you can get ahold of a loud little flying piece of plastic from Amazon, and they’re a lot of fun. Some of them even come with cameras and Wi-Fi for control via a mobile app.

Unfortunately, these apps are pretty low quality — they’re unreliable and frustrating to use, and look out of place in 2017. The more I used these apps, the more frustrated I got, so I started thinking about ways I could provide a better solution, and two months later I emerged with two things:

1. An iOS app for flying quadcopters called SCARAB, and

2. An open-source project for building RC apps called QuadKit

Continue reading

5 minute read

Hi there! We’re Kat and Omosola and we’re software developers at Shopify. We both started working at Shopify back in May, and we felt both excited and a little nervous before we got here. You never know exactly what to expect when you start at a new company and no matter what your previous experience is, there are always a lot of new skills you need to learn. Thankfully, Shopify has an awesome onboarding experience for its new developers, which is what we want to talk about today.

Continue reading