7 ms·

>Already it’s pulling teeth just to get literate commit messages… I usually push back on this because those commit messages almost never actually get read. It'

>Already it’s pulling teeth just to get literate commit messages… I usually push back on this because those commit messages almost never actually get read. It's an investment whose dividends are nebulous and hard to pin down. It's rare that I look at a commit, and it's even rarer that I read it and wish that it had a better message. There are all sorts of other documentation I routinely wish people put more effort into writing (comments, a "why" attached to every test, how to guides, tutorials), but rarely ever a commit message.

paulddraper 2y ago
Surely you do it often enough that an extra 90s would not be an undue cost?
- hitchstory 2y ago
  I'd estimate I probably commit ~30-50 times a day. I dig into and read a commit message once every 3 months. A 90 seconds a commit that's an hour a day spent writing beautiful commits. That one hour a day could be substituted with one conversation "hey, why did you do xyz in [ linktocommit ]?" every 3 months. If you dont do these back of the envelope calculations in your head when trying to figure out if something is worth doing I highly encourage it.
  - kragen 2y ago
    Maybe you should be using `git stash` and `git stash pop` rather than commits. Or go back and squash your 30–50 commits into one or two, which might take ten minutes. What you're doing is better than not using version control at all, but only barely.
    - hitchstory 2y ago
      I do squash them where appropriate. I do use git stash where appropriate. These arent nonobvious novelties, save perhaps to junior engineers.
      - kragen 2y ago
        Well, that is kind of what you sound like.
        Supermancho 2y ago
        > Well, that is kind of what you sound like. This is what senior engineers do. Interrupted to switch tasks every 10 min. Make your good changes as a commit and move to the next task. Maybe you get back to it today, maybe not.
        kragen 2y ago
        That's definitely not how Jeff Dean and Sanjay Ghemawat wrote MapReduce and Bigtable. I'm sure what you're saying is correct at many companies (I've seen a few), but it's a stupid policy, depriving them of the benefit of having senior engineers.
  - lanstin 2y ago
    Do you not have code reviews?
  - paulddraper 2y ago
    You make a new commit every 12 minutes for eight hours?
    - Supermancho 2y ago
      > You make a new commit every 12 minutes for eight hours? You only work 8 hours? Your changes are that big? These are bad faith questions.
      - paulddraper 2y ago
        These questions are not made in bad faith.
    - hitchstory 2y ago
      That sounds like a reasonable average, yeah. Some tiny changes take 45 seconds, some harder changes take 40 minutes. I find that working in working code increments that are as small as possible to be ideal.
norir 2y ago
Writing good commit messages can be good self-promotion. You may not realize who is watching the repo and this is an easy way to differentiate yourself from you colleagues and make your work appear interesting and important. Also, I have found that writing commit messages often forced me to rework a poor solution whose weakness became apparent only when I tried to explain it. In other words, often the value of the commit message is not the message itself but rather the process that produced it. It's a bit like musical scales. Almost no one is performing scales at a concert but also almost no one is performing without scales as a part of their regular practice.
- hitchstory 2y ago
  >can be good self-promotion. You may not realize When I said nebulous and hard to pin down this is kinda what I meant. Do you routinely monitor commit messages on adjacent teams' repos? I dont. I dont know anybody who does. When I want to know something about their code I ping them a slack message and vice versa. I dont think the CTO is reading commit messages either, theyre too busy. I think it's good to ask when and why people actually do read commit messages to make sure what you write aligns with what they want to see.
fsmv 2y ago
If you wrote better commit messages you might look at them more because they're a lot more useful. At work I see it as explaining why the code is there so when people check the blame layer they can find out and not delete my code if my reason is still relevant. At home it helps a lot to write changelogs later when I do a release and it helps so much to see the last few commits when I pick a project up again after a month or two.
- hitchstory 2y ago
  I mostly just message the person who wrote it if I have questions when I look at a commit and have questions. I suppose if I painstakingly write 1000 beautiful commit messages I could save myself from having that one conversation when somebody else has a question about one of those commits.
  - moe_sc 2y ago
    That doesn't sound future proof. People leave projects/companies, people forget. Code comments are also far from good. They have the same issue as duplicatet code. Comment and code age indiviually. Now you have to maintain both and it's for them to diverge. Git commits are a snapshot of the codebase. Commit messages in them are pinned to a code version. Comments in commit messages are therefore always tied to the right version of code.
    - hitchstory 2y ago
      People leaving is a great reason to write literate tests and other kinds of docs - the kind people actually look for and want to read. If somebody asks a question that can only be asked by looking in a commit message that usually represents a failure in one of those docs.
  - kccqzy 2y ago
    I'm an introvert. I don't want anyone to message me (or worse, set up a meeting with me) just to understand what my commit does. Furthermore writing is itself a way to enhance clarity of thinking. Very often during the process of writing out a commit message I realize something else in the commit is missing.

