亲爱的同事，
转眼我在这个团队工作已有一年的时光，这一年也完成了我从通讯行业转入互联网圈的过渡。过去的一年给了我很多观察（团队）的机会，也带给了我不少思考，从我过去一年的寥寥几篇博文你应当能看到部分。
今天，我想借这篇文章与大家聊一些内容，以便你更加明白：为什么我在工作中对自己和大家的要求都那么高？为什么我强调责任与重视培养工作好习惯？为什么我会直接批评和积极表扬人与事？希望你的其它“为什么”也能在这里找到答案的线索！


现实与虚拟
 现实社会中有很多让人恼火的事：想排队按序办事，却总有些人插队；想维护家里楼梯走道的卫生，却发现总有人乱扔垃圾和随地吐痰；车祸明明缘于对方过失，但他却百般否认与狡辩；想喝上干净的自来水，不求助于净水器似乎没有可能；等等。林林总总！
 对于一名构建虚拟世界的软件工程师，我们不得不变得“性格分裂”，因为我们不能将现实中的脏、乱、差带到我们所构建的虚拟世界里。这种“不能”并非我们一厢情愿，而是现实所迫，因为“脏乱差”的虚拟软件世界一定会给用户带来糟糕的产品使用体验，也会为我们的工作生活增加额外的成本（加班等）。一旦明白这一点，你就会理解我为什么在工作中的要求会那么高，而且是多方位的！
 面对现实与虚拟，我们不得不适时进行模式切换。在社会生活中，不要过于较真而影响自己的健康；在工作生活中，我们应力求构建完美的虚拟软件世界。
 刚加入团队之时，发现大家所写代码多了些随意，团队知识管理也没有“官方”途径而是各自写在自己的文档或记在头脑中（那时作为新人的我还是为此经历了不必的痛苦）。为了改变编码随意这种现状，几个月前我决定着手实施编码规范。坦白说，这是我的职业生涯中首次大张旗鼓地推行编码规范，以前我一直认为写出有质量的代码（和文档）是软件工程师所应做的本份之事，无需过于强调。当时决定推广的另一大主因是，我们产品所基于的开源项目的根基非常好，除了自身代码就是一个优秀的参照外，更有着完备的编码规范和规范检查工具。然而，编码规范的最高境界并非“格式”，而是我们的“态度”，因为规范解决的只能是形式问题，而无法规避不恰当命名等非形式问题。也正因如此，你们所写的大部分代码我都会走查，通过不断指出问题并帮助改善的方式培养大家的认真态度。最近，每当我看到代码中存在你们改善质量的痕迹时，都会会心一笑；面对大家指出我所写代码中所存在的改善点时，我更加高兴并给予肯定和感谢，因为我坚信这是我们团队所应倡导的文化。大家回头看一看，过去的几个月我们团队在这方面取得了质的进步。
 谈及团队知识管理，不得不说到我所带头编写的《软件开发指南》和《技术白皮书》。《软件开发指南》中的内容一方面很好地指导了我们的工程实践（涵盖软件设计、流程等大大小小的各方面），另一方面为新人上手起到了积极作用。前者从目前我们的项目中基本杜绝了模块混乱、加速了新版本合并速度和使得软件开发活动更规范化可以看出，后者则从最近WL在晨会上说“《指南》写得很好”得以佐证。
 值得强调的是，所有这些进步都是我们共同创造的，没有你们的积极参与和快速跟进根本不能取得现有成绩，也很难轻松走得更远。还记得我在项目总结会上所说的“我为人人，人人为我”吗？
 现实如此不完美，我们能否从构建的虚拟软件世界多找到些完美呢？！
 

 面子与责任
 面子的重要性无需多言，“捍卫面子”的意识也深入了我们的骨髓。然而，正如我曾在邮件中所提到的，以我在外企工作时的观察发现，美国的工程师之所以更富质效在于他们不是将面子放在首位，取而代之的却是责任。也正因如此，美国的工程师很喜欢发问且有时的问题让人觉得 “尖锐”，这一特质无论他们是面对同行、还是“领导”都一致。
 我坚信，一个讲面子与一个讲责任的团队将形成截然不同的两极。讲面子的团队大多低效并很有可能集体无能，而讲责任的团队将运作得务实、高效；重视面子的团队看到问题采用的是回避态度，讲责任的团队看到问题会指出并较真甚至承担。责任之所以重要，是因为它会促使我们在工作中有所作为——用心按时、按质完成工作。一个讲责任的团队也不容易出现“技术军阀”和“管理官僚”，这两者对于团队的杀伤力都可称为是“核武级”。
 重面子的团队还有另一个突出表现：团队成员很“听话”，上级说什么就做什么，不想不问，但承担不良后果。这种团队往往会凸显出“领导”的“重要性”，因为没有“领导”团队就不知要干什么、要向哪走。与之相反的是，重责任的团队即便短时没有领导者也能有序运作，甚至倒逼管理者有所作为。
 另外，责任不应只是对于自己和团队，还有对于家庭的部分。比如，通过尽可能少加班多与家人在一起、陪伴孩子成长。意识到这种责任，你往往会花更多的时间去提高自己的能力和效率，而不会一味地想着加班是解决工作问题的万能药。我一直不能理解那些没事却在加班的人，他们对于家人如此，在工作中真的可靠吗？在业务发展不需要的情形下，频繁的加班不是个人能力有问题，就是管理出现了问题。
 再者，讲责任会促使团队的成熟，使得成员重视承诺，这对项目的有序运作至关重要。重视承诺的含义是：我们对于无法按期完成的工作不承诺，而一旦承诺就要努力达成。
 理解了我对面子与责任的看法后，相信你能明白为什么我会在晨会上不时提问，也能理解为什么我敢说且主动承担非职务之内的（管理）工作、会私下找你聊工作上的事和很少加班。这一切都是责任使然，是我应该去做的！
 

 批评与表扬
 人追求完美是无极限的，无论我们多么有经验、专业和职位多高，始终能做一个更好的自己而获得成长。显然，成长的过程中不可避免地会犯错。矛盾地，在纠错的过程中我们又有惰性而阻碍前行。面对自身错误惰于纠正的情况下，我们如何向前？需要来自他人的批评！
 说到批评很容易让人想到《人性的弱点》中所倡导的“不要批评他人”观点，也很容易让人浮想“说话的艺术”。我对于批评有着不一样的看法和使用方法！
 首先，我们得对批评的反应调低一点敏感度，不要一听到批评就什么都听不进，甚至出现逻辑混乱地狡辩的状况（比如，人家批评你的是事，但你说人家批评你时的态度不对。其实，只要人家事批评得对，即使态度有点不妥也得包容，可以将之理解为“我做错了而导致别人的情绪”）。其次，碰到批评先深呼吸，之后想一想所批评的问题确实存在吗？在一个讲责任的团队中，批评不光很少出现，一旦出现大家也能平常心面对（注：批评出现多了很可能表明团队管理出现了问题，不作为的事多了。从团队对于批评的态度可以看出这个团队是重面子的还是讲责任的）。在使用批评的方法上，我主张批评的目的不是让人难堪，而是帮助他人改进，在实施批评之前先友好地提醒对方错在什么地方和如何改进。如果友好提醒还解决不了问题，那只能实施批评了。被批评虽让人难过，但也会让人记忆深刻而避免下次再犯同样的错。对于批评的艺术问题我并不想多谈，因为工程师大多很单纯、是非少，只要各自心态摆好真的无需复杂到将批评“艺术化”。
 谈及批评不得不说说表扬。表扬是一种对他人付出的肯定与欣赏，但中国的工程师好象不大擅长使用这种方法去表达自己的情感。我发现表扬很容易出现“礼尚往来”的现象，你今天表扬了别人，过几天可能也会收到对方的表扬回报。这种事情如果在团队出现得多了就很容易带来轻松的氛围，也容易让人体会到自己对于团队的重要性，这样不好吗？
 与表扬相似的是，我们在工作中还可以：当因自己的工作失误而给人带来麻烦时说声“对不起”；获得别人的帮助后道声“谢谢”；向他人咨询问题时用“请教个问题”开头。这些小细节做起来很容易，但对团队建设的贡献却很大！
 出色的团队离不开批评，且是通过表扬而培养的！
 

 质效与习惯
 我在美国工作的（累计）半年时间里，所涉项目周末从未见人加班，即使项目非常紧张依然如此。周末行驶在高速公路上，时不时能看到房车或被拉着的游艇从车旁驶过，很是感叹。人家不加班又何以如此高质效且过着丰富的周末生活呢？
 在软件行业，质量与效率是一个永恒的话题，但却鲜有人真正了解它们从何而来。也往往迷失于SCRUM、CI、ET等诸多方法论中。
 要做到有质效地工作，首先离不开各位承担应有的责任，其次是良好的工作习惯。前者会促使我们持续变得更专业、善于思考和较真，后者则使我们高效，两者一结合质量也随之有了。以我的观点，中国的工程师只要没有将责任和工作好习惯落实好，谈其他的方法论都没用，谈了也白谈。
 说到工作好习惯很容易让人觉得发虚，有点看不见摸不着的感觉。我也一时很难在这说清楚，需要大家在工作中多观察，了解我是如何做和思考的。培养工作好习惯的另一个值得一提的好处是，它有助于杜绝技术问题演变成管理问题，从而使得团队更加轻量和高效。
 精品产品是有气质的，是团队责任与工作好习惯的折射！
 

 最后，过去的一年我们一同收获了不少，在这个伟大的开源项目上工作也让我觉得很有乐趣。谢谢你在碰到问题时主动与我讨论、谢谢你曾经授予我的技术决定权，因为尽管你们有的不说，但我能感受到你对我技术能力的肯定和信任！同时，也谢谢你们曾经给予我的帮助！
 

