How can I become more independent and better at unblocking myself with tricky technical issues?

• My process for dealing with these issues (assuming I can't fix it myself) is as follows:
  • Find the relevant code (which you've already done)
  • Blame the code to get the landing diff
  • From the diff, you have the author and reviewers
  • Ask those people for help. If they can't help you, ask for names of people who might be able to help you. If you're worried about this step, I recommend taking this course: [Course] Effective Communication For Engineers
  • Ask those new names for help and keep repeating the process of asking for help/names until you solve the problem.
• The main gap to bridge here is generally the confidence needed to reach out to so many people for help and escalating properly. If you're running out of time and people aren't responding fast enough, you can bring in your manager to "grease the wheels".
  • Don't see needing to ask for help like this as a weakness and a sign that you're not independent. Thinking this is a common failure mode I see with earlier-in-career engineers. It takes a long of work to follow up with people like this and ask the proper questions.
  • In fact, the opposite of true. If you don't follow this process and bring people together to solve the issue, you're just going to struggle on it for a long time and/or deliver a bad fix for the issue. This will make people like your manager and TL worry when handing off issues to you in the future as they fear a painful, drawn out experience on your end.
• Keep in mind that this is a great learning exercise. When you have to "traverse the coworker graph" a lot, you will usually be learning many bits and pieces of the overall system along the way. If the fix is complicated enough, you can even write an in-depth Workplace post about it, sharing your crazy story on how you figured out this super gnarly XFN issue (I've seen many Meta engineers do this to great success). Looks good for people axis!

Related resources:

• "How can I root cause bugs faster?"
• "I'm trying to fix a P1 bug, but some relevant code is owned by another team. Unsure about ownership and how to proceed."

I can't replicate that deep knowledge they have as I'm fairly new to the company.

Update your mindset. Believe in "I need to replicate that deep knowledge and I could achieve it." Then the right question to ask is "how can I achieve it efficiently?"

You should proactively get help to unblock yourself. The most important thing is to focus on "learning how to fish" instead of "getting the fish" in the process. It's part of the journey you are expected to take during your stay at Meta.

When I was a Bootcamp mentor and then later a Bootcamp mentor coach I kept telling people that it's critical for a Bootcamper to learn how to get the information they need. It's what the Bootcamp tasks should drive the Bootcampers to learn: ask POC to provide the context; ask POC to answer questions; ask POC who else to get the information if the POC doesn't know; follow the lead and jump through multiple hops to get the information; (when you are more senior) make decisions based on incomplete information.

Usually, it takes you one to two years to get enough institutional knowledge in a large company like Meta. The senior engineers in your team know where to find the right people and ask the right question. Ask them to show you how they do it. Ask them to walk you through each step in their process. Isolate the ones you can pick up quickly and accept the ones that take time to accumulate.

If they tell you "I just know this person on top of my head. So you should go ask them." That's something you need to accumulate over a long time. You just wouldn't know such things on top of your head.

If they tell you "I look up the manager and the tech lead in the org chart. I reach out to and ask them whether they are the best people to talk to about this question. It turns out the manager is technically hands-off and the tech lead is new to the team. They recommend I talk to another senior engineer in the team for my question." This process is the "fishing skill" you can observe and mimic quickly. Ask them to show you "how to use the org chart in Workplace", "how do you identify the tech lead in a team", "how to write a message to reach out to strangers in another team", or even "how to not feel bad if those strangers say no to me or just ignore me". Focus on learning in this way by keep asking people to demonstrate how they would do stuff that you can't do independently, yet.

The main difference between back-end and front-end when it comes to debugging is that you can't see pixels on screen. You can still add print statements, step through with the debugger, etc, and I recommend you try to do all those things.

When it comes to logging, I highly recommend figuring out how to get all logs to print to a console that you can then grep through. Quality of life when debugging is really low without it - I worked with both back-end and front-end at Meta, and we had this for both.

After finding the error, the goal is to understand how it is thrown. Is some piece of data missing when it shouldn't be? Are you going down some completely unexpected control flow? Use a mix of debugger and print statements to "detective" your way through this.

All that being said, a lot of the things like navigating the file structure and identifying the correct log files seem like pretty specific, extremely tactical things that I really think are best learned through talking to people. These are the kinds of issues where you can easily spend hours on it just trying to figure it out yourself even though this isn't really a part of coding fundamentals - It's just tribal knowledge specific to your setup.

I think others already made a lots of good points. I will just add one.

Let us be clear, you are replicating that deep knowledge as we speak. A big part ramping up is asking for help to unblock yourself. Leverage the fact that you are new and earlier in your career to ask pertinent questions. Senior engineers expect you to ask questions especially during onboarding.

You should also do two things while asking those questions

• make sure you do not ask the same question twice.
• document your findings & learnings and share with the team.

Do you have any tips on how to debug through these massive backend codebases? As a new engineer, it has been a steep learning curve needing to figure out the file structure of packages and where in log files to look for the right error to point me to where the bug is at in the code. Also, being new with Java, I have been struggling to figure out what to do after finding the error, not all error statements in Java are as.. robust as I would maybe like (cough cough Rust cough cough 😂)