First few months/years* (depending on the size of the project), learn the project with its idiosyncrasies, try to understand the business logic and reasons why things were done in the way they were done (often there are good reasons), write good code for your assignments, write tests to cover the existing behavior, even if it's buggy. Earn the trust of the team.
Start to identify well-defined areas with a good ratio of impact/risk/difficulty and propose changes to tackle them. Refactor/redesign such solution gradually, with feature toggles. Rinse and repeat.
*"First few months/years" may seem exaggerated. The point is that you should be tackling the problems only if you really understand them, and that's unlikely the case when you just come into the project. As you learn, you understand smaller pieces and can tackle those. But to tackle the big problems, you often need to understand much more of the project.
Comments
First few months/years* (depending on the size of the project), learn the project with its idiosyncrasies, try to understand the business logic and reasons why things were done in the way they were done (often there are good reasons), write good code for your assignments, write tests to cover the existing behavior, even if it's buggy. Earn the trust of the team.
Start to identify well-defined areas with a good ratio of impact/risk/difficulty and propose changes to tackle them. Refactor/redesign such solution gradually, with feature toggles. Rinse and repeat.
*"First few months/years" may seem exaggerated. The point is that you should be tackling the problems only if you really understand them, and that's unlikely the case when you just come into the project. As you learn, you understand smaller pieces and can tackle those. But to tackle the big problems, you often need to understand much more of the project.