At what time of day do famous programmers work? | Hacker News Reader

At what time of day do famous programmers work?

ivan.bessarabov.com

651 pointslionix206 comments

Personally, I’d be very cautious about assuming that commit time has anything to do with work time.

For at least 15 years I’ve had a policy - and so have the people on my teams - to avoid merging or committing to public branches at night or just before & during weekends so that you don’t accidentally hose other people on the team, who rely on automated builds & testing. We write code at all hours, but wait to commit/push/merge to master until the morning when everyone’s there.

I realize that not everyone has policies like that, but these are high profile programmers who are likely to have their own complicating factors. Linus, for example, commits a lot of merges that other people depend on; his code reviews and code writing might be on separate schedules.

Isn't that what feature or topic branches are for? Commit in your own little world, merge when you are ready to share.

Yes, that is what feature branches are for. The policy I’m talking about is referring to when people share, not when they commit to a feature branch. Sorry, I did initially described it only as “commit”, so that was my fault, not yours.

But a lot of teams prefer that you do rebases and have a flat commit history, rather than have merge commits (so your commits would reflect the time of rebase onto master, not the time you first committed to your topic branch).

I still think this a very cool back-of-the-envelope estimate though.

> (so your commits would reflect the time of rebase onto master, not the time you first committed to your topic branch)

That's not the case with git. By default it preserves the original commit time.

I think they may be talking about squashing several commits before rebasing, creating new commit(s).

Yes, this is what I meant. It wasn't clear, thanks. Generally squashing all the feature commits in a branch into 1 atomic commit in master.

It just calls it author date (it records one commit date and one author date), and one of those is preserved by rebasing. :)

Strange policy about commits — why just not push at night or during weekends? Why's everyone not working on branches?

> Strange policy about commits — why just not push at night or during weekends? Why's everyone not working on branches

That is what I’m saying. The policy is avoid pushes to master. My policy does apply to branches too once there are more than a few people in the branch.

Lots of people do work in branches, but everywhere I’ve worked, plenty of people skip branching when they’re making what they think are “small” changes. And some places I’ve been, the team has decided on a policy to skip branches & merges for single commit changes due to the history noise it causes.

The policy is to avoid breaking changes being committed to master when people aren’t around to notice & fix it.

You’re describing merges, not commits, or pushes to remotes.

One can commit and push to branches all day.

Merging them to master without a heads up is a bad idea, except where teams have implemented a process that can handle it

Many of us do a “squash merge” (use git rebase to compress to meaningful points in a CR and again before merging to master or feature branches). This creates a clean history at the expense of not being able to stalk others work at high granularity or get as large a score on github’s tracker.

Git rebase interactive with fixup or squash will combine the commits into the first one. So the timestamp will still be somewhat reflective of when work is done (on average).

Are you sure?

It seems fairly likely to me that the average time of day that someone makes the initial commit on a new branch would be quite different from the average time of day that they make commits generally. Am I misunderstanding?

Though I wouldn’t be surprised if there is at least some biasing. E.g. first commits happening relatively soon after regularly scheduled scrum meetings. At least if they’re the type of developer who checkpoints after incremental changes.

I'm not convinced that a 'clean history' beats a richer more fine-grain history.

There's a reason frequent small commits are generally thought to be the way to go.

except of my dozens or so commits to a feature branch, most of which are "update" or "fix test" or "oops forgot edge case". But for the one squash commit, it's "some-feature-tag: nice description of the changes (#relevant-pr)".

and there's no way I'm going to write more than one nice commit message for a branch.

You can still get the fine-grained commits if you keep your merges focused on one thing.

> You can still get the fine-grained commits if you keep your merges focused on one thing.

Right. This is what Git Flow does. Best of both worlds.

Stalking other workers at high granularity is sometimes the only way I have to figure out what was going through their head (or indeed, my head 2 years ago) when they wrote this... very interesting logic.

