一个野生程序员的成长之路
Updated:
我大学读的并不是计算机专业。只是很粗浅的学习过一点 C 语言，知道简单的 for loop，if 语句等，以及一个叫 Foxpro 的数据库。我当时出去面试，说只用过这个数据库的时候，你都无法想象当时那些面试官脸上的鄙视的表情。后来，幸运的在做对一道智力题的情况下，被一家小公司看上，踏上了程序员的道路。然后就一直在珠海待了几乎 12 年了。
成长足迹
我还依稀记得，在第一家公司，CORESOLUTIONS，最开始承担的两个工作任务。
刚进公司，负责带我的人帮我拉了源代码，配置好环境后，然后和我大概讲了一下他打算让我做的页面的样子，然后让我在系统里先自己看看。当时那个系统，页面是由一套 JAVA 实现的内部 UI 渲染组件，在 JSP 里面生成出来的。所以，网络外面是完全查不到参考资料的。我对照着系统现有的其它参考页面和代码，大概花了半天还是一天，把我要做的页面，模仿着做了出来。当我问他那是不是想要的效果时，我还很清楚记得他当时那么一丝惊讶的表情，内心还是有些窃喜。紧接着的另一个任务，是要用 JavaScript 写一个函数，做出能点击 HTML 的 table 任意表头对记录排序的功能。这个任务足足花了我 3 天。
因为我是非科班出身，底子差，怕被他们发现我太搓，只能自己不断尝试和憋着自学 Java，JSP，JavaScript 和 DOM 元素的各种操作方法。况且当时我要面对的 Leader 是会因为下属（或自己）某些事情做的不好，猛敲键盘发脾气的。一开始压力真的很大，而且不敢轻易问问题。
在这个公司待了差不多 8 年。那段时间接触的东西很杂，学很多不同的技术和做了很多项目。要做什么，马上学什么，用什么。
- 测试：带小团队参与渣打银行一个项目的 UAT 测试
- 支持：公司资深顾问集体跳槽后，承担 Schick 公司 Manugistiscs 系统的技术支持
- 数据仓库：香港 Lane Crawford 的 BI 和 Crystal Report 项目
- 外包：在香港 Laws Group 用 Powerbuilder 做产品，在 UBS 用 JAVA 做内部投资产品系统
- J2EE：用公司 J2EE 的框架，做广州 DailyFarm 和上海 Apparel Group 的项目
后来，因为公司放弃用 JavaScript，用 ZK 那个框架写 UI，我就离职了。
之后，去了东方海外货柜航运公司，做它们内部的航运系统。本来是奔着它们的前端项目去，更深入学习 JavaScript，却没想到被派去美国学习几个月，接手后端，就变成后端代码写的多一些了。而且毕竟我的经验也相对丰富，所以后来带团队和沟通时间花费，比自己写代码的时间还要多一些。
做的好的地方
回顾这些的经历，它们对我的学习，沟通和应变能力的提升有客观影响。下面是我个人做的比较好的几点。也正是因为这样，前面的发展还是比较顺的。
迅速学习和应变
- 整体思维
比较常见的技术学习模式有两种。一是从整体到细节，另一种是从细节到整体。一般来说，采用第一种学习模式的人，学习速度更快一些。这种模式下学习的人在面对新技术的时候，一般只需要知道整体概念，大概包含哪些组件，每个组件分别起什么作用，怎么相互关联，然后就可以开始使用这个技术实践了。而习惯第二种方式的人，他们需要细嚼慢咽的看文档，把一个概念的大部分细节都理清，才能继续下一个。
对于我来说，在面对一个新的方法、类、代码库或者技术的时候，我首先要做的事情，就是尝试从整体上理解这个新的方法或者类用来干什么，新的代码库的整体结构是怎么样的，入口在什么地方，新技术的整体理念是什么。整体思路有了后，按需再逐步填充细节。前面说到的半天就把页面做出来的例子，就是因为我只需要结合现有页面，再猜一猜框架 API 的大概用法，就可以做出来了，即便我不完全理解整个框架。所以，整体思维是帮助我迅速解决问题，学习新技术的重要手段。
- 实践
学了就用，立即实践。其实我以前经常面临的情况更夸张，是现用现学。但不论如何，重点是通过实践来学习和掌握理论知识。有不少人看了一整本书下来，都还没有动过手。但是，只有真正实践起来，你才会发现那些你原来以为已经懂了的概念，可能完全不知道怎么和实际联系起来。
- 独立思考，不轻易提问
正如前面所说，我一开始是不敢问，因为怕别人觉得我太搓。如果遇到需求的问题，我就把自己当用户，从常识出发。这样才能让自己更具备产品思维能力，而不至于沦落为一个仅仅是盲从需求的码农，我还能根据自己的技术优势，反过来给业务分析人员意见。如果是技术问题，自己尽量找文档、示例，能从 Google 找到答案的，就不应该问他人。所以，在你打算张口提问之前，再想想，别急着问。
不过后来我带刚毕业的新人时，我是鼓励他们问问题的。只是要学会什么应该问，和怎么问。有兴趣可以看看之前写的 一点点对提问，分享和影响力的看法。
- 化压力为动力
我真的觉得压力有时是一个好东西。恰当的压力，把你推出舒适区（Comfort Zone），身处伸展区（Stretch zone）的时候，你很多的潜能都会被逼出来。之前我被频繁的派往不同项目，学习新技术，并在客户一线，真的感觉被推着走，所以成长的也很快。所以，要恰当给自己添加压力，定目标和 deadline。
沟通能力
我之前任职的公司都是港资公司。身为一个广东人，精通粤语和不错的英语让我在语言上有了很大的优势。很自然的，我成为了香港老板，内地员工之间沟通的桥梁。英语能力也让我能比别人有更多的项目机会，向外接触客户，甚至出国的机会。
当然，语言我觉得还不是最主要的。最重要的是能迅速准确地理解他人的想法，尽可能为下一步行动提出可行意见，并达成共识。我觉得这是高效协作的最基本的要求。很多人说程序员不善于沟通，所以，我在这方面做得还可以的情况下，机会就比别人多一些。
不怕吃亏
很多毕业生眼高手低，脏活累活不干，认为没有价值，学不到东西。当年，我自认起点比较低，上级无论指派什么任务都去做。比如，我曾经被要求找出 JSP 里面不必要的 import 和项目里所有只捕获了顶级异常的 JAVA 类，再看每个的使用是否恰当。这些脏累活，有些虽然只是体力活，有些却可以思考是否可以用程序来解决的，有些还有助于增进对公司系统的理解。不挑活，把小事做好，可以极大提升信任度，才有可能接手更重要的任务。
还有另一个就是，先把工作干好，才提要求（加薪，请假等）。很多同学，还没开始干活，就要这要那，好像是先要把自己的要求都满足了，东西先拿到手，才愿意付出。怕吃亏，其实最后可能更吃亏。
乐于分享，授权
工作两三年后，我都基本需要带 2 ~ 6 人的团队。带人的时候，我都会注意怎么引发他们思考，分享我的知识和经验给他们，也乐于授权给他们做一些有挑战的事情。之前写了一些文章总结，有兴趣的可以看看。
做的不好的地方
既然上面好像说的我很多方面都做得很不错了，但是为什么还没有出人头地，走上人生巅峰，做个 CTO 什么的? 因为上面某些做得好的地方，处理不好的话，其实会有点反作用。
技术太散，深入不够
因为我具备快速学习，较杂的技术面和良好的沟通能力，在 CORESOLUTIONS 时，从老板的角度出发，我就更适合做一些外包项目。虽然我混了一个看似牛B的顾问这样的头衔，但是由于我是非科班出身，基础不够扎实，有些细节是要回头补上才行的。再加上我不断的转换项目和使用不同的技术，填坑就变得更难。况且，最主要是我自己没有刻意并主动地寻找某一个技术点和领域深入下去，并向公司提要求，要往什么方向发展。所以，T 字的那一竖，不够深。
反思总结不够
自身较杂的技术面，就像完整的拼图上面这里一块，那里一块一样。自己没很好的花时间认真反思，梳理和沉淀，把它们更好地链接起来，形成自己的完整的知识体系网络。
后面怎么弄
现在，我打算先从 JavaScript 开始，整理知识点，顺便写一本供别人入门学习 JavaScript 的书 Tasting JavaScript，现在已经写到第 5 章了。然后再根据之前参与的基于 Node.js 开发的系统，按自己的想法再重新构建，把系统分层，架构，日志，测试，前后端结合等，好好地梳理一遍，补充一下那些不完善的系统和运维等方面的知识，以形成自己的体系。后面如果有机会的话，再接触一下运营和产品。最后说不定真能胜任一个小小的 CTO 哦。其实，最重要的是有把事情做成的能力。