5 ms·

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 w

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.

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.