The biggest WTF programmer I work with squashes all of his commits. So every commit is 100-400 lines of Rube Goldbergian majesty.

> You’re describing merges, not commits, or pushes to remotes.

Both merges and commits can be pushed. I’m not exactly sure what distinction you’re trying to make.

Also, btw, I’m using git terminology, but not everyone uses git. I’m including my experience on teams that use Perforce, for example.

> One can commit and push to branches all day. Merging them to master without a heads up is a bad idea.

Yeah, right, exactly. You agree with me. My policy is about putting anything new in the master branch during off hours, because breaking changes that evade the tests may not get fixed until work hours, and prevent other people from working at night or over the weekend.

The article is about the times of day Git commits were made, not the times of day they were pushed, nor the times of day people used other source-control systems like Perforce. You said, "I’d be very cautious about assuming that commit time has anything to do with work time," citing your own policy of not pushing at night as an example of how "commit time" may not have anything to do with work time. Now you're saying, "My policy is about putting anything new in the master branch during off hours," which is to say, it's about pushes, not commits.

This means that your original top-level comment is completely irrelevant to the article you are commenting on, which is unfortunate, since it's the top-voted comment on the article. You should edit the top-level comment to reflect that fact, or, if that's not possible, add a second-level comment retracting it.

I stand by my top comment, avoiding pushes Friday and waiting until Monday often leads to both code commit times on Monday and merge commit times on Monday. (Edit: and BTW I know this for a fact, because we monitored average commit times to make sure the policy was being adhered to.)

If you look at the code from the article, you’ll see that the author did not filter out merge commits. The word merge doesn’t even appear in the article. The OPs data includes merge commits.

You’re trying to draw a hard and idealized line that doesn’t exist in real companies. Squashes often happen right before push. Stashing for the weekend rather than committing is common. People unsafely leaving uncommitted changes in their workspace over the weekend is common. Most devs in my experience are not git experts, and they don’t always use git in best practices kinds of ways. That is made evident every time there’s a git thread on HN.

I am talking about commit time, my push policy affects my commit times. You can’t count on commit times to demonstrate anything.

> You can’t count on commit times to demonstrate anything.

Very extreme stance! Especially for so deep in thread. Sometimes it’s nice to make your ideas more specific as you go deeper in conversation, not just radicalize and double down.

Interesting; I don’t consider what I said extreme or radical at all. I’ll rephrase it into a question: what do you claim that commit time demonstrates, considering that commit times can and do in practice very often change immediately prior to push?

How can a commit time change?

It's a different commit. I was talking about introducing and then pushing new commits with different timestamps than the original, not somehow modifying timestamps on a specific commit. The commit that gets pushed can, and often does, have a different timestamp than the timestamp on the commit when the code was written.

git commit --amend changes author time.

git commit --amend --reset-author changes both author time and commit time.

git rebase changes commit time.

All three commands can be used just before a merge and push to clean things up. So there is no guarantee that the author time or commit time we see in the final commit history accurately represents the actual time at which the work was done.

Commit time has some correlation with when code is written. It’s not perfect, but for me personally it’s usually close.

Whether that correlation models reality closely enough to be useful depends.

My understanding of your “commit time demonstrates nothing” assertion is that you are saying there is no useful information there, which seemed like a radical position for so deep in the thread.

You're attempting to defend the relevance of your comments to an article about the development practices of, among other people, Linus Torvalds, by saying, "Most devs in my experience are not git experts, and they don’t always use git in best practices kinds of ways." Perhaps you are not aware that Linus Torvalds originally wrote Git, and did so specifically to mechanize what he considers to be "best practices".

Edited to add: apparently something in my phrasing is leading you to believe that I'm angry with you and wanting to attack you. I'm not sure what that is, but that isn't my intention. I just think what you're saying isn't true, or rather is presumably true of your company but not of this article, and I was trying to explain why. I'm sorry for writing in what is apparently an aggressive tone.

