[wheybags]

I actually think jumping straight in and refactoring is one of the best ways to learn a new codebase. If it's set up consensually and as a learning tool, the combo of refactoring + review from older team members is a great way to learn, even if your changes ultimately don't make it to prod.

[disgruntledphd2]

As long as you have decent test coverage, this is a brilliant idea. It's a terrible idea if you don't.

[eptcyka]

You can still do it without tests as long as you have a version control system that isn't absolute garbage.

[H8crilA]

The broadest version is that you can let a junior do that if the system is well managed: has tests, the reviewer has good knowledge, there are good rollback procedures, good metrics exist; whatever it is that's appropriate is functioning.

[disgruntledphd2]

Can you? I would be incredibly nervous about breaking unknown stuff and it not getting noticed without tests.

For context, I work predominantly with stats/DS problems, where errors may not actually cause obvious (or indeed any) warnings/errors.

[eptcyka]

As long as you play around in your own branch and never merge your changes, what's the risk? You can try and make changes purely for the purpose of getting to know the code.

[disgruntledphd2]

yeah, fair I suppose. Personally, I find that changing things and watching the tests fail gives me a lot more insight than just running the code, but that's just me I suppose.