- 勤奋——根据 10000 小时原理，即时每天花费8小时，每周休息两天，也需要近五年时间才能达到“熟练”。
- 严谨——对待代码、问题一丝不苟，不能得过且过，“just working”绝对不能成为评判标准。
- 主动——对于不知道或不理解的问题，一定要主动查找资料、询问他人，敢于探求原理，不要满足于黑盒状态，但也不要对某个细节过于执拗、搞错重点。
在求是潮，或者可能是在你的整个计算机职业生涯中，自学都是非常重要的一环。 在学校里，计算机的专业课多是算法、数据结构、操作系统、体系结构之类的基础 课，除了教授给你计算机的这些基础知识以外，更重要的是训练学习能力，以便你 能够迅速掌握新的知识。对于千奇百怪的编程语言（尤其是动态语言）、日新月异 的专门开发技术、开发软件和开发方法这些东西，一般认为是没有必要成为一门课 的，而一个合格的CS学生（或者说是程序员）都应该能够靠自学迅速掌握这些。
在一开始，我们会“引导”着你进行自学，提供一个方向以及一些指导或相关资料， 不过在今后的日子里，还是需要逐渐拜托对“指导者”的依赖。希望最终我们能够一 起“交流”，而非“指导”。
自学的最重要手段就是阅读。除非有特殊需求，一般不推荐观看视频，尤其是在学 某一具体的语言和技术时。主要原因是大多数视频主要面向完全零基础的初学者 （尤其是国人录制的PHP相关教学视频），质量参差不齐，并且视频教学比较难以 自己控制学习进度。另一方面，今后学习一些更新的技术时，很难找到视频讲解， 倘若养成了“视频依赖”对今后发展不利。
阅读材料主要有两大类：教程（tutorial）和文档（doc/manual）。前者常以类似 书籍的形式出现，适合快速入门；后者主要指的是官方的文档、手册，特点是细致、 权威、更新及时，当需要查询某一具体特性时，应当选择这个。如果希望对某一 技术真正的“精通”，那么通读（扫读）一遍官方手册也是有必要的。
关于阅读材料语言的选择，还是要推荐尽量选择英文资料，除非该文档一开始就是 用中文编写，主要有以下原因：
- 中文文档一般由英文文档翻译而来，可能存在翻译错误、落后等问题。
- 英文资料的基数大，更容易出现优秀的作品，国内的高手们在撰写重要技术 文章时也会选择使用英文。
- 所有通用的技术一定有英文文档，只有在国内比较热门的才会有中文翻译； 即使有翻译也仅限于官方手册之类，一些博客文章、论坛问答等补充资料不会 有中文翻译。所以学会阅读英文文档是十分重要的。
- 技术文档所使用的其实是“计算机英语”，语法平直简单，少数专业名词也是 程序员应当掌握了解的，所以只要静下心、沉住气去读，凭借大家能考过四六 级的英语水平，肯定是没有问题的。
- 充分的阅读是表达的基础，日后倘若遇到问题需要和他人甚至是原作者讨论， 英语是最佳的工具，一口蹩脚的英语以及一句“Sorry for my poor English” 会让沟通变得困难许多。
首先，对于技术文档，请使用 Google 而非百度，并尽量使用英文关键词。 即使是中文关键词，“更懂中文”的百度也并不能“更懂技术”。具体原因就不多 做解释了，和百度饱受诟病的唯利是图的排序算法、中英文材料的质量差距、 爬虫的索引广度都有关系。
至于 Google 访问困难的问题，有 smarthosts 以及各种翻墙方法的帮助，自己搞定。
尽管各大搜索引擎都在加强对自然语言识别的投入，希望用户能够“自然”地获取 答案，但就现阶段来看，搜索引擎对于完整问句的识别仍然不尽如人意，尤其是 中文。使用问句的直接结果就是，你可能会得到一堆类似“百度知道”、“XX论坛” 这样低质量的搜索结果（下文会提到）。
参看国外优秀的技术问答社区 Stack Overflow ， 即使是“问答”社区，其中大部分的问题都是以简短的非完整句表述的，大量使用 祈使句和分词、不定式结构，看看这儿的问题你就会对怎样使用英文描述一个问题 有一个感性的认知。
那么，怎样才是好的关键词呢？其实“关键词”这个说法本身就已经很能说明问题了， 尽量选择能够贴切描述问题的“词语”（或短语）而非句子。
至于如何算是“贴切”，判断标准是是否包含了能够将这个问题和其他类似问题区别 开来的关键信息，例如系统死机蓝屏时，直接搜索“Windows 蓝屏”无疑是非常糟糕 的选择，搜索“Windows 7 蓝屏”就要好一些（当然原因是 Win7 比较少蓝屏）。最 好的办法是记下蓝屏时的提示信息（尤其是错误代码），甚至有能力的话，翻看系 统日志和dump，这样便能比较准确地查到想要的结果了。
对于编程时遇到的问题，编译/运行错误、函数名等等都是比较好的搜索关键词。
选择以下结果：
- 选择靠前的结果（指的是 Google 中靠前的结果）。
- 选择较新的结果，尤其是对于更新很快的技术（对于博客文章， Google 搜索 结果中直接可以看到发表日期）。
- 官方信息是最好的（包括官方文档、官方论坛和 bug tracker ）。
- 其他优秀来源包括：IBM/Microsoft/Mozilla/... Developer Network、 StackOverflow、Github。
- 一般来说也比较好的来源还有：独立博客（英文为佳）、Blogspot博客等。
（注意，某些结果可能需要翻墙访问。）
不要选择这些结果：
- 百度知道及一些国内小论坛（尤其是XX初学者论坛）。
- 文中包含代码但没有代码高亮（一般情况下这表面作者水平有限或为转载）。
- 直接给出一两句话的操作方法或代码，没有给出任何解释说明。
- 百度博客、QQ空间中的文章。
当你遇到通过阅读文档、搜索都无法解决的问题时，你可能碰到麻烦了。一般来说， 如果一个问题花费了一个小时仍然没有进展，你一定要考虑向别人提问了。
你的首选提问者当然就是我们，如果我们也无法解决，你可能需要在互联网上向他人 （有时候甚至是开发者）提问。提问的首选方式是文字，因为它能准确地包含所需要 的信息（以及避免拼写错误提示的尴尬），必要时还可配上截图等。使用文字还迫使 你在提问之前自己先将问题认真思考一遍，才能表述清楚。有些时候，在重新整理、 描述的过程之中，问题就得到了解决！另外，文字还可使回答者能够有宽裕的时间阅 读及查找相关资料。至于沟通工具，邮件是最好的选择。
不管是向我们还是向其他什么人提问，请切记：同使用搜索引擎时一样，把问题准确 地表达清楚，提供尽可能多的信息，节省对方的时间，尽量不让对方再向你索要信息。
这里有一篇开源教父、著名黑客 Eric S. Raymond 所写的“提问的智慧”的中文版， 请一定仔细阅读：
邮件是技术工作者的首要联系方式。请尽快注册并确定一个长期使用的邮箱，尽量选择 Gmail 、Hotmail 等有保障的国际邮箱服务，以避免出现丢新等情况。确定邮箱之后， 请在你的智能手机上设置好推送功能。收到邮件后，如果不能在一小时内处理，也应该 先回复一个“收到，稍后处理”。要做到邮件和短信拥有同等优先级和及时性，不要让别 人在发送邮件后再短信提醒你“邮件已发”。
请使用一个标准的邮件客户端，以避免出现编码问题（乱码）。若你使用的是中文版的 Outlook 等（或 QQ 邮箱网页版），请更改你的默认回复设置，使用 “__Re: __” 打头， 不要使用中文的“回复”，因其可能在某些客户端下存在兼容问题，并会使外国人很困扰。
请使用有意义的邮件标题，不要使用“一封信”甚至是空标题。
最后提一下邮件列表，邮件列表是这样一个服务：它存储了一串邮箱地址，并拥有一个 自己的地址，向这个地址发邮件会导致邮件被自动发给列表中的所有邮箱地址。在没有 论坛以前，邮件列表就起到了讨论串的功能。即使是有了网页版论坛的现在，邮件列表 独特的优势而仍然在技术圈中广为使用。请阅读以下链接，对其礼仪有一个大概的了解， 但不必100%遵照执行，因为每个邮件列表都有一些自己的偏好。
Issues 和 Bug Tracker 其实非常相像，硬要说区别的话，前者用途更广一些，后者则 专注与跟踪代码 Bug 。由于我们内部使用的是 Gitlab ，之后的工作中你将会频繁接触 到 Issues 。它既是提交 Bug 的渠道，也可以作为 TODO List 或 Wish List ，甚至 还可以向开发者提问。在 Github 这个“代码社交”平台上， Issues 的作用得到了充分 的发挥。
以下给出了一些编写代码时的常见注意事项，有些东西仅仅是一个关键词，希望大家 自行搜索；有些东西则是一个“概念”，大家不妨先有个印象，日后就会逐渐理解。
- 统一是最重要的！不要固执己见，听从团队安排。
- 缩进：常用的有 TAB 缩进（具体宽度由编辑器设置决定）、4空格或8空格缩进
- 命名：全大写命名法（常量名）、驼峰命名法（对象方法名）、全小写下划线命名 （全局函数名）、首字母大写（对象名）……请尽量遵照所使用的语言及框架的惯例 （convention）。尽量不要使用拼音，尤其是拼音缩写！
- 注释：公开方法一定要有接口说明，使用了精妙的技巧或有需要注意的地方也应加 注释，待实现处应加上“TODO”便于搜索。很少有开发者会加“太多”注释，所以尽管 多加一些吧！
- 不要单步调试！（很多脚本语言也难以单步追踪。）
- 多静态查错（阅读、检查代码），对有疑义的地方进行有针对性的调试。
- 增加调试代码时一定要小心，采取相应措施避免其出现在最终生产环境中。
一句话——永远不要相信用户！不同于竞赛，再也没有“给定的输入格式”。
明确每一步自己在做什么，确保对用户输入进行了必要的过滤（包括 SQL 过滤和 HTML 转义等）。尤其是在你使用某些“框架”的时候，请确保你知道这个框架做了 什么、在什么地方做了，以防止出现“漏网之鱼”。