定位

还记得当初为什么选择程序员这个职业么？如今程序员所在的行业处于发展上升期，薪酬待遇整体高于传统行业，所以各类程序员培训机构如雨后春笋，流水线般的为各类只差程序员的公司批量供应，这样的批量生产似乎有点把程序员当成了工厂的工人。

而程序员的工作实际更贴近于工匠，既有创造性的工艺性工作，也有模式化的工程性工作。想清楚自己成为程序员的初衷是什么？只是为了进入一个相对高薪的行业，得到一份工资高于平均水准的工作？这样终究是走不了太远的。

很多入门程序员都是刚从学校毕业的，曾记得在吴多益（@nwind）的一篇工程师成长分享的材料上，如是说：

从小到大的教育，我们习惯性被安排：“课后作业是 X1、X2，后天必须交”，“本学期的必修课有 XX、YY，必选的选修课有 ZZ、WW”
十几年来你都是这样度过的，但现在你已经不在学校了，你要安排你的未来。

刚入职场的程序员依然保持这个习惯，等着主管安排，工作就是完成主管安排的任务吗？好吧，这只是工作的一部分。如果你每天的工作就只是完成被安排好的任务，那么你自己的成长就会非常的慢，因为主管安排任务并没有那么多的精力来考虑任务是否适合个人的成长发展。这些任务是组织发展的需要，而不一定适合个人的发展，但组织是付了薪酬来让你完成任务的，所以这是工作的必需部分。

自己才是职业生涯的管理者，想清楚自己的发展路径：远期的理想是什么？近期的规划是什么？而今日的任务和功课又是什么？今日之任务或功课哪些有助于近期之规划的实现，而近期之规划是否有利于远期之理想？

今日除了任务为什么还有功课？功课是学校里的概念，职场里没有。所以离开学校进入职场的功课都是自己给自己安排的。任务来自主管的安排，功课来自自己的安排。很多时候我们只去完成任务却从未给自己安排功课，而等着被安排和主动安排，在未来将产生巨大的差别。

一开始我们可能只有模糊的远期理想，也没那么清晰的近期规划，但一定要有足够清晰明确的今日任务和功课，即使在你的主管因为各种原因没给你安排的情况下。方向不太可能一朝定好，就不管不顾埋头走路。需要定期检视，抬头看路，因为如今环境和大势的变化也是很快。在边走边看的过程中逐步就清晰了近期的规划甚至远期的理想。而主管在你职业发展的路上，除了大部分时候给你安排任务，偶尔也可能给你创造机会，而机会出现时你能否抓住，全在今日功课上。

学习

在《浪潮之巅》一书中，吴军博士写道：

国内: 小时候努力，到大学后就不努力了
国外: 到大学后才开始努力，很快就超过国内学生

这反应了我们教育中作为学生的一种心态，觉得毕业了离开学校了就不需要多努力学习了。但程序员这个职业所面临的技术发展和更迭远超其他行业，你即便只是为了能够保质保量的完成任务，就需要保持持续学习。

而且在面临信息和技术爆炸的时代，还要有选择性的学习。我读大学那阵，学程序期间喜欢电脑，就爱帮同学 DIY 装个机什么的，而且还反复折腾安装操作系统。那时的 Windows 系统的特点就是越用越慢，一年半载需重装一次就又恢复了，但这些折腾其实都不属于程序员的学习范围（题外话：如今用 Mac 再也不浪费精力操心装系统的事了）。

而有选择性的学习在于需要找出真正与你近期规划有关的学习路径。假如你工作入职后公司使用 Java 为主要开发语言，而大学里你一直学习使用 C 或 C++ 编程练习。这里再假设你对计算机相关的基础性学科和知识掌握良好，比如：操作系统、数据库、网络、组成原理、编译原理、算法基础、数据结构等等。那么为了更好的完成工作任务，就需要学习 Java 编程语言、技术相关的东西。

对于学习语言本身我觉得最高效的方法就是看一本该领域的经典入门书，比如对于 Java 就是 Thinking in Java，这是我称为第一维度的书，聚焦于一个技术领域讲得透彻清晰。在有了该语言的一些实际编程和工程经验后就可以看一些该领域第二维度的书，比如：Effective Java，The Art of Unix Programming 这是聚焦于特定领域经验总结型的书。

而另外一些像 Java 开发需要大量使用开源框架又该如何学习？微爱 CTO 张铁蕾同学曾写过一篇《技术的正宗与野路子》 里面介绍了如何用真正「正宗」的方式去学习并快速掌握这些层出不穷的开源新框架和技术。

