Productivity 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?

Alex and Rahul and the other senior people on Taro have consistently emphasized how important good software engineering fundamentals are to long-term career success as a software engineer. This is in contrast to learning the latest popular framework or area of development. Can people define what those fundamentals are and how one should go about acquiring/improving them?

Thanks!

I get a lot of JIRA tickets for bugs where it's not clear what the fix should be. How can I find the problem area and relevant code faster with these issues?

Is sprint planning and agile not a thing at meta? I’m doing a lot of research since I’m trying to see how it’s like as I’m spending time leetcoding and if the vibes there are it’s on you to plan your projects and set a timeline then sprint planning would actually make the engineers not excel in independent planning?

And it seems like it’s against good e4 performance to be prompted to set your deliverables at the end of the sprint? Just not sure how agile is used cuz if it’s on everyone to figure out how to project manage on their own then what’s the point of agile?

I recently started at my new gig as a remote tech lead. While I am on the West Coast, most of my team is either on the East Coast or in Europe (+11 hrs). Meetings start at around 7 AM PT and go on until 11:30 AM PT!

Here is my challenge: I am a morning person & like to do more deep & undistracted work during the morning hours (Coding / Reading / Writing) . Screen time in the mornings usually drain me out & my productivity dips post multiple zoom / G-meet calls. What are your thoughts on how could I balance my sacred morning hour time between meetings & impactful work?

Thanks!

Sometimes I feel like I didn't get 40 hours "worth" of productivity after a week, and it didn't make sense to physically spend 40 hours working that week. Is it possible to succeed as a software engineer working less than the traditional 40 hours? I imagine it requires being able to get the work done faster - What are some techniques to do that?

When learning new things, I often find that I don't know this, don't know the best practice in that, and so on. If I go down these rabbit holes, a lot of time is spent and not much progress is made in the original project. If this is a scene at work, usually there are external factors to guide you not to go down these rabbit holes, be it the deadline on a task or advice from colleagues. But how to manage this while building side projects? Especially, time after work is equally precious that you sacrificed doing other things to build a skill, and progress gives motivation. But at the same time, going down these knowledge rabbit holes also builds knowledge, and be more niche. How would you trade off knowing everything vs progress in side projects?

How do you keep up with everything that is happening on the team with different projects, doc designs and code reviews?

I'm a self-taught, aspiring Android engineer, looking to land my 1st full-time role. I have around 4 hours a day to learn software development, and I'm wondering how I can spend my time the most efficiently. Here are the 2 core things I want to understand how to balance my time between:

• DSA (data structures and algorithms)
• Building projects for portfolio

I've done a lot of research on how to be a good manager, but now do I just "trust the process" or how do I ensure we are a high performance team over the next half?

I'm a newish EM at a Series-B start up of 150 people, ~25 engineers. So far I have positive feedback from my manager and reports that I am empathetic and supportive. What my manager is telling me now though is that we need to see results. Productivity and performance seem OK in my first months but it is too soon to really see my impact. My manager noted that since we have scaled up from 4 engineers to 25 and gone mostly remote over 3 years there may be a loss of a sense of urgency and the feeling of impact per dev. We are also split into many teams with a smaller scope per team.

The temptation when asked to "get results" might be to ask for constant updates from developers and punish them when fake hard deadlines are given and missed (we are a B2C company so there are rarely actual deadlines). So how do I motivate my team to work hard in a healthy sustainable way? How do I measure the progress and reward them fairly while creating a team focused culture and not one that is competitive and individualist?

Below are some of the management ideas I'm using/working towards. I have lots of room to learn how to do each better, so advice on which to prioritize my effort at improving first would be great in addition to notes on what's missing and what seems off on the list:

Individual attention

• Working with each individual to set SMART goals for the next half
• Working with each individual to figure out what motivates them, and do that
• Figuring out what learning each person wants to do and giving them support there
• Regular, timely feedback (positive and negative)
• 1:1s where I do a lot of listening, help remove blocker
• Shielding from outside distraction and unhelpful pressures

Team culture

• Creating a lowercase-a agile mindset: people are first and it is ok to fail and we learn from our mistakes. We can fail gracefully by making small, quick launches where we get frequent feedback from the users, and feedback from coworkers on how we are succeeding/failing
• Making the team effective first, efficient second: 5 wrong things done in a quarter are worse than 2 right things that move the needle
• Setting team OKRs for the next half that the team wants to accomplish
• Encouraging team work on tasks, pair programming, positive code review culture, etc
• Improving the process to make it effective and fun around how the flow of work happens between planning, selecting tasks, marking things as done and tested
• Team demos with stakeholders to show off results and get feedback

Bonus questions about motivation: In 1:1s how do you figure out what motivates someone since they might not say extrinsic things like money even if that is what they are working for, or the opposite they might be happy at their level and just like the work they do with a good work life balance but might not say that directly either. Also if there is a team of 5 where 2 want money and 3 love the work for itself, how do you tailor their experience to that? The first two will still want fun/interesting work and the second three still want to get promoted and compensated fairly.

Thanks!

I work overtime a lot, and it's pretty stressful. I'm also worried that amidst all this effort working for Meta, I'll lose track of who I am overall and what I can do for other companies. What can I do to strike a better balance here?

I think I'm a good generalist with technical breadth and got I ask appropriate questions to learn a new stack. I think I lack in technical depth. Either I haven't had opportunities to develop meaningful technical depth or I haven't known how to leverage those opportunities.

A perceived limitation is I tend to associate these opportunities only with refactoring, which needs buy-in from business, but maybe there's more I don't see. My experience has been business only wants to spend the type of work that applies to covering 80% of the needs and the rest tend to be edge cases that don't get much review during initial design & implementation.

An idea I've considered is deliberately practicing DSA interview questions with the intent to identify concepts that may carry over to other implementations. How feasible does this seem?