Leaving aside the subjective topics (ego, oppinions ...) I can touch a few other spicy problems.
The company (managers, sales etc) will not value the new guy's work, most probably. The work he is doing most of the cases will not directly affect an important product KPI. Even if the work improves the product is not a visible (for non tech ppl) impact, I was actually reading this article earlier Why I Quit Google.
The old devs must explain the new guy the entire history of the project and most important the context. Understanding WHY those decisions were taken is more important (business vs tech decisions, like stupid example: we had a voucher of 10000$ on Azure and we didn't went to AWS, or we wrote that class because the management told us it will only stay in production for 2 days, which ofc they always lie).
Personally I got over this "fear" of legacy code only after I read the "Refactoring by Martin Fowler" book, I discovered a new world of challenges and opportunities, and understand how a code can and should evolve over time.
Related to this, a lot of oppiniated devs don't like, agree or know about the YAGNI principle, and when you are new to a project, and see the current problems is easy to say .."the todays issue could be solved by design last year when they wrote this system, but now I have to waste time and do their work...".
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Leaving aside the subjective topics (ego, oppinions ...) I can touch a few other spicy problems.
The company (managers, sales etc) will not value the new guy's work, most probably. The work he is doing most of the cases will not directly affect an important product KPI. Even if the work improves the product is not a visible (for non tech ppl) impact, I was actually reading this article earlier Why I Quit Google.
The old devs must explain the new guy the entire history of the project and most important the context. Understanding WHY those decisions were taken is more important (business vs tech decisions, like stupid example: we had a voucher of 10000$ on Azure and we didn't went to AWS, or we wrote that class because the management told us it will only stay in production for 2 days, which ofc they always lie).
Personally I got over this "fear" of legacy code only after I read the "Refactoring by Martin Fowler" book, I discovered a new world of challenges and opportunities, and understand how a code can and should evolve over time.
Related to this, a lot of oppiniated devs don't like, agree or know about the YAGNI principle, and when you are new to a project, and see the current problems is easy to say .."the todays issue could be solved by design last year when they wrote this system, but now I have to waste time and do their work...".