How to Navigate Time?

Oh man. So. I said yes to everything when I first started being a SWE 6 months ago. It was a huge mistake. I was trying to do too many things at once. Ultimately, I took a huge reputation hit and it took months to recover.

So after reading your post several times, I'm getting the impression that you're putting too much pressure on yourself. The expectation of any new employee is to get the most important work done first. That's pretty much it. Then you add stuff like code review, refactoring, etc.

I wish I knew a few of these non-ENG related (but even more important) things before I got into tech... 😴

Having Boundaries

If your teammates ask you for help and you're swamped with work, just say no. They'll understand, almost any reasonable person will. This is really important because if you never say no, people may just keep asking you to do things.

Stretching Deadlines (in moderation)

You're never going to have 100% days all the time. So if there's a seemingly small project but there's a lengthy review process, it's good to give yourself 20-30% breathing room to put less pressure on yourself.

Not trying to learn everything at once

If you try to learn everything at once, you'll learn nothing. How are you supposed to know what the code reviewers on your team look for, before you've even landed any code?

It takes time to meld your coding style with the team's. It takes time to give consistent and thoughtful code reviews to your coworkers. It takes time to add value via ad-hoc tasks.

^side note: I think it's actually harder to add value with ad-hoc tasks than your main work. They are prone to be poorly scoped and not prioritized properly, so it could be a huge time sink to work on these if you're new.

Final Thoughts

Enjoy the grind! Make sure to have some fun. Touch some grass. Blow some money on concert tickets or something. As a highly paid SWE, it's your turn to stimulate the economy 💸

I totally get this. Once I started working, I realized there would always be a ticket around the corner for me to do. With a ticket backlog so large, how will I ever have the time to get alignment, scope a project, and drive it to completion?

What I eventually realized is that you need to make the time. If you don't set aside some dedicated time every week to work on your highest priority item or come up with a new project that will drive your career, then you will endlessly be working on tickets that may or may not be impactful (and suffer a context switch every time you do it).

For me, I feel like I have a pattern of getting pulled into these tasks during my sprints and sometimes missing my deadlines by few days and so have adapted to avoiding these tasks

Can you batch some of these requests together instead of completing them ad hoc? Can you reasonably avoid completing these tasks?

I'm not sure if you are personally assigned work for each sprint or if you pick up tasks to do. One thing I realized with many engineers is that those who are proactive in finding impactful work to do and seem busy are not as often expected to perform many of these ad-hoc tasks.

So many good questions, lots to unpack here!

Is it a realistic view that senior engineers could work 40 hours per week, or is that almost impossible?

Starting off with the good news, it is definitely possible to be a senior engineer and work ~40 hours per week, even at a top company. It's admittedly tougher now given the market, but it's still 100% possible. In fact, my little brother is doing this literally right now - He's working very reasonable weeks at Robinhood as a very high-performing senior engineer. I talk in-depth about how this is achievable here: "Is it possible to do well at a SWE job working less than 40 hours a week?"

I wanted to know what the correct approach is here, do we try to think this beforehand and allocate some sprint points for these tasks?

From my understanding, these tasks you're referring to are ad-hoc and pop up unexpectedly. It doesn't really make sense to preemptively allocate points for these tasks as you don't know how many will pop up and how bad they will be.

If these random tasks do consistently pop up though, you can try allocating some buffer every sprint cycle. So assuming you do the standard 2 week sprint which is 10 business days, just assign everyone 9 days worth of work. From here, the logic is pretty simple:

1. If random tasks pop up - Use the 1 day of buffer to tackle them
2. If random tasks don't pop up - Use the free day to grab something off the backlog

For me, I feel like I have a pattern of getting pulled into these tasks during my sprints and sometimes missing my deadlines by few days and so have adapted to avoiding these tasks.

I totally get wanting to avoid ad-hoc tasks entirely, but I don't think that's the right idea. There are many legitimate cases where an ad-hoc task should be prioritized over what you already have on your plate, a major production outage is the main example.

This is admittedly a bit tough as a junior engineer, but I highly recommend developing the more nuanced skill of evaluating a task's importance. From there, you ingest extra tasks if it makes sense (and ideally move something that's currently on your plate into the backlog) and push back diplomatically if it doesn't make sense. I talk about the push-back mechanism in-depth here: Stay The Course

Here's a good thread about defense mechanisms into an overly "agile" team as well: "How do you deal with a team that uses "Agile" and equates story points to hours?"