给2015-2016学年度第一学期《Flash动画设计》通选课全体同学的一封信
 
《Flash动画设计》通选课全体同学：
 
 
你们好！很高兴你们选择此课做为培训兴趣爱好、提高个人技能。本着“公开、透明、负责”的原则，考虑此课的特殊性、专业性，就此课的上课内容、教学风格、考核方法统一解答如下。
 
一、上课时间
 
本学期第二周起始，每周三的第十、十一、十二节。
 
二、上课地点
 
第一、三、五、七次课在教学楼（多媒体教室）235，学习理论知识；其他课次在机房上机310实践。注意，请遵守《机房规定》。
 
三、课堂内容
 
我们讲授的软件版本是Flash CS4。
 
四、考核方式
 
1.中期作业，
 
2.期末考核，
 
五、课程大作业
 
全体同学，必须在第八次课前完成下列作品之一。请在三题目中任选其一。
 
 
注意1，提交多次或提交多个作品时，只算成绩最高者计入总分；
 
注意2，作品首封皮（即第一帧处，时间3s），应包含下列信息：学号、姓名、学院、专业、星座（可省略）、家乡（可省略）；
 
 
注意3，提交的作品请以学号命名，统一格式*.swf；且作品与源文件统一压缩成rar。
 
题目1：我理想中的女朋友（男朋友）；
 
