2005年1月2日
大多数锐气十足的学生从来不向前辈征求意见。在计算机科学领域，这样做是正确的。因为前辈们很可能说些“在2010年前，市场对于那些只会敲击键盘的代码工人的需求将会超过一亿（因此前景是乐观的）”，或者诸如“Lisp语言现在真的很热门”。
看起来简单， 实际上复杂
2002年3月4日
事情没有看起来那么简单，再加上减低风险性的指导思想，只能让你得出如下的结论：先设计再编程序，先思而后行。
行进中开火
2002年1月6日
按步就班并不难。通常我一天是这样度过的：1，去上班。2，查电子邮件和上网等等。 3，考虑是否应该吃完中饭在开始干活。4，吃完中饭回来。5，查电子邮件逛网。6，终于决定应该开始工作了。7，查电子邮件逛网，东瞄瞄，西看看。8，再次决定确实应该开始开始干活了。9，打开该死的编辑器。10，一直会些程序学到晚上7：30，写到忘记时间。
在以上第8步和第9步之间似乎有点缺陷， 因为我不是每次都能顺利地执行下去。
第四战略篇：膨胀软件与80/20的谣传
2001年3月23日
膨胀软件的存在是有道理的。最起码的，如果程序员不用担心软件的大小，那么软件就可以早点出版。用户可以早点得到更多的功能。这些功能用时有益，不用时无害。
每日构建（daily build）是你的朋友
2001年1月27日
当你使用版本控制来管理源代码时，一个程序员偶尔会导入（check in）代码以至你构建失败。例如，他们新增了一个代码文件。在他们本人的机器上一切OK，但是他们忘记把这个新增的文件导入（check in）到版本控制服务器上了。 于是破坏构建的罪魁祸首高高兴兴的回家了。别的程序员由于构建失败以至无法继续工作，也闷闷不乐地回家了。导入代码破坏构建的结果非常严重（但是又发生的很频繁），于是每日构建（daily build）自然而然地产生了。这样任何人的任何导入代码如果破坏了构建都会被尽快发现。对于大的团队来说，每日构建最好在午餐 时间进行。每个人都在吃中饭前导入（check in）代码，当他们吃完饭回来时，构建应该已经结束了。如果构建成功，好极了！每个人导出（check out）最新的代码继续开始 工作。如果构建失败了，某人来修正它。但是别人可以使用前一个构建成功的代码继续工作。在微软的Excel团队，我们又一个规矩，谁破坏了构建，他（她）就是负责照看构建过程作为惩罚，知道他找到下一个接替者。这是个很好的办法，没有人原意破坏构建而接受惩罚，同时被惩罚的人也有机会学习每日构建（daily build）在我的最新的文章 每日构建是你的朋友中有更多的描述。
The Joel Test: 软件开发成功 12 法则
2000年8月9日
有没有听说过SEMA？这可是衡量一个软件开发组好坏的很深奥的系统。 别按那个联接！给你六年你也搞不清这玩意。所以我自己随便攒了一套衡量系统，信不信由你，这系统，三分钟就可掌握。 你可以把省下的时间去读医学院了（译注：美国的医学院可是要读死人的！）。
轻松面试找到理想员工－非官方的面试技术指南
2000年3月23日
Fog Creek公司最重要的雇佣标准是:有头脑, 并且
完成工作就是这些了。
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
