I am slowly building a reputation in my team as someone who can’t just make a change without restructuring everything. Maybe it’s a behavioural defect, unnecessary perfectionism. It could just be pure stubbornness. Whatever you put it down to I am not planning on changing any time soon and I would encourage my team to adopt a similar attitude.
When you start your journey as a software developer, contributing to an existing code base can be daunting. You are keen to keep your changes minimal, not to rock the boat and you don’t know any better. What choice do you have but to emulate the existing work?
I think that fear of going against the grain or overstepping your mark can contribute to a viscous cycle of reinforcing bad practices, multiplying technical debt and stifling creativity.
Let me explain why I think this way.
Questioning is good
I think putting yourself out there is good for all parties. The worst case scenario is your implementation is bad and someone tells you why. You lose a bit of time but you learn something. The best case scenario is that your approach is taken up, other people might learn something and after some refinement, the code base is better for everyone.
If you have a positive experience as a junior with more experienced developers welcoming a change of opinion I think this fosters a better team spirit of innovation and openness. You will be more receptive when you are in a more experienced position and people will value your receptiveness to new ideas.
I have always seen programming as a creative activity. There are different ways to achieve the same outcome and different people express themselves in their own ways. Thinking outside the box and trying to approach problems from different angles often leads to more innovative ideas that can push your project to the next level.
Boy Scout rule
Leave the code base in a better state than you found it
The old mantra of the scouts. Don’t be happy with returning your campsite to the state in which you found it, if you find something broken by someone else, a bit of rubbish left behind. Pick it up, fix it. Sure it is outside the scope of your task but without these little acts of good will a code base can decline into a state of neglect.
It can be as simple as fixing a typo in a variable name or fixing some indentations. Maybe the scope of corrections could be slightly more involved like extracting a bloated inner class or refactoring a unit test file. Whatever it is, take pride in your project and sort it out.
Refactor to do
I read a quote recently which resonated particularly with me.
Make the change easy then make the easy change
To refactor is to do.
You shouldn’t be happy forcing an awkward change, potentially breaking a nice pattern. If the new functionality doesn’t fit with the current implementation, the current implementation needs to change. The fact that a change is not easy to make should not be overlooked.
Refactor first. Try to keep it simple, aim for the code to functionally do exactly the same thing. A reviewer can then just satisfy themselves that nothing has broken. You also separate any refactoring tasks from any new implementation which should help cap the complexity and keep you focused.
If your unit test coverage is good, you should be able move things around with confidence. If your unit tests are well written, any restructuring should be easy to reflect in test updates (surprise surprise tests are important).
Once you have set everything up, the feature should be trivial. Trivial changes are easy to understand when the next person picks it up. Also the review becomes much more intuitive. Funnily enough, simpler code is less buggy code as well.
To sum up
Normalise refactoring, do it constantly and keep putting quality first. Good codebases are just nice to work on, I am convinced team morale is strongly tied to code quality. As a developer you should always try to justify refactoring work, it will pay off in the long run.