12

How to Navigate Time?

Profile picture
Entry-Level Software Engineer at Taro Community21 days ago

As I go through the lectures on Taro, it seems like we need to have a lot of ownership, deal with ad-hoc problems to help the team, review a lot of code, refactor, and etc.

I feel like this is really hard in a scrum setting where we know what we exactly we are going to do that sprint, and if we do not work on the assigned tasks, our projects get delayed, missing deadlines.

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? Or as we become higher level engineers, are we just expected to work more? Is it a realistic view that senior engineers could work 40 hours per week, or is that almost impossible?

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. How could I avoid missing deadlines and still work on these tasks, at the same time maintaining work life balance?

467
5

Discussion

(5 comments)
  • 12
    Profile picture
    AI/ML Eng @ Series C startup
    21 days ago

    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 💸

    • 2
      Profile picture
      AI/ML Eng @ Series C startup
      21 days ago

      In my enthusiasm, it looks like I missed a few points 😅 Some things I notice about really, really good engineers is that

      Breaking Down Work

      They're just so good at breaking things into atomic tasks. If there's a whole new workflow, they break it down into as many trivial tasks as possible and knock them out.

      Some of Alex's videos on "how real system design/feature planning is done" are super helpful. There's like 3-5 of these at least somewhere.

      Getting the right people involved

      If there's a feature that involves approval from 3+ people, I've seen them just get ahead of the work and gather requirements super efficiently.

      TLDR; good engineers are really good at doing the preparation before coding so they have to write 70% less code when the implementation actually begins. WLB does exist, but I think you'll have to fight hard for it.(being efficient, constantly improving, picking the right companies/teams)

  • 9
    Profile picture
    Entry-Level Software Engineer [SDE 1] at Amazon
    20 days ago

    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.

    • 2
      Profile picture
      AI/ML Eng @ Series C startup
      20 days ago

      Wow you write well! I really like your point about being proactive finding work to do. This definitely makes life easier, as you're no longer at the mercy of your Jira board

  • 8
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    19 days ago

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