Thank you, yes I’m well aware that Linus wrote git. I’m not sure what made you so angry, but I’m up for continuing this discussion if you’re really open to discussion, as opposed to proving me wrong no matter what. It currently feels like the latter, but I think you’re not listening or understanding what I’ve said. It seems like you’re making assumptions.

Maybe you missed that I pointed out above that Linus makes a lot of merge commits, and you’ve just ignored my previous point about merge commits which is completely and directly relevant to my comments. The article included Linus’ merge commits in their histogram of his commit times. If Linus is waiting to merge like I do, then the data is skewed. If Linus is code reviewing and emailing in the morning, and writing code at night, then the data is misleading.

The merge commits made by Linus will have as their date and time the time when he made the merge locally on his own machine, which can be different from the time that he pushed those changes out (and given that he specifically designed git to have this capability it seems rather plausible that he uses it).

Merge commits are really the same as non-merge commits. The only difference is the number of parent commits, which is irrelevant for this discussion.

For what is worth kragan is entirely right here.

As strawman arguments often are within their own context. That doesn't mean I'm wrong. My point that merge commits were included in the OP's article and data went unanswered by @kragen, and it's directly relevant to what I said at the top; merge commits don't represent work time, but they're being counted here. Code commits also don't necessarily represent work time either, due to squashing, stashing, and general dev practice, so I haven't heard any evidence that convinces me otherwise. Do you have any to add?

Your attack on my integrity here is unwelcome and entirely unwarranted; that does make me angry. I regret having given you so much of my time in this thread and having assumed good faith on your part.

> Your attack on my integrity here is unwelcome

I absolutely did no such thing. You may wish to consider taking that untrue statement back, for the sake of your integrity. Nothing I said is attacking you personally in any way.

You called for a retraction of my top comment, implying it is flip-flopping and hypocritical, but you misunderstood my argument and made a rebuttal point that didn't address mine. That's a straw man, and since you appear to believe "straw man" is judgemental, it is not. It simply means you're arguing against a different point than the one I made.

It's a fact that you haven't yet responded to the merge commit point I made, and that merge commits in the OPs data are relevant to my original comment.

> I regret having given you so much time

You make it sound like I'm supposed to appreciate you calling my words untrue and "completely irrelevant". How does arguing with me and saying I'm attempting to defend an irrelevant position amount to you extending good faith?

Merging is work too. The times of merges are indicators that the person did work at that time.

Obviously the methodology is limited but it does seem to work well in practice. If you have evidence that the statistics are wrong for one of the listed programmers, please do share it.

I find kragan's comments to be creating strawman arguments. They are unnecessarily confrontational.

That to me seems more like a sign that you should be enforcing a policy that pushing the merge button is gated by tests passing (& in successful application pushing the "merge button" should be nothing but a request to automation to apply the merge & do the tests before actually pushing it as a new master). If you're saying that there are breaking changes that are possible that test coverage is insufficient for, I would propose that the test coverage needs to be addressed. Is this advice for small 1 person repos? It can be if you want to develop good habits or be more diligent at preventing defects. It becomes more applicable as more people start contributing.

Teams I’ve worked on do gate the merges by passing tests. You’re right; test coverage is insufficient. I’ve never worked anywhere with sufficient test coverage, I truly hope to some day, but new features in my experience have always come with new breakage and new tests.

> Is this advice for small 1 person repos?

I’ve never used a wait to push policy on my own repos, I’d say my policy doesn’t make any sense in that scenario. The goal of the policy is to prevent breaking other people, not to prevent breaking myself.

Your original comment reads like pushes only goes to master, so you wait to push to a non master branch until working hours.

I found the phrasing abstruse relative to my daily way of thinking of these things

We have emergency production rollback to the last working deploy. That's what you do when breaking changes are committed to master. Letting devs commit to master directly? Horrible idea.

That’s a great strategy that works in some scenarios. Preventing weekend breaks would depend on a daily deploy schedule? I do normally revert first and ask questions later when breaking changes appear, that’s similar to what you’re saying, I think...

