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.
[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.
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.
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.
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.
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
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.
> 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.
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.
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 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.
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.
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.
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 :)
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.
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.
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 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. :)
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.
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.
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!)
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.
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.
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 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.)
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'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.
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 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.
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 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 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 ;)
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!
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 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.
"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.
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.
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.
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.
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.
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...
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.
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".
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.
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...
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.
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!
Really? I'm so surprised to see so many "Awesome! Go for it" answers to this.
While I admire the dedication and focus it takes to stay up to such routine, I am certainly concerned by the quality of life and the narrow mindedness of enforcing upon oneself to code on a daily basis. What about days off? Going out friends / family for a weekend or holidays? One would suggest to bring your laptop so you can stick to it? This is madness to me...
I love to code, contribute to OS projects, do code for a leaving and for myself - but for nothing in the world I'd even attempt such thing.
Setting yourself with goals is great and required to some extend but on a proper schedule. Going to the gym 3 times a week can be achieved without being complexed by the fact you didn't go there every single day - and yet you can substantially improve yourself. I don't envy those buffy dudes that stick to it.
I'll stick to enjoying evenings with my wife, do code maybe 1 or 2 times during the week days, spend an extra day on more complex issues on the week end, and rest for the last day. Just saying.
Mhh, read the article a bit more carefully. Specifically:
Minimum viable code. I was forced to write code for no less than 30 minutes a day.
30 minutes a day? That's not exactly a huge quality of life problem or a work addiction. That's keeping a useful skill up to par, the same way I'd expect a good musician to practice every day.
Besides, when you're a serial procrastinator, tactics like these can help you break out of that rut.
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.
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.
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.
Can't speak for the OP. In my case "code every day" is meaningful because I have a lot of responsibilities outside of writing code. It's good to have a reminder to always get in a bit of coding time at least.
That doesn't make me a workaholic. I'll still stick to ~8h days. It just means I'm not completely forgetting about the coding side for a couple of days and then feeling super-guilty there's no commit for a week.
(Obviously, Sat/Sun are exempt from "code every day".)
I think your comment deserves many more replies. It is taken completely granted that this is the case. I don't think it is good at all but that is the mindset.
Writing code every day doesn't necessarily make you a workaholic. Working on code all day, every day might make you one though.
What John is doing is akin to what an artist would do to hone their skills. Practice. Every great singer practices often. Every master of a musical instrument. And for programmers, it's a similar thing - there's no substitute for writing code.
His approach is to write something meaningful every day, but it shouldn't be interpreted as 'let the code writing take over your life every day'
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.
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.
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.
Finally, I want to say I personally disagree with the OP's 2nd point:
2. It must be useful code. No tweaking indentation, no code
re-formatting, and if at all possible no refactoring.
(All these things are permitted, but not as the exclusive work of the day.)
I've noticed that when I'm really tired or "not feelin' it" sometimes I just want to do something that takes 10 minutes so I can keep the chain going. When I spend a day (ie: 10 minutes) refactoring some code, I don't lose my motivation to work on my project tomorrow. It's breaking the chain makes me lose motivation and if I forced myself to write something "useful" on a day I don't feel like it, I may just end up breaking the chain instead. It's of the utmost priority to lower the bar to work on your project and rule 2 is an obstacle to that. Plus, I take mild offense to the idea that refactoring is not considered useful :)
And, if I had this rule I think I'd avoid refactoring a lot of code that needs it. I'd spend more effort squeezing that square feature into that round hole if refactoring "didn't count".
It's crazy that I found this today...I just started something similar except instead of coding every day I set a goal of 4 hours per week and I use Beeminder to track my progress. Many of the benefits you listed are spot on especially "the feeling of making progress is just as important as making actual progress." Now that I have children, coding for 8 hours on a Saturday just doesn't work. To reach my current goal of 4 hours per week, I plan on coding for 30 minutes in the morning or night where I can but I also have arranged with my wife one weeknight where I leave the house and go code at a coffee shop for 2-3 hours.
While Resig's dedication is admirable, I'd caution against applying his advice too broadly. He is doing it because he has side projects that he wants to complete. There's no reason to force yourself to code every day for coding's sake.
I've been doing a lot of side-project hacking the past three months, as evidenced by my Github activity graph (https://github.com/zhemao), which, admittedly, is not as impressive as Resig's. However, this week, I finished up my latest side project and found myself at a loss for new ideas. At first, I did feel a bit guilty about not doing any coding, since it had been a long time since I had nothing to work on. But then I realized that there's more to productivity than a nice contribution graph and sometimes it's good to take a step back in order to think, reflect, and get inspiration.
I'm currently reading through Patterson and Hennessy's "Computer Organization and Design" to learn more about computer architecture. I'd also like to practice my saxophone some more, start learning how to draw, help a friend who is still in college find a job, and expand my social life a bit. My Github account will still be there when I am ready to get back into it.
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.
"An interesting side effect of writing side project code every day is that your current task is frequently running in the back of your mind. Thus when I go for a walk, or take a shower, or any of the other non-brain-using activities I participate in, I’m thinking about what I’m going to be coding later and finding a good way to solve that problem."
Is that not a negative? I find it hard to stop thinking about what I'm working on, and it negatively impacts my life. I leave the office after 8 hours, but the next 2 hours are spent turning over problems in my head, and the 2 hours before I sleep are spent on it too. The days that I work on a problem at the office for a few hours and can't unblock myself before leaving are hell. My brain won't turn off until I can get into work the next day and begin on the problem. Some days I will even wake up in the morning or night with answers to the problem. Why is the AWS instance in my head turned on all night long when I'm not even getting paid for it?
2 years ago some friends and I started writing one song each per week (and met every Thursday to listen to our respective master-pieces). We mostly ended up composing and recording the songs on iphones the Wednesday night before (thank god for GarageBand), and after 3-4 weeks were producing more creative content in this compressed timeframe than we'd had been able to with no deadline before. A few months in we skipped a Thursday or two, and suggested the solution was to write one song per month instead. That was definitely not the solution. We didn't find more time to write, and the lack of schedule killed the momentum. My biggest regret of the last year is not sticking to it - however a friend just moved to our city with the condition that we'd get it started again with the weekly frequency, so I'm optimistic :)
I had this experience when i was working on a book and i had to spend considerable amount of time every week on one example. The book had 100 examples so it took me two years to complete the book but the experience was amazingly satisfying because i was able to justify the effort, going slow and steady.
The other thing i noticed is the increase in quality when you do less but give more time to think. Keeping the problem in your mind create innovative solutions. Which is impossible if you want to just hack up everything one weekend.
My personal favorite is keeping a point system for all the good things you want to do in your day and add them up for weeks and at the end of the month, check the total and see where are you lacking behind. What percentage of life you are actual able to live the way you want. Haven't got to 100% yet but above 60% i give a pat in the back.
I recently started the same discipline. I spent a good part of my career writing code then worked my way up to executive management and stopped. After several years as Director of this, or VP of that, my skills had eroded. Late last year I decided to take a sabbatical and get back into the game by applying to Hack Reactor in SF. It was an intense period of two months of pre-course work (18 Code School classes and a bunch of coding assignments), followed by three months of intense work on site where we went 11+ hours a day for 6 days a week. One of the disciplines there is to work on a short “toy problem” every morning for 30-60 minutes. Although I finished the program recently I am keeping up that practice as well as working on my real project, a new startup for social video. I’ll never stop coding again!
I'm curious if 30 minutes is the lower bound on meaningful project time if the constraint of writing code is lifted. I've been thinking about what kinds of projects could be decomposed into 20 minute work units, allowing some work units to basically be all thinking (design, specs, figuring out how to split up a problem, etc.) and others to be more coding.
I'm suspicious that there are many projects that could be decomposed like this, or even into 10 minute blocks, but that it'd be really helpful to have tools that makes this more achievable -- ones that basically remind you of where you were and help with the what-do-I-do-next decision.
Does anyone have any experience with this kind of development process?
I’ve been finding mind maps extremely helpful for doing exactly what you describe: working in small chunks through the process of approaching a high-level problem. (I currently use FreeMind for this, but I want to find something that works better on my laptop and/or would let me edit maps on my phone as well.)
I use mind maps like an endlessly hierarchical to-do list. Every high-level task I want to accomplish is a node, and whenever I start to think about the approach to one, I make child nodes for the broad strokes of that approach. So long as I’m actually interested in completing the project, I can continue to break each step down in this way until I get down to a level where it’s easier for me to just start writing code. (This level varies largely, depending on my mental state at the time.)
If I stop at any point I have all the thoughts that came to me, written down in exactly the places they’ll be useful. I can go as deep as I want into breaking down any particular step, knowing that those thoughts will be available later. And it’s much easier for me to spot problems and reconsider my approach when my plans are all laid out hierarchically in front of me.
I might sound overexcited about this because I hadn’t figured out how to use any external tools to help me think about my projects before I was recently introduced to mind maps, and they immediately had a huge impact on my ability to think about my projects without getting bogged down. So if you already have tools that give you similar benefits, take all this with some salt or whatever.
Anyway, I’ve lately been working mostly on weekends and finding myself with similar issues as the blog post describes, so I’m planning to start trying to do a little bit every day instead, starting today. I think I will be content if the little bit I do on some days is breaking down some tasks I haven’t yet thought through in my mind maps, even if I don’t write any actual code.
I'm actually testing this strategy for competitive programming. Was very difficult to train for the ACM-ICPC when I was working as developer, but now that I only study in the University I solve at least a problem a day for maintain my streak in my Github in these are the results in some online judges for competitive competitions:
http://community.topcoder.com/tc?module=MemberProfile&cr=227...http://codeforces.com/profile/jhtan
It works!..
Last year, I [1] set a goal to teach myself git by committing at least once every day for a month. At the end of this, I saw the streak, and was too afraid to see it go down to 1 in a snap. Ever since, I've been committing code daily, and it's been about 40 weeks, and I'm still going strong. Being a full time student, this wasn't really easy for me, but I'm proud of myself.
The one thing I learned is, that the problem isn't the lack of ideas or time, but the lack of motivation to work on them.
Related: for the first time in my 15-year programming career, I've spent the past year or so doing more engineering management than actual coding, and it has noticeably improved my programming ability.
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.
I don't write code every day, but that is largely due to my military obligations as a reservist. Other than that, I often work on various side-projects and/or help others with their coding woes as a way to learn & help keep sharp. I'm disciplined enough to learn what I need to on my own time whenever I want.
Sometimes I burn out, and in those instances I take my free time away from programming.
The most important take away is to figure out how you want to improve yourself, instill passion in doing so, then executing.
I love coding, but the idea of doing it every day would make me hate it so quickly. I love learning new technologies when I want too, or fiddling with a concept, but I want it to be because I want to do it and not because I feel obligated too. I've put myself in that situation before and all it did was bum me out and push me close to a burnout situation, it works for some people sure but people should be doing things because they enjoy it.
Don't write code every day, do something you want to everyday.
Very inspiring, but take into account that John (most likely) lives in a good enviroment to proceed with this, his job is intellectually demanding but he is not overworked or extramulti-tasked.
If your job leaves you depleted, and when you arrive home you're like a husk of a human being you can't expect to do something like this.
Take into account that great developers like John live in a place where they can grow, you can't copy what they do and expect to have the same great results in a not so great environment.
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?
As much as I like this idea, I do wish John talked more about HOW he did it. "No More Zero Days" is a good thing as a target, but it's often unachievable.
For me at least, the context switch required between what pg calls the manager's schedule and maker's schedule is so huge that it takes hours to cross that gulf (that's what I'm mostly switching between anyway)
Do you just sit down and force yourself to hammer out code?
I've made it a point to NOT check things in on Sundays. I break my own rule. I get the OCD gimmick to get yourself motivated but ...
I flies against of my philosophy of coding. Less is more, quality over lines of code. Not coding for coding sake. And coding on paper and writing out data structures and algorithms.
Hey, if a whole bunch connected green dots gives you a feeling of accomplishment. Enjoy!
I totally agree with this. About a month ago I created a site that puts up a new programming or logic puzzle every day Monday-Friday. The exercises usually take no more than 30min and the community has been steadily growing. If you're interested you can check it out at http://problemotd.com/
Something similar can be found at Project Euler, http://projecteuler.net/ or at Codewars, http://www.codewars.com/, although those have a stricter format than your examples. For example, the challenges at Project Euler all have a single number as answer. Some problems can thus be solved via mathematics, but for most a program -- you may pick the language -- is most efficient.
I find my daily intelligence is highest in the early morning 6:30 am but productivity peaks at about 9:30 am.
Anything in the afternoon is a steady decline and by evening I should just do something that doesn't involve sitting in front of the glowing box. Trying to push yourself too hard results in overall productivity loss.
I've read multiple articles on people doing this. Practice is the best way to learn. Admittedly, I've tried and failed on this before. I love seeing people succeed and become better at their practice using this method. It can only serve as inspiration for others. Thanks and congrats!
I'm guessing this doesn't apply to the average developer; after all, we write code for a living. I sure do. I don't usually do any coding when not on the clock, after all, I've already done 8ish hours of work by then (and if I'm lucky, most of it spent coding).
I tried to do this, but in the end I ended up getting a job at a fast food place (part time). It uses different parts of my brain (as opposed to freelancing), and forces me to stick to the schedule. I can't exactly explain it, but it really gave me a BIG productivity boost.
Does working toward your side projects without necessarily writing code count? There are some days where I devote myself to figuring out something on my system that's essential for my side project, and those days I don't necessarily write any code.
It's best if you actually just _read_ code everyday and the writing is just the side effect of tinkering with it. Like chess you will save a lot of time by learning from other people's games before you actually do something on your own.
This is exactly my approach on my side project, but rather than "write code every day" I say "make some progress every day". Simply because it's not a Open Source framework, but a wannabe product.
I am totally facing the same issue which you faced about working only during weekends. Your idea of working everyday seems nice i will try giving it a go :)
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.
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.
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.
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.