Hi,
I am a mid level engineer. Recently I was given a task which had a tight deadline. I started looking at the task and was stuck as the results from the code run were not as expected while testing. I was unfamiliar with this area of code so tried my best to understand the code and investigate the cause of unexpected result. I raised this with the team and also raised this as a blocker. I mentioned that I did not have confidence in going ahead with the task without understanding the cause of the unexpected results. My team was unhappy with this as the code has been working okay so far without any issues and the unexpected results were likely because of a gap in my understanding. The team assumed that I did not want to do the task whereas my hold up was not wanting to proceed without having a clear understanding of what's going on.
Should I have approached the situation differently? How to work with an unknown or hardly known area of code on a tight deadline?
I have had issues in the past with the team because of performance and other reasons. I have recently improved my performance but fear falling back to the old ways.
Thanks
The problem here is that it seems like you're trying to run away from the issue instead of tackling it head on - This is why your team is unhappy. Flip the mindset:
The former is reactive and helpless while the latter is proactive and taking control. As a senior engineer, you are going to get plunged into crazy situations all the time. If you have been on your team for a while as a mid-level, I imagine your teammates (and especially your manager) are expecting you to take on these ambiguous, unknown problems with more confidence to make progress towards senior.
This is a very common behavior evolution I have taught to countless mid-level engineers as I mentored them to senior. While junior -> mid-level is mostly sharpening what you know, mid-level -> senior requires a more fundamental behavioral shift where you are developing the "meta" ability of learning how to learn so you can quickly adapt to any crazy situation. So I just wanted to let you know that you're not alone in this journey - Most mid-level engineers have been where you are and have come out the other side as much better engineers! 😊
I understand that charging into the unknown can be scary, but if you have a supportive team, they will welcome you taking the initiative with open arms. The first step is championing that healthy go-getter mentality and taking that leap of faith. I believe in you!
Here's a bunch more resources that cover this topic:
I mentioned that I did not have confidence in going ahead with the task without understanding the cause of the unexpected results. My team was unhappy with this as the code has been working okay so far without any issues and the unexpected results were likely because of a gap in my understanding.
The most important thing in this situation is to have very clear communication with your team where you come up with an action plan of 2-3 things you are going to try, how long you expect them to take, and what you will do if these things fail. Make sure to report back with exactly what happened when you executed your action plan. You want to avoid being stuck in a limbo zone where there is no progress being made at all. You and your team should be clear about what the next steps are. Make sure to reach out to people if you are blocked.
How to work with an unknown or hardly known area of code on a tight deadline?
Action is the key here, too. Just start breaking things and printing out comments to make sure the code is functioning as you expect. If there's a part of the code that raises a question, try to break it, or try different inputs to see what happens. It can be easy to get intimidated with a codebase that's new because there's a barrage of so many unfamiliar ideas. The best thing is to test your assumptions by breaking the code (locally, of course).