本文是Write Code Every Day的中英文对照，给自己指定一些原则，并通过自律坚持下去，在编程之路上才能走的更远，以下是原文。

去年秋天我的支线代码项目 遇到了一些问题，项目进展不足，而且我没法找到一个完成更多代码的方法（在不影响我在Khan Academy方面的工作的前提下）。

我主要在周末进行我的支线，当然有时候也在晚上进行。这个方法对我而言效果不佳。我的压力太重了，我需要在周末努力完成尽可能多的工作（如果没做 到，我会为此感到挫败）。还有一个问题是我无法保证每个周末都有空，而且我也不想把周末所有的时间都花在编程上（失去一切放松娱乐的机会）。

此外，每隔一周进行编码的话，间隙太长了。太容易忘记你正在做什么，或者你还需要做什么了（即使你有笔记）。如果你错过了一个周末的话，问题就更严重了，间隔一下子变成两周了。多周的上下文切换可能是致命的（我有很多支线项目因为这类注意力缺乏而死亡了）。

Jennifer Dewalt 去年通过在 180 天创建 180 个网站的方式来自学编程，她的做法启发了我。我决定采用一个简单的策略：每天编码。

我决定为自己定下一些规则：

  1. 每天必须写代码。我可以写文档、写博客或者写其他东西，但是这些不能代替写代码。
  2. 代码必须是实际起作用的。调整缩进、重新排版不算。如果有可能，重构也不算。（可以进行这些事情，但这些不能是一天唯一的编码。）
  3. 所有代码必须在午夜之前完成。
  4. 代码必须是开源的，放在Github上。

有些规则比较武断。比如代码其实不用在午夜前写完的。但我担心熬夜导致代码质量下降。同样，代码也不用开源，或者放在GitHub上。我这么做是想强迫自己写代码的时候上点心（考虑可读性，同时较早地考虑模块化）。

到目前为止这个策略很有效。我基本保持了20周的连续工作。我之所以写这篇博客，正是因为它完全改变了我编写代码的方式，更重要的是影响了我生活和心智。

这个习惯的改变产生了一些有趣的结果：

最小可行的编码。 我强迫自己每天花不少于半个小时来写代码（如果少于这个时间就很难写出有价值的代码了，特别是回忆前一天写了什么还要花一点时间）。工作日的时候我有时写得多一点（一般不超过一个小时），周末我有时整天写代码。

写代码成为习惯。 值得一提的是我并不是特别在乎上面的Github图形。我觉得这是这个实验最值得借鉴的一点：这是你为自己做的一个改变，而不是为了满足别人对你工作的评价。节食和锻炼也是一个道理：如果你不在乎提升自己，那么你永远都不会取得成功。

与焦虑作斗争。 在开始这个实验之前，我时常为没有完成足够的工作或取得足够进展而感到焦虑（工作和进展都难以量化，因为我的支线项目没有死限）。我意识到，感觉到进展和 实际推进工作同样重要。这令我大开眼界。一旦我每天持续地推进项目，我的焦虑就开始消散了。我对自己的工作量很心安，我再也没有那种难以承受的渴望，想要 疾风骤雨式地推进项目的渴望。

周末。 以前，在周末完成工作绝对是前进的关键动力（因为通常而言这是我唯一大量推进支线项目工作的机会。）现在情况不一样了——这是件好事。期望在一个周末完成 一周的所有工作只会让我失望。我极少很完成工作，因此为了完成更多工作而拒绝了其他喜欢的周末活动（例如吃 dim sum，参观博物馆，去公园游玩，陪伴我的伴侣等）。我深深地感到，虽然支线项目是非常重要的，但是它们不应该是生活的全部。

后台处理。 每天编写支线项目代码的一个有趣的副作用是你当前的任务时常在你大脑的后台运行。因此当我去散步或沐浴的时候，或者进行其他不费脑的活动的时候，我在思考 我接下来将做哪些编码，寻找解决问题的好方法。我以前一周或两周编码一次的时候可不是这样。当时时间被花费在思考其他一些事情上，通常是在为没法完成任何 支线项目而感到焦虑。

上下文切换。 拾起支线项目工作的时候总会有上下文开销的。很不幸，重拾整整一周前的思考是极其困难的。每天做一点对此很有帮助，因为间隔时间大大缩短了，让我很容易想起在做什么。

平衡工作。 这个改变最重要的方面之一是我已经简单地学会了如何更好地平衡工作、生活和支线项目。我知道自己每天都要做支线项目，因此我需要更好地管理时间。如果我计 划晚上出去，并且很晚才能回家，那么我需要在早上为支线项目工作，在开始为我主业Khan Academy工作之前。同样的，如果我在外面，而我还没有完成我的工作，时间已经很晚了，那么我需要尽快赶回家去完成工作（以免错过一天）。我需要指出 的是我发现自己把更少的时间花在爱好上了（例如木版画），但是这是一个合理的代价，我得接受这个。

对外沟通。 跟外界沟通自己的新习惯是很有好处的。我的伴侣理解每都必须完成工作，因此有活动安排有时需要据此作出调整。这样我就可以很方便地说：“是的，我们可以出去/看个电影/等等。但是我之后需要写代码。”我的伴侣会理解我，并在安排活动时考虑到这点。

我写了多少代码？ 我很难相信自己在过去的几个月写了这么多的代码。我新建了几个网站，重写了一些框架，并创建了大量node模块。我写了如此之多的代码以至于我有时我都忘记自己做了写什么——几周前的工作感觉是很久远的记忆。我非常非常高兴自己能写这么多代码。

我认为这个习惯的改变是一个巨大的成功。我希望自己能持续保持这个习惯。同时，我尽力向其他希望能完成大量的支线项目的人推荐这个策略。告诉我这个策略对你而言是有效还是无效。我很希望能从你那里听到一些有意思的东西。

关于作者

John Resig， jQuery之父，同时也是Pro Javascript Techniques和Secrets of the JavaScript Ninja的作者。他目前主持 Khan Academy 的开发工作。

原文 Write Code Every Day

Write Code Every Day

Last fall, work on my coding side projects came to a head: I wasn’t making adequate progress and I couldn’t find a way to get more done without sacrificing my ability to do effective work at Khan Academy.

There were a few major problems with how I was working on my side projects. I was primarily working on them during the weekends and sometimes in the evenings during the week. This is a strategy that does not work well for me, as it turns out. I was burdened with an incredible amount of stress to try and complete as much high quality work as possible during the weekend (and if I was unable to it felt like a failure). This was a problem as there’s no guarantee that every weekend will be free – nor that I’ll want to program all day for two days (removing any chance of relaxation or doing anything fun).

There’s also the issue that a week between working on some code is a long time, it’s very easy to forget what you were working on or what you left off on (even if you keep notes). Not to mention if you miss a weekend you end up with a two week gap as a result. That massive multi-week context switch can be deadly (I’ve had many side projects die due to attention starvation like that).

Inspired by the incredible work that Jennifer Dewalt completed last year, in which she taught herself programming by building 180 web sites in 180 days, I felt compelled to try a similar tactic: working on my side projects every single day.

I decided to set a couple rules for myself:

  1. I must write code every day. I can write docs, or blog posts, or other things but it must be in addition to the code that I write.
  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.)
  3. All code must be written before midnight.
  4. The code must be Open Source and up on Github.

Some of these rules were arbitrary. The code doesn’t technically need to be written before midnight of the day of but I wanted to avoid staying up too late writing sloppy code. Neither does the code have to be Open Source or up on Github. This just forced me to be more mindful of the code that I was writing (thinking about reusability and deciding to create modules earlier in the process).

Thus far I’ve been very successful, I’m nearing 20 weeks of consecutive work. I wanted to write about it as it’s completely changed how I code and has had a substantial impact upon my life and psyche.

With this in mind a number of interesting things happened as a result of this change in habit:

Minimum viable code. I was forced to write code for no less than 30 minutes a day. (It’s really hard to write meaningful code in less time, especially after remembering where you left off the day before.) Some week days I work a little bit more (usually no more than an hour) and on weekends I’m sometimes able to work a full day.

Code as habit. It’s important to note that that I don’t particularly care about the outward perception of the above Github chart. I think that’s the most important take away from this experiment: this is about a change that you’re making in your life for yourself not a change that you’re making to satisfy someone else’s perception of your work. The same goes for any form of dieting or exercise: if you don’t care about improving yourself then you’ll never actually succeed.

Battling anxiety. Prior to starting this experiment I would frequently feel a high level of anxiety over not having completed “enough” work or made “enough” progress (both of which are relatively unquantifiable as my side projects had no specific deadlines). I realized that the feeling of making progress is just as important as making actual progress. This was an eye-opener. Once I started to make consistent progress every day the anxiety started to melt away. I felt at peace with the amount of work that I was getting done and I no longer had the over-bearing desire to frantically get any work done.

Weekends. Getting work done on weekends use to be absolutely critical towards making forward momentum (as they were, typically, the only time in which I got significant side project coding done). That’s not so much the case now – and that’s a good thing. Building up a weeks-worth of expectations about what I should accomplish during the weekend only ended up leaving me disappointed. I was rarely able to complete all the work that I wanted and it forced me to reject other weekend activities that I enjoyed (eating dim sum, visiting museums, going to the park, spending time with my partner, etc.) in favor of getting more work done. I strongly feel that while side projects are really important they should not be to the exclusion of life in general.

Background processing. 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. This did not happen when I was working on the code once a week, or every other week. Instead that time was consumed thinking about some other task or, usually, replaced with anxiety over not getting any side project work done.

Context switch. There’s always going to be a context switch cost when resuming work on a side project. Unfortunately it’s extremely hard to resume thinking about a project after an entire week of working on another task. Daily work has been quite helpful in this regard as the time period between work is much shorter, making it easier to remember what I was working on.

Work balance. One of the most important aspects of this change was in simply learning how to better balance work/life/side project. Knowing that I was going tohave to work on the project every single day I had to get better at balancing my time. If I was scheduled to go out in the evening, and not get back until late, then I would need to work on my side project early in the day, before starting my main Khan Academy work. Additionally if I hadn’t finished my work yet, and I was out late, then I’d hurry back home to finish it up (instead of missing a day). I should note that I’ve been finding that I have less time to spend on hobbies (such as woodblock printing) but that’s a reasonable tradeoff that I’ll need to live with.

Outward perception. This has all had the added benefit of communicating this new habit externally. My partner understands that I have to finish this work every day, and thus activities sometimes have to be scheduled around it. It’s of considerable comfort to be able to say “Yes, we can go out/watch a movie/etc. but I have to get my coding in later” and have that be understood and taken into consideration.

How much code was written? I have a hard time believing how much code I’ve written over the past few months. I created a couple new web sites, re-wrote some frameworks, and created a ton of new node modules. I’ve written so much I sometimes forget the things I’ve made – work from even a few weeks prior seem like a distant memory. I’m extremely pleased with the amount of work that I’ve gotten done.

I consider this change in habit to be a massive success and hope to continue it for as long as I can. In the meantime I’ll do all that I can to recommend this tactic to others who wish to get substantial side project work done. Let me know if this technique does, or doesn’t, work for you – I’m very interested in hearing additional anecdotes!

Posted: April 10th, 2014