> Letting devs commit to master directly? Horrible idea.

I’ve never been on a team that disallows commits to master. I can see the thinking, and maybe I should be doing that, but for whatever reason, the places I’ve been are less formal than that and they might be concerned about slowing down turnaround times during the day when people need to share things more quickly.

FWIW, I am including git and also VCSs other than git. It’s harder to wall off the master branch in Perforce as a policy decision. And maybe I just haven’t been on a large enough team to warrant having someone with full time merge duties...

> the places I’ve been are less formal than that and they might be concerned about slowing down turnaround times during the day

I'd be more concerned about code being committed to master without code review.

I think the reason for confusion is that you seem to say that people doesn't even commit their work when they work, but only when they're pushing as well. dchest is (seemingly) asking why don't you commit when you're done, but delay the pushing (according to your policies)?

The confusion was my fault, but I think is mostly gone now. I initially described it as commits when I was thinking of pushes, partly because I’m lumping both git and Perforce experience together. I edited my comments to be more clear, and it seems to have helped.

The question asked is valid, and we do commit often, we only avoid pushes to shared spaces at night, so some commits may have representative time stamps. As others have mentioned, squashing might compromise that, and commits made Friday but pushed Monday are, in my experience, more likely to be modified Monday right before pushing. For me, it’s pretty rare that the first commit time survives until push, I’m almost always squashing code, multiple times, before it’s ever pushed.

Absolutely! In addition, if you've spent a full day on a single commit, it'll show in these stats as a single data point at the end of the day - the fact that you were working for the 8 hours leading up to the commit as well is lost.

This isn't entirely correct. Git commits have two timestamps: the author timestamp and the commit timestamp. Git only shows the author timestamp by default, and that timestamp definitely survives `git commit --amend` and other operations like rebase with squash. I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream.

Unfortunately, TFA doesn't discuss which timestamp is being looked at, though that leads me to suspect that it's looking at the author timestamp because that's the default.

> that timestamp definitely survives `git commit --amend` and other operations like rebase with squash.

You're only talking about the first commit in a squash, and assuming that there aren't multiple squashes, right? There isn't only one timestamp in a squash, so you lose all but one of them.

> I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream.

Right, exactly, this illustrates why looking at timestamps isn't a good proxy for work time.

> TFA doesn't discuss which timestamp is being looked at

Here's the relevant portion of the script from the article:

    git log --author="Linus Torvalds" --date=iso

a merge to master should only be done after a review, eg. PR is accepted by X reviewers which most likely happens only during working hours. Not sure I understand your policy, people randomly committing/pushing to master without review is not a good idea at any time.

For history noise, just rebase before merging and you won't get a merge commit. It's really easy and preserves the use of branches.

Our process is:

- create a branch for every change - make commits relatively small, but complete; each commit shouldn't break the build our the tests - request peer review when the code is ready to merge - when reviewed, rebase onto team's development branch and merge

It always surprises me that workplaces with automatic deployment don’t have deploy windows. Automatic deployment only occurs 10-3 in your region and you can deploy by overriding outside that time to get out emergency fixes.

Most CI systems support running builds automatically on an interval, and I think some support time ranges as well.

In a way a lot of this CI/CD stuff was easier when you ran it on your CI system.

The policy is to risk breaking stuff only when people are in the office. It's a good concept.

I think that 'to avoid merging or committing to public branches' means 'to avoid pushing' here, specifically the 'to public branches' part.

Because, obviously, it's pushing commits that's problematic, not committing per se (in git vocabulary).

These are commit times, not merge times.

The article includes merge commit times; I read the script.

Includes them yes, but doesn't only use them.

Even merge commits aren't pushes.

Looks like you already addressed that merge time != commit time. That being said, while it's hard to make a blanket statement about what part of the working process a commit falls, I'd venture a guess that it's usually at the end of a period of work. Given that, the commit time covers an indeterminate period of time before the commit's time. So having no commits at 6 AM doesn't mean the person isn't working at 6 AM, but it probably means they aren't working at 5 AM or 4 AM.

