back
7 comments
A good manager, especially if they can recognize weakness in the existing code base, will let you refactor things. I've quit a job before when I wasn't allowed to rewrite code which actually wasn't even functional.

I've been extremely fortunate and that most of my recent managers have been okay with me either completely rewriting the code base, or implementing my own practices. I have no qualms about leaving a job where I'm not able to do my best work.

If I'm given the task to do so.
Let me add to this...

Any experienced developer is going to dislike her new team's code. It's just the way developers are. They like the code to match the way they think or what they're used to. New code bases are always counter-intuitive at first, and it feels like that wastes your time.

That means every new, experienced hire is going to want to refactor. It does not mean they should refactor or that anything is actually urgently wrong with the code.

I've had people who refactored, broke their build, couldn't fix, and ended up scrapping the branch entirely. It was a complete waste of time.

I don't see that as a waste of time at all. The programmer learned a lot and didn't damage the codebase, assuming the changes went unmerged. This sounds like a pretty good way to come to grips with the problem domain.
That's true, not how I took the question but it can totally be a valid strategy to help understanding of the code base.
I agree to this observation. Especially in teams with hight fluctuation they spend most of the time refactoring their code in cycles to fit some personal taste.
Refactoring things is part of the job. But while new on a team I prefer to err on the side of caution. You can learn a lot more by observing and listening sometimes.