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.
I use it all the time for just these purposes.
Are there any other similar apps out there?
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.
Far more minimalist. Just a calendar and mark, but I can set reminders and view my overall progress.
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 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.
For my book 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 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
I highly recommend that methodology for anyone trying to build a [productive] habit.
> 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.
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 :)
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.
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.
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. :)
Filed a bug: https://github.com/munificent/game-programming-patterns/issu...
Edit: Oh, are you the one whom Herb Sutter used his benchmark in the Build conference talk about C++ a few days ago?
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?
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'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.
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!)
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.
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.
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 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 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.
I guess that's the threshold of the internalised habit.
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.
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 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".
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.
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...
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.
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 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.
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.
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".)
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'
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.
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.
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.
Here's an article that really complements the submission: http://start.jcolemorrison.com/how-i-fight-procrastination/ It's titled "How I fight Procrastination" and gives advice on how to break up tasks into day-sized activities.
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.)
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".
Will need to change my attitude and get more done. Good piece.
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.
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.
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?
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'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 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.
Last year, I  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.
Your huge list of projects has been a huge help in that regard, so thanks!
If the latter is true, do you really need advice?
Said differently: flow is the opiate of the masses.
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.
It's easy to become complacent. Most people are.
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.
Don't write code every day, do something you want to everyday.
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.
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?
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 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!
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.
Really enjoyed your post, though. I think I might give it another shot from a different perspective.
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.
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.
it applies not only to coding, but also to other areas
Always be coding.