4 ms·

5 commits a week is normal? Im going to assume those are big commits.. I personally would do a commit for every little class or method I write. I did 18 last w

5 commits a week is normal? Im going to assume those are big commits.. I personally would do a commit for every little class or method I write. I did 18 last week for example. Also I'm curious what he means by 'burnout' I'd take that to mean mentally exhausted from too much stress. Sounds like he was more vaguely dissatisfied or unmotivated.

packetslave 11y ago
A "commit" at Google tends to be a bit bigger unit of work. To submit a changelist to Piper, you need a code review, your code probably needs unit tests, etc. Probably not 1000 lines of code, but probably not 10 either (unless it's a bug fix) Obvious caveat: there are 20,000+ engineers and hundreds of teams at Google. Things aren't exactly the same everywhere.
nostrademons 11y ago
On the high side, actually. In many cases you'll need to get your code reviewed by an external team, and oftentimes their SLA for one round of code review is 24 hours. That a.) incentivizes big commits and b.) sets a floor on the latency of your commit process. My long-term average at Google was 5 commits/week, max was IIRC 24/week, and min was 3 months to get one commit written, reviewed, and approved. By contrast, when I'm coding on my own for my startup, my long-term average is 20 commits/week, max was about 14/day, and min is about 1/day.
marssaxman 11y ago
5 commits a week sounds like a lot, actually. Nothing gets pushed without a code review and it's a rare code review that doesn't require some changes, which therefore require another test run, etc. You'd have to be working steadily and have some very responsive teammates in order to get a commit in every single work day. At least, that's the way it worked when I was there. I sure as hell didn't get 5 commits in a week.
dcherman 11y ago
It also depends on what you mean by commit. Are we talking 5 commits in 1 merge request (Git style), or 5 individual pieces of code to be reviewed separately? In any case, I think 5 per week is extremely reasonable; I actually do less these days. I used to commit a dozen or more times per week, but these days I tend to work on the larger and harder components that people require. That means more thought and more design. It's not doing less work, it's just doing harder work. This person may also have had review reponsibilities. Doing a truly thorough code review takes time to complete, and that time is time that you're not coding. It's important though; I may not be coding while I'm reviewing, but I'm sharing knowledge with a dozen other developers who hopefully learn from it (as I learn from others reviewing my own code). In aggregate, I hope that my lack of frequent commits actually helps the company rather than hurts it since hopefully I'm enabling many others to do better work.

packetslave 11y ago

A "commit" at Google tends to be a bit bigger unit of work. To submit a changelist to Piper, you need a code review, your code probably needs unit tests, etc. Probably not 1000 lines of code, but probably not 10 either (unless it's a bug fix) Obvious caveat: there are 20,000+ engineers and hundreds of teams at Google. Things aren't exactly the same everywhere.

nostrademons 11y ago

On the high side, actually. In many cases you'll need to get your code reviewed by an external team, and oftentimes their SLA for one round of code review is 24 hours. That a.) incentivizes big commits and b.) sets a floor on the latency of your commit process. My long-term average at Google was 5 commits/week, max was IIRC 24/week, and min was 3 months to get one commit written, reviewed, and approved. By contrast, when I'm coding on my own for my startup, my long-term average is 20 commits/week, max was about 14/day, and min is about 1/day.

marssaxman 11y ago

5 commits a week sounds like a lot, actually. Nothing gets pushed without a code review and it's a rare code review that doesn't require some changes, which therefore require another test run, etc. You'd have to be working steadily and have some very responsive teammates in order to get a commit in every single work day. At least, that's the way it worked when I was there. I sure as hell didn't get 5 commits in a week.

dcherman 11y ago

It also depends on what you mean by commit. Are we talking 5 commits in 1 merge request (Git style), or 5 individual pieces of code to be reviewed separately? In any case, I think 5 per week is extremely reasonable; I actually do less these days. I used to commit a dozen or more times per week, but these days I tend to work on the larger and harder components that people require. That means more thought and more design. It's not doing less work, it's just doing harder work. This person may also have had review reponsibilities. Doing a truly thorough code review takes time to complete, and that time is time that you're not coding. It's important though; I may not be coding while I'm reviewing, but I'm sharing knowledge with a dozen other developers who hopefully learn from it (as I learn from others reviewing my own code). In aggregate, I hope that my lack of frequent commits actually helps the company rather than hurts it since hopefully I'm enabling many others to do better work.