科普文：Write Code Every Day 编程每一天

我决定给自己定下几条规则：

1. 每天编写代码。我可以撰写文档、博客、或者做任何其他事情，但必须在写完代码之后。
2. 代码必须可用。无需调整缩进，无需重新格式化，尽可能无需重构。
3. 所有代码必须在午夜前写完。
4. 代码必须开源在 GitHub 上。

　　上述规则难免过于武断。代码不一定非要在午夜前写完，我这么说只是为了避免过度劳累，导致不良代码的产生。把代码放在 Github 上，是为了强迫自己更加细心（让自己尽早考虑代码重用以及模块化）。

　　截至目前，我已经连续工作接近二十周时间，而且取得了显著的成功。我想告诉大家，这种策略改变了我编写代码的工作方式，对我的生活和精神产生了巨大的影响。

　　以下是习惯改变之后发生在我身上的几件趣事：

　　最小可用代码。我每天强制自己编写代码不少于三十分钟。有时候工作时间可能稍长一些（但一般不超过一个小时），周末的时候，我常常工作一整天。

　　编程是一个习惯。有一点需要注意的是，我并不特别在意代码在 Github 上的受关注程度。我认为我从这项实验中得到的最大收获是：这是我为我自己做出的改变，与其他人无关，我不想以此取悦任何人。就像培养个人饮食与健身习惯一样：只有当你真正开始关心自己的进步状况时，进步才会发生。

　　对抗焦虑。在开始这项实验之前，我经常处于高度焦虑的状态 - 总是担心自己无法完成足够的任务（尽管我给自己没有设定最后期限）。我在实验中慢慢意识到，感受进展本身与取得实际进展一样重要。这一点让我大开眼界，只要每天都能取得进展，焦虑感自然就会消失。我对工作不再抱有过高期望，这样，我的内心就能始终保持平静。

　　周末。以前，周末工作对我以及对项目进展来说，绝对至关重要（因为只有在这个时段，我才进行大量的编程）。现在的情况已经截然不同，这真是一件大好事。我之前每个周末都会给自己安排一定的工作任务，但实际完成情况常常令人失望。我很少能够按时完成这些任务，以至于不得不退掉其他的周末活动，比如，吃吃点心，参观博物馆，逛公园，朋友聚会等。你知道，这些活动对我的生活都有着积极的作用。我强烈地感觉到，即使个人项目再重要，也不应该与生活中的其他内容发生冲突。

　　后台处理。每天都为自己的个人项目做一点工作，将会产生一种副作用 - 你会觉得你的大脑始终处于编程中。当我外出散步、淋浴，或者任何其他非脑力活动时，解决问题的灵感时常显现。这在以前从来没发生过。那个时候，我的时间大量消耗在忧虑之中。多数情况下，忧虑并不能帮助我完成给更多的任务。

　　环境切换。通常情况下，从一个项目切换到另一个项目需要一定的转换成本。不幸的是，当一个项目停顿一周之后，你很难恢复到原来的思考状态。在一个项目上停顿时间越短，越有利于恢复记忆。

　　工作平衡。改变带来的最重要一点是，学会如何更好地平衡工作、生活、以及个人项目。事先知道自己的安排，这能让我更好地平衡时间。如果我打算晚上外出，而且很晚才回来，那我就会早点开始我的个人项目。另外，如果我还没有完成我的工作，我就会晚点儿再出去，或者，尽早回家（尽量不错过每天的工作）。我注意到，我花在业余爱好上的时间少了（如雕版印刷等），但这是一个合理妥协，我必须适应。

　　对外沟通。对外沟通这个新习惯给我增加额外的好处。我在个人项目上的合作伙伴很容易了解我的工作计划与进程，他们的工作计划更易于制定。外出、看电影等活动显得更加自然，这种生活很舒服。

　　代码量。我简直不敢相信自己在过去几个月的工作量。我创建了一个新网站，重构了一些框架，还构建了一大堆新模块。我写的太多了，以至于有时候，我会忘记曾经做过的事情。那怕是几周前的工作，对我来说，就像一个遥远的回忆。我对我所做的一切非常满意。

        我认为，这次改变对我来说是一次巨大的成功。可能的话，我希望继续保持下去。在此期间，如果有谁希望像我一样，我将尽我所能向你展示和推销这一策略。如果你在应用这项策略的过程中，遭遇任何问题或疑惑，请一定和我联系。我很乐意听到一些逸闻趣事。

　　作者：John Resig，程序员，jQuery 之父，现生活在美国纽约。

　　原文：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.

Illustration by Steven Resig

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 to have 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!

Discuss this post on Hacker News.

Posted: April 10th, 2014