Take care of relationships. Your family and friends are more important than your code. Caring for your team’s well-being and career goals, and creating a friendly, inclusive environment, will free them to write the best code they can.
NB: I skipped #FridayDevAdvice last week because I was overseas taking care of my sick mother. Nothing is more important than the people in your life. Take care of them!
Refactoring can help keep a mature codebase fresh. But refactoring can impose a hidden cost when you support multiple releases.
A security patch or feature that you want to cherry-pick to previous releases will not apply cleanly post-refactor. More significantly, your engineers must remember the old design as well as understand the new, to synthesize a patch that makes sense for the older branch.
This is not an argument against refactoring! But keep this hidden cost in mind the next time you hack an old codebase.
If you are an introvert (as I am), remember to slightly overcommunicate in your daily emails and chats. What you perceive to be overcommunication is probably closer to the appropriate level expected by others in your team.
Keep your commits clean. Address only ONE issue per commit. Make sure the project continues to build and run at each commit. Your future cherry-picking or reverting self will appreciate it.
PS: And no sneaking in small, unrelated changes to avoid a code review! You know who you are.
In a sufficiently large organization, embrace Conway’s Law. Create software that mimic organizational structure, or modify organizational structure to mimic software architecture. Any other arrangement leads to chronic friction.
As a corollary, refactoring of organizational structure can be a forcing function for refactoring software architecture. It may take time, but your software will eventually reflect your new organization.
Copyright ©2014–2023 Dave Rahardja. All rights reserved.
Any use without prior written permission is subject to licensing fees.