Hi guys, I’ve recently joined a new team and learning a new coding language. The first task given to me by my team was a refactoring task to ramp up. They said to take your time as there’s no rush to finish it right now. However, it seems to be a very complicated refactor as there’s multiple lambda functions each referencing variables from all over the place. How do I communicate this with the team and not look incompetent?
In this particular case, I would try to firstly spend some time only for the analysis phase. Basically, I try to analyse where all the lambda's are being invoked from.
I start scoping out the changes which need to be done in order to facilitate the requirements. Thereafter, we analyse the impact of those changes. I feel that an engineer who has been in the team a bit long enough might be able to help you assess all the business use-cases that are being impacted, or point you in the direction of how to evaluate the same.
Once you have the business usecases listed down, I suggest you to surface the same to the team, and try to understand more about what these business usecases entail at a high level. It is better to phase out a project that impacts alot of flows, especially when you are refactoring something. One way of doing it is to have some feature flags based on which you can enable the refactoring for a certain percentage of users. This way the scope is communicated much better to the entire team and it is a learning opportunity for the team as well.
Following things are very important in my opinion:
Please make sure to keep other team members in loop on the changes you are making and get it reviewed from time to time, in order to get feedback.
Some other references for a fun-time read:
How do I communicate this with the team...
I think similar to the above advice, I recommend just creating a very nice write-up on why the refactor is much more complicated than initially thought. I'm assuming you have a task, so you can just put this context there and let whoever assigned the task to you (or the entire team if it makes sense) know.
Some tactics to use for the write-up:
Something else I want to call out is to view this as an opportunity. Solving problems with gnarly technical scope is a huge part of growing from E3 -> E4, so this task gives you an opportunity to demonstrate this deeper technical skill.
...and not look incompetent?
Don't worry at all about this!
You're a fresh E3; of course you aren't going to be a super competent engineer at this point in time. Your team knows this as well, and they'll be supportive of whatever you ask or bring up as long as you do it politely and show that you did the legwork (i.e. doing the documentation as mentioned before). Embrace being a n00b and just put yourself out there! When you do that, you'll learn fast and stop being a n00b sooner than you thought.