题目2：我的大学生活（或我理想中的大学生活）；
 
题目3：我的家人。
 
 
请同学们早点准备，制作成较好的作品。

 
 
各位 wuhan2020 开源社区成员：
 
2020年1月25日，春节，在这个特殊的日子，我们正式发起了《wuhan2020：武汉新型冠状病毒防疫开源信息收集平台》的开源项目，用开发者们的方式支援这场没有硝烟的战争。截至2020年1月28日21时，全国共有4630个确诊病例、73个治愈病例、以及106个死亡病例，海外60个确诊病例，形势异常严峻。
 
缘起
 
项目之初，我们看到的是，面对突如其来的新型冠状病毒疫情，武汉及周边各市县均爆出物资供给不足的情况，而重大公共卫生事件在公共社会事件中属于较复杂的类型，统筹安排难度大，周期长。而且，目前信息采集与公布平台不一致，信息散乱很难进行有效沟通，大量图片信息不利于实时沟通。
 
作为开发者群体，我们思考的是能否利用数字平台优势，让各供需方进行分布式自助对接可大幅提升效率。故发起该项目，旨在统一收集本次事件中相关事务处理方的信息，并利用开源和分布式协作优势实时更新并通报，提供各方的联系平台。这里，供需数字化和信息的透明快速扭转是我们认为的关键所在。
 
事实上已有相似的石墨文档项目发起，保持在 50 人左右的协同编辑热度，但石墨文档编辑的方式，很难保证格式一致性，需要有专人实时对内容格式进行编辑，各种标注较为混乱，而且对于后期加入程序可视化与交互能力并不友好。正好我们又是一群开源爱好者，故直接在 GitHub 上发起了该项目，望众程序员可以齐心协力，共克时艰。
 
项目功能
 
