I'm a serial over committer(swanson.github.com)
swanson.github.com
I'm a serial over committer
http://swanson.github.com/blog/2011/11/02/engineering-over-under.html
48 comments
I 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.
The commit message is like a title. All diff lines must be related to it or they should be in another changeset.
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...
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...
I thought it was either that, or someone who carefully used fast-forward merges and rebasing to give the illusion of a completely serial history for a project that actually involved a fair amount of branching.
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.
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.
Well, I first guessed topic right from the title, but then I noticed domain name and second-guessed myself, thinking that this is witty title for what you described. Then again that may be like the second-level of wittiness by the author to host this blog entry on the github. Reminds me this classic scene from the "Princess Bride".
me too, I worked with a guy who did that, it was annoying when looking over his revisions, during a period of 1-2 days of work (on a project with just 2 people committing on it), the rev number would increase by 50 sometimes
^ this
I have the same problem: 'yes' is so much easier to say than 'no,' but the quantity of my projects is affecting the quality, and I don't like it.
Derek Sivers has a suggested approach for over-committers: "Hell yeah, or no." It's helped me cut down on my projects (and leaves me with more awesome things to work on, on average). Give it a read: http://sivers.org/hellyeah
Derek Sivers has a suggested approach for over-committers: "Hell yeah, or no." It's helped me cut down on my projects (and leaves me with more awesome things to work on, on average). Give it a read: http://sivers.org/hellyeah
Wow, thanks for that link - that's a really good post.
There's a related video too:
http://www.youtube.com/watch?v=ICKlhVMzE_c
Nothing undesirable happens immediately as a result - except that maybe your manager is a little bummed out. But maybe the next time one of these projects comes up, they’ll ask Bob first. Maybe that speculative project turns into a full fledged project and you missed your chance to work on it.
And when the over-committer Bob ducks out of the project due to time constraints, the manager will come back to you, knowing you have a good track record of completing tasks.
And when the over-committer Bob ducks out of the project due to time constraints, the manager will come back to you, knowing you have a good track record of completing tasks.
"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.
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.
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...
You'll find that there's never a shortage of cool work to do. What if you didn't wait for your boss to come to you, committed to (mostly only) your own stuff, knocked it out of the ballpark, and then only committed to boss-driven stuff that was at least as cool as what you'd otherwise be doing by yourself?
That's actually a really good way to 1) be known for hustle 2) be known as a finisher 3) work on mostly cool stuff.
There is no shortage of awesome possible work. Ever.
That's actually a really good way to 1) be known for hustle 2) be known as a finisher 3) work on mostly cool stuff.
There is no shortage of awesome possible work. Ever.
IMO the most valuable is knowing when to walk away from a side project. Start a side project or hack on an idea you enjoy but when you start becoming stressed by it or realize it's not panning out as you expected, take a breath and kill the project. Harder to do with work projects but still possible. Scope the MVP to somthing that can be "done" and then allow management to iterate and see if this is the direction they want to go in.
I can't agree more.
I used to work for a company that develops smartphones that still holds top 3 market share in US. The day-to-day work is eating up all my time. When I'm developing my own project, I never seem to accomplish anything. I planned out some huge tasks for myself each night and I was so determined to finish them all, but it all ends up with losing the focus.
After all, I developed a small app for myself, I hope it would help you while you're doing your side project ( I try to not sound like I'm doing advertising for my project... since it's free of charge, feel free to use it and give me some feedback if you like ).
www.vodolist.com is what I come up while I was still employed at my old employer. What I could do with this app is that, I decided to do only "3 tasks" for my side project. ( and only 1 task for some other smaller project. you can customize it ). With only a few tasks involved each day, I can force myself only work on the important and only crucial components of my side project.
This post gets a little long with the help of scotch so I guess I'll just stop here for now.
After all, I developed a small app for myself, I hope it would help you while you're doing your side project ( I try to not sound like I'm doing advertising for my project... since it's free of charge, feel free to use it and give me some feedback if you like ).
www.vodolist.com is what I come up while I was still employed at my old employer. What I could do with this app is that, I decided to do only "3 tasks" for my side project. ( and only 1 task for some other smaller project. you can customize it ). With only a few tasks involved each day, I can force myself only work on the important and only crucial components of my side project.
This post gets a little long with the help of scotch so I guess I'll just stop here for now.
I like the visualization of goals feature, it seems like a useful self-analysis and reward system. I might give it a go. Thank you.
Actually for your own stuff, not work, absolutely over commit. Eventually you will improve your performance to the point where you start finishing things, then you'll be finishing lots of things, and you might even end up with the kind of productivity that most teams wish for... also you will find where your limits lie for work through experience, instead of having to guess (which programmers famously get wrong) making it easier to not under commit yourself to tasks at work.
People say finishing is everything, and they are right, but like most skills finishing is not binary "yes" or "no", once you can finish things you can progress to being able to finish them better, faster and with less code. Ironically, owing to the nature of learning and the human brain in general you will have a hard time improving your finishing skills unless you regularly wind up in the situation where it is very difficult, or impossible to finish.
People say finishing is everything, and they are right, but like most skills finishing is not binary "yes" or "no", once you can finish things you can progress to being able to finish them better, faster and with less code. Ironically, owing to the nature of learning and the human brain in general you will have a hard time improving your finishing skills unless you regularly wind up in the situation where it is very difficult, or impossible to finish.
At first when I saw this headline and that the source was github I thought it meant making too many commits in git. I couldn't figure out why that would be such a bad thing.
Me too. I thought it was going to be a tutorial on using squash/rebase.
All I could think of was making it difficult to find exactly what commit fixed/introduced what bugs.
Luckily, there are things like git bisect to help you. On the flip side, finding the commit that caused the bug is much more valuable with smaller commit, particularly if you limit each commit to one logical change in the code.
And if it is, you can just do some squashing and rebasing later on to fix it.
Well said. I completely empathized with your sentiment. So much so that I had to write more in response them what is probably appropriate in a comment section.
I commit to small one-off projects for friends, longer-term work with acquaintances, and whip up my own projects all the time. Sometimes the projects are freelance, and sometimes they are simply "free." All this serves to satiate the needling feeling in the back of my brain that I might just be missing out on something.
Here's the rest of my thoughts: http://blog.glenelkins.com/the-over-committers-dilemma/
I commit to small one-off projects for friends, longer-term work with acquaintances, and whip up my own projects all the time. Sometimes the projects are freelance, and sometimes they are simply "free." All this serves to satiate the needling feeling in the back of my brain that I might just be missing out on something.
Here's the rest of my thoughts: http://blog.glenelkins.com/the-over-committers-dilemma/
Fellow "serial over committer" here. I find it preferable to accept all new opportunities, but make sure stakeholders/I understand my availability. After prioritizing, nobody's surprised when some projects complete and others don't gain momentum. If you're letting others down, they probably overestimated your time/resources.
There is a cost in overcommitting as there is the opportunity cost.
But I believe there is a way to overcommit with the "under commit, over deliver" line of thought. That will allow you to still look at the new opportunities and present an option ("sure - let's talk first"..."could get done by xx".."too late? well next time perhaps").
One thing I've found - while handling many side-projects is to know each one has a priority based on how much I'm invested in one of them and the benefits that one will bring. If you have the priorities set upfront, it'll be easier to make decisions in case something gotta give. But if you "under commit" to a lot of different commitments, you'd still have some space :)
One thing I've found - while handling many side-projects is to know each one has a priority based on how much I'm invested in one of them and the benefits that one will bring. If you have the priorities set upfront, it'll be easier to make decisions in case something gotta give. But if you "under commit" to a lot of different commitments, you'd still have some space :)
I like the idea of prioritizing, but I find that even small projects that I abandon have a disproportionately large negative effect on my emotions/confidence/drive. It reminds me of what someone once told me about the stock market - getting $100 feels good, but losing $100 feels so much worse.
have you tried "selling the idea" to someone else? Perhaps someone that wants to learn to code, or work with design, or write - depending on the type of project, even small ones, its good to energize someone to try it than to drop it.
A shared success is better than no success.
A shared success is better than no success.
That is an awesome idea. And if no one wants to "buy" then probably no one cared about it in the first place so I shouldn't feel bad about letting it die. I'll have to try it out - I've got a good project in mind that this approach might work for.
In 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!
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!
Starting 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
I've been on HN too long. I read the title and assumed the article was about someone's revision control habits.
I think the key to recovering from over-commitment is to increase your rates. If you are over-committed, you are giving away your time for too little money.
The article is about someone who works a steady non-contract job who signs up for personal side projects and research stuff at work, I'm not sure how you think "increasing your rates" applies in the situation.
(FWIW, if you're a contractor who has more work than they can complete, I absolutely agree with your analysis)
(FWIW, if you're a contractor who has more work than they can complete, I absolutely agree with your analysis)
This is me right now exactly. I am swamped because i have over committed to too many thing. It is stressing me out and I don't know how to escape.
Are there any commitments that you can put on pause? Maybe you can't just drop the project, but if you aren't going to have time to work on it for a month, then officially delay it for a month so it's at least off your mind.
[deleted]
the most important thing is finishing. optimize for that. anyone can start, few can finish.
[deleted]
It sounds like the problem is a boss who knowingly asks you to work on projects on your own time. The rest of the example story sounds like a poorly run, passive aggressive workplace.
I am not completely cured of the habit, but what helped me with this -- and more importantly, what helped me actually begin finishing things -- is simply being very careful to only talk about what I've done, not what I'm working on or what I'm planning.
There's this thing called "substitute for completion" where if you talk about some project, even one with hundreds of hours of work remaining, your brain gets the same reward as actually completing it. A smaller dose, perhaps, but essentially the same thing. So your brain figures out that it can just keep coming up with new ideas and telling people about them and it will get an echo of the same feeling of accomplishment as actually doing it, without the hard work.
So what seems to work for me is only talking about my projects in the past tense. When I want to say "I started a new game last week and it's going to be the most awesome augmented reality zombie squirter ever", instead I say, "I wrote a new game event system last week and it turned out pretty good," because that's as far as I got. It's also motivating because I can't wait to tell people about all the cool stuff I have planned, but I have to wait until I actually do it.
I put out a second beta of my current project on TestFlight yesterday. It was a good feeling. It's been a ton of hard work so far. But it's not in the app store yet, so I'm not going to post about it until it is.