[larusso]

I always get triggered when a new team member comes in and starts to rename variables in Pull requests and plans out huge refactorings. I‘m like ok you are five minutes into this code without any knowledge why it is shaped and named like this. Not that the person is or isn’t correct it is just how fast people are willing to change working software because they feel they can make it better in an instant. The second reason I get triggered is that I think it is quite rude to the programmers that came before. I have to swallow a lot of pride over the years because of course ones code isn’t without fault. But to point that out from a newbie in the team who maybe only want to proof that they can code? Super hard for me ;)

[hombre_fatal]

I still cringe at the memory of my first webdev job out of university. I thought it would be a good idea to alphabetize all of the methods of the behemoth User.rb class of an ancient Rails application.

The other developers let me do it and, looking back, they obviously didn’t want to rain on my parade as a junior dev that was eager to help out and “improve” things, god bless them.

[Scarblac]

On the other hand, it's also bad when a new person comes in who treats all existing code as gospel and is afraid to fix things that are clearly messy. Or doesn't even see the need.

I think I actually prefer your type, at least they care about improving things, and they're going to make it theirs.

[cesnja]

I almost always welcome such initiatives because the new team member brings a fresh perspective and is unencumbered by our existing knowledge. And they don't have that many responsibilities yet, thus they can focus on the code itself. But good test coverage and thorough reviews are necessary to do this.

[larusso]

No don‘t get me wrong. I see this as well and have an inner fight when the typical: Let’s clean this up PR pops up. What I mean are changes that have no real value other than a change from Person X in file Y. Yes one can rename tons of methods and variables. But maybe these names stem for a reason. I have one example where the variable names where generic in nature and the change request renamed them according to the concrete implementation. You can argue back and forth about this :)

[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.

[andybak]

I agree but I also worry about a certain "Stockhold Syndrome" with large codebases. Sometimes it's the fresh pair of eyes that can see exactly how bad some things are. Once you've learned to understand something you tend to have a rosier view of it.

And sometimes the harder it was to understand something, the more invested you become in it and the more you want to defend it.

[andybak]

Doh. Typo "Stockholm"...

[lukebuehler]

The trust to refactor needs to be earned. There is a social dimension to refactoring. People that come to a codebase and immediately start refactoring don’t understand this. They believe they can just make objective arguments and others will accept them.

[avip]

Team newbies should write unit tests.

[ThalesX]

Bugs, tests, documentation, grooming, there's plenty of stuff to do to get one's feet wet.