旨在统一收集本次事件中相关事务处理方的信息，并利用开源和分布式协作优势进行实时更新并通报，提供各方联系的综合平台，其核心是通过公开众包的形式进行采集数据，同样通过众包审核后，将带有数据来源的信息合并到代码仓库中，并形成一套完整的流程机制。
 
在项目初期，其实我们并没有仔细思考整个平台的功能，特别是从产品的角度，这也受限于团队本身。我们首先制定了几件容易想到的事情，包括：
 
存储格式：标准的csv文件
信息主体：医院信息、酒店信息、物流信息、生产信息、捐赠信息、捐款信息、预防治疗手段、新闻内容等
信息实时录入功能
部分可视化与信息查询界面
外部数据汇集：微博、头条、搜索引擎信息等
 
在项目开始实施后，我们开始遇到了一些问题，同时也总结了部分经验，具体如下。
 
遇到的挑战
 
工作量大，累成狗，很多信息需要挨个打电话落实
网上流传的有些信息被篡改，不知道群里的数据本身是不是被篡改
我验证的信息，别的小分队、组织也在验证，重复劳动
甚至有个硬要求：只把官方发布的数据算进去
医院内部的信息可能数据贡献者跟发布者没有同步
数据的时效性无法保障
如何避免跟其他群或者组织重复验真
如何将其他组织的数据变成可信任的数据源
信息收集渠道不统一，多种工具同时在用
 
总结的经验
 
流程、流程、流程：流程是规范大家行为，保证每个人的行动一致、结果的偏差小
数据输入和验证漏斗：搜集—验真—录入—发布
与公开信息交叉验证
医院汇总人员直接录入，可信程度最高，同时带上录入员信息
 
重新顶层设计
 
基于上述挑战和经验，我们重新进行了顶层设计，并把中心放在标准的流程和标准的录入规范上面，同时继续用石墨工具进行统一信息采集。这里要重点提一下石墨团队，直接拉了主力开发人员协助我们进行数据接口的对接。探索中，我们逐步形成了如下的协作流程：
 

 
持续更新，以Github上的为准
 
目前我们设计的《信息协作流程规范》中，信息流程如下：
 
石墨表格 --> Git 数据仓库 --> 前端展示
 
其中，石墨流程包括：
 
任何人可以填写申请表单，获得某类信息的录入权限
信息录入有格式要求，通过石墨公式进行强校验
录入信息需要有源链接，提供有效的数据校验能力
审核人有严格的制度，审核人信息实名落地，保证不会有恶意审核
石墨文档中，申请并通过的账号有录入权限，但表头与审核状态列只有审核人可以编辑
审核人在审核确定某条记录真实后，会锁定该行，不能再进行编辑
对于数据重复校验，使用石墨的重复数据自动高亮功能提示，并提供脚本的定时检查能力
 
数据落仓包括：
 
石墨数据可以自动化落入 Git 数据仓库
通过配置方式决定哪些文档数据可以落仓
落仓时仅落入已经审核通过的数据，未通过数据不予落仓
落仓无需二次校验，直接推入数据仓库
落仓由程序自动化进行，保证数据实时性不会高于 15 分钟的误差
落仓时会进行额外的数据预处理，方便后续处理
对于特定行，例如特定医院记录，邀请联系人成为该行数据编辑人，仅能编辑本医院条目，其他类别类似
 
数据展示包括：
 
数据仓库包含各种数据类型的实时数据
任何开发者可自行开发可视化展示、检索、分析程序，直接使用线上数仓数据
 
通过以上流程，采取分组制，流水线作业，好处是：
 
操作行为可控，能收敛
严格用核心成员保证审核人的来源，保证了数据录入有效性，所有数据必须经过实名审核员审核
保证自动化程度，保证后期的大规模水平扩展能力，除数据审核外全流程数据落地全部自动化，无需人工介入
保证数据有效性，数据审核后锁定，除数据源负责人，无人可进行修改
保证数据时效性：该条需要该平台首先成为唯一数据源平台，则数据源负责人在需求变动时仅需修改表单对应行即可
数据是实时变化的，而且由于使用的是 Git 数仓，其实我们可以拿到所有的历史变化记录，便于数据分析工作
 
基于上述思想，我们形成了《信息收集录入流程规范》，录入组必须遵循这样的规范才能录入信息；同样，我们也形成了《信息审核流程规范》，审核员也必须按照该规范才能进行数据落仓。
 
我们希望通过自动化手段来聚集数据，当其成长为主要平台时，各数据源自然会来我们这里发布和修改数据，而我们的四层权限体系也保证了数据的真实有效。当然最重要的全流程的自动化，以保证在水平扩展时不会导致人力成本爆炸。我们技术团队的主体来自高校的老师和学生，集中在计算机专业和数据分析专业，全流程管理和自动化一开始就都在考虑之列的。
 
我们的初衷是帮助整合信息，让大家能够快速获取有效实时的数据和信息，这个初心是不变的。我们同时也还有自己的学业和事情，也不是非要做成一个重要的项目，如果有别人做的比我们好，自然是应该学习的，但如果我们觉得我们的方式更好，那我们就应该坚持做下去再看结果，这就是开源的核心所在。
 
长远看，我们的项目可以快速发展，对接任意数据源、任意数仓、任意数据格式，三个解耦，使得其有很好的扩展能力。最理想的情况是，官方直接用我们的数据平台进行数据录入，即保证了高效性，也保证了数据的真实性。当然，这需要我们共同来努力，使其成为一个最有影响力的平台，直接的信息源实名录入，是我们最想看到的结果。
 
基于上述思想，项目目前的形态架构大致是下面这个样子（并不严谨版）：
 

 
持续更新，以Github上的为准

 
中间的三个规范是我们最重要的核心，也是希望能够持续迭代成为全网标准，目前共包括三个规范：《信息协作流程规范》、《信息收集录入流程规范》、以及《信息审核流程规范》，相信随着项目的不断推进，还会有更多更加细致的规范出来。
 
最下面一层是我们整个开源社区目前正在使用的基础设施。其中GitHub和码云用来做开发协作与数据落地，出于数据安全的考虑，最终的数据落地会是在码云平台上，协作流程目前还是在GitHub上的原因是GitHub的协作生态要好太多（懂的人自然懂），特别是集成了我们自己的协作机器人Hypertrons。当然，后续也不排除某个合适的时间，我们也同时支持码云平台的协作。Slack是我们开发者日常交流通信的工具，即ChatOps，为什么不用微信，同样也是懂的人自然懂，类似Slack这样的工具对于开发者来说太重要，大家可以多尝试。
 
而对于非技术人员来说（信息采集、审核、宣传、协调等），则主要是通过石墨文档来进行信息采集与审核，通过微信来进行日常的沟通交流。也正是因为此，我们逐渐形成了多个小分队，并实行组长责任制。
 
最上层是基于本项目落地的数据平台的各种应用，包括数据门户、数据可视化、数据同步等，相信随着项目的推进，还会有更多有意思的应用出现。
 
 
 
持续更新，以https://github.com/wuhan2020为准
 
社区组织
 
wuhan2020开源社区目前包括如下几个组：
 
技术组：项目工程技术实时团队，目前主要通过Github + Slack进行协作；
信息组：目前主要负责信息的收集与录入，主要工具为石墨文档；
协调组：协调几个小组之间的协同与协作。
 
这是最开始形成的三个核心小组，到了第三天和第四天，我们又形成了三个新的小组：
 
宣传组：对项目进行宣传，包括品牌的建设，文案、设计等宣传资料的制作，以及渠道的拓展；
审核组：根据审核规范对录入的信息的真实性进行审核；
风控组：对项目整体风险进行控制，包括信息安全风险、合规性等方面。
 
之所以增加风控组，我们认为除了数据的真实性，数据的安全性问题同样重要，合法合规同样是我们必须遵守的，也请所有正在做贡献的朋友们引起重视。因此，再次声明一下：本项目所收集的数据均是通过正规渠道通过公开众包的形式进行采集的，通过众包审核后，均附有数据来源，项目本身的核心是提供一套流程机制和规范，尽量发动志愿者、合作方、甚至是官方来进行数据采集的动作，并且坚持知情同意的原则。
 
在上面工作小组的基础之上，我们形成了《wuhan2020入组工作攻略》，这样，新来的朋友们可以更具自己的特长，选择加入的工作组进行工作，包括加入渠道，小组负责人等信息。
 
关于开源
 
