What makes a great contribution to a codebase?
blog.eliperkins.com
blog.eliperkins.com
You mentioned feature flags, but not cleaning them up. You’re so careful to call out leaving time for other things, I absolutely recommend calling out that feature flags (and releases) MUST MUST MUST be finished, and not left in a perpetual 100% rolled out mode! Do the work to clean it all up! If you leave jank, jank is now examplary.
Regarding feature releases, spend the extra month or whatever making the NEW way the ONLY way, when applicable. It otherwise becomes impossible to change any code for the better— “oh you can’t change those two things actually because we didn’t finish releasing these two legacy features and now we have to support them all in the code forever”— No!!!!
You do half that in a larger organization and it's a disaster. Structure and formalized communication becomes so much more important as a team and project grows.
The only time that's 100% fine is if you've already legally committed to destroying the codebase by the end of the month.
I can count on one hand the amount of commit messages I've read that were useful. If I'm trying to understand what the code does I'm more interested in reading the code, even if the commit message is extremely detailed. When the team is small it's even less important because I'm already aware of every change being made.
Just my experience though; would be glad to hear others deriving benefit from commit messages and describing how those messages should be written.
At this point I almost weekly have to review the full context on a pr to make sure my fix won’t break some historical use case that isn’t immediately obvious.
I'd argue tests are much better to guard against accidentally breaking contracts, since they can tell you when that happens, and even why it's important that it doesn't. If that doesn't work, code comments are also good, since they are immediately attached to the relevant code, even if it's refactored and moved elsewhere. "// this looks wrong but " is pretty common in my code.
Warnings in commit messages may be irrelevant, and the deprecation notice may not appear in the same "git annotate".
Especially for projects with any sort of longevity, the commit log is an awfully large haystack to keep such important needles in.
Commit messages are primarily about communicating all of that to others. But if there is no one else to communicate to...
Is it a good idea to have all your commit messages as emojis (or blank) even if you're just working on it yourself? Probably not. Will the codebase be "destroyed" by "the end of the month"? Yeah nah.