Suggest you to read through this resource and the answers in the thread: 

- <https://techcareergrowth.slack.com/archives/C01M20V3MEJ/p1661834266692019>
- <https://techcareergrowth.slack.com/archives/C01M20V3MEJ/p1661862937399349?thread_ts=1661834266.692019&cid=C01M20V3MEJ>

Grab

Senior Software Engineer

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:
- Start it in phases, and a certain phase should contain the cluster of code pieces that are cohesive or as a whole form a certain business usecase, so that impact is minimal in terms of the changes, in case of any issues.
- Add tests, if they are not there already for the changes you are making, in order to make sure that whilst these changes are being done, the core functionality should still be served in the same manner. For example: a function intending to save data to a table should still do that and input - output mapping for that function should still remain the same.
- Telemetry: Push monitoring metrics around the flow you are refactoring. This helps you to assess issues if any, once you rollout the changes. In my opinion, post-production support and how quickly a system reacts to impact is testament of its resilience.
- Document, Document, Document! I cant stress this enough how important is it to document the things you are doing. Why did you chose to refactor it in a certain design pattern and not something else? For each business usecase, what all testing was done? What is the go to production checklist? 
- Remove the dead code. Once you have rolled out your changes, and they are out in production serving all the business usecases correctly, then plan to remove the dead code. 
Do read [this article](https://medium.com/p/a163a1b41f00) I wrote on how important and underrated documentation is.

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:
1. [https://martinfowler.com/books/refactoring.html](https://martinfowler.com/books/refactoring.html)
2. [https://www.amazon.in/gp/product/0131177052](https://www.amazon.in/gp/product/0131177052)

Adding to Rahul's advice, I would like to say that you can get started and keep trying to connect dots between what you've studied and how the same is implemented in the codebase you're working on.

Quite often, a new framework or programming language can seem a bit alien due to lack of usage by the user, however try to understand the fundamentals and not get trodden down by the syntax. For instance, loops and mutex variables share the same meaning across languages even if syntax may vary widely. This is a transferrable skill and understanding the basics will go a long way. Don't feel bad if you need to refer the syntax during the initial usage. If you understand what purpose it is serving, it would eventually come to you. 

Alongside connecting the dots, you can try to build your own mini projects that give you some experience of how things are done in that particular language.

At last, don't feel shy to ask questions within your team. You can refer some amazing pointers [here](https://link.jointaro.com/cNcCY7RXvoVsxHDe8) on asking questions.

A good reference to [a channel that has some videos on Golang](https://www.youtube.com/c/GolangDojo).

Communication is a skill that software engineers often underestimate in terms of importance, and being good at it is effectively a senior engineer requirement. In this series, Alex breaks down the principles and tactics he uses to communicate effectively.

Alex's Guide To Effective Communication

In this course, Louie tells you the things your manager wants to tell you, but can't. Either because it would make things awkward, or it would get them in trouble. 

These are things you'd have to learn the hard way. This is the advice Louie wishes he had years ago, that you will get now. This course condenses a year of One on Ones into 1.5 hours.

Timeless Career Advice for Software Engineers

Every engineer wants to become senior someday, but this promotion is notoriously difficult, especially at FAANG. Learn what it takes to quickly become a high-performing senior engineer.

[Course] Grow From Mid-Level To Senior Engineer: L4 To L5

As a software engineer, you are more than just your code. As the person bringing the product to life, you are uniquely positioned to have a strong influence on its direction. In fact, it's extremely important for very senior engineers to get to know their PM and develop strong product intuition.