Comment by corytheboyd | Hacker News Reader

Comment by corytheboyd | Hacker News Reader

Parent Full thread

Guess I’m just jaded by big tech, but all I can think is “oh sweet summer child” hah…ha… now I’m sad. Maybe just post-work depression lol. It’s totally worth caring about this stuff vigilantly as a small team though. Big teams too of course, but we all know how that goes.

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!!!!

I'd argue, on the contrary, that it's primarily in a larger team and project this stuff is necessary. The smaller the team and project, the more process you can get rid of. Commit straight to master, use single emojis for commit messages, like realistically there's a team size where that is 100% fine.

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.

>use single emojis for commit messages

The only time that's 100% fine is if you've already legally committed to destroying the codebase by the end of the month.

That's pretty exaggerated. I rarely read commit messages from projects where I'm the main (or sole) author. Even after several years of not working on something I rarely have difficulties remembering why I did something. And the really weird funky shit tends to be documented by comments.

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.

The person you're responding to built a search engine from scratch.

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.

IME hard disagree. Projects with any longevity and/or turnover will have code that doesn’t seem to make sense but was put there for a reason. Commit messages are key to giving the context because even though there might be descriptions people will put the relevant slack messages and jira tickets in the pr or commit.

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.

> 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.

Wouldn't comments and/or tests be more effective than a commit message in that scenario? Seems like you're putting a lot of faith that future devs will read through commit messages to avoid breaking things.

Reply on news.ycombinator.com