3 ms·
> I do think I'm improving our codebase on a daily basis. What does this mean exactly? If you are redesigning the code base it could be like going into someone
by foobarbaz33 4y ago
> I do think I'm improving our codebase on a daily basis.
What does this mean exactly? If you are redesigning the code base it could be like going into someone's house and redecorating for them. It's no longer familiar. If that's the issue then yes slow down, talk about it and get consensus first. Even if your way is objectively a win.
If it's bug fixes, new features, etc. That's different. You should be encouraged to produce. But politics matter, so you will have to feel the situation out and decide. Bosses may be using you as the new yard stick to measure performance.
- rramadass 4y ago+1. Good Practical Advice.
- rudasn 4y agoThis. 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.