paulddraper 2y ago

Surely you do it often enough that an extra 90s would not be an undue cost?

hitchstory 2y ago
I'd estimate I probably commit ~30-50 times a day. I dig into and read a commit message once every 3 months. A 90 seconds a commit that's an hour a day spent writing beautiful commits. That one hour a day could be substituted with one conversation "hey, why did you do xyz in [ linktocommit ]?" every 3 months. If you dont do these back of the envelope calculations in your head when trying to figure out if something is worth doing I highly encourage it.
- kragen 2y ago
  Maybe you should be using `git stash` and `git stash pop` rather than commits. Or go back and squash your 30–50 commits into one or two, which might take ten minutes. What you're doing is better than not using version control at all, but only barely.
  - hitchstory 2y ago
    I do squash them where appropriate. I do use git stash where appropriate. These arent nonobvious novelties, save perhaps to junior engineers.
    - kragen 2y ago
      Well, that is kind of what you sound like.
      - Supermancho 2y ago
        > Well, that is kind of what you sound like. This is what senior engineers do. Interrupted to switch tasks every 10 min. Make your good changes as a commit and move to the next task. Maybe you get back to it today, maybe not.
        kragen 2y ago
        That's definitely not how Jeff Dean and Sanjay Ghemawat wrote MapReduce and Bigtable. I'm sure what you're saying is correct at many companies (I've seen a few), but it's a stupid policy, depriving them of the benefit of having senior engineers.
- lanstin 2y ago
  Do you not have code reviews?
- paulddraper 2y ago
  You make a new commit every 12 minutes for eight hours?
  - Supermancho 2y ago
    > You make a new commit every 12 minutes for eight hours? You only work 8 hours? Your changes are that big? These are bad faith questions.
    - paulddraper 2y ago
      These questions are not made in bad faith.
  - hitchstory 2y ago
    That sounds like a reasonable average, yeah. Some tiny changes take 45 seconds, some harder changes take 40 minutes. I find that working in working code increments that are as small as possible to be ideal.

norir 2y ago

Writing good commit messages can be good self-promotion. You may not realize who is watching the repo and this is an easy way to differentiate yourself from you colleagues and make your work appear interesting and important. Also, I have found that writing commit messages often forced me to rework a poor solution whose weakness became apparent only when I tried to explain it. In other words, often the value of the commit message is not the message itself but rather the process that produced it. It's a bit like musical scales. Almost no one is performing scales at a concert but also almost no one is performing without scales as a part of their regular practice.

hitchstory 2y ago
>can be good self-promotion. You may not realize When I said nebulous and hard to pin down this is kinda what I meant. Do you routinely monitor commit messages on adjacent teams' repos? I dont. I dont know anybody who does. When I want to know something about their code I ping them a slack message and vice versa. I dont think the CTO is reading commit messages either, theyre too busy. I think it's good to ask when and why people actually do read commit messages to make sure what you write aligns with what they want to see.

fsmv 2y ago

If you wrote better commit messages you might look at them more because they're a lot more useful. At work I see it as explaining why the code is there so when people check the blame layer they can find out and not delete my code if my reason is still relevant. At home it helps a lot to write changelogs later when I do a release and it helps so much to see the last few commits when I pick a project up again after a month or two.

hitchstory 2y ago
I mostly just message the person who wrote it if I have questions when I look at a commit and have questions. I suppose if I painstakingly write 1000 beautiful commit messages I could save myself from having that one conversation when somebody else has a question about one of those commits.
- moe_sc 2y ago
  That doesn't sound future proof. People leave projects/companies, people forget. Code comments are also far from good. They have the same issue as duplicatet code. Comment and code age indiviually. Now you have to maintain both and it's for them to diverge. Git commits are a snapshot of the codebase. Commit messages in them are pinned to a code version. Comments in commit messages are therefore always tied to the right version of code.
  - hitchstory 2y ago
    People leaving is a great reason to write literate tests and other kinds of docs - the kind people actually look for and want to read. If somebody asks a question that can only be asked by looking in a commit message that usually represents a failure in one of those docs.
- kccqzy 2y ago
  I'm an introvert. I don't want anyone to message me (or worse, set up a meeting with me) just to understand what my commit does. Furthermore writing is itself a way to enhance clarity of thinking. Very often during the process of writing out a commit message I realize something else in the commit is missing.