Software engineer onboarding

Learn about our culture and values

Before you dive in to engineering tasks like reading and writing code, it is important to give yourself the time and space to set the context for the work you will be doing here at Sourcegraph.

1. Read our company values.
2. Read our engineering principles and practices.
3. Start reading Turn the Ship Around and Orbiting the Giant Hairball in any order (you can expense these books). As you are reading, share and discuss your thoughts with your team.
   • Turn the Ship Around - An inspiring story of how Navy captain David Marquet turned the lowest performing submarine in the Navy into the top performing one with his bottom’s up leadership style.
   • Orbiting the Giant Hairball - An entertaining self-account of Gordon MacKenzie’s experience fostering creativity on his team at Hallmark Cards. Buy the hard copy. There are lots of fun illustrations and short stories. It is a quick read and probably unlike any other book you have read.

Starter tasks

Your manager will assign to you three starter tasks that you should aim to complete in your first three weeks. These tasks are small, atomic, and intended to expose you to different parts of our codebase and product: it’s important that you build the flexibility to fix any problem you’ll be faced with at Sourcegraph, and don’t narrow down your comfort zone to a certain part of our codebase or product.

As you’re working on these tasks:

• Optimize for learning: your priority is to soak up as much context as possible, not to ship something as fast as possible.
• Aim to be as incremental as possible:
  • Open a pull request as soon as you feel like you’re ready for feedback or input on your code—you can make it a draft pull request if your code is still a work in progress.
  • Favour splitting up your work in multiple pull requests every time it makes sense—shipping frequently is important.
  • Ask yourself what tests are appropriate for the change you’re tackling, and add them!
• If you need help, remember everyone is here to answer any question—ask for help in your team’s channel (or any appropriate channel), and add the answer to our docs or the handbook if you feel like it can help future teammates.

As you complete these tasks, share your accomplishments in #progress 🙂

Pairing sessions

Reach out to every member of your direct team, and set up a two-hour pairing session with them. These sessions will be an opportunity to get to know your teammates, understand what they’re working on and why, and learn more about our codebase and development flows!

Take the first 20–30 minutes of the session to have an unstructured, introductory chat. Then, start hacking! Your teammate will set up a live share and walk you through what they’re currently working on. Ask as many questions as possible, to try to understand:

• What problem is your teammate trying to solve?
• Why is that problem important? What team goal does it fit under?
• What are relevant RFCs, PDs, GitHub issues or documentation pages?
• What parts of our codebase need to be changed to solve this problem?
• How will we test the code being changed?
• Will there be future work needed after solving this problem? How could you contribute?

Teammates should prepare these pairing sessions so that they bring you the most value, and allow you to quickly ramp up on what the team is working on and why.

Other resources

We have many resources available to help you onboard and gain context:

• Read through our architecture overview.
• To complement the architecture overview docs, watch the architecture video (10 minutes).
• Read through the rest of the engineering handbook to learn more about how we operate.
• Read how we choose and continually update our goals.
• Read how we collaborate with design to request or implement design work.
• Watch this high-level overview of the Sourcegraph codebase and repositories on Github (13 minutes).
• Read our Testing Principles to learn how we think about testing. Reading this makes sure you know what others on the team are referring to when we refer to certain types of tests.
  • More concrete documentation and troubleshooting help for when you’re running, writing or debugging your first tests can be found in the dev docs page Testing the Sourcegraph main repo. This is mainly as reference (you don’t need to read this all now) but useful information to have in hand.
• For Frontend Engineers:
  • Watch Figma for Sourcegraphers part 1 to learn about how design and engineering work together.
    • Part 2, working with the Wildcard design system shows how to work with our design system and may be interesting for anyone who wants to submit designs.
  • Read Testing web code to understand our preferred patterns and approaches for writing tests in the frontend. We recommend reading this before you write your first test in the frontend.
  • Read our Styling UI documentation to understand our CSS stack and the constraints we work within when styling UI. We highly recommend reading this before you start working on a frontend task, as it will make you more effective.
  • Read our TypeScript programming patterns to understand what TypeScript patterns we follow that are not easily detected with lint rules.

Reading

Keep reading and discussing Turn the Ship Around and Orbiting the Giant Hairball.

Start contributing to your team’s goals

By now, you’ll have shipped multiple improvements, paired with all members of your immediate team to understand what they were working on, and learned a lot about Sourcegraph. It’ll be time for you to start contributing to your team’s goals! It’ll be up to you to define how you’ll accomplish this:

• Pick a current iteration goal you’d like to start contributing to (or work with your team to define these iteration goals if the team is in planning phase).
• Chat with the teammates currently working on that goal, and relevant stakeholders (product, design, CE) to understand the problem being solved.
• Prepare a proposal for how you’ll work with the team solving that problem in the following three weeks. Your work may include:
  • Working on previously identified GitHub issues
  • Doing spikes to solve unknowns and learn more about the problem
  • Writing RFCs to propose solutions, and planning resulting development work
• Discuss your plan with the team and your manager.
• Get hacking!

At Sourcegraph, you’ll be expected to own the problems your team is solving, and work with the team to define solutions and plan your work—we think it’s important that you start doing this early on!