I was working on a P1 - High priority bug today which needed to be done within a day. This bug was assigned to me by a Senior Engineer who was supposed to pick up this task but was delegated to me. This engineer has been pretty helpful to me when I was ramping up on things. He explained me the context of the bug in a short call. I figured out the fix and sent him the method which was responsible for the issue and the stack-trace from the log and how I am going to fix it.
I was then told by the same engineer to not 'swing by small small things by me and that I take the entire ownership of the task I am doing and bring it to closure'. I do agree with this and understand that they have other priority meetings and features to work upon but my entire purpose of sending him updates was then I was not going off track and that the CR which I am going to raise does not have a lot of revision / reviews.
I just need to know when exactly are we supposed to let the other team member know how much we have progressed and also at the same time not let them feel that I am not taking ownership of my tasks?
Note: I'm going to assume you pinged this person directly - Please correct me if I'm wrong.
As with many situations, it's important to have empathy here. A tenured senior engineer on the team is going to own a lot of things, which means they're going to receive pings constantly. This was my life at Meta after growing into a tech lead. This means that almost all senior engineers are going to try to reduce the amount of pings they get, so they can better focus and not get overwhelmed. Personally, I would be confused if an engineer pinged me directly about their progress on a bug that should take ~1 day.
That being, I think the issue here is how you communicated, not whether or not you should have communicated at all. Something I have pushed for time and time again is to communicate in as public a setting as possible. Here are the other mediums you could have used to communicate the status of this bug:
These are more public avenues of information that the senior engineer can then use to consume the status info in a more convenient, asynchronous way for them.
For more advice on communication, I highly recommend my series on "Effective Communication". Some things that come to mind with how this series can help: