标签：
码路指南
但人们这么表达的时候可能并没有意识到常说的这种兴趣是一个不怎么靠得住的驱动力。这种兴趣往往是一种一时的好奇心，而不是与自己性格特质相契合，可以用来给生命解闷的那种兴趣。
总的来看，兴趣可以分为两个层次：一个是浅层次的。比如看到一个游戏比较酷可能想玩玩，看别人写博客，自己也写几篇；另一种则是深层次的。比如：爱因斯坦你不让他思考，他可能感觉活着就没什么意思了。
人和人之间的体力往往相差不大，但智力的差异却往往不可以道里计。所以一个经验丰富的老农半天种一亩地，一个不太熟练的忙和一天大致也可以搞定一亩地。
我个人感觉，越是靠近体力一端的工作越不可能兴趣驱动，而越靠近智力一端的工作越可能是纯兴趣驱动。恰如我很难相信干重体力活的人是因为兴趣一样，我也很难相信爱因斯坦不去做以色列总统而选择继续研究物理不是因为兴趣。
基本上讲，35岁以前要把需要花大量时间，比较硬的技能，学习曲线陡的技能掌握，具备工作所需要的所有主要技能，而35岁之后则主要关注知识的更新和某些软技能。
学习时添水战术效率真的很差，每次点一根火柴烧水，一亿年水也烧不开一壶。同时，比较硬的技能往往是需要大块时间投入的，但年纪越大时间越呈现为碎片化，越难搞定硬的知识 —— 先天就容易造就添水战术。比较软的技能，则可以用碎片时间来学习，比如：提高PPT的制作水平，提高表达能力。
如果能够安排好自己的时间和软硬知识的关系，那么就可以在特定基础上做积累，小步前进，使自己的价值越来越高。从这个角度看，年轻绝对是一种债务，大多数人必须在他没完全结束前，还掉所欠的东西。
那么具体来讲那些东西是比较硬的，要在35岁前搞定呢？这因目标而异，但下面这些项目应该具有非常高的通用性：
假设说一个人的学习已经聚焦，并且学习的内容和自己实际参与的项目也相吻合，那么是不是就没有问题了？很不幸，答案仍然是否定的，在任何一个子领域里，仍然需要进一步去考虑“博”与“专”的均衡。
与此同时，把一个API研究的再透，也是低值人群，因为这种深入理解和单纯会用某个API相比，从创造价值的角度看，差别不大。
这也就意味着对于大多数软件开发人员而言，要去寻找广博与精专间的均衡点：既不能闭上眼睛，也不能就用显微镜来看世界。而这一均衡点的价值则可用反木桶原 理来说明：木桶原理说的是桶里的水是由最短的一块板决定的，但考量人的价值时却是适用于反木桶原理，即人的价值往往由最长的一块板决定。
考虑博和专的问题不能离开产品开发进行考虑，前面曾经提到过，产品开发往往和公司的现金流绑定的更紧，能为现金流贡献力量的技术才是有价值的技术。 而产品开发本身事实上对博和专的程度提出了最基本的要求，这种要求往往具有迭代的特质。为了形象的说明这一点，这里举一个通用的例子来进行一点说明：
在第一次跌代里，往往需要达到两个最基本的目标。第一个目标是可以为产品贡献自己力量，但代码质量普通。这个目标如果达不到，一个人会失去自己的存在价值。
这时候最少需要了解某种语言（比如：C++)、某个平台（比如：Windows)、某个IDE（比如:Visual Studio)和某些业务相关 的知识（比如：打印体系）。这个范围可以尽可能圈的小点，但用到的则要学透。比如：不管接触到那个框架，都要去了解它的内存机制、线程机制、异常处理组件 构建和国际化处理这些全局性的机制，而不能只是了解某个接口怎么用。
这并非是很高的要求，没有这些就变成了“靠运气编程”，写完程序后还要祈祷他能跑起来。了解这些之后就可以负担起部分开发工作，否则的话只能做旁观者，没法参与到实际工作中来。
第二个目标是把事情做好，并能负担些层次更高的工作。这时候要比较深入的了解面向对象、结构化方法、设计模式、理解设计原则，并能把它们用好。至少要能判定，这个程序写的好，那个程序写的不好，同时面对需求能把工作进行下去。
完成上述两个层次后，可以有两个方向可供选择。
1. 可以进一步考虑专的问题，比如在特定领域里把知识深化下去。
2. 可以把博再推进一步，比如：熟悉专门领域的专业知识、熟悉多种既存框架的特性、熟悉提高用户体验的关键点。熟悉多种既存框架的特性的具体含义是：
设计某一种解决方案时，首先要考虑的就是是自己开发还是使用现有的模块。一旦决定使用现有的模块（包，框架等），那就要进一步考虑究竟用那个。
做这类工作时，如果没有一定广博的知识，做选择的时候就会特别的艰难。
简单来讲越是没实践经验的人越不适合学习软件工程，越需要规划整体把握全局的时候越需要学习软件工程。
而避免“失去焦点”这一陷阱的第一关键则是分类：对软件开发进行分类，对软件所关联的知识也进行分类，形成自己的大局观和整体视图。
“扮猪吃虎”这事儿小说里看着很爽，但挪到现实里来很容易让人掉到学习陷阱里。更可怕的是，现实里有这种心思的人其实也还很多。
有时候会看到这样一种现象：很多人自学的东西和工作中用的东西完全没关系。比如：一边用着C#做Web开发，一边自己学习着C/C++做嵌入式。
这事并不一定不对，只能说非常危险，很可能会导致那样都没有高度。我们得承认当人生被错位的时候，往往只能这样来改变命运，这是没办法，也是正确的。但首先要认识到这样做是相当低效的，低效到一定程度后对的事情也并不一定有结果。
对薪资不满意应该是程序员希望跨界的一个原动力，但收入和年限正相关，与语言非正相关却说明单纯从功利角度看跨界并不明智。因为假设一个人Java语言用过三年，C#用过三年，总的来看收入水平更可能处在三年的水平上，而不是六年的水平上。
解决艰难问题时，天分很重要；解决复杂问题时，练习很重要。所以软件开发的学习过程中，实践很重要，纯理论知识的权重较低，当然基本的算法复杂度还是要明白的。
这也就意味着脱离项目实践的学习投入产出比往往会差。比如说：编程中常见的多线程问题。如果单纯从学习的角度看，创建线程本身并不复杂，掌握各种线程同步 方法（事件、信号灯、互斥量等）也并不复杂。写简单例子的时候，也很少会出错。但一旦落到具体的场景下，虽然多线程的本质没变，但没经验的人几乎一定会在 涉及多线程的代码上导致一会儿出，一会儿不出的问题。
再比如说：你可能看了很多设计的书，但从来没有从头到尾写过什么程序，总是在既有代码上修修改改，或者只是完成几千行代码的小工具，那么你的设计知识是很难融汇贯通的，也还是无法很好的承担大系统的设计工作。
这点上有一个旁证，根据统计最多的Bug是由新手导致的。这从侧面说明，能做和能做好之间的鸿沟需要大量的实践来填平的。
在这样一种前提下，期望先选个工作，再自己学习，努力转行这样的想法是损失很大的。单纯从增值效能上看，解决这点很简单，除非必须放弃当前的工作领域，否则要以当前参加的项目为根基展开学习，这样才能比较好的调和学习和实践。
而除非一个工作领域过于偏狭，大多时候在编程语言（C#→C/C++）、不同领域间（图形处理→地理信息系统等）穿越损失可能更大。
单纯从达成某一目的而言，读书往往非是绝对必要条件。
秦始皇把书一把火烧了，刘邦项羽一样造反并取得胜利。但读书无疑的可以加速一个人增值的过程，记不得是谁说过：实践无疑是人类最好的老师，但只靠实践来认知世界无疑也是愚蠢的。这是非常精辟的。除此之外，要想培养大局观，那就非读书不可。
每个人的亲身经历，在大的时空背景中往往只是一个简单的截面，这一截面中绝不会包含可以归纳出所有真理的事实，因此只依赖于自身的实践也就必然限定 了一个人的视野。 这一点随着一个人的责任范围变大往往会体现为一种制约和限制。所以培根讲：有实际经验的人虽能够处理个别性的事务，但若要综观整体，运筹全局，却唯有学识 方能办到。
即使从实践来看也是如此，要想培养出一种大局观，那就非读书不可。而大局观往往是成为将帅之才的必要条件。
机关
现在在国土资源部门负责信息方面的管理工作，工作内容嘛，几乎不怎么从事开发了，最多就是偶尔改下原有系统/网站的代码。然后就是负责局里的一些大 大小小的信息系统事务，日常维护，与其它机关单位打交道……等等。怎么说呢，感觉就是一枚不断运转的齿轮，辅助局这个大机器的每日正常运转。 机关单位里虽然不像开发公司里那么忙，但也不是很多人想象得那么清闲，大部分时候还是挺繁忙的。
1. 网站的Android客户端
2. 魔题库
我的编程成功秘笈是：
我觉得我现在就挺好，在事业单位里，钱多事少离家近，在环境优美的珠海舒舒服服过活，没事就自己折腾下技术，有空就自己捣鼓下项目，写写博客什么的，为啥 一定要背井离乡到北上广拼呢？不是说去北上广拼不好，而是生活有很多种选择。为啥做IT就一定要努力去比过别人？努力去超越别人的技术，努力去超越别人的 月薪，这就像跑马拉松一样，太累了。
1一个正规可以帮到很多人的网站，一个月大概12K收入
2 股票，去年回报大概相当于全年薪水
标签：
原文地址：http://www.cnblogs.com/dqxu/p/4905111.html
