Communication Q&A and Videos

Every time, when my manager asked me to do some changes to the repository that is totally new to me. I became scared.

I prefer to do research by myself first. But I got lost in the new repo by reading file by file, and don't get the clarity.

So I ask the repository owner to provide documentation, mostly they don't maintain documentation, and even if they do, it is not updated or it involves a lot of detailed feature-wise documentation, which is usually not relevant to my requirement.

Then, I call the POC of that repo, but I couldn't figure out what is the right question to ask in the first call. Over time, I ping him asking questions whenever I face hurdles while achieving the requirements.

Sometimes, I put a debugger or logs to understand the flow of code.

The above processes took a lot of my time.

What is your suggestion to get clarity in the new repo such that I can complete my requirements in less time?

An XFN stakeholder came up with a last minute requirement for a big project I'm working on, which will probably slow down the launch by at least a couple days. I already made promises to other XFN about the launch date.

What's the best way to mitigate the heat on failing to launch on time and zooming out, how do I deal with last minute launch blockers in general?

I am been working as a Senior software engineer for quite some time now. To move to the Staff level, one feedback/pointer I got was to start developing opinions on how to do certain things. When people start respecting your opinions, they start to see you as a leader.

The problem I have is, in many cases, I don't have enough relevant experience for the problem at hand. Also, I find, that in discussions I am listening more than I am speaking. Having no opinions, and finding it hard to express opinions for fear of being judged and losing respect in case my opinion is wrong, are the problems I am facing.

Is there any advice on how to develop these skills?

What are the some of the fundamentals to have a strong product sense for a software engineer?

During layoffs many engineers are working in war time mode vs peace time, especially the companies still figuring out Product market fit.

So how can I as an engineer help or challenge product direction, read data insights, do user research, etc where I am not directly involved.

I feel like there is lot going on around user research and the product goal is set but how can I provide valuable input make sure we are heading to right direction and at the same time keep working on right technical things to make product closer to its goal.

I'm learning it's important not just to do good work but also to make your work visible to your team and sometimes wider circle. This is common feedback given to junior engineers at Meta. What are some ways to get more visibility on my work and what are some rules of thumb (e.g. structure of posts, cadence of posts, when to share progress in team meetings)?

I've gotten feedback that I'm more on the quiet side and that I could be more active in meetings. However, I feel like I don't have much to add when it comes to meetings. I want to say something that's insightful and adds value to the conversation, but I'm unsure how to come up with that level of material, especially on-the-spot during the meeting. How do I figure out what to say?

I have been wanting improve my technical understanding on what I am working on:

• Since there's so much happening in the backend, frontend and database levels, it can get intimidating to try and see how it all makes sense, when it all feels chaotic trying to put everything together.
• I feel that the one thing that could help me progress to the senior level is to better my technical influence, and I was wondering how I can improve on that.
• I have been proactively speaking with senior engineers and the architect involved with the new feature that's being worked on. That has really helped me better my understanding on what I'm working on. But when it comes to the code, it can be challenging since there are so many files that depend on one another, and I feel that I would need to spend a couple hours a day just understanding how each of those code files work.

What other steps can I take to enhance my technical influence, and then reach that senior level?

What does Alex Chiou read?

How does he think when he writes?

Is there a certain number of drafts?

Does he get someone to read it and give their thoughts etc?

When I read Alex's work, it makes me think better. I learn something new because I think - oh, I could also think this way. Oh, someone else can think this way. Oh, I learned something new.