Just a few points... I'm happy you are not afraid to call yourself "junior". Humility goes a long way to becoming a great programmer. Asking permission is obe

Just a few points... I'm happy you are not afraid to call yourself "junior". Humility goes a long way to becoming a great programmer. Asking permission is obeisance but it is also communication. Whoever you asked may have knowledge of dependencies upstream or downstream. By asking, you gave that person the chance to add a little context to the change you propose to make and, quite possibly, prevent the team from working overnight to correct an issue you created. Even with 25 years in the field, I still ask other engineers about changes I want to make. Quite often we talk through any ripple effects before I set hands to keyboard. Be especially careful in modifying interfaces, library calls, etc. Basically, any module that other systems depend on should be modified with a lot of caution and testing. Your caution should grow at least linearly with the dependency graph. Over time you will develop a sense of which changes you can make without asking, which changes you should talk with others about, and which ones to stay clear of. Your primary responsibility is creating good software. Your second responsibility is staying employed. Don't fret over every oddity you see in a code base. Refactoring is good for all the reasons people listed in the comments. Figure out which ones have the highest value and talk with the other developers about them. ("Live to fight another day")