There is a possible issue though - would they commit immediately after coding - how long do they need to work on a commit before actually committing it?
Yes and that's most irrelevant because we were discussing the device offset as users travel between timezones.
Unix Timestamps are always expressed as UTC/TUC which remain constant regardless of device offsets.
The origianl comment's assertion that users don't typically adjust their offsets is moot since commits are stored in UTC anyways. I was just pointing out that many devices automatically adjust offsets.
For one or two isolated commits, that is a fair question. But with hundreds I think it evens out.
A more detailed analysis could also take in account the number of changes. How many files per commit? How many lines, maybe?
The day of week is also a very interesting metric, that is very visible e.g. on github's timeline. I know my busiest days in terms of commits are in the middle of the week, a marked decrease on Friday afternoons, and if there are commits in the weekend, they most likely contain swearing in the message.
Edit: I'm betting Brad Fitzpatrick's pattern in Go (current job?) and memchached (not current job?) would vary in terms of day of week, not just hour.
I was wondering the same thing and also how one's habits change over time. I wonder would something like the Linux Kernel repository have sufficient history to show this?
Probably also heavily related to whether you have kids or not. I remember Linus saying that before he had kids he used to work during the night, but he had to stop that so he could drive them to school, etc.
I used to write lots of code at all hours of the day, 8 hours at work, 6+ hours at home.
Then i had kids, and while i still write code 8 hours a day at work, i rarely find the time to write anything in my spare time anymore.
Every now and then i have "some project" that i'm working on, but it's mostly in bursts of 2-3 days, followed by 3-5 days of "doing nothing". The 2-3 days are _not_ weekends, and i usually end up losing sleep over it.
Kids are relentless, and no matter how late you stayed up, they still get up at 6 AM, and needs to be taken to kindergarten/school, and requires you to be (mentally) present in the afternoon/evening.
I guess you could talk about a "soft burnout" happening from the 2-3 days burst.
I'm trying to change the burst periods into more frequent, shorter periods of 1-2 hours, hoping the increased frequency will reduce the "ramp up" time while getting "into the zone".
And there are other things that distract us with age. Eg I recently bought a house. Now I’m always coming home to do housework instead of coding. Also burnout can happen from acute events which we are more likely to run into over time. I hit a specific conflict at work and mostly lost the will to work OT for years after that.
I'm a forgetful person, so I commit very often but with label "tmp", and later I squash them all into 1 proper commit before pushing. I'm sure I'm not alone, so commit time can't be used as barometer.
I dislike the apparent inability to label groups of changes with `git stash`, so instead before leaving a branch with in-progress changes I'll commit them all as "WIP". Then, when I return to the branch, I'll check if the previous commit was WIP (`git log -1`), and if so will reset it (`git reset HEAD~1`). It's the best workflow I've discovered for dealing with this problem, and it means that I don't lose my commit history which is otherwise very clean.
Temp branches or tags are probably the "proper" way to stash a history of changes in git. `git stash` is mostly a convenience feature for when you want to quickly clean up your working tree to eg. pull latest changes from a remote.
I like the approach of creating a new temporary branch for changes I need to stash. When I come back to the work I usually bring the changes back to the branch I'm working in with `git cherry-pick -n <commit hash>`. The -n flag cherry picks the changes over without making a new commit, so I can finish whatever I was doing and then make a proper commit.
I hate stash because it’s too easy to accidentally pop. I just use a lot of branches, get familiar with git rebase, and learn about git reflog in case I screw up.
When I'm working on a new change I always create a new branch and (almost) always just work against one commit. I'll just keep amending that commit. I generally work out my tickets so that they are small enough that I don't have too many concerns with each branch, so maintaining a commit history isn't all that useful. I'm pretty sure I do loose out on the "looking really busy with lots of commits" in my github history tracking, but I could care less.
I would suggest making use of 'git commit --fixup' or 'git commit --squash' which creates a commit that is specially-named such that you can later squash everything together with `git rebase --autosquash'. It's really transformed how I work on large patchsets.
It is ridiculous how many nice features git has accumulated through the years, but their discoverability is... not excellent -- partially because of how many options we now have. It's a vicious circle.
I never saw anyone do this. May I ask what the point is? If it's just going to be in your local version and you later have to do (a very small amount of) work to get it back into one commit, why bother committing random stuff intermediately at all?
Oh, I use undo in my editor for that kind of thing. But I guess if you want to make large changes, this might be one way of doing it. Pretty sure that's what 'git stash/pop' is supposed to be used for, but I don't use those either so I wouldn't know if that works well.
Nice graphs. It is interesting to note that the scale changes. In each graph, an asterisk represents a different number of commits. Especially of note is that Brad Fitzpatrick made a small number of commits in Memcached.
Cool information! I've always thought that I am more productive in the morning - but now I'm interested in crunching the numbers to see what it actually looks like. Obviously you can be productive and not make commits to a project, but it would still be fun to know.
It's difficult to draw any conclusion since we don't know their work pattern. If you commit at 12 it probably means you were working between 9 and 12, or between 11 and 12 or maybe it's just yesterday's work ? Who knows.
Sleep is a very technical thing, it's a 'Brain maintenance time'. It's not about saving energy or anything that could/should be bypassed (otherwise we'd be tired awake at night, useful for defending against predators in the wilderness -- nature accepts a great cost for this shutdown). I find my memory improved significantly once I started being more careful with my sleep, for instance. I wish I had come into contact with this instead of the bragging 'I barely need any sleep!' culture.
Full disclosure: I am definitely not famous, but might be considered a programmer.
I found that when hacking for a several months on a solo prototype project, my hours drifted later and later so that I ended up going to bed around 4 a.m., and rising at 11. It's really hard to correct! In terms of productivity, though, the wee small hours are hard to beat.
I'm also certainly not famous -- but I've found the same for myself. I'm far more productive between midnight and 4 or so than any other time of the day. Very hard to make those hours work with a family though.
From the projects they mention, the only one I can see really benefiting from TLA+ would be memcached. For most things it doesn't make a whole lot of sense to use it, unless you're writing a potentially distributed app. If you just want to model a regular program, then you'd be better off looking at PlusCal, which is more oriented to regular programs that aren't designed to be distributed. It compiles down to TLA+ so you get the same benefits, but with an easier to understand syntax.
Edit: Also if you want to learn about how famous programmers work, then there's no better source than the book Coders at Work by Peter Seibel. http://www.codersatwork.com/
Who would you consider famous among currently active programmers that aren’t on this list?
I knew about half of the list (mainly the authors of software I use). I could probably name a few who are equally famous, but not many who are more famous.
edit: I went back and counted. I recognized 4 of 7 names.
To be fair, every community has its own heroes. Somebody like Bellard is probably completely unknown to most people living in the MS ecosystem, for example.
My gut reaction to this was the same as everyone else - to question the validity of using commits as a measurement of time worked.
But then I read further and realized that this isn't a research study, it is just a clever script to output some data from github. So I'm going to go run it on a couple of my projects, see what it says, and enjoy that someone put it together.
I've run similar git stats scripts (I think it was a Debian package actually) on my own projects, and for me at least, they were pretty reflective of my own working habits, with a time lag of an hour or two in the mornings.
It's interesting to me hearing people in the comments talk about committing after hours of work. I instinctively commit after every maybe 30 loc, especially if I feel it has value. I'll sometimes squash them down if the PR turns out particularly noisy. It would be interesting to compare the average size of commits as well I'd imagine.
In my opinion, the project should be in a working state (everything builds, all tests pass, and the built binary or library would be usable) after every commit. Additionally, every commit should also contain unit tests for the code that's being changed, if possible.
Sometimes it's possible to meet these criteria after writing just 30 lines of code, but more commonly it will take 100-300 lines of code and several hours to get to that state.
I can imagine a better time: that of their home timezone. Perhaps it is +0400 where someone makes a commit, but if their home time zone is -0700, that is a bit different situation.
What does wall clock mean? How do they know the geographic position of the authors at their time of commit? I have my laptop's time set to my SO's because if I want to know my current timezone I can just look down at my watch.
214 comments
[ 5.5 ms ] story [ 79.7 ms ] threadGenerally I take a small light laptop when traveling, and then just connect to the desktop back home for doing real work such as committing code.
I know that at a lot of Big Cos do not let their engineers to have source code on laptops anyway (so easily lost and stolen).
Unix Timestamps are always expressed as UTC/TUC which remain constant regardless of device offsets.
The origianl comment's assertion that users don't typically adjust their offsets is moot since commits are stored in UTC anyways. I was just pointing out that many devices automatically adjust offsets.
A more detailed analysis could also take in account the number of changes. How many files per commit? How many lines, maybe?
The day of week is also a very interesting metric, that is very visible e.g. on github's timeline. I know my busiest days in terms of commits are in the middle of the week, a marked decrease on Friday afternoons, and if there are commits in the weekend, they most likely contain swearing in the message.
Edit: I'm betting Brad Fitzpatrick's pattern in Go (current job?) and memchached (not current job?) would vary in terms of day of week, not just hour.
Another useful graph would be commit volume versus time (where volume is e.g. number of lines modified)
So, my graph isn't exactly going to tell you at what hours I code but at what time I sent pull requests to my coworkers for example.
I used to write lots of code at all hours of the day, 8 hours at work, 6+ hours at home. Then i had kids, and while i still write code 8 hours a day at work, i rarely find the time to write anything in my spare time anymore.
Every now and then i have "some project" that i'm working on, but it's mostly in bursts of 2-3 days, followed by 3-5 days of "doing nothing". The 2-3 days are _not_ weekends, and i usually end up losing sleep over it.
Kids are relentless, and no matter how late you stayed up, they still get up at 6 AM, and needs to be taken to kindergarten/school, and requires you to be (mentally) present in the afternoon/evening.
I guess you could talk about a "soft burnout" happening from the 2-3 days burst.
I'm trying to change the burst periods into more frequent, shorter periods of 1-2 hours, hoping the increased frequency will reduce the "ramp up" time while getting "into the zone".
git stash push -m "my stuff"
> Then, when I return to the branch, I'll check if the previous commit was WIP (`git log -1`), and if so will reset it (`git reset HEAD~1`).
This is a single commit.
It is ridiculous how many nice features git has accumulated through the years, but their discoverability is... not excellent -- partially because of how many options we now have. It's a vicious circle.
But yes, --autosquash looks nice.
According to this study I would be working 5 to 11pm
> I often worked nights and slept during the day, but I almost always got 8 hours of sleep. There are still 112 hours left in the week!
https://twitter.com/ID_AA_Carmack/status/932718658366857216
I found that when hacking for a several months on a solo prototype project, my hours drifted later and later so that I ended up going to bed around 4 a.m., and rising at 11. It's really hard to correct! In terms of productivity, though, the wee small hours are hard to beat.
Does Bellard think the whole project through for days and then simply hacks it down in a few hours?
Does one of them use TLA+?
Do they use iterative approaches, where the first few versions are really buggy?
Edit: Also if you want to learn about how famous programmers work, then there's no better source than the book Coders at Work by Peter Seibel. http://www.codersatwork.com/
I knew about half of the list (mainly the authors of software I use). I could probably name a few who are equally famous, but not many who are more famous.
edit: I went back and counted. I recognized 4 of 7 names.
But then I read further and realized that this isn't a research study, it is just a clever script to output some data from github. So I'm going to go run it on a couple of my projects, see what it says, and enjoy that someone put it together.
If it's more than a day of work I might commit and push unfinished stuff before i stop for the day, but otherwise no.
Edit: although the latter happens very rarely. IMO if a unit is a whole day of work, maybe it needs splitting.
That is probably becouse we use Perforce where you don't do local branches by default.
Sometimes it's possible to meet these criteria after writing just 30 lines of code, but more commonly it will take 100-300 lines of code and several hours to get to that state.
> to filter only the commits by one person get the local time of that commit and aggregate it by hour when the commit was make
So these are all in local time of the computer doing the commit, if I am not mistaken.
> The script uses the time the author saw on his wall clock when doing the commit. I can't imagine better time to use for such graphs
[1] https://gist.github.com/bessarabov/674ea13c77fc8128f24b5e3f5...