How do I balance slow code spelunking on my own vs. asking questions to speed things up?

Thanks for sharing such a thoughtful question! I think this discussion should help a lot here: "How do I balance being more independent and asking questions?"

I already ask a lot of questions, and I want to be more self-sufficient because my full-stack team members are pretty busy. (They are all kind and would all be willing to to take some time out of their day.)

I totally get the empathy here, but I feel like you may not be leveraging them enough (and they may actually want to help you more and are waiting for you to ask!).

Of course, there is such a thing as being a bother by asking for too much help. A communication "trick" you can use to get around that is to proactively give them an out. So whenever you ask for help, just tack on a, "No worries if you're too busy to help me, I totally get it! I can go ask someone else 😊", to the end. Another thing I recommend doing is adding a "No rush!" somewhere in there to any ask you have that isn't urgent.

How can I get faster at reading code on my own while balancing a team transition?

Have you tried pair programming? When junior and onboarding engineers in general start out, they're going to have a ton of questions. If you find yourself asking 5+ questions to the same person across a day, it's probably more efficient to just pair program with them for 30 minutes and get all your questions out there in a single burst instead.

While I understand that there is likely no magic threshold to determine the point at one needs to ask for codebase navigation guidance, a good rule of thumb would be helpful when possible.

My rule of thumb is asking a question if you're unable to make any progress on something you're blocked on for 15-30 minutes.

However, I feel like what will help you here is creating a target to work backwards from. In other words, find yourself a coding task and give it a due date. You mentioned that you have a decent high-level understanding of components but are unclear when it comes to the "nitty-gritty". You truly understand the nitty-gritty by actually playing around with the code, but it's easy to do this aimlessly if you don't have a concrete goal. Having a deliverable should fix that.

It doesn't matter if the task is as small as "Change this button from a dark blue to a light blue", just make sure that it has clear success criteria and a date attached. You can ask some collection of managers, tech leads, and whatever other mentors you have on the software engineering side if they have any small tasks they can give you. Series B is somewhat early, but I feel like that's a scale where there's probably a pile of small bugs and tech debt lying around.

Once you have the task, you simply ask questions when you don't think you can complete it on time. You can use decomposition to help figure out when that is.

Best of luck!

Here's how I increased the momentum I had by applying a combination of soft and technical skills to rapidly unblock myself.

If there are diminishing returns from figuring out the problem yourself, you should probably ask for help. But before you do that, here were some questions that I asked myself when I was blocked:

• What are my knowledge gaps?
• Are there low hanging fruits to reduce the knowledge debt as much as possible before I make the ask?

Your mentality should be, how do I make it as easy as possible for another person to help me? This might involve doing some homework before asking any questions. You want to rapidly map out what you know vs. what you don't.

Keep in mind, the person helping you is often far removed from your comprehension gaps. They're not a mind reader, so your goal is to clarify what you don't understand to make it easier on them. After all, it's much harder to help someone who doesn't know what they're searching for than to help someone that does. The way to receive effective help is by reflecting on the problem(s) you're facing.

Here are some things you can do before you make the ask:

Part I: Gain Self-Awareness By Doing Your Homework

• Skim through methods to gain a high-level understanding
• Command-click through methods to gain a comprehension of execution flow
• Run the program/service while printing log statements to gain insights about service behavior
• Git blame code to see which coworkers could help you
• Keep track of important questions as you explore — sometimes you might run into conceptual gaps, other times there are procedural gaps in how to set up the environment, etc. Batch the questions you plan on asking to save as much time for your coworker.

At some point, you're going to hit a wall in terms of what you can figure out vs. what you can't. Regardless, try to do things efficiently, and don't spend too much time here. Just having a list of questions alone is already enough.

• In any case, figure out your knowledge gaps as quickly as possible. During your meeting, clarify these gaps by asking everything that you're missing (things you couldn't figure out yourself), as well as any potential popup questions that might show up during the conversation.
• The quicker you pay down the knowledge debt, the faster you develop an understanding, the faster your code velocity. This all equates to having higher confidence at work.