But that all being said, we only have a handful of people worth of data points and who's to say that Linus isn't someone who writes his code the previous day and commits it the next. Or that Guido isn't someone who makes lots of small commits as he's working. Hell, maybe they all squash multiple days worth of commits leaving it with a timestamp for a totally different time.

tl;dr: Yeah, I don't know that we can glean that much super reliably from this data set.

YEP.

We instituted a policy of NO CHANGE FRIDAYS! To avoid fucking up peoples weekends.

Commit time and push time are not the same time.

I would avoid deploys before weekends, holidays, and vacations but you have problems with your pre-merge/pre-commit testing setup if it possibly screws people up when you land something.

Interestingly, many pathologists have a policy of not signing out cases (do I commit this patient to a cancer-not-cancer diagnosis?) in the evenings. The move is generally more self-protective (tired minds make bad decisions), but certainly the 24-hour folks like hospitalists aren't looking for me to add more work to their nights and weekends either.

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.

From John Carmack:

> 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

Happy to see this being pointed out. Sleep is the single most important factor in code quality & correctness https://twitter.com/hillelogram/status/1119709859979714560

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.

This has a name: https://en.wikipedia.org/wiki/Night_owl_(person)

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.

git stash save my stuff (deprecated)

git stash push -m "my stuff"

What GP wanted was to stash a history of commits, not just the current state of the working tree. `git stash` is fundamentally unable to do that.

That's just called a branch. What GP described was committing all their changes into a single WIP commit.

They were describing many different WIP commits, and then later squashing them to a "proper" commit.

That's a branch.

> 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.

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 use stgit for this kind of thing.

Yes I think your workflow is more correct than using stash. Work that is fully intended to enter the branch should be in commits, not stashes.

You can also use `git commit --amend` to clean up a WIP 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 do this all. the. time. i'll squash multiple in-progress commits into one before submitting a PR.

Do you use `rebase` for that?

Probably git reset.

nah most likely `rebase -i`

yeah, `rebase -i` for the squash.

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.

Great tip, thanks.

You da real mvp.

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.

`git commit --fixup` very nice, I never particularly liked the workflow of "git rebase -i <hash>"

Eh, `git rebase -i master` (or some other branch) isn't so bad, or you can always rebase against origin/<your-branch>.

But yes, --autosquash looks nice.

You might like Magit's WIP feature: https://magit.vc/manual/magit/Wip-Modes.html

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?

Ever used a quicksave feature in a video game right before doing something destructive/risky/experimental?

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.

git stash follows you around, while a temp commit is bound to a branch

I mainly use the staging area for this. Not yet create a commit, but get the diffs out of the way.

To those asking about whether time zones are considered, the author responded in [1]:

> 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...

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.

I think the calculated wall time incorrectly.

>> The timestamp is the number of seconds since 1st January 1970. If we convert 1563188141 to more human date we'll get "2019-07-15 10:55:41" — that is the time in UTC timezone. Then we add "03" hours and "00" minutes to that time and get "2019-07-15 13:55:41" — that is the time the commit author can see on his wall clock when he did commit.

Usually the +0300 indicates that the times tamp is at +3 hours from UTC. Eg. the timestamp is already in local wall time. The offset can be used to convert it to UTC.

So if the author did what they wrote. Then I reckon all the data is actually in UTC and not local wall time.

Unix time is always the number of seconds since 00:00:00 Thursday, 1 January 1970 UTC time. Git records the committer's time zone, since the time would normally be converted back into a human readable form.

This is a good example of the ages old falsehoods about time. You're mostly right, but you're missing leap seconds.

The one for Chris Lattner is definitely off: https://twitter.com/clattner_llvm/status/1150992062365310977

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?

Another issue is that when you travel to a different timezone, you don't necessarily update the timezone of your system.

