[jariel]

Not to take away from the premise offered in the article ...

But is there a selection bias here? Some kinds of work invariably involve more github activity, small fixes and the like. Those things are generally, unambiguously 'productive' and 'leave the code better', which lends us to believe 'top performers'. Surely, this might be true but I think within a specific context.

If find solving new or novel problems involves a lot of work that is hacky, experiemental, quick trial, often the kinds of things that in most cases don't even get checked in.

[lmm]

Why not? Doing experimental things that might not work out, or need radical revisions, is exactly when VCS helps the most.

[jariel]

Because the scratch code is usually pointless, it's the 'key notes' that matter.

200 lines of crazyballs scratch code is not 'the insight' really 'the insight' was that the API works 'really slowly upon first iteration, but very quickly after n iterations' - which implies x, y, z possible courses of action.

I suppose you could jam it in the VCS but I've never personally cared.

Now that I think about it ... it's interesting because that's definitely not what a VCS is for, though it could absolutely be used in that way.

A VCS really is not that great to store arbitrary, secondary related activity and notes wherein 'the code' really isn't the important thing.

What's missing here is really a form of document/information sharing that just hasn't caught on very well. Or perhaps I'm still caught up in the ridiculous Confluence/Atlassian garbage, which is the worst wiki ever made.

[kevin_thibedeau]

By such a metric people who write the final implementation on the first commit are complete slackers.