Thanks for sharing and sorry to see you struggling with this.
+💯 on both what Alex and Rahul noted.

One thing my manager asked me to do last year was to strictly restrict my work time to <= 40 hours/week and increase my product by > 2x.
Now, this, as you might guess is very challenging when I was already spending 50 hours a week. I felt only thing I had in my control was putting in more hours, what else can I do.
But, gradually I learnt how to break down, prioritize and parallelize my tasks in a way that overall I may get more work done in same time. So, it's still possible that task 1 took 3 days for completion, but now I could do 3 tasks in 3 days instead of just 1.

Another thing I learnt was that I was spending too much time figuring out things on my own without bothering anyone else. And I agree that it feels being useless, imposter syndrome, being a pain in butt when asking questions, but trust me you are doing yourself and your team a favor by asking those questions in first 6-7 months of your ramping up. Imagine asking the noob question 1.5 year down the line or not asking them at all and staying stuck.

Third thing which has really been super beneficial for me is making a note of 2-3 goals everyday and finishing those tasks by end of day. And doing a retro at end of day on what could have done so that tomorrow if same goals come in I could complete them in half the time.

4. You think you are working 6 am to 11 pm, but you are doing a lot more than what you are thinking you are doing. You are doing:
- office work
- managing kid
- grocery shopping
- some TV/YT
- a lot of worrying and over thinking, etc etc...

i. How about you start tracking all these activities and time spent on them.
ii. And start following promodoro technique for all of office work, house work and rest time.

5. Don't feel guilty of taking rest. Consider that as part of something your body needs and plan that in your day. Per CA law one should take 0.5 hr break after every 3.5 hours of work. Your body and might need more. No point slogging and skipping that break if you aren't being efficient.

Mid-Level Software Engineer [L4] at Google

Vaibhav Agarwal

Dig deeper and assess where are those thoughts stemming from. Meditate/journal/talk - whatever works for you.

How about you share this project idea, someone else leads it, and the problem gets solved making the world and company a better place? Let's say you don't get any credit for it at all (very unlikely), you still get the experience of coming up with an idea, validating it, marketing it and seeing it go from ideation to deployment.
You might be able to follow along with the leader leading it, or take part in some small way in it.
But, ultimately the customers would be happier.

Prioritize on adding value, it's okay if you don't get credit. Recognition will follow, if not now, maybe later. There are several more ideas in the place where this one came from, just waiting to be unleashed.

Having worked in both such "agile" and big tech "not so agile" environments, I can say that one can excel in both the envs.\
They simply need different mindsets, and a willingness to find motivation and do good.

**Big Tech / Flexible Environments:**

The SWE needs to be skilled at time and project management, and driven to prototype with new ideas.\
SWE defines a lot of their priorities on their own (esp. so for more senior SWEs).

At the end of quarter / year you are evaluated on the impact you landed.

Its highly encouraged for the SWE to find more interesting and important problems that need to be solved.\
These might be product, process or technical debt related, etc.

**Strictly Agile Environments:**

There is a dedicated Project Manager / Scrum Master who enables the team to be focussed and deliver on time. There is additional overhead to create tickets, plan story points, evaluate velocity, do retros, etc.

In such environment, a strong staff / principle engineer breaks down the complicated problems to small and very small size chunks which can be solved in 1-8 hours and then files tickets for them. Now, these tickets are divided among other engineers, prioritized and individual/team velocity is measured accordingly.

Agree, as a junior engineer, it might feel like being a small cog in the wheel of an assembly line.\
But, this leads to great opportunities to grow as well:

1. **Get better at task breakdown**\
   For every task assigned to you, create a plan and try to subdivide it into very small tasks. Think of you being assigned an intern who will be doing these hour long atomic tasks and the text you write is clear enough that they don't need to ask you on how to do it anymore. Once you are so good at this, and each task indeed takes you 1 hour, try to do this for more and more complex problems. If these subtasks are taking you longer than 1 hour, break it down further.\
   Also, if you have done this breakdown beforehand, you know for sure how much time its gonna take. And with that, the Scrum Master won't be able to push you to reduce the points / hours on it without asking you to maybe remove some subtasks from it.\
   Further, as you practice this skill, aim that your hour long atomic tasks get done in 45-50 mins max. If your atomic tasks are taking longer than 1 hour, learn from it and break it down further the next time.
2. **Find some interesting large project / problem**. Document it, explaining the benefits, risks, scope, resource needs, etc.\
   Get this approved by Product and Engineering managers, etc.\
   This is what a staff / principle does, but you as a junior eng can do this too for a project that you are proposing.
3. **Find patterns** in the atomic tasks that you / everyone in the team is doing repeatedly.\
   \- Maybe sending an email after a release is cut, or\
   \- Syncing latest code and restarting server, or \
   \- Finding production objects and replicating them to create mock objects for testing, etc.\
   \
   And see if you can automate / write scripts / batch them to simplify any of this?\
   Essentially, if your team was able to do 100 story points last week, what can you do / help so that the team does 150 points next week?
4. **Create tickets for yourself** which are related to your own learnings / explorations / prototyping.\
   Story point these, and get them included in your sprint.\
   It might be as simple as, I will spend 3 hours reading this whitepaper on Friday and put it on your Kanban board.\
   I am sure neither your Engineering Manager nor project manager will have a problem with this.\
   Rather, they would appreciate if you could present learnings from this whitepaper to the team.

NOTE: We try and not modify current sprint.\
So, plan your next sprint today and get at it so good that you don't have to modify your sprints mid-way. :)

Be A Good L4+

Communication is a skill that software engineers often underestimate in terms of importance, and being good at it is effectively a senior engineer requirement. In this series, Alex breaks down the principles and tactics he uses to communicate effectively.

Alex's Guide To Effective Communication

Become An l6

If you're a software engineer, you can't progress in your career by simply doing what you're told. Over time, you need to learn how to create you own scope, especially as you reach senior and staff levels.

[Taro Top 10] How To Create Scope As An Engineer

L4 -> L5

Learn what real system design looks like by seeing Alex use the tactics he used as a Meta/Robinhood tech lead to scope out a Taro feature. The skills here are crucial to being a senior+ engineer at FAANG and other top companies.