最后再来聊聊开源的一些事情。开源首先是我们团队的专业技术爱好和一种高效工作方式的共识。而在当下这个灾难场景下又有一层特别的含义，那就是数据开源。我们认为，正是因为相关部门数据的不开放、流转不透明，才导致了今天这样一个困局。而数据的使用方式也应该是开源的，这就涉及到软件开源了，不仅是使用方式，整个软件的构建过程也同样应该开放透明，这就是协作开源了。短短的几天，我们已经深刻体会到这种开发模式的威力，正所谓开源界一天，IT界一年。我想整个社区的开发者也会慢慢有我们类似的体会。而且会由量变带来质变，那就是公平度与自由度！
 
今天，得益于全人类共同的实践成果，使得我们能够以一个更加平等的方式重新组织社会、重新安排生活。这种组织与安排不仅发生在我们的现实社会中，还进一步渗透到了我们的数字空间中，并通过互联网进行了放大与加深。
 
今天的开源界，非常像当年的美洲新大陆。广大的开发者们正在共同开拓一个新的开源数字生态，而发源于计算机工程领域的开源正在从专业领域走向普通大众、从技术工程走向科学想象、从社区治理走向与社会科学与人文科学的结合，甚至需要进行人类学式的文化研究。
 
我们希望这个开源项目与开源社区，承载的不仅仅是这次肆虐的病毒抗争，同时还是一次开源社会实验，通过聚集全球的协作者，形成共识，战胜苦难，解决全人类所面临的难题。
 
 
 
wuhan2020开源社区共同体
 
2020年1月28日
 
 
 
相关文档：
 
《wuhan2020入组工作攻略》：
 
https://shimo.im/docs/tQ8Phx3KdgkHDR8y/read
 
《信息收集录入流程规范》：
 
https://shimo.im/docs/v3xCCYVWhtHvq9w8/read
 
《信息审核流程规范》：
 
https://shimo.im/docs/jRQdGwqjwdPVqJpG/read
 
相关阅读 | Related Reading
 

 
感谢所有支持wuhan2020项目的朋友！我们招唤更多人加入！
 

 
wuhan2020：武汉新型冠状病毒防疫开源信息收集平台
 

 
开源社恭祝大家新年快乐
 

 
    
 
     
