Live data from Hacker News

At what time of day do famous programmers work?

ivan.bessarabov.com

101–110 of 215 posts

Re: At what time of day do famous programmers work?

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

Re: At what time of day do famous programmers work?

#104
post #83

Earlier quoted context omitted.

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

> 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, exactl…

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.

Re: At what time of day do famous programmers work?

#105

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

Re: At what time of day do famous programmers work?

#107
post #72

Earlier quoted context omitted.

> 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” chan…

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.

Re: At what time of day do famous programmers work?

#108
post #69
post #65

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/…

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

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

Re: At what time of day do famous programmers work?

#109
post #65

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/…

These are commit times, not merge times.

Re: At what time of day do famous programmers work?

#110
post #65

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/…

[deleted]
Post reply on HN