This "don't break the chain" approach has worked extremely well for me, particularly during busy periods of high stress. I first learned about it in my college writing classes, where you're supposed to write something, anything, meaningless jibberish even, every single morning. Recently I read about Seinfeld using this approach to great successs. Every day he works on material, and puts a big, fat, "X" on the calendar.
An important change that I made, compared with these techniques, is that I require myself to write meaningful code. It's certainly much harder to do that but as a result I find myself developing good time management skills. Knowing that I have to be mentally "present" for my work forces myself to schedule and plan my days better, resulting in higher quality work all around!
When did you find yourself getting most of your coding done? Mornings? I'd love to try something like this, but it will probably mean writing code at like 6 am..
Personally I like to do my side coding project in the evenings. I find that if I do it in the morning it's too "all consuming" (I'll end up working on it to the exclusion of my main work.) For me morning/early afternoon is my prime coding time so it feels right to devote those hours to my job. I concede that the weekday side project code won't be the most amazing ever, but it's something and it's moving me forward.
How do you define meaningful code? I feel like I'd quickly run out of approachable ideas without reinventing some wheel. I'm also not to the point that I can write Node/Python/other packages and have them be useful or unique.
When the so called Seinfeld technique really takes off, you forget to even mark the calender, then get the gratifying experience of going back and marking a big block of days after the fact.
I guess that's the threshold of the internalised habit.
"This "don't break the chain" approach has worked extremely well for me".
I believe you are certainly not the only one. Changing "tasks" into habits greatly helps to achieve your goals. I recently read an excellent book about habits called "The Power of Habit" from Charles Duhigg. I sincerely recommend reading it.
And for the OP, thanks for posting and sharing your ideas. I can relate to many of the things mentioned in the post. Especially for the anxiety part. It does not matter what you are coding, as long as you code something. I've solved some problem's from Project Euler and after each exercise I've felt a sense of accomplishment and restful.
There's actually a site called http://dontbreakthechain.com/ which serves as a bit of motivation for getting personal development work done. I've had issues with remembering to check the site everyday even if the work gets done, but perhaps making it the homepage would help.
In the book The Artist's Way by Julia Cameron she talks about "morning pages". Every morning write 3 pages of anything. Works for me and it is a nice daily meditation exercise.
Then you could make finding what you want to do with yourself a daily practice. Could be meditating, or a period of isolation -- walk in the woods, time in quite reflection...
Parent said that Seinfeld used it. That reddit post is Seinfeld declining credir for an idea which he considers a non-idea. He called it a "dumb non-idea" in the sense of "runjake's running program: put your shoes on evey day, so you are ready to go for a run when you have time." It's a "dumb non-idea" because it's so basic, but it's still something some people do.
As you can see, I'm about to lose a ton of green. I'm at 87 days as my longest, but July 6, 2013 was brutal for me. I was actually flying, and had saved a small bit of work to do during a layover, but then I totally forgot.
Once that chain was broken, it was super easy to justify taking some time off...
I agree, definitely. I tried to emphasize how important it is to make this a lifestyle change (equivalent to dieting or exercise) rather than just a "check the box" tactic. I've absolutely broken streaks in the past (especially for dieting and exercise) - but I feel confident about this one because I care about it so much. I just can't let it fail!
One thing I've found is that when you miss days, having some sort of planned reset time is definitely helpful. I use the same chain technique to journal every day through 750words. They track streaks both overall in days and visually on a montly basis, meaning that if you fall off the wagon, you can still easily get back on. The motivation comes from the fact that you can work from scratch towards getting another perfect month. I really like this approach, though I'm not sure exactly how you could apply it to Github's commit UI.
Currently I'm in the complete opposite modus operandi. I don't do a lick of side-project work during the week, and on weekends I take a modafinil(wakefullness promoting medication) and stay up nights on end to crack out as much as I can.
I get an INSANE amount done on the weekends that I have the energy to pull this off, but it's horrible for my health. The rest of the week I have anxiety about the coming weekend, and it completely throws of my circadian rhythm. Not to mention that I'm only able to pull this off perhaps once or twice a month.
I'll definitely be changing my work schedule to be more in-line with a daily habit. Being able to look back and see a lot of consistent work being done sounds way preferable to being able to look back at a few weekends of consistent insanity.
I would say changing to a more consistent work schedule is definitely a good idea, but don't lose the "schedule" part. There's a huge advantage to being able to say "okay, now is work time".
However, after writing that I imagine it's a very personal thing, not everyone will work best in the same way.
Haha yeah I totally agree there. I've got a time allotted every day after work that I really could fill with at least 30 minutes of coding, but somehow it gets diverted to god-knows-what.
Yeah, that's always the hardest part. Messing around on HN/Reddit/Twitter/etc. and/or watching TV - it's so easy to not even realize that you're procrastinating. I find that when I realize what I'm doing I can usually extract myself and get to work - the hard part is just getting to that point!
no side effects from the modafinil? I take them very rarely pretty much only when it's of the utmost importance that something gets done by a deadline and even then i'll only take a half or a quarter.
Same here. The only side effect I've noticed is that I can find myself extremely obsessed with writing long-winded rants to people if I get side-tracked from the task at hand. I know that this is a commonly reported side effect, so I always catch myself and force myself to stop before I get that far, but it's something to watch out for.
I used to take 8 modafinil / day but have been able to bring my wakefulness back to what I feel is going to be normal for me without medication.
I did experience one side effect -- paranoia. I became really paranoid about what my spouse was doing behind my back. I knew that there was nothing going on though, so I was able to finally make the call to get my doctor to take me off the medication. I'd imagine the situation would be much worse if you were paranoid but didn't realize that you were delusional.
I know for some people, TDD is the kind of friction-causing mechanism that kills the desire for everyday coding...but I've found it extremely helpful, even for small personal projects.
On nights when I absolutely cannot write a piece of working code, I scaffold out the tests. When I wake up the next morning and have 5 minutes with my coffee, I pass a test. Not much gets done, but by building the habit and ability to "jump into coding", no matter the time, place, or circumstance...that's how I've been able to build the coding-zen-mentality needed to write "real" code when the time comes.
Great post! A similar approach has been working really well for me. I'm on target to hit a year of consecutive days of coding this weekend. GitHub: https://github.com/zachlatta
I had a bit lower baseline than the author. My rules are as follows:
1. Commit something, anything. Even if it's just fixing a typo in a readme or phrasing some documentation better.
I just want to caution folks, from experience, that it is easy to miss the forest for the trees if you are constantly trying to code.
I think the key takeaway here is that sticking to a plan is helpful, and that a coding heavy plan is a productive one. This is a great post for that.
I would argue that a good plan should include time off for reflection, and to avoid burning out. I have seen too many engineers burn out because they were convinced that working constantly was optimal for progress.
Perhaps surprisingly I feel like this process has allowed me to come to these conclusions even more quickly. If I spend five days in a row working on the same thing it's a giant red alarm in my mind. "Is this the most important thing I should be working on? Why did I just spend five days working on it? Should I move on to something else now?" I'd contrast this with before where if I only worked on it every weekend my ability to make those realization would be on the scale of a month, rather than a week - allowing me to adapt and respond much more easily.
Yes, it makes you more productive, but what if you fall in love, get sick, have a child...? Then you feel guilty about not catering to your side projects and guilt breeds procrastination.
I learned how to break down work into small pieces and rather finish one small piece and then call it a day instead of leaving something half-working for the next day. Because of this, I left projects dormant for 3 months and then picked them up again.
Granted, my side-projects are for-fun and not for-money, that makes it easier...
I think you might be conflating things a bit. The guilt about a lack of productivity already exists (daily work, or not). Doing daily work helps to mitigate it to a large degree. Naturally if I get sick I'll be comfortable enough to "let it slide". If anything I'll be eager to get back to work right when I can.
I do agree that breaking things into tiny tasks is the best way to go, it's helped me tremendously. More than anything else though it seems that passion is the largest "secret ingredient". If you're not passionate about the work it just won't happen, regardless of what happens in your life.
>The guilt about a lack of productivity already exists (daily work, or not).
This is what I think is unhealthy. If you want to spend a lot of time coding in your free time, go for it. If you notice guilt because you are slacking, you should revisit your priorities and earnestly think about why you are coding that much.
If you are a constant procrastinator, forming good habits, even on trivial stuff, reconnects you with why you need to do the work, and prepares you for getting started.
But after awhile, you find that you're just working, and need to produce. So it switches to deliverables.
My only life hack addition: instead of calling it a day, pick what you are going to set for your next completion goal before you quit. This was a Hemingway hack to make sure he could get up the next morning and start writing immediately. I've found that even the most informal mental commitment the day before solves the starting problem and ends up producing more positive streaks. It is great at overcoming (and preventing) any kind of "block".
On a slightly related note, I'm trying to impose a new behaviorist training on myself. I've never been one to listen to music when working, although I love music (as in member of two active bands, produced many albums love music).
So now, I'm trying to do work in album-length increments. Put on the headphones, pick an album, and work on one task all the way through it. No breaks, no interruptions. It's kind of a Pomodoro technique variant, a bit longer and with the headphones involved for extra habit and insulation from the outside world.
Well, what kind of music do you like? Good albums, as opposed to just a bunch of songs strung together, are kind of a special thing.
Might I suggest a Nick Drake album? He only made three (although there are technically more), and all of them have excellent full-album flow. It's folky and acoustic, so not to everyone's taste, but it's beautiful stuff. Alternately, a classic Pink Floyd album? Those are also very this-is-a-complete-album.
Zero days are great. Enjoy them without guilt. Don't fear going back to day 1. Make your decision each day if you're going to enjoy a zero day or get something done and long streaks can follow.
Telling a programmer to write code every day is a bit like asking an aspiring carpenter to swing a hammer: it's a necessary component of improving your skills and building things, but it is also a narrow, technical task that has limited value in isolation.
Having said that, programmers should spend at least as much time reading and thinking about code as they do writing it. You can write code for hours each day and do nothing but revert to the technologies and techniques that you find most comfortable.
I'd agree with you if my primary desire were to improve my ability as a programmer. Unfortunately, at least at this time, it's not. My major concern is getting meaningful work done. I spend far too much time thinking and reading about technologies, techniques, and planning for the future - more time needs to be spent on actually implementing all the amazing stuff that you want to exist.
There are a number of technologies that I'm interested in right now (machine learning, "NoSQL" databases, graph databases, computer vision analysis, Node.js, amongst others) so I will just casually read about these things as time goes by. When the time comes for a new project I'll try to use one of them (but usually only one, too many new technologies and you're spending too much time just learning APIs). This has helped me to continually pick up some new techniques. Not sure if this is a silver bullet but it's been working pretty well for me. I try not to stress too much about jumping on the latest tech - I'd much rather wait and have others try it out and let me know if it does/doesn't work!
I agree. I have the habit of constantly learning, without producing. So I'll pick up side projects, suck the learning-marrow from their bones, and discard them without finishing.
I have so little to show in terms of actual work product, which I am attempting to fix with a similar "don't break the chain" approach.
I have been in the same boat as you when it comes to side projects, but I'm curious about your use of the metaphor of "sucking the marrow from the bones" because that metaphor is typically used to describe completion to an extreme. For example, if "eating an animal" was your metaphor for working on a side project, I think that a more apt extension to that metaphor would be "leaving meat on the bone" rather than "sucking the marrow from the bones". However your metaphor refers to the marrow as "learning-marrow" which confuses the larger metaphor that is "eating an animal".
Have I completely misunderstood the extended metaphor you were trying to use?
You gotta think of your project as you think of a woman you are in love with, otherwise, there's no sex. I think there is a lot in common between love, advancing in a project and even picking a movie to watch - they all involve a kind of 'sexual' openness towards the subject.
i know it's usually frowned upon to make jokes on HN, but it's amusing that this comment seems be sexualising everything and your user name is an anagram of "viagras"
It's actually a word in Sanskrit, meaning creative energy, but it has a secondary meaning of seed / discharge. And my comment sexualizing the relationship between a dev and his work is not a joke - I really believe that thing that allows us to enjoy such work that other find repulsive is a kind of attraction similar to sex. I'm using this insight for finding a good attitude towards my work - you know, you gotta admire the curves before you get into the mood. :-P
I have the exact same problem, I love learning new stuff, thinking about new projects, mentally designing code and UIs... but I do much less of actual coding done than I would want to. One reason is that once the novelty of the project wears of, it becomes a boring routine work.
maybe if you keep your projects in the "really small" size bin you can actually finish them before the boredom sets in. and the positive feedback loop might even prop you up to see a bit bigger projects through.
When I think too much my ideas change; what was once meaningful is not anymore. Feature creep is the other problem: as time passes features creep in and I never move out of the design phase.
I can appreciate that perspective, and there must be value in your approach if the quality & amount of code you produce is any indication. (As an aside, I really enjoyed Secrets of the JavaScript Ninja; that book changed the way I think about JS.)
I'd agree with you if my primary desire were to improve my ability as a programmer. Unfortunately, at least at this time, it's not. My major concern is getting meaningful work done.
FWIW, code I don't have to think about tends to not be the meaningful part of a project.
The best way to employ the things you learn and discover when reading and thinking about code, is to write code. All the reading and thinking is no good without the part where you write code.
I see your point but I don't think when John says "Write Code Every Day" he means writing without thinking. Of course any decent programmer knows thinking about the architecture, pattern, design, data structure and algorithm while writing code is paramount.
What I see him saying is that practice the art of coding every day but you can't write code without thinking so it's kind of implied to me.
For me the interpretation is to not just write code everyday, but write QUALITY code everyday. Quality code that improves what you're working on, challenges you to learn new things, and contributes to the development of this skill.
Otherwise I could write hello world for 30 minutes a day.
I'm going to go out on a limb and say nearly everyone reading programming blogs don't need to be told this, but a large fraction of them do need to be told to "get shit done"
The statement "Practice makes perfect." is false if you don't invest time in reading, thinking, doing retrospectives of your work. The 50/50 ratio seems fair enough.
I am a total convert to the "don't break the chain" idea. I started writing a book on game programming[1] about four years ago. At the time, I was working at EA, miserable, and highly motivated to have the book done so it could help pad my resume. I got a book deal (O'Reilly) then, when that fell through, another (Apress). I had a real writing schedule, and a very supportive wife, and I would work on it for hours at a time.
Then I left the game industry, moved across the country, and had another kid. Suddenly, motivation and time were scarce. I backed out of the book deal and basically put it on hiatus for two years. I still really wanted to finish it but it just wasn't happening.
About a year ago, I realized that if I didn't finish it soon, I never would. My familiarity with the domain was fading every day. I didn't want the project to be a failure, so I decided to try writing every day.
I didn't have a set goal each day, but I try to do around 30-45 minutes. That ends up being ~500 words of first draft, ~1,000 words of later revisions.
In the past 309 days, I've finished 12 chapters. That's 59,568 words, plus a few thousand more for intro sections. I've redesigned the site twice, set up a mailing list, gotten a business license, and a bunch of other grunt work.
I'm about halfway through the very last chapter now (!). In less than a month, I should be able to say the book is done. (Though what I mean is that the manuscript is done, I'll be doing ebook and print versions after that.)
I absolutely could not have done this without working on it every day.
The "don't break the chain" rule is brittle: if you do break the chain, your motivation can crater. I think [Beeminder](http://beeminder.com/) has a clever solution to this problem; it gives you a way to track and enforce your goals while being robust to the occasional lapse.
Another way to structure the chain is a chain of unbroken weeks, instead of days, especially for actions that stand a pretty good chance of being derailed by life. Like going to the gym. Mark a week as "checked off" if you hit the gym for at least 3 of the 7 days. That way you've got several "buffer days" to act as a cushion.
I haven't found this. Because I can still see a calendar that shows all the days I hit my goal, my motivation doesn't suddenly evaporate if I miss a day. One of the keys I think is setting goals that you can't fail at. So rather than "go to gym" which is a hard habit to form, you could start with "do 10 pushups". Eventually once the habit has formed you can step it up, but it's far more valuable to win/succeed every day than it is to accomplish lots on one day then laps for 5.
EDIT: for example here are my current widgets for the My Chains app on android: https://db.tt/pYRrrPZs you'll notice they're pretty quick and easy, but there are quite a few of them. This gives me a tremendous sense of achievement and progress which has been invaluable in the quest to form better habits.
Oh yeah the corner groupings are rad. best thing about the xperia is the keyboard though... I can't stand touch screens!! Although my ideal form factor is candybar the only other phone in existence that does what I need is the Motorola Pro+ which is really fragile. I currently have like 4 xperia sk17a's ... Stockpiling them like a survivalist.
I agree, that's what happened to me. Now I have a rule to not go 2 days without working on one of my coding project, so if I miss a day I don't get discouraged.
That has to be one of the most interesting monetization ideas I've seen in quite some time. Pretty genius (I'm assuming the money if you go off track goes to them) :D
> what are your self-publishing plans (if you don't mind discussing them)?
The book will remain freely available in web form in its entirety. When I put up the last chapter, that will include a nice redesign that should hopefully make it pleasant to read across most devices.
Soon after, I'm going to start working on an eBook and print version. I'm not sure how I'll do the eBook yet, but I'll do some investigation. The book is written in markdown, so it should be fairly straightforward to eBook-ify it.
For the print version, I'll be laying it out by hand with lots of love in InDesign. I was a designer before I turned to programming, and I've always wanted to typeset a full book. I didn't think I'd have to write it first to get the opportunity!
Sometime soon, I'll also contract out for a proofreading pass over the book. Each chapter has gone through a few revisions already, as well as numerous bug reports from eagle-eyed readers, but there's always mistakes. I'll pay out of pocket for it.
I'm purchasing my own ISBN. I'll put the eBook and print-on-demand version up on Amazon. I'm not sure if I'll sell it through other channels yet. I still have to look into it.
The best thing I did was start a mailing list when I was about halfway through the book (using MailChimp, who are swell). It's got over 2k subscribers now, so when the eBook and print versions are ready, I have an audience I can tell.
> What software do you use for writing?
Sublime Text. The first thing I did when I started the book was set up a very simple workflow. I have a Python script[2] that takes the markdown, transcludes the code snippets (which are in separate source files so they can be compiled and tests), and converts it to HTML.
I write in Sublime and then run the script to see the resulting output. I find seeing the prose in two different forms (markdown and styled HTML) helps me during the editing process. It's serves as a proxy for a fresh pair of eyes.
No problem. One quick thing I learned: pandoc is sooooooo much better for this than anything else. I was originally using Calibre to generate stuff, and their epubs don't follow the spec, and so don't work correctly in some readers. I was _this close_ to writing a Ruby script that would unzip, s/foo//g, rezip it back up, before I found pandoc.
I'd recommend Leanpub[0]. They accept markdown and their workflow is pretty easy and non-exclusive.
For my book[1] I just used pandoc and Makefiles, but once the school year ends and I turn my attention back to the book getting it up on Leanpub is a priority.
I use the "don't break the chain" idea as well and it has helped me out tremendously. I currently have three separate calendars for April taped next to my computer so that I can see it every day/all day as a reminder. I will not have any leisure time until I mark an X for the day on all three calendars. The three calendars are for improving myself professionally/career (coding every day), physically (gym), and mentally (reading 1 hour).
I highly recommend that methodology for anyone trying to build a [productive] habit.
[HabitRPG](http://habitrpg.com) is totally awesome for this, a great motivator. You can setup "Dailies" so that when you're done writing your daily 500 words, you just check it off. Or set it up as a habit and give yourself a "+" whenever you get a new chapter done.
For Android, I like Habit Streak Pro [1]. You give a list of things you want to maintain a daily streak on, and then it asks you at the same time every day how you did.
My longest recent streak was a 5+ month one on sticking to a restricted diet. The power of that was amazing; any time I considered straying I'd feel like I would be throwing away months of work. (I finally broke the chain on day 3 of the flu; I was miserable and wanted comfort food.)
My tips: Have it ask you the daily questions first thing in the morning, so you start your day with a reminder of your streak. And try to keep the number of goals very low, 1-3. More than that and I find it too hard to build good habits.
I chuckled to myself at this bit because it's the type of productive-but-utlimately-unnecessary task I'd find myself doing if I were trying to write a book.
Not trying to be a downer, that's an impressive streak and I hope your book does well!
Yes, I have to work hard to limit my non-writing tinkering, so I timebox the design stuff pretty harshly.
I started the book four years ago, so the first design was unreadable on mobile devices (fixed position navigation will do that!). After a number of complaints, and the creation of Google Web Fonts, a mobile-friendly better design was a necessity.
I just finished another redesign that will launch when the last chapter is done. It's even more mobile friendly and has a front page that reflects the completed status of the book. It also just looks a hell of a lot better. :)
How do I donate something to your cause to say thank you for the work you've already done (and for putting it online for free)? Paypal/Bitcoin would be easiest, but anything will do. :)
If you want to back that up with cash, the best way will be to buy a copy of the print version when it's out. Part of the magic of self-publishing is that I get a very large cut of the sales of that, so it's a good way to say thanks. (And you get a physical book out it!)
Very good discipline in the article, and very good discipline in your plan too.
If you don't mind me asking - what's the point in writing a book about an area that you used to work in, but didn't want to going forward? (I assume you moved out of gaming if the domain was fading)
I'm not keen on working in games professionally right now (though I wouldn't rule it out forever), but I'm still quite into game programming. I don't spend much time doing it these days though, since most of my limited free time lately is either on writing or programming languages.
But I'm still really passionate about the subject material (games and software architecture) and I think the book could be written, and I could write it. I also just really want to finish something for once in my life. Getting email from people asking me to keep working on it for two years didn't hurt either. :)
One little secret about the book is that it's not actually game-specific at all. Almost all of the patterns in it are equally useful in non-game software, but I think games are a much more interesting motivating example than yet another accounting application with EmployeeRecords and PaymentAccountTypes.
Thanks for sharing. Yes - games are a much more interesting subject matter than accounting records. :-)
I think it's a worthy endeavor no matter how it ends for you. You're contributing to the broader base of knowledge in the world, and clarifying your own thoughts in the process. Even if there isn't tangible immediate benefit to you, it's still a good thing to do.
Hey I'd just like to tell you that your site is an awesome resource and was useful to me as a student when I was talking my OO design courses. As someone with a gamedev hobby background your site made learning about patterns much easier for me. I will be sure to buy the book when it comes out. Thanks for putting in the hard work and making it available.
> As someone with a gamedev hobby background your site made learning about patterns much easier for me.
This is really reassuring to hear. One of my hopes with the book was that framing architecture in terms of games (which are graphically and conceptually very concrete) would make it easier to understand the more abstract concepts it's about.
I like the "don't break the chain" method as well. I actually designed a calendar that displays the whole year at a glance. Mine is printed out and placed on a wall that I will see every day. I use it for the "don't break the chain" idea, but it is also really good at reminding me how short a year is. Really drives home the idea that every day is important.
Hey, I just wanted to sign-in and comment to say that at some point in the past, I found myself reading your book website. I do recall back then it had way less chapters, and I remember hoping that it'd find its way to completion eventually. I see a lot of new chapters. Great work! Very good resource, too.
He works on Dart for Google. I also find him an excellent critic (inclusive of dart) in forums. Some of his insights have cleared up things for me that are expressed vaguely elsewhere in comparison. I would like to see him do something more expansive on the tradeoffs between objects and ADTs (hint hint). Maybe he has done but I can't find it.
> I would like to see him do something more expansive on the tradeoffs between objects and ADTs (hint hint).
I'm probably not the best person to answer that. My knowledge of real academic theory isn't as strong as I'd like, especially around type systems.
I assume you've read William Cook's paper on the same topic ("Object-Oriented Programming Versus Abstract Data Types")? I skimmed it a while back and felt like it clicked for a while but it's sadly unclicked since then. It's on my (interminably long) list of paper to try to grok better.
Well it was worth a shot anyway (you made some comment in that area before that I thought was good). I need to go back over that Cook paper myself. Thanks for reminding me.
No, I left EA about four years ago. I was hoping to stay in the game industry but somehow snuck into Google instead. I'm working on Dart now and couldn't be happier.
> Oh, are you the one whom Herb Sutter used his benchmark in the Build conference talk about C++ a few days ago?
Interesting, how did you end up in Dart team? I mean that "famous" Google-way of randomly assigning employees to projects. And is there any way to apply directly to Dart (or any other) team?
My starter project at Google was working on front-end UI code for what eventually became Hangouts in G+. Lots of JS in a very large JavaScript application.
I really like UI stuff (that's what a lot of my background is in), but I wasn't at all interested in the domain (videoconferencing) and trying to do an app-like user experience in the browser is not something I would wish on my enemies.
Through total random chance (we took a one-off improv class at work together) I met someone who was spinning up a small team working on tech to try to push the web forward. This was right around the birth of my second kid, so I got my manager to agree to let me switch teams when I came back from paternity leave.
I worked on that for a short while before the project ended up getting reshaped. My little team then basically spent a week or two interviewing teams at Google to see where we'd go. It was awesome: we literally had teams coming to us pitching themselves.
Since I love programming languages and open source, the Dart team (which was still in it's very early days) was a great fit.
Did you work on Madden at EA (since you mention it in the intro)? If so I'd love to read more about the architecture of that. I've always wondered how offensive/defensive line interaction and AI worked -- among a million other things. And the book looks good!
> Did you work on Madden at EA (since you mention it in the intro)?
I did, though I didn't really touch gameplay. I was a UI programmer on Madden PC 2002 (Oh God that's over a decade ago now, what happened to time?) and I worked on the first version of Madden for the X360 doing mostly animation and tool pipeline stuff.
I'm not the best person to ask about it, but the part that blows my mind is that the "AI" for the game is deeply tied into the animation system. Madden has hundreds (thousands?) of individual player animations: runs, tackling, blocking, catching, you name it. The AI works roughly by searching for an animation that lines up with what it wants to do.
For example, if the ball is coming towards a receiver, it looks for a catch animation that will put his arms in about the right place and that stitches together well with the animation he's currently playing. If it finds one, then it transitions to that animation and makes the catch.
This means the producers who are building and tuning the gameplay do much of it by tweaking animation: changing timing, deciding to add more animations of certain types, etc.
As far as I know there is no holistic set of data or code that says, "this is the AI of Madden". Instead, it's just the sum of all of these animations.
I've been learning game dev recently, i'm a web dev by professions so it's acting as a nice refreshing change to code at night. It's been difficult to find quality resources for someone who is an experienced programmer but unfamiliar with the principles of game development. I had stumbled across your site numerous times, noted the quality of the work and finally bookmarked it few weeks back.
In case you're ever lacking motivation, just think that the work has been invaluable to someone like me coming to game dev for the first time. It's a truly excellent resource and i will surely buy the book when it's released. I'm signing up for the mailing list now.
Thanks again for your hard work
EDIT: I even just noticed that I even had the site open already, right at the back of my massive stack of open tabs :)
Life is too short to waste it in things you don't love. Remember jQuery brought you fame, not because you were chasing fame itself but because your love for jQuery and programming.
Love for what you do comes first, money is just a secondary effect.
Haha ehhh I think you're reading into this a bit too much. It is possible to love more than one thing - I love helping educate people and doing it at a scale that Khan Academy can provide. I also love building reusable JavaScript libraries. I also love building tools for Art Historians. They all shouldn't be to the exclusion of each other and, in fact, there's often overlap. Part of the fun in life is embracing that and trying to make the most of it!
It's vital to keep your nose in real problems if you're working on tools, otherwise it's easy to go off into the weeds.
Additionally, a substantial part of research/creating things is time not spent working on it. It's really similar to working out: the rest time is when the growth occurs, and the time at the gym provides the impetus.
One big problem I've learned with not working consistently at any one task is that after dropping and returning to a project, I find myself being familiar enough with areas I last touched that I want to speed through them to reach a point where I begin working on new ideas and concepts. But in most cases, those areas I left off at were the very reasons I jumped ship, either because they were too difficult or mind-numbing to wade through, leaving them incomplete/unlearned, and resulting in me having to take a few steps back to fully refresh myself before I can continue building, which leads to a lot of frustration and feeling like I'm wasting a ton of time.
The pitfalls of context switching is mentioned often in this article. I have a "problem" where I'll work heavily on a side project for a few days, before getting bored and wanting to move onto another project. The result is that I have many unfinished side projects.
Is it better to focus on one project until completion, even if you aren't as into it anymore? What do other HNers do regarding multiple on-going side projects?
I would say shipping is definitely life improving. Shipping is where you expose your work to the public and open it up to feedback and criticism. You can learn a lot more from direct feedback than you can learn from a general book.
I have far too many books and half finished projects that will never get finished. I have forgotten most of the stuff I learned from them.
Don't focus on the how. You can produce good code by:
1. Coding every day
2. Hackathons
3. Coding on certain days
4. However you want.
What matters though, is how -you- work. Are you the sort of person who prefers to code as much as possible? Code every day. Do you enjoy getting a big thing done fast? Hackathons are for you. Do you have children, a life or a job? You might want to code whenever you can instead of trying to force yourself into something that might not work for you.
I was onboard with this school of thought for a while, right now it isn't my flow.
I work hard as-is teaching WDI at GA. I commit code frequently, but I also really want to focus more on work-life balance at the expense of getting more done. This summer, I'm taking two months off to do Burning Man and travel the country via motorcycle. During that time I expect no code to be committed. Do I feel bad about that at all? Not in the least bit, in fact I'm super excited to do it.
Currently, I try to not do much work on weekends. I like working hard during the week and then stepping away from the computer. I'll go and play music, ride my motorcycle, hang out with friends, travel, etc. The more time spent on my laptop on weekends feels like I'm missing out on things that matter strongly to me right now.
Now I am nowhere near the prolific coder that John is, and nowhere near his skill. I don't think he's wrong for doing it this way, but it isn't right for me and I'm glad that its producing results for him. I also go through periods of wanting to code daily, and other times where I'm ok with not coding for several days at a time.
To each their own. Also, Hi John!!! I haven't seen you since betahouse or you holding a Jelly at your place in Cambridge.
I agree with your sentiment -- I've been through long periods of little-to-no side project hacking. Like multi-year, long. I've been working on my current side projects for over two years now but I finally made the decision last fall to make the hard decision: either this is going to be something that I REALLY want to get out there (and thus, I need to work really hard to make it happen) or I need to be comfortable with letting it slowly progress over a long period of time. I made the decision to go for it, so I'm writing the code to make it happen!
But yeah, for every season there is definitely a different formula. In the next phase of my life hopefully I can find other things to bring this level of excitement and stimulation!
You're absolutely right in that its critical to either kick things into gear, or know that its going to take a long time for things to happen. That's excellent focus. I look forward to shifting back to the other side at some point. Maybe in 2015 ;)
I agree. Its nice to get away form the computer and achieve other things. A break from coding also helps build hunger to get back into it on a Monday morning. I love programming, but there's a lot more to life that doing it everyday.
I think your system leads to a happier, healthier you, since you're doing what you like. I don't know about John, but I'd code every day, because I actually enjoy coding. I have the feeling it applies to him as well.
It's the same with writers who write every day, no matter how little, to get into the rhythm and to constantly improve.
Also, doing something every day, doesn't imply neglecting other parts of your life. It just means constantly giving to something you care about.
Absolutely this. You can also use a tool like Gitstats (if you don't use Github) to track your progress. A lot of my code is written inside thirty minutes on the bus and tube on the way to work. Sometimes you might feel like there's no point even pulling the laptop out of your bag since the time window is too small- but every time you will surprise yourself with how much you manage to get done.
The best thing about the 'little and often' approach is how you get drawn into fixing something big just by starting to fix something small. Getting into The Zone for hours at a time is great and everything but honestly I'm starting to view the whole process as just clocking in keystrokes.
My gitstats (http://notes.darkfunction.com/gitstats/index.html) is showing commits on 56 of 85 days. A week of the remainder I was on holiday, and I tend to rebase quite a lot so actual days committed should be higher. But in that time I have written over 18,000 lines of code and removed over 6000. Almost a full iPhone application since January in my spare time, now onto the home stretch and couldn't be more pleased with the results.
220 comments
[ 2.4 ms ] story [ 261 ms ] thread[1] http://www.joesgoals.com/index.cfm
https://habitrpg.com/
I guess that's the threshold of the internalised habit.
I believe you are certainly not the only one. Changing "tasks" into habits greatly helps to achieve your goals. I recently read an excellent book about habits called "The Power of Habit" from Charles Duhigg. I sincerely recommend reading it.
And for the OP, thanks for posting and sharing your ideas. I can relate to many of the things mentioned in the post. Especially for the anxiety part. It does not matter what you are coding, as long as you code something. I've solved some problem's from Project Euler and after each exercise I've felt a sense of accomplishment and restful.
1. http://www.reddit.com/r/IAmA/comments/1ujvrg/jerry_seinfeld_...
For my personal situation I can't guarantee I would get time to do coding every evening but 2 session a week seems feasible.
I run every two days. The chain is still a chain, but it's just a slight more distributed one.
I printed a calendar and stuck it on my wall. Then I just mark it off with a big circle when I finish a run, or a cross when I fail.
See my graph: https://github.com/steveklabnik
As you can see, I'm about to lose a ton of green. I'm at 87 days as my longest, but July 6, 2013 was brutal for me. I was actually flying, and had saved a small bit of work to do during a layover, but then I totally forgot.
Once that chain was broken, it was super easy to justify taking some time off...
Currently I'm in the complete opposite modus operandi. I don't do a lick of side-project work during the week, and on weekends I take a modafinil(wakefullness promoting medication) and stay up nights on end to crack out as much as I can.
I get an INSANE amount done on the weekends that I have the energy to pull this off, but it's horrible for my health. The rest of the week I have anxiety about the coming weekend, and it completely throws of my circadian rhythm. Not to mention that I'm only able to pull this off perhaps once or twice a month.
I'll definitely be changing my work schedule to be more in-line with a daily habit. Being able to look back and see a lot of consistent work being done sounds way preferable to being able to look back at a few weekends of consistent insanity.
However, after writing that I imagine it's a very personal thing, not everyone will work best in the same way.
I did experience one side effect -- paranoia. I became really paranoid about what my spouse was doing behind my back. I knew that there was nothing going on though, so I was able to finally make the call to get my doctor to take me off the medication. I'd imagine the situation would be much worse if you were paranoid but didn't realize that you were delusional.
On nights when I absolutely cannot write a piece of working code, I scaffold out the tests. When I wake up the next morning and have 5 minutes with my coffee, I pass a test. Not much gets done, but by building the habit and ability to "jump into coding", no matter the time, place, or circumstance...that's how I've been able to build the coding-zen-mentality needed to write "real" code when the time comes.
I had a bit lower baseline than the author. My rules are as follows:
1. Commit something, anything. Even if it's just fixing a typo in a readme or phrasing some documentation better.
2. You must commit every day.
3. Every contribution must be useful.
I think the key takeaway here is that sticking to a plan is helpful, and that a coding heavy plan is a productive one. This is a great post for that.
I would argue that a good plan should include time off for reflection, and to avoid burning out. I have seen too many engineers burn out because they were convinced that working constantly was optimal for progress.
Yes, it makes you more productive, but what if you fall in love, get sick, have a child...? Then you feel guilty about not catering to your side projects and guilt breeds procrastination.
I learned how to break down work into small pieces and rather finish one small piece and then call it a day instead of leaving something half-working for the next day. Because of this, I left projects dormant for 3 months and then picked them up again.
Granted, my side-projects are for-fun and not for-money, that makes it easier...
I do agree that breaking things into tiny tasks is the best way to go, it's helped me tremendously. More than anything else though it seems that passion is the largest "secret ingredient". If you're not passionate about the work it just won't happen, regardless of what happens in your life.
This is what I think is unhealthy. If you want to spend a lot of time coding in your free time, go for it. If you notice guilt because you are slacking, you should revisit your priorities and earnestly think about why you are coding that much.
If you are a constant procrastinator, forming good habits, even on trivial stuff, reconnects you with why you need to do the work, and prepares you for getting started.
But after awhile, you find that you're just working, and need to produce. So it switches to deliverables.
My only life hack addition: instead of calling it a day, pick what you are going to set for your next completion goal before you quit. This was a Hemingway hack to make sure he could get up the next morning and start writing immediately. I've found that even the most informal mental commitment the day before solves the starting problem and ends up producing more positive streaks. It is great at overcoming (and preventing) any kind of "block".
So now, I'm trying to do work in album-length increments. Put on the headphones, pick an album, and work on one task all the way through it. No breaks, no interruptions. It's kind of a Pomodoro technique variant, a bit longer and with the headphones involved for extra habit and insulation from the outside world.
Might I suggest a Nick Drake album? He only made three (although there are technically more), and all of them have excellent full-album flow. It's folky and acoustic, so not to everyone's taste, but it's beautiful stuff. Alternately, a classic Pink Floyd album? Those are also very this-is-a-complete-album.
Having said that, programmers should spend at least as much time reading and thinking about code as they do writing it. You can write code for hours each day and do nothing but revert to the technologies and techniques that you find most comfortable.
I have so little to show in terms of actual work product, which I am attempting to fix with a similar "don't break the chain" approach.
Have I completely misunderstood the extended metaphor you were trying to use?
I extract the goodies from whatever I'm learning, and never finish the project I'm learning from.
My attention shifts as soon as the project stops being interesting & new, and becomes "work" to finish up.
FWIW, code I don't have to think about tends to not be the meaningful part of a project.
What I see him saying is that practice the art of coding every day but you can't write code without thinking so it's kind of implied to me.
For me the interpretation is to not just write code everyday, but write QUALITY code everyday. Quality code that improves what you're working on, challenges you to learn new things, and contributes to the development of this skill.
Otherwise I could write hello world for 30 minutes a day.
The statement "Practice makes perfect." is false if you don't invest time in reading, thinking, doing retrospectives of your work. The 50/50 ratio seems fair enough.
Then I left the game industry, moved across the country, and had another kid. Suddenly, motivation and time were scarce. I backed out of the book deal and basically put it on hiatus for two years. I still really wanted to finish it but it just wasn't happening.
About a year ago, I realized that if I didn't finish it soon, I never would. My familiarity with the domain was fading every day. I didn't want the project to be a failure, so I decided to try writing every day.
I didn't have a set goal each day, but I try to do around 30-45 minutes. That ends up being ~500 words of first draft, ~1,000 words of later revisions.
In the past 309 days, I've finished 12 chapters. That's 59,568 words, plus a few thousand more for intro sections. I've redesigned the site twice, set up a mailing list, gotten a business license, and a bunch of other grunt work.
I'm about halfway through the very last chapter now (!). In less than a month, I should be able to say the book is done. (Though what I mean is that the manuscript is done, I'll be doing ebook and print versions after that.)
I absolutely could not have done this without working on it every day.
EDIT: for example here are my current widgets for the My Chains app on android: https://db.tt/pYRrrPZs you'll notice they're pretty quick and easy, but there are quite a few of them. This gives me a tremendous sense of achievement and progress which has been invaluable in the quest to form better habits.
Sorry it's MyChain
Just curious... what are your self-publishing plans (if you don't mind discussing them)? What software do you use for writing?
The book will remain freely available in web form in its entirety. When I put up the last chapter, that will include a nice redesign that should hopefully make it pleasant to read across most devices.
Soon after, I'm going to start working on an eBook and print version. I'm not sure how I'll do the eBook yet, but I'll do some investigation. The book is written in markdown, so it should be fairly straightforward to eBook-ify it.
For the print version, I'll be laying it out by hand with lots of love in InDesign. I was a designer before I turned to programming, and I've always wanted to typeset a full book. I didn't think I'd have to write it first to get the opportunity!
Sometime soon, I'll also contract out for a proofreading pass over the book. Each chapter has gone through a few revisions already, as well as numerous bug reports from eagle-eyed readers, but there's always mistakes. I'll pay out of pocket for it.
I'm purchasing my own ISBN. I'll put the eBook and print-on-demand version up on Amazon. I'm not sure if I'll sell it through other channels yet. I still have to look into it.
The best thing I did was start a mailing list when I was about halfway through the book (using MailChimp, who are swell). It's got over 2k subscribers now, so when the eBook and print versions are ready, I have an audience I can tell.
> What software do you use for writing?
Sublime Text. The first thing I did when I started the book was set up a very simple workflow. I have a Python script[2] that takes the markdown, transcludes the code snippets (which are in separate source files so they can be compiled and tests), and converts it to HTML.
I write in Sublime and then run the script to see the resulting output. I find seeing the prose in two different forms (markdown and styled HTML) helps me during the editing process. It's serves as a proxy for a fresh pair of eyes.
[2]: https://github.com/munificent/game-programming-patterns/blob...
I put my "toolchain" to do this up on GitHub, which really is just a Makefile that feeds things to Pandoc: https://github.com/steveklabnik/words
For my book[1] I just used pandoc and Makefiles, but once the school year ends and I turn my attention back to the book getting it up on Leanpub is a priority.
[0] https://leanpub.com/authors
[1] https://learnjavathehardway.org/
I highly recommend that methodology for anyone trying to build a [productive] habit.
Filed a bug: https://github.com/munificent/game-programming-patterns/issu...
I use it all the time for just these purposes.
Are there any other similar apps out there?
Far more minimalist. Just a calendar and mark, but I can set reminders and view my overall progress.
My longest recent streak was a 5+ month one on sticking to a restricted diet. The power of that was amazing; any time I considered straying I'd feel like I would be throwing away months of work. (I finally broke the chain on day 3 of the flu; I was miserable and wanted comfort food.)
My tips: Have it ask you the daily questions first thing in the morning, so you start your day with a reminder of your streak. And try to keep the number of goals very low, 1-3. More than that and I find it too hard to build good habits.
[1] https://play.google.com/store/apps/details?id=uk.amimetic.ha...
https://chains.cc/
I chuckled to myself at this bit because it's the type of productive-but-utlimately-unnecessary task I'd find myself doing if I were trying to write a book.
Not trying to be a downer, that's an impressive streak and I hope your book does well!
I started the book four years ago, so the first design was unreadable on mobile devices (fixed position navigation will do that!). After a number of complaints, and the creation of Google Web Fonts, a mobile-friendly better design was a necessity.
I just finished another redesign that will launch when the last chapter is done. It's even more mobile friendly and has a front page that reflects the completed status of the book. It also just looks a hell of a lot better. :)
If you want to back that up with cash, the best way will be to buy a copy of the print version when it's out. Part of the magic of self-publishing is that I get a very large cut of the sales of that, so it's a good way to say thanks. (And you get a physical book out it!)
If you don't mind me asking - what's the point in writing a book about an area that you used to work in, but didn't want to going forward? (I assume you moved out of gaming if the domain was fading)
But I'm still really passionate about the subject material (games and software architecture) and I think the book could be written, and I could write it. I also just really want to finish something for once in my life. Getting email from people asking me to keep working on it for two years didn't hurt either. :)
One little secret about the book is that it's not actually game-specific at all. Almost all of the patterns in it are equally useful in non-game software, but I think games are a much more interesting motivating example than yet another accounting application with EmployeeRecords and PaymentAccountTypes.
I think it's a worthy endeavor no matter how it ends for you. You're contributing to the broader base of knowledge in the world, and clarifying your own thoughts in the process. Even if there isn't tangible immediate benefit to you, it's still a good thing to do.
> As someone with a gamedev hobby background your site made learning about patterns much easier for me.
This is really reassuring to hear. One of my hopes with the book was that framing architecture in terms of games (which are graphically and conceptually very concrete) would make it easier to understand the more abstract concepts it's about.
Sometimes I look at the table of contents and see how all of the chapter links are filled in and working and it surprises me too.
Edit: Oh, are you the one whom Herb Sutter used his benchmark in the Build conference talk about C++ a few days ago?
I'm probably not the best person to answer that. My knowledge of real academic theory isn't as strong as I'd like, especially around type systems.
I assume you've read William Cook's paper on the same topic ("Object-Oriented Programming Versus Abstract Data Types")? I skimmed it a while back and felt like it clicked for a while but it's sadly unclicked since then. It's on my (interminably long) list of paper to try to grok better.
No, I left EA about four years ago. I was hoping to stay in the game industry but somehow snuck into Google instead. I'm working on Dart now and couldn't be happier.
> Oh, are you the one whom Herb Sutter used his benchmark in the Build conference talk about C++ a few days ago?
Yup!
My starter project at Google was working on front-end UI code for what eventually became Hangouts in G+. Lots of JS in a very large JavaScript application.
I really like UI stuff (that's what a lot of my background is in), but I wasn't at all interested in the domain (videoconferencing) and trying to do an app-like user experience in the browser is not something I would wish on my enemies.
Through total random chance (we took a one-off improv class at work together) I met someone who was spinning up a small team working on tech to try to push the web forward. This was right around the birth of my second kid, so I got my manager to agree to let me switch teams when I came back from paternity leave.
I worked on that for a short while before the project ended up getting reshaped. My little team then basically spent a week or two interviewing teams at Google to see where we'd go. It was awesome: we literally had teams coming to us pitching themselves.
Since I love programming languages and open source, the Dart team (which was still in it's very early days) was a great fit.
I did, though I didn't really touch gameplay. I was a UI programmer on Madden PC 2002 (Oh God that's over a decade ago now, what happened to time?) and I worked on the first version of Madden for the X360 doing mostly animation and tool pipeline stuff.
I'm not the best person to ask about it, but the part that blows my mind is that the "AI" for the game is deeply tied into the animation system. Madden has hundreds (thousands?) of individual player animations: runs, tackling, blocking, catching, you name it. The AI works roughly by searching for an animation that lines up with what it wants to do.
For example, if the ball is coming towards a receiver, it looks for a catch animation that will put his arms in about the right place and that stitches together well with the animation he's currently playing. If it finds one, then it transitions to that animation and makes the catch.
This means the producers who are building and tuning the gameplay do much of it by tweaking animation: changing timing, deciding to add more animations of certain types, etc.
As far as I know there is no holistic set of data or code that says, "this is the AI of Madden". Instead, it's just the sum of all of these animations.
That is probably the code I'd pay the most money to get a walkthrough of.
In case you're ever lacking motivation, just think that the work has been invaluable to someone like me coming to game dev for the first time. It's a truly excellent resource and i will surely buy the book when it's released. I'm signing up for the mailing list now.
Thanks again for your hard work
EDIT: I even just noticed that I even had the site open already, right at the back of my massive stack of open tabs :)
Life is too short to waste it in things you don't love. Remember jQuery brought you fame, not because you were chasing fame itself but because your love for jQuery and programming.
Love for what you do comes first, money is just a secondary effect.
Additionally, a substantial part of research/creating things is time not spent working on it. It's really similar to working out: the rest time is when the growth occurs, and the time at the gym provides the impetus.
One big problem I've learned with not working consistently at any one task is that after dropping and returning to a project, I find myself being familiar enough with areas I last touched that I want to speed through them to reach a point where I begin working on new ideas and concepts. But in most cases, those areas I left off at were the very reasons I jumped ship, either because they were too difficult or mind-numbing to wade through, leaving them incomplete/unlearned, and resulting in me having to take a few steps back to fully refresh myself before I can continue building, which leads to a lot of frustration and feeling like I'm wasting a ton of time.
Is it better to focus on one project until completion, even if you aren't as into it anymore? What do other HNers do regarding multiple on-going side projects?
-The Next Episode Remix
If the latter is true, do you really need advice?
Said differently: flow is the opiate of the masses.
It's easy to become complacent. Most people are.
I have far too many books and half finished projects that will never get finished. I have forgotten most of the stuff I learned from them.
What matters though, is how -you- work. Are you the sort of person who prefers to code as much as possible? Code every day. Do you enjoy getting a big thing done fast? Hackathons are for you. Do you have children, a life or a job? You might want to code whenever you can instead of trying to force yourself into something that might not work for you.
I work hard as-is teaching WDI at GA. I commit code frequently, but I also really want to focus more on work-life balance at the expense of getting more done. This summer, I'm taking two months off to do Burning Man and travel the country via motorcycle. During that time I expect no code to be committed. Do I feel bad about that at all? Not in the least bit, in fact I'm super excited to do it.
Currently, I try to not do much work on weekends. I like working hard during the week and then stepping away from the computer. I'll go and play music, ride my motorcycle, hang out with friends, travel, etc. The more time spent on my laptop on weekends feels like I'm missing out on things that matter strongly to me right now.
Now I am nowhere near the prolific coder that John is, and nowhere near his skill. I don't think he's wrong for doing it this way, but it isn't right for me and I'm glad that its producing results for him. I also go through periods of wanting to code daily, and other times where I'm ok with not coding for several days at a time.
To each their own. Also, Hi John!!! I haven't seen you since betahouse or you holding a Jelly at your place in Cambridge.
I agree with your sentiment -- I've been through long periods of little-to-no side project hacking. Like multi-year, long. I've been working on my current side projects for over two years now but I finally made the decision last fall to make the hard decision: either this is going to be something that I REALLY want to get out there (and thus, I need to work really hard to make it happen) or I need to be comfortable with letting it slowly progress over a long period of time. I made the decision to go for it, so I'm writing the code to make it happen!
But yeah, for every season there is definitely a different formula. In the next phase of my life hopefully I can find other things to bring this level of excitement and stimulation!
I say: take three months off from even touching a text editor and practice guitar every day.
I think my system leads to happier, healthier human beings.
It's the same with writers who write every day, no matter how little, to get into the rhythm and to constantly improve.
Also, doing something every day, doesn't imply neglecting other parts of your life. It just means constantly giving to something you care about.
The best thing about the 'little and often' approach is how you get drawn into fixing something big just by starting to fix something small. Getting into The Zone for hours at a time is great and everything but honestly I'm starting to view the whole process as just clocking in keystrokes.
My gitstats (http://notes.darkfunction.com/gitstats/index.html) is showing commits on 56 of 85 days. A week of the remainder I was on holiday, and I tend to rebase quite a lot so actual days committed should be higher. But in that time I have written over 18,000 lines of code and removed over 6000. Almost a full iPhone application since January in my spare time, now onto the home stretch and couldn't be more pleased with the results.
Really enjoyed your post, though. I think I might give it another shot from a different perspective.