借用张铁蕾同学原文里的一张图，每一项开源框架或技术相关的信息可以组织成上面这张金字塔结构图。Tutorial 和 API Reference 层次的信息资料帮助我们快速上手开发，而 Spec 和 Code 帮助我们深刻理解这门技术。而其他相关的技术书籍和文章其实是作为一种补充阅读，好的技术书籍和文章应该有官方资料中未涵盖的特定经验或实践才算值得一读。更多学习的细节建议大家直接看上面这篇原文吧。

自省

乔治·海尔迈耶（George Heilmeier，1936-2014），一位美国工程师、技术管理者。他是液晶显示技术的主要发明者之一。他在科研领域最著名的事情就是他提出的「海尔迈耶系列问题」：

你要做什么？不要用术语，清晰的表述你的目标。
这件事现在是怎么做的？现在的做法有什么局限？
谁在关心？你的方法有哪些创新？你为什么觉得你的方法能够成功？
如果你的方法能够成功，它能带来怎样的变化？
你的方法需要花多少钱？需要花费多少资源？要怎样在过程中和结束进行评估？

我觉得用在学习成长上也有异曲同工之妙，因为现在的技术方向和路线太多，即使选定了路线依然会有很多茫然，有时我们想要学习一门新技术或在项目中引入一项技术，就可以试试套用「海尔迈耶系列问题」来自省一番。

• 你学习这门技术的目标是什么？
• 这个技术现在是怎么做的？有什么局限吗？
• 这个技术有什么创新之处，为什么它能够取得成功，要是在项目中引入这个技术，谁会关心？
• 如果它能成功，会给我们带来怎样的变化？
• 采用这门技术的成本、风险和收益比如何，我需要花费多少资源（时间、金钱），如何去评估它的效果？

程序员有时粗浅的学习并了解了一点新技术，就想着如何应用到真实的项目中。用上面的问题来问问自己，如果有回答不上来的，说明你对这门技术掌握并不充分，那就还不足以应用到实际项目里。

多维

有些程序员写了两年代码觉得太枯燥就想着是不是可以转管理，比如转技术主管之类的。李笑来老师也曾写过一篇文章《从平庸走向卓越的最佳策略》，里面提到的最佳策略就是：“多维度打造竞争力”。从技术到管理似乎就是一条多维度的发展路径，是这样吗？

但是，李笑来老师那篇文章的策略有个前提就是先要在一个维度做到足够突出，用 100 分作为满分评价的话，在一个维度上需要达到 95 分。而这个足够突出的维度，实际上就是你现在赖以生存的维度，又称基础维度，这是其他维度得以发展的根基。

所以，若你真想在程序员这条道路上从入门到精通，选择了这个维度作为基础维度，就需要不断在这个维度去精进。有一本书叫《程序员修炼之道：从小工到专家》 和本文的主题很类似，只是写作的维度更贴近细节。这本书中文版最早出版于 2004 年，而英文版可能还要早两年，已经十多年了。我查了下豆瓣书评，一共三个版本加起来才 2000 多条，可见十多年来读过的人确实不多。

关于本书，最好的评价来自 Ward Cunningham：

本书美之所在：它体现它的哲学，以如此谦逊的方式。
本书的哲学将渗入你的意识，并与你自己的哲学交融在一起。
它不鼓吹，它只是讲述什么可行。
但在讲述中却又有更多的东西到临，我们有时称之为「无名的品质」（Quality without a name）

我刚工作那年读了一遍，其实领悟很少；工作第六年又读了一遍，感觉好多共鸣之处；最近思考本文主题时又想起这本书却发现记不起细节了，于是又读了一遍；这回我终于学会了如何强力研读一本书，写了满满的读书笔记和批注，发现很多道理和路径这本书里都详细的解释了，而且神奇的是十多年来除了书中提及的一些举例用的技术有些过时，其他方面依然是金科玉律，值得好好品鉴。书里涵盖了一名程序员真正面临的一些问题：

• 与软件腐烂作斗争
• 避开重复知识的陷阱
• 编写灵活、动态、可适应的代码
• 防止靠巧合编程
• 使你的代码“防弹”
• 捕捉真正的需求
• 无情而有效的测试
• 让你的用户满意
• 建立注重实效的团队
• 无处不在的自动化

当这些问题倒下而你还在程序员的阵地上，想必那时你就会让人感受到那种「无名的品质」，那么你也就走完了程序员从入门到精通之路。

按一万小时理论即便你在一个领域每天浸淫 10 小时以上，最快估计要精通一个领域也需要三年，这里还没算休息或突发状况的干扰，所以实际上也许需要五年。成长需要时间，不必觉得目标太远而乏力。保持每年、每月、每天都略有进步就好。

程序员的职业道路