I thought this was going to be about someone meticulously doing git commits after every tiny little change.
^ this
I'm a serial over committer
41–49 of 49 posts
Re: I'm a serial over committer
#42Starting things is easy. Finishing is hard. Most people start various side projects. Very, very few have the resolve to finish them.
It's not just about resolve. Plenty of side projects turn out to be not worth finishing.
True. It's important to know when to stop something. Sometimes the project just isn't worth your time anymore
Re: I'm a serial over committer
#43"I want to be that go-to person, that expert, that guy who Gets Shit Done."
I have a few bad experiences with "the guy who gets things done".
There's an old saying that the last 10% of the work takes 90% of the time.
If you stop after the first 90% (or why not at 80%?) and jump to the next exciting project, you will be percieved as very productive. And because you don't put in the time to properly document things, you'll be the only one who knows it all and you'll be percieved to be a guru who knows everything.
Sure, it might not work perfectly, but it's only minor flaws that someone else can fix. Right? You're too busy being productive in your new project, leaving a mess for people to maintain in there.
And it works. Your managers see you as the go-to guy. You will get things done. And the fact that people then spend ages of time to patch your work just proves how much more efficient and better than them you are.
Yeah, you probably guessed it: I spent the day yesterday cleaning up someone elses unmaintainable, undocumented mess. Someone who is now working on a new project.
Re: I'm a serial over committer
#44"I want to be that go-to person, that expert, that guy who Gets Shit Done." I have a few bad experiences with "the guy who gets things done". There's an old saying that the last 10% of the work takes 90% of the time. If you stop after the first 90% (or why not at 80%?) and jump to the next exciting project, you will be percieved as very productive. And because you don't put in the time to properly document things, yo…
Thanks for the well written summary of this problem! I'm in a similar position as you are. We have a "hero who gets things done" - he is really good at writing quick prototypes that somehow work, but his code is unmaintainable and not even correct at the corner cases. I am not quite sure what we - the rest of the team - should do about. We managed to get him back into a project he started from his new project to help us clean it up, and we hope that this is a step in the right direction...
Re: I'm a serial over committer
#45In his book "Predictably irrational", Dan Arielly, talks about this exact behavior and explains it from a behavioral economics vantage point. In essence he is saying that the missed opportunity cost of not taking on "all projects" is far less than the risk you are taking by working on so many different things at once. In one of the chapters he tells the tale of a chinese general who burned his army's ships thus leaving them no choice but to win all battles ahead since they now had no other option.
On another note, you are not alone. It is an anxiety that, IMO, emanates from you not being able to read the pattern correctly. And that only comes with experience and exposure. Once you get to a point where you can "see" the general direction of things you will be able to accurately filter the probably-doomed-to-fail from the probably-a-bang-in-the-making projects.
Lastly, think of this; Who do you prefer to be?: - being the guy that doesnt know how to say no and never finishes anything fully (like a drift wood that never reaches a shore)
- being the guy that is selective but dedicated to the projects he chooses to work on. (like a power boat)
Anxiety is not something you can beat in 2 days but being aware of it is a major step. Work on it!
Re: I'm a serial over committer
#46I thought this was going to be about someone meticulously doing git commits after every tiny little change.
I'd like to read a post about the optimal granularity of git commits in different situations. I don't think I'm experienced enough particularly when it comes to intense collaboration to write it myself
It depends somewhat on your perspective. Some people like to lie, and others do not[1].
Personally, I don't mind lying a bit in my personal projects.
To lie, you simply make a new branch for each feature or otherwise related changeset such as a hotfix. Within that branch, you make as many commits as you want, the more the merrier.
When the branch is ready to merge, you use "git merge --squash branchname" which will pull in the changes from branchname in an uncommited form. Then, you can use "git diff" to view the differences and make one single commit with an appropriate commit message detailing each change.
The upside is that it is atomic without needing to use the git-workflow no fast-forward business. The downside is you're lying.
[1] http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebas...
Re: I'm a serial over committer
#47I've been on HN too long. I read the title and assumed the article was about someone's revision control habits.
Re: I'm a serial over committer
#48I thought this was going to be about someone meticulously doing git commits after every tiny little change.
I'd like to read a post about the optimal granularity of git commits in different situations. I don't think I'm experienced enough particularly when it comes to intense collaboration to write it myself
My granularity is: Different things go on different commits. For example, you can include 30 files and hundreds of lines in one changeset if they are all related to the new feature X, but do not in the same changeset correct the indentation of a code block.
The commit message is like a title. All diff lines must be related to it or they should be in another changeset.
Re: I'm a serial over committer
#49I thought this was going to be about someone meticulously doing git commits after every tiny little change.
When I first started using revision control on a work project, I used to commit after every few lines to "save" my work. Without commit messages. Boy, did I pay for that one.
I first used Git before I really understood source code control and more or less did the same thing. Kept it up until a friend of mine that I was working on the project with figured out that there had been upwards of 200 commits in one day with no commit messages. Oops.