Aren't most devices configured to adjust automatically these days?

I personally don't travel with my desktop :)

Generally 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).

At least Google has made an exception for me when I’m working on code hosted on Github. Most of that is (or will be) public so there’s low risk.

Neither my Linux nor Windows 10 laptops do.

Both can be configured to do this, but I'm not sure it's enabled by default.

In the blog post it specifies that it uses the Unix timestamp, which doesn't account for timezones.

It's Unix timestamp followed by timezone.

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.

It wouldn't even out - you never commit before writing code, so any measurement based on commit times will be consistently biased to later times.

And perhaps they commit first thing in the morning, after a nightly test succeeded (or perhaps they simply forget to commit at night).

Another useful graph would be commit volume versus time (where volume is e.g. number of lines modified)

I think is different for every person. I usually commit often but I'd squash multiple commits into one.

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.

Every time of the day, it's like asking at what time does a musician compose, or an artist paint or a author write. Surely, we can consider the physical activity work, but the mental activity is also work and precedes the physical.

The brain churns on the problem at hand most of the time even when we are away from the computer. I would even be bold to say, more so when we are away from the computer and not distracted by typing.

Absolutely this. Working on something else entirely is often the best way to resolve difficult logic problems that I get stuck on.

Just throw it on the "subconscious pile" and let my brain chew away on it in the background.

> Every time of the day, it's like asking at what time does a musician compose, or an artist paint or a author write.

