Writing a commit message doesn't seem like a good example because it's usually a moment where you can pause the flow state because you've just completed the thing that needed flow
They're more like the period at the end of a sentence, so that you can flow into the next one.
I have found it to be a sign of inexperience when devs protest "good" (whatever that means to you) commit messages.
They seem to have never worked with legacy code that has a good commit history you can rely on.
Arguing commits break flow would likely come from the same mouth that comments are useless and the code is self documenting. The "doesn't write code thinking of others" type.
I've actually found the opposite to be true. That usually the people harping for rich commit messages are the ones not thinking of others. That they are trying to get their coworkers to bend or produce extra work just to make their personal workflow more ergonomic. The information they seek is already redundantly documented, often 3 times over in the form of PR messages, jira tickets, requirements documents, slack history, etc.
In a perfect world yes that is true, but I've worked at multiple places where Jira got reshuffled by someone and either entire projects got deleted or ticket ids were reset.
Slack history and requirement documents are rarely linked in commit messages and looking through thousands of documents and channels to search the context of a commit is nauseating.
There's never a need to write an essay in a commit message, but 2-3 paragraphs won't kill anybody either.
But are they at all discoverable from the code base? Those PR messages, jira tickets, and slack history ought to be linked to in the commit message, and that requirements document checked in.
(None of those links help when you switch to different providers; but that might not be too bad, depending on timescales of those changes)
anything that is not in the commit message or in the commit itself is practically useless. documentation covers how to use a thing. it usually doesn't cover why a change was made. that why also normally does not end up in code comments, and even less so would be aparent from the change it self. the commit message remains the only place where the why can be documented meaningfully and along with the change where it is needed.
at least in my current project working with legacy code that i am not familiar with, the why is the most important detail about a commit.
Most teams I've been on just link to the PR from Jira and Slack. The PR links to the commit message, and the commit message explains the change.
Other stuff like "this is ready, can you review it?", or "we can ship feature X now" lives in the other tools.
Note that (in the rare case where you want to), you can then search for links to old PRs in the other tools. Also, putting the jira ticket number in the commit message usually makes sense.
I find writing commit messages helps my development flow:
Why did I spend an hour refactoring 1000 lines of rust code again?
It worked the first time I got it to compile again, so it's probably fine, but it was a subtle non-functional change. I'd better commit + write a good message so:
- I don't forget why I just did that
- In case I need to back out the next step
- So that my coworkers know what I'm up to, and don't ask me on slack.
when i am writing commit messages i am actually very focused. i study the changes and try to condense them into a helpful description. incidently i am working with legacy code now which has me studying the commit history forwards and backwards, and good commit messages that allow me to discover changes that i am interested in are really making a difference.
PRs are merged squash everywhere I worked, so whats the point? Commit messages are hardly ever useful for me working on a task for a few days or even weeks.
Git keeps the commit messages when using `git merge --squash`.
By default it will produce a commit message starting with `Squashed commit of the following:`
The contents of this message are staged in `.git/SQUASH_MSG`.
When using GitHub the squash merge commit behavior is configurable and the teams I've been on have kept it configured to keep the commit messages of the commits being squashed. I assume GitLab has similar functionality.
Yes, I didn’t find it entirely convincing either, other than if you struggle with the right wording for the commit message, then it indeed can have the effect of being more of a disrupting break than if you were seamlessly proceeding with the next connected coding step that your mind was already occupied with.
One of the truly great programmers I met at VMware was almost obsessive in the way that he thought about not just commit messages but the entire structure of the commit log. The goal was to make changes appear as a flow of understandable commits that build to some greater goal.
I would add that's in some sense "externalizing" an ideal flow state in the sense of the article. Real flows are hesitating and often emerge incoherently. So you end up reworking the commits to represent the path you would have followed had you understood things fully at the start.
I think a better example that might be more broadly relatable would be "a lot of latency between writing something and seeing if it works", ie. long compile times, slow tests, long startup time for an executable, needing to restart a server, etc.
There is no "turn off slack notifications" solutions to this kind of thing, and it's a big persistent flow-shattering time sink for me.
