Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

At what time of day do famous programmers work?

ivan.bessarabov.com

Post reply on HN
Print view View original

121–130 of 215 posts

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

#121

Post by gwern »

segmondy wrote: post #76

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…

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

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

#122

Post by yesbabyyes »

srfilipek wrote: post #117
breck wrote: post #79

Earlier quoted context omitted.

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

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

#123

Post by breck »

yesbabyyes wrote: post #122
srfilipek wrote: post #117

Earlier quoted context omitted.

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

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

#124

Post by martinhath »

dahart wrote: post #107
martinhath wrote: post #98

Earlier quoted context omitted.

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

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.

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

#125

Post by dahart »

erikpukinskis wrote: post #118
dahart wrote: post #112

Earlier quoted context omitted.

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

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

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

#126

Post by dahart »

kragen wrote: post #120
dahart wrote: post #112

Earlier quoted context omitted.

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

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". Edit…

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.

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

#127

Post by kzrdude »

srfilipek wrote: post #117
breck wrote: post #79

Earlier quoted context omitted.

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.

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

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

#128

Post by samstave »

dahart wrote: 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/…

YEP.

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

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

#129

Post by id10t-detector »

dahart wrote: post #112
kragen wrote: post #104

Earlier quoted context omitted.

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…

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

Beep. Beep. Beep beepbeepbeepbeepbeep

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

#130

Post by dahart »

vlovich123 wrote: post #119
dahart wrote: post #83

Earlier quoted context omitted.

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

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

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.

Post reply on HN