That's a pretty useless way of seeing things. You might as well define eating or going on the toilet as 'writing' since hey, they might be thinking about it while they're doing it. If you look at actual writers talking about when they write (https://www.gwern.net/Morning-writing) many of them are quite explicit about taking breaks to do other work like correspondence or family/friends in order to not think about writing.

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.

I usually work 9-5 and commit before going home. I might pick it up again at home and commit my changes before I go to sleep, around 11.

According to this study I would be working 5 to 11pm

As someone who generally works a 9-5 job at a company where most people are expected to work 9-5, can anyone explain if there are any norms or rules that enable someone to work such abnormal hours at their companies?

Do companies like Google not care as much about work hours? I can't imagine anyone showing up at 2pm at any of the places I've worked, regardless of how productive they were.

Game developer here, most of the companies I worked at had an expectation that you show up around 12 and leave around 8-9. Guess it's a culture thing.

Now that I'm a remote contractor, I can finally live according to my natural schedule and wake up around 5pm.

I think this really depends on the attitude of the company and specific managers. Each quarter I'm given a list of projects and just need to have them done by the end of the quarter.

Thankfully my boss has seen that I'm much more productive with my abnormal schedule so I'm inclined that this type of freedom probably comes on a case by case basis.

I know a former Technical fellow at Microsoft. He told me people gave him crap & joked it must be nice to be a TL and have the power to leave at 3P. On the other hand it had been years since he hadn’t watched the sun rise drinking coffee at the office. He told me he tries to make sure he doesn’t get out of bed till he hears his coffee machine go off at some time like 4A.

Also, at google I’ve known people to work part of the day from home or have moderately shifted schedules to avoid traffic. Though there are often team-wide “core hours” where you are expected to be available for a meeting.

After you've proven yourself, some places will let you get away with a lot.

As others have already mentioned, it depends on the manager and the company, but I noticed that most tech companies are super lax about it and don't care when and how much you work, as long as you get expected work done, are responsive during a good chunk of the day (i.e., still have a lot of schedule overlap with your teammates, so that they can reach you out for help), and are able to participate in team-related things like code reviews/meetings/etc.

For example, some of my teammates do 8 to 4, some noon to 8, and others do 9 to 1 then go to gym/do chores/whatever, and then 4 to 8. As long as you deliver and communicate well within your schedule, no one cares.

I personally like it, because some days I might not feel good at all in the morning, so I get in late, but then I get a weird burst of energy around 7pm when I get home, so I sit down and end up writing some code.

Keep in mind, this is a double-edged sword, because you might end up working late at night to get some burning feature done or fix a nasty bug blocking the rest of the team.

Tldr; Small companies. And "earning" it.

After 6-12mo getting shit done, probably including a 12-20 hour working until "oh shit loading money" issue. And discussion with my boss. I have freedom to time shift my work. I'm consistently present for meetings. But if I'm blocked by external factors ill take Monday off so I can work on Sat (unblocked on weds) to meet following Monday deadline. Often work late at night where I can get solid block of 3-4 hour uninterupterd. I mostly work 10 to 7 to avoid traffic. I vaguely track hours and I average 36-40 or less. But they are so much more productive. Many people spend 8+ hours at work but get little done. My 6 hours are solid work. It also helps me manage burn out.

Im slightly manic depressive and partner/childless. Works great for me. YMMV.

I've never worked (as a software engineer) at a company that expects their employees to show up at 9am. Now, at the place I where I work currently, most people _do_ tend to show up between 8-9am and leave by 5-5:30, so working at 6pm I often find myself among a single-digit number of people still at the office, but I think such schedules are usually driven by people's life obligations (having kids, mostly) and personal preferences (naturally early risers) rather than company requirements. I myself routinely wake up around 9am, and come in the office between 10:30-11:15am. I've been here for 5+ years, gotten a substantial raise each year since I've started, and recently gotten promoted. In talking with my manager, my working hours have never ever been brought up as a negative (in fact, my current boss tends to get in around 10:30am himself, mostly to avoid rush hour traffic).

I graphed this for myself a while ago in my work as a technical founder of CircuitLab (YC W13): https://imgur.com/37mbya5

Two striking findings emerged (and FYI I'm a "frequently commit small logical changes" person):

1. My work patterns seemed surprisingly self-consistent, with a notable gap 2am-10am for sleep and around 1pm for lunch and exercise. (Plus a markedly lower average in the evenings after 7pm for seeing friends, just relaxing, etc.)

2. The intersection between my curve and the window of 9:00am-6:00pm is only 53%. If a "conventional" employer were to constrain my productivity to that window, that's at least some first-order measure of how much inefficiency that constraint would likely produce for me personally -- 47% reduction.

Fabrice Bellard apparently merges commits to Qemu between 21 and 22, and to FFmpeg between 22 and 23.

I always code between 8 and 16 o'clock, sometimes until 17, but then stop.

Programmers and engineers have family and hobbies too.

Stop making the myth of the endurance programmer more and more inflated. It's proven and true that shorter working Hours have major bursts of productivity against longer ones.

> and timezone information (+0300)

> 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.

I wonder how much this is related to age.

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.

Quite a bit i'd imagine.

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.

Check for yourself in case you’re interested: https://gist.github.com/bessarabov/674ea13c77fc8128f24b5e3f5...

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.

The work patterns would be more interesting.

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?

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/

Does this take into account timezones?

4th paragraph.

Maybe maintainers commit "early", merging other people's work that piles up at night, while contributors commit "late", at the end of the workday?

I code a lot at evening/nights but I almost always let it rest until the next day after waking up and do a review and then commit.

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.

I don't know, I commit logical units. Changes that do something. If they're a one liner, that's it. If it's 500 lines, that's it.

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.

I would like to do that at work but the code review and Jira ticket adds to much overhead so we mash stuff together to umbrella commits.

That is probably becouse we use Perforce where you don't do local branches by default.

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.

Agreed here. I think it leaves the commit history to messy if the commits aren't actually fully functional changes.

How does got get "local" time zone. I sometimes commit on systems set to utc. And I'm unsure how many people accurately set time zone in online tools like github. And many devs esp famous ones travel a lot. Not to mention moving.

All this to say, there's too many unknowns for me to trust this "study"

I've made a breakdown on a daily basis as well (statistics on #commits/hour/day) :

https://gist.github.com/davidalbertonogueira/dfc1b114285523c...

No one should care. Seriously. There is no super secret work time that will make you a super-programmer.

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.

> Linus is the author of the Linux operating system

Hmmmm... Not quite. Albeit I am a massive fan of the Linux kernel, though Torvalds is _not_ the author of the Linux operating system (if we assume that Linux is the equivalent of GNU utilities + the Linux kernel).

Why would we assume this? A kernel is absolutely an operating system.

I write a lot of code at night, then commit during the day after a double-check.

Are the times localized to the timezone they're in?

I've been meaning to do something very similar to this for a while to see what hours people at large tech companies are committing at

But do you trust that commit time is going to actually be accurate? There si no telling how many off commit hours go into a pre-merge

I don't get why so many people here are up in arms about commits not actually representing real work or when it was done. The author never stated what he thinks a commit represents and yet so many of you try to find some kind of flaw with his method and ascribe your own meaning to words he never said. Just enjoy this for what it is - a simple histogram for commits in a project.

Travel would totally mess this up. I don't bother to update `timedatectl` when I am on the move.

Should be interesting to also check if people work during weekends or not, not just the time of day.

Who cares? Why does it matter?

Exactly, no-one cares. This industry is creating a culture of celebrity programmers and worshipping and glorifying the code they write.

It does not even remotely matter. What matters is who is going to maintain all of this after the years to come. (Or they could be even obseleted or superseeded anyway.)

For-profit clickbait items reinforce unhealthy and unrealistic digital hallucinations to stay in business, and celebrity developer bloggers do much the same in order to advance their careers. You don't know how they are to work-with or if they have even earned their chops. Worse, the celebrity effect tends to ruin most people as they become insufferably entitled and/or uncooperative. These sort of people are often vastly overrated and can absolutely annihilate the morale of teams.

But why you interested in famous ones instead of the productive ones? :)

Are the commits represented in UTC time when using the script?

It's in local time as an offset of UTC. So, if you pool by repo then you could have two commits at 13:00 even though they were commited at different times of the day, but in different time zones.

Do all these individuals work from a US time zone, or does fit report the user’s local time zone from which the commit was made?

It is local time zone. The commit log has time zone info.

It's unfortunate that the author chose to only include male programmers in the post.

Why is it unfortunate? Or am I missing some sort of implication here? And what about black programmers? Does it matter? If so, why?

Hypothetically the author thought of “epic programmers” and only came up with white males. Women and PoC have given great contributions in our industry and are underrepresented. This could have been an opportunity for the author to learn about some and give them a bit of credit.

Can you give us some examples of programmers of "epic" repute that are women or people of color? (Or both?) I'd like to be able to bring them up when I find myself reading something that doesn't include them.

As a google employee the first person who comes to mind is Sanjay Ghemawat. Jeff Dean is upheld to mythical levels within Google but he pair programs with Sanjay who is almost unknown.

Jess Frazelle is pretty famous for her work on dockerization as well.

https://en.m.wikipedia.org/wiki/Sanjay_Ghemawat

Margaret Hamilton https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_en...

Someone who is active during git time: Audrey Tang https://en.wikipedia.org/wiki/Audrey_Tang

https://en.wikipedia.org/wiki/Yukihiro_Matsumoto

https://en.wikipedia.org/wiki/Junio_Hamano

https://nehanarkhede.com/

https://en.wikipedia.org/wiki/Viral_B._Shah

All day and all night!

whenever works for you...

tl;dr Rob Pike eats lunch at noon

Let's cargo cult the advice on this ftw. Also let's piss off our managers by saying, "Yeah, I heard this on Hacker News." Here for the downvotes to get back to 666.

Lmao. OP items like these reek of people looking for shallow poser shortcuts rather than digging in.

Author is probably a non-native English speaker, so, gentle correction: "At what time of day do non famous programmers work?"

The original article was written in Russian, so I'm assuming this is an automatic translation.

TIL who the hell these 'famous' folks are!

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.

Reply on news.ycombinator.com