I liken this process to exploring an RPG game — you traverse through the world, and the relevant parts of the minimap light up as you explore new territory. Over time, you get familiar with locations you explore and remember where to go when you need certain resources. Likewise, when you're having the conversation with your coworker, you want the minimap to reveal itself as much as possible, and you do this by asking as many questions as needed to bridge the gaps of your understanding.

By now, you should have a much better understanding, though, you might run into problems still. There are situations where requiring additional help from the same peer is necessary, especially if you want to be more efficient, and you do that by asking even higher quality questions.

As such, the next part is learning how to ask high quality questions while retaining knowledge and mitigating knowledge loss.

Part II: Knowledge Retention and Asking High Quality Questions

There's really no point in asking questions if you're not growing from them. Asking questions has a time cost, and you want to make sure it pays off. A good outcome from asking questions means:

1. You have high knowledge retention, and you're able to replicate your understanding through application
2. You never have to ask the same question twice
3. If you do ask a question, it's always different, with the intention of further deepening your understanding.

If you apply this correctly, your questions should increase in quality, as well as your depth of knowledge. Here are some tips on how to maintain high knowledge retention while being valuable to your coworker:

• (1) Do not write notes during a conversation. Writing notes prevents you from paying attention. You'll be too focused on keeping track of everything that is being said. It also prevents you from engaging in higher-order learning where all the knowledge retention occurs.

  • Instead, record and track relevant discussions and upload videos to a service like Loom where the audio can be transcribed to CC.

  • You can search for key terms like "ProcessA" in the search box of the transcript to jump to relevant timestamps.

  • You can even write efficient notes (after the discussion) like so: [timestamp] + link to loom - processA

    • This way, you quickly review how ProcessA is done instead of needing to write extensive notes about ProcessA itself.

  • Additionally, Loom prevents you from needing to ask the same questions twice -- you can review the vod at a later time -- and this gives you more bandwidth to pay attention during the conversation

  • In short, focus on learning while you let Loom handle the knowledge tracking for you.

• (2) Reflect on your understanding, especially if your knowledge foundation is weak, and get validation from the other person before moving onto the next topic. You want to make sure you're not developing false knowledge, and since your goal is to build knowledge as quickly as possible, focus on clarifying your understanding and learning as much as possible through active engagement.

  • If you don't confirm your understanding, you're wasting your coworker's time. There's a time cost for them to teach you, so you owe it to them to learn what you don't understand.
  • You can do this through reflection, repeating in your own words what you think they are saying, and getting feedback to see if you're going in the right direction.

• (3) Ask relevant follow-up questions to further increase your knowledge depth around a given problem. This effectively enhances the depth of your knowledge tree and increases your knowledge retention, thus making your understanding more nuanced and easier for active recall.

• (4) Lastly, if your coworkers are too busy to help you right now, explain the problems/questions you have via Loom, batch them together in one video, and then asynchronously send them to your coworker.

  • In doing so, you don't have to set up a meeting, you provide visual context to help your coworker understand the problem you're facing, and you give them an opportunity to respond when they're available to help.
  • Also, explaining the problem yourself gives you the additional benefit of gaining a deeper understanding of what you don't know, and sometimes you can even "rubber duck" yourself out of the situation to come up with a solution.

Most of the tactics above are best used in a remote working environment. Some might not be applicable in all scenarios but try to implement what you can.

Part III: Giving Back

Assuming all went well, you were able to rapidly unblock yourself and finish the project/deadline. If so, it's time to give back to your coworker. After all, they invested a good amount of time in helping you grow, and you were able to take your learnings to implement some awesome things. This is a good moment to give shoutouts so upper management is aware of their impact, and to share about your accomplishments as well.

Your coworker will not only feel thankful, but will be more willing to help you in future circumstances -- especially because of your proven track-record for success, and your ability to learn very quickly. Your reputation will improve and others will see you as a potentially worthwhile investment.

All in all, capitalize on giving back and people will help you succeed.

Hope this helps!