给计算机专业学生的一封信    
 
     

 我始终认为，对一个初学者来说，IT界的技术风潮是不可以追赶的，而且也没有能力去追赶。我时常看见自己的DDMM们把课本扔了，去卖些价格不菲的诸如C#, VB.Net 这样的大部头，这让我感到非常痛心。而许多搞不清指针是咋回事的BBS站友眉飞色舞的讨论C#里面可以不用指针等等则让我觉得好笑。C#就象当年的ASP一样，“忽如一夜春风来，千树万树梨花开”，结果许多学校的信息学院成了“Web 学院”。不少大学生都去做Web 了。当然我没有任何歧视某一行业的意识。我只是觉得如果他们把追赶这些时髦技术的时间多花一点在基础的课程上应该是可以走得更远的。 
 
 几个误区 
 　 
 初学者对C#风潮的追赶其实也只是学习过程中经常遇到的几个误区之一。我将用一些实际的例子来说明这些现象，你可以按部就班的看看自己是不是属于其中的一种或者几种： 
 
 认为计算机技术等于编程技术: 
 
 有些人即使没有这个想法，在潜意识中也有这样的冲动。让我奇怪的是，许多信息学院的学生也有这样的念头。认为计算机专业就是编程专业，与编程无关的，或者不太相关的课程他统统都不管，极端的学生只要书上没带“编程”两个字他就不看。 
 
 其实编程只是计算机技术应用过程中一种复杂性最低的劳动，这就是为什么IT业最底层的人是程序员（CODER）。计算机技术包括了多媒体，计算机网络，人工智能，模式识别，管理信息系统等等这些方面。编程工作只是在这些具体技术在理论研究或者工程实践的过程中表达算法的过程。编程的人不一定对计算机技术的了解就一定很高。而一个有趣的现象是，不少大师级的计算机技术研究者是不懂编程的。网上的炒作和现实中良好的工作待遇把编程这种劳动神秘化了。其实每一个程序员心里都明白，自己这些东西，学的时候并不比其它专业难，所以自然也不会高档到哪里去。 
 
 咬文嚼字的孔已己作风: 
 
 我见过一本女生的《计算机网络原理》教材，这个女生像小学生一样在书上划满了横杠杠，笔记做得满满的，打印出来一定比教材还厚。我不明白的是，像计算机网络原理这样的课程有必要做笔记？我们的应试教育的确害了不少学生，在上《原理》这一类课程的时候许多学生像学《马列原理》一样逐字背诵记忆。这乃是我见过的最愚蠢的行为。所谓《原理》，即是需要掌握它为什么这样做，学习why，而不是how（怎样做）。极端认真的学生背下以太网的网线最大长度，数据帧的长度，每个字段的意义，IP报头的格式等等，但是忘了路由的原则，忘了TCP/IP协议设计的宗旨。总之许多人花了大量的时间把书背得滚瓜烂熟却等于什么也没学。 
 
 在学习编程的时候这些学生也是这样，他们确切的记得C++语法的各个细节。看完了C++教程后看《Thinking in C++》（确实是好书），《Inside C++》，《C++ reference》，this C++, that C++……，然后是网上各种各样的关于C++语法的奇闻逸事，然后发现自己又忘了C++的一些语法，最后回头继续恶补…。有个师弟就跟我说：“C++ 太难了，学了这里忘了那里，学了继承忘了模板。”我的回答道：“你不去学就容易了”。我并没有教坏他，只是告诉他，死抠C++的语法就和孔已己炫耀茴香豆的茴字有几种写法一样毫无意义。你根本不需要对的C++语法太关心，动手编程就是了，有不记得的地方一查MSDN就立马搞定。我有个结论就是，实际的开发过程中对程序语法的了解是最微不足道的知识。这是为什么我在为同学用Basic（我以前从没有学过它）写一个小程序的时候，只花了半个小时看了看语法，然后再用半个小时完成了程序，而一个小时后我又完全忘记了Basic 的所有关键字。 
 
 不顾基础，盲目追赶时髦技术： 
 
 终于点到题目上来了。大多数的人都希望自己的东西能够马上跑起来，变成钱。这种想法对一个已经进入职业领域的程序员或者项目经理来说是合理的，而且IT技术进步是如此的快，不跟进就是失业。但是对于初学者来说（尤其是时间充裕的大中专在校生），这种想法是另人费解的。一个并未进入到行业竞争中来的初学者最大的资本便是他有足够的时间沉下心来学习基础性的东西，学习why 而不是how。时髦的技术往往容易掌握，而且越来越容易掌握，这是商业利益的驱使，为了最大化的降低软件开发的成本。但在IT领域内的现实就是这样，越容易掌握的东西，学习的人越多，而且淘汰得越快。每一次新的技术出来，都有许多初学者跟进，这些初学者由于缺乏必要的基础而使得自己在跟进的过程中花费大量的时间，而等他学会了，这种技术也快淘汰了。基础的课程，比方数据结构，操作系统原理等等虽然不能让你立马就实现一个linux（这是许多人嘲笑理论课程无用的原因），但它们能够显著的减少你在学习新技术时学习曲线的坡度。而且对于许多关键的技术（比方Win32 SDK 程序的设计，DDK的编程）来说甚至是不可或缺的。 
 一个活生生的例子是我和我的一个同学，在大一时我还找不到开机按纽，他已经会写些简单的汇编程序了。我把大二的所有时间花在了汇编，计算机体系结构，数据结构，操作系统原理等等这些课程的学习上，而他则开始学习HTML和VB，并追赶ASP的潮流。大三的时候我开始学习Windows 操作系统原理，学习SDK编程，时间是漫长的，这时我才能够用VC开发出象模象样的应用程序。我曾一度因为同学的程序已经能够运行而自己还在学习如何创建对话框而懊恼不已，但临到毕业才发现自己的选择是何等的正确。和我谈判的公司开出的薪水是他的两倍还多。下面有一个不很恰当的比方：假设学习VB编程需要4个月，学习基础课程和VC的程序设计需要1年。那么如果你先学VB，再来学习后者，时间不会减少，还是1年，而反过来，如果先学习后者，再来学VB，也许你只需要1个星期就能学得非常熟练。 
 几个重要的基础课程 
 　 
 如果你是学生，或者如果你有充足的时间。我建议你仔细的掌握下面的知识。我的建议是针对那些希望在IT技术上有所成就的初学者。同时我还列出了一些书目，这些书应该都还可以在书店买到。说实在的，我在读其他人的文章时最大的心愿就是希望作者列出一个书单。 
 
 大学英语－不要觉得好笑。我极力推荐这门课程是因为没有专业文档的阅读能力是不可想象的。中文的翻译往往在猴年马月才会出来，而现在的许多出版社干脆就直接把E文印刷上去。学习的方法是强迫自己看原版的教材，开始会看不懂，用多了自然熟练。吃得苦下得狠心绝对是任何行业都需要的品质。 
 
 计算机体系结构和汇编语言－关于体系结构的书遍地都是，而且也大同小异，倒是汇编有一本非常好的书《80x86汇编语言程序设计教程》（清华大学出版社，黑色封面，杨季文著）。你需要着重学习386后保护模式的程序设计。否则你在学习现代操作系统底层的一些东西的时候会觉得是在看天书。 
 
 计算机操作系统原理－我们的开发总是在特定的操作系统上进行，如果不是，只有一种可能：你在自己实现一个操作系统。无论如何，操作系统原理是必读的。这就象我们为一个芯片制作外围设备时，芯片基本的工作时序是必需了解的。这一类书也很多，我没有发现哪一本书非常出众。只是觉得在看完了这些书后如果有空就应该看看《Inside Windows 2000》(微软出版社，我看的是E文版的，中文的书名想必是Windows 2000 技术内幕之类吧)。关于学习它的必要性，ZDNET上的另一篇文章已经有过论述。 
 
 数据结构和算法－这门课程能够决定一个人程序设计水平的高低，是一门核心课程。我首选的是清华版的（朱战立，刘天时）。很多人喜欢买C++版的，但我觉得没有必要。C++的语法让算法实现过程变得复杂多了，而且许多老师喜欢用模块这一东西让算法变得更复杂。倒是在学完了C版的书以后再来浏览一下C++的版的书是最好的。 
 
 软件工程－这门课程是越到后来就越发现它的重要，虽然刚开始看时就象看马哲一样不知所云。我的建议是看《实用软件工程》（黄色，清华）。不要花太多的时间去记条条框框，看不懂就跳过去。在每次自己完成了一个软件设计任务（不管是练习还是工作）以后再来回顾回顾，每次都会有收获。 
 
 Windows 程序设计－《北京大学出版社，Petzold著》我建议任何企图设计Windows 程序的人在学习VC以前仔细的学完它。而且前面的那本《Inside Windows 2000》也最好放到这本书的后面读。在这本书中，没有C++，没有GUI，没有控件。有的就是如何用原始的C语言来完成Windows 程序设计。在学完了它以后，你才会发现VC其实是很容易学的。千万不要在没有看完这本书以前提前学习VC，你最好碰都不要碰。我知道的许多名校甚至都已经用它作为教材进行授课。可见其重要。 
 
 上面的几门课程我认为是必学的重要课程（如果你想做Windows 程序员）。 
 
 对于其它的课程有这样简单的选择方法：如果你是计算机系的，请学好你所有的专业基础课。如果不是，请参照计算机系的课程表。如果你发现自己看一本书时无法看下去了，请翻到书的最后，看看它的参考文献，找到它们并学习它们，再回头看这本书。如果一本书的书名中带有“原理”两个字，你一定不要去记忆它其中的细节，你应该以一天至少50页的速度掌握其要领。尽可能多的在计算机上实践一种理论或者算法。 
 
 你还可以在CSDN上阅读到许多书评。这些书评能够帮助你决定读什么样的书。 
 
 日三省乎己　　　　 
 每天读的书太多，容易让人迷失方向。一定要在每天晚上想想自己学了些什么，还有些什么相关的东西需要掌握，自己对什么最感兴趣，在一本书上花的时间太长还是不够等等。同时也应该多想想未来最有可能出现的应用，这样能够让你不是追赶技术潮流而是引领技术潮流。同时，努力使用现在已经掌握的技术和理论去制作具有一定新意的东西。坚持这样做能够让你真正成为一个软件“研发者”而不仅仅是一个CODER。 
 
 把最多的时间花在学习上 
 这是对初学者最后的忠告。把每个星期玩CS或者CS的时间压缩到最少，不玩它们是最好的。同时，如果你的ASP技术已经能够来钱，甚至有公司请你兼职的话，这就证明你的天分能够保证你在努力的学习之后取得更好的收益，你应该去做更复杂的东西。眼光放长远一些，这无论是对谁都是适用的。 
 
 相信你已经能够决定是否学习C＃或者什么时候去学它了。