Look for a fix that works on both setups
A general principle in situations like this is the Scout Rule:
Leave the code in (at least) the same, or (preferably) better shape than when you found it.
So your senior colleague has their development environment set up in a specific manner. There can be many reasons for that, some possible ones good and very valid, some unnecessary and maybe even harmful.
Good reasons for this setup may include that...
- It expedites development, debugging and/or deployment
- It includes functionality that is not present in other setups
- It deals with backwards compatibility that is required for interoperability with other modules
- Changing to another setup may require extensive work to ensure that the rest of the code still works as intended (*).
Bad reasons for this setup may be...
- Laziness or otherwise irrational resistance to keep up the development environment to date ("It works fine for me, I won't touch it!")
- Prejudice against newer versions as "Untried, therefore unsafe".
- "We have always done it this way"
What you can do here is ask your senior colleague: "How come you are using that? Is there a specific reason?". And they will tell you. Maybe their reason will be — in your opinion — good and valid, or it will be — again in your personal opinion — a bad reason. But do note that most likely they feel that the reason is valid.
What would make the least bit of fuss is if you make a change that works on both setups, provided that you do the change correctly. For that you need to go through a...
If you want to use the Scout Rule, and "fix" a problem that is not directly related to your work, it is usually appreciated if you do it. But only if you make sure that what you do is actually better. As such you must make sure that...
1. My changes will not break things
The road to hell is paved with good intentions
The first thing you need to do is make sure that your fix does not actually break anything. The usual safeguards — no compiler errors, code review, automated tests — will help you there. Avoid checking a Scout Rule Fix into the main development track, instead use side branch of the code and get the change tested before anything else.
2. My changes will not make things more confusing or add unnecessary complexity
This point is rather self explanatory. It is a virtue to keep the code simple and maintainable. If your change means that it becomes harder to read, build or deploy the code, then it is best to leave the change out. But if it can be added with no change to the complexity of the code, nor the build and deploy process, then it is OK.
3. My changes will improve things
Just like the senior developer thinks that their setup works for them, so you may fall into the same trap. And while an improvement for you is indeed reason enough to affect a change, you may wish to ask others too "Is this worth it?". If they agree that this is an improvement, then go ahead.
(*) I have have had code break from just upgrading to a new sub-version of a development kit... not even the minor version but the sub-version.