9 ways to build technical depth, fast

Understanding a new technical stack isn’t easy, but these nine activities can help you get there faster.

When a software engineer transitions to a new role or team, building technical depth quickly allows them to become effective team members sooner.

But what does technical depth mean? This comes from deeply understanding the technology, tools, and systems used in a particular domain or project. Technical depth encompasses your ability to interpret, troubleshoot, and contribute to the codebase, as well as your proficiency with other tools and systems used by your team. It means you can quickly analyze and solve problems, enabling you to contribute to the team’s success faster.

Here are nine ways to build your technical depth, fast..

1. Schedule technical 1:1s

Managers have 1:1s with their team, but developers need connection with their team as well. Scheduling coffee chats is a good way to  build deeper personal connections, but they can also be used to build technical connections. 

When speaking with your teammates, find the areas where they consider themselves experts and ask them about it:

• What is causing you problems?
• What tools do they wish they had? 
• What do they find themselves repeating? 
• What bugs do they wish were fixed but never have time to get to? 
• What in their dev environment is a problem? 
• What do they find most exciting? 

These conversations provide context that allows you to understand  what the team’s work looks like, why things are the way they are, and  where the opportunities to make them better are. 

2. Ask questions

Our first instinct as engineers is often to dive into the code and figure it out ourselves. It’s fun and we don’t want to bother anyone. While you do need to look at the code, you also need to pause and ask questions. 

In most cases you’ll be working with teams that are already experts on their products. Use their knowledge to jumpstart your own. You aren’t being a bother or a drain, you’re taking the fastest path possible to being a strong team member. Let them build your knowledge so you can return the favor and quickly contribute your knowledge and experience back to them.

3. Shadow on-call devs

A great way to learn how systems work is to see how they break. Ask whoever is on-call for your product area to pair with you when they get an issue during your working hours. This will give you first hand experience with the tooling, code, and problem areas. 

If there are areas of the product that need work, they are the ones most likely to be triggering bugs. This builds your expertise in the exact domain where the team most needs expertise.

4. Targeted pairing

At Shopify, we have a strong pair programming culture. Pairing can be a highly intentional exercise when you’re learning in a new area. 

Find someone on the team who is working on a hard problem or big task and ask to pair with them. Or, approach the most tenured member of the team and ask them to show you their favorite and least favorite parts of the code. 

Just like shadowing on-call devs, this can give you knowledge of the scariest and newest parts of the code. The most recent code will show you not only what the team is working on, but what code, PR, and review standards are being followed.

5. Review pull requests

It’s natural to be  hesitant to review a pull request when you’re new to a team. It’s easy to  assume you don’t have enough context to give a good review, when actually, the opposite can be true. 

That lack of context can make you  less likely to have code blindness. This is where you are too close to  the code being written and can no longer see any of the inherent assumptions that have been made. 

A pair of fresh eyes that can ask questions and challenge assumptions can make an excellent reviewer. Teams should also be creating commit messages and pull request descriptions with the assumption that someone reading it may not have the same context they have. For example, someone may read the messages a year later while debugging a problem. A new reviewer can point out when a pull request or commit message lacks the detail for any developer to understand the what and why behind a change.

6. Work on a scary issue

When someone onboards to a team, they’re often given an easy starter issue to work on. However, if you want to build technical depth quickly, the opposite approach would be more effective. 

Pick an issue on the backlog that looks downright frightening! Working through something that seems really challenging up front can be a great way to force yourself to dig in, understand the system, and grow more quickly than by picking up some low-hanging fruit. It can also be a nice confidence boost once you actually work through that uncertainty and execute.

7. Fix the docs

In an ideal world, team docs are up-to-date and have all the context you need built right into them. But in reality, docs start to slide out of date the moment they’re written. 

Read the docs, but more importantly, verify that they’re correct. Start with the onboarding docs and use them to bring up your full development environment and use the product. Find out what is wrong and what is unclear, then fix it. Read the rest of the docs and update what’s out of date, unclear, or needs more detail. Continue this as you build your context. 

Once again, ask questions. You know you understand something when you can write about it. If you don’t have time to do all the fixes, ask the experts if they can please fill in the gaps you find.

8. Walk the code

Another useful exercise is taking  a walk through a new codebase. You can do this by  getting the dev environment running and pulling up the logs and the database. Check the initial state of the data in the database and then take a single user action with the product. After that action, skim over the logs generated and check what data has appeared in the database. Then use those inputs to find the parts of the code path that were just used and walk through that path. If you get stuck, the `git blame` prompt is great for knowing who to reach out to with questions. Take notes as you go and draw diagrams to keep track of where and what’s happening.

9. Diagram the product

Finally, create high-level diagrams of the code flows and models for your product. If they already exist in the team’s documentation, verify that they’re still correct. If they don’t exist, use all the raw notes and diagrams from your code walkthroughs to create new ones to add to the docs. Get the rest of the team to review and correct what you’ve done and  build a sense of ownership to carry forward for everyone. 

Time to get started

Building technical depth quickly is crucial when transitioning to a new role or team. It lets you become an effective team member faster, enabling you to start contributing back the knowledge and experience you were hired for. 

From scheduling technical 1:1s, to diagramming the product, each of these steps provides a unique way to gain insight into the product and build your expertise. Remember, asking questions now makes you able to answer questions later.

Special thanks to my mentee, Craig Coles, and colleague Rose Robertson, for inspiring this article.