3 ms·
This. I've been in a similar situation, but on the other end. We hired a very expensive (for us) freelancer with the goal of fixing some very critical performa
by rudasn 4y ago
This.
I've been in a similar situation, but on the other end. We hired a very expensive (for us) freelancer with the goal of fixing some very critical performance issues. We had all aspects of the issues documented, even line numbers of where the problem was (thanks, datadog). So we knew about the issues, but had no time to address them properly (very small team).
So this new developer starts refactoring a bunch of unrelated or seemingly related code, with pull requests in the 5k+ changes range, but no real performance gains (we needed to see CPU going down by 50% or more).
It would have taken us more time to review those pull requests and provide valuable feedback, than to fix the issues ourselves (which we finally did, by updating one or our dependencies).
Point is, as a new person on the team everything looks bad because its unfamiliar to you. But there's a reason for that current state and unless you try to, or show that you are trying to, understand why it's like that I don't think you are actually making things better - just more familiar to you.