= 27d567bc2d48d9f40e9ccc20ea370b15)
Andy_McKenzie comments on 2015 New Years Resolution Thread - Less Wrong Discussion
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (55)
My new years resolution, as part of a longer-term goal to become better at coding, is to make at least one commit to github every day in 2015. Not all of these will be public, because some of them will be currently private code associated with my lab work. But, I'll post a screenshot at the end of the year.
Has anyone tried a similar thing, have advice for me, or think that this is a terrible idea?
Trying to literally make one commit every day (as opposed to something like seven commits every week) ties one to a schedule that would be unrealistic for many people. I enjoy activities like backpacking, international travel, and spending entire days with my girlfriend; none of those are very compatible with a goal of making one commit in each 24-hour period.
It also seems extremely vulnerable to the "what the hell" effect. Miss one day, and you've technically blown the goal. Worse, the reason for missing a day may be largely out of your control (illness, power outage, blown CPU, whatever); unless you have a solid "when (not if) I fail..." plan, you may find yourself choosing not to push as hard to fix things because "it's not my fault".
+1. You could do it Beeminder style and make it so doing 10 commits in a single day gives you 10 days of runway.
Personally it sems that number of commits is a metric too easy to game. If you generally are honest with yourself, keep it, but I wouldn't use it if I were to set a goal for a group of students. Another metric that is less easy to game on a personal level is time spent with your programming environment open, which is effective if you tend to either not start programming or stop prematurely. Finally the ideal metric is to have a set of features or a certain output you want to achieve and have that as a goal with the caveat that these goals tend to be too hard to achieve in the mean time.
So overall, I'd recommend time spent programming as a weekly goal and a final product as an overarching goal with the explicit option of re-negotiation.
It's a great idea. The most important part (possibly the only important part) of learning to code is to actually write code, code that's useful to you. Small commits are a good habit (too many people have an SVN-era instinct that commits are "expensive"). Heck, if I were doing this (as someone with a full-time job that's mostly coding) I'd make it a branch every day, with at least 8 commits on it. (Perhaps if you want to follow CBHacking's suggestion you could make it a branch every week, with at least 7 commits on it; that way, to be "on target" you commit every day, but you can miss a few days and make it up if you need to).
My standard way to avoid the "what the hell effect" is: miss one and it's ok, miss two and it's all over.
I am not sure if there is much correlation between the programming quality and commit rates.
Based on ~5 years of professional programming experience, I'm very confident there is a strong correlation between programming quality and commit rates. (Though Goodhart's law may be a danger)
I totally agree that quality programming tends to lead to higher commit rates. It's the other direction I am dubious about, like you say.
That's probably true. Can you think of anything that I could do that would correlate with programming quality and that doesn't depend on other people? I.e., I could say get at least two GH repositories with >= 1 stars, but that relies on other people, so doesn't seem process oriented enough for a NYR.