最近有刚入门学编程的小伙伴问我关于程序员的情况，我想不如就把自己做程序员的感悟写出来，希望能帮助到还在困惑的小伙伴。

文章可能有点长，如果想只想看干货，可以跳到后面的小标题，找自己感兴趣的章节。

为什么要当程序员？

对于一个刚入职场的人来说，程序员是一个非常不错的职业。

编程入门不难，就像大多数的编程书籍，第一个实例就是输出“Hello World”，当然你可以将它改成任何你想要的字符串，或者写上自己的名字，都是很容易的事情。成就感就这样不太费力就获得了。

到了实际工作中，你编写的程序应用到了产品上，正是你的努力，让产品有了生命，鲜活了起来。如果运气好，产品推广的很成功，很多用户买单使用，那一刻你会很幸喜，原来我也可以让这个世界变得更美好，这就是程序员工作来带的价值感。

美国心理学家亚伯拉罕·马斯洛在1943年在《人类激励理论》论文中所提出马斯洛需求理论。书中将人类需求像阶梯一样从低到高按层次分为五种，分别是：生理需求、安全需求、社交需求、尊重需求和自我实现。

程序员的工作满足了这套理论里的最高的需求－自我实现的需求。还有一个解释是，当高级需求被满足时，可以降低对低级需求的渴望。这也是为什么那么多程序员就算是挤地铁，吃快餐，长时间加班，也依旧乐于自己的工作。

稳定的收入是一方面，我觉得更重要的是工作带给他们的满足感。相比其他初级工作，比如文员，助理。编程能带来更快速的反馈，或许一个月的努力，你就能写出一个游戏，而且在过程中，你自己清楚，目标是在一步步的靠近。

随着工作年数的增长，除了编程技能更熟练，你的逻辑思考能力也是在不断的培养和强化。阅读别人的程序，就是在理解和学习作者的逻辑思路。当你要自己动手写的时候，你就需要自己厘清思路，思考逻辑。如果出现逻辑上的漏洞，就是在为自己和同伴埋下一个坑，迟早你会需要来修补这个坑。就在日复一日的修修补补中，你的逻辑思考能力是在不断的被打磨。

绝大多数的程序员是需要和其他人协作完成一个更庞大的系统的。所以程序员的工作不会仅是编程而已，还需要管理自己的计划和目标，和其他人沟通等等，如果想成为更高效能的程序员，下面这些问题或许你应该要想想。

如何成为高效的程序员？

1.  如何设定目标

当我们从Boss 那里接手一项任务时，可能目标不一定是清晰的。要完成任务的是你，所以具体目标是需要自己来设定。比如：Boss 会说：小王，这个案子接下来就交给你来跟了。接下这个案子，是任务，不是目标。而你要做的是，把任务转化为目标。这时你要做的第一步是，收集信息。和这个案子相关的信息，收集的越多越好。

更多的信息会有助于提供更多角度，更高的视角，它们会帮助你做出更高效的决策。比如：你收集到客户3月15日要来拜访，那么在制定短期目标时，就要将客户拜访时需要的内容先完成。所以制定目标最关键的是，收集信息。

2. 计划赶不上变化

初入职场时，我时常会质疑boss 让我列计划的必要性，因为没有哪一次是能按照计划来执行的。后来想明白了，我其实不明白做计划的意义。没错，一般设定计划的初衷是，希望它作为接下来工作安排的参照。但是，我们最根本的目的其实是希望更高效的达成目标，完成任务。

有一个困难是，我们只能根据当前掌握到的信息来设定未来的计划，这样的计划是带着预判和猜测的。当新的信息加进来，而它是会对结果产生影响的，我们就需要重新思考计划。所以说，作计划是一个逐渐完善清晰的过程，很难做到一次搞定。

比如：开始，我们计划用方案A来实现目标，做到一半的时候，我们产生了新的想法是方案B，而且它能更好的完成任务，这时我们就需要调整计划，按照方案B来执行。

3. 解决问题的策略

程序员的工作中有很大一部分是解Bug，这些Bug 可能是设计时考虑不周导致的，又或者是很多错中复杂的原因导致的。每一个Bug 都有自己的症状。就好像人感冒了症状可能是打喷嚏，流鼻涕。Bug 的症状也不少，比如功能无效了，运行中断了，更有严重的当机等等。当我们接到问题的时候，被告知的是症状，而客户希望的也是症状的解除。但是如果程序员以症状解除的目标来解决问题，很可能会埋下隐患。

我想讲的是，解除症状只是结果，解Bug的目标其实是找到问题的原因。找到原因我们才能知道问题的影响究竟有多大，才知道什么样的solution 才是最优的，也能最大程度的考虑去避免side effect。有时候，我们找到问题原因后，甚至会不解这个问题。可能解决的成本非常高，或者带来的side effect 可能比本身的问题更严重。

查找问题原因的过程，就像是透过一个点的延展，去探索当前的系统架构和逻辑。在初面对一个庞大的系统时，我们最大的困惑往往是不知道从何处开始学习，开始了解。而出现问题正好是一个契机，一个切入点，如果只是为了解除症状，而不去探究问题的原因，就相当于放弃了深入学习的机会。而每一次的深入了解，都会为你日后解决问题带来帮助。所以面对问题，找原因可能比解决它更有意义。

4. 客户最需要的是什么？

客户总是不断的向我们提出问题，解决问题是做好客户支持的核心吗？当然，客户需要我们帮助他们解决问题，可是据我观察客户真正最想要的是放心。

客户发了一个邮件过来，你立即开始着手处理，想着用最快的速度，保质保量的完成任务，解决问题。这样想是没错，可是问题解决总是需要一段时间的。这段时间你要怎么办呢？是埋头苦干，以最快的速度解决吗？

不是，更好的做法是尽快的告知客户，你正在为这个问题努力，并告知客户可以完成的时间。客户收到你的这封邮件，就算问题没有立刻解决，他也会放心。当你一次次的按照约定，解决问题，你在客户心目中的信任度和口碑就在逐步的上升，以后有问题，他都愿意来找你。因为找你他放心。

陌生人之间的协助之所以困难，因为彼此缺乏信任基础。当你不断的向外建立自己的口碑，就是在形成你的影响力。这对于你日后的发展，都是非常有益的。所以解决问题不是核心，建立信任才是。

5. 写文档输出的好处，教就是最好的学。

我有一个习惯，要了解一个新东西时，会边看边记录，这样的好处是，让我更容易在各个知识点之间建立联系。大脑的工作记忆区的容量是很小的，30s 前看的东西，很快就忘记了。

有效的学习是需要将各知识点连接起来，才能发挥效用。记录就可以弥补工作记忆不够的问题，记录一个新知识点时，可以同时看看上下知识点之间存在哪些关联，并将这些关联也记录下来。等你梳理完一遍后，就可以通过记录，再消化一遍。日后需要时，也更方便查找你想要的信息再哪个部分。

还有一个更高效的学习方法是费曼技巧，就是将你学到的知识教给别人。看看下面这个知识吸收率的金字塔，通过教别人你才能掌握到知识的90%。

所以教别人最大的受益人是你自己。

6. 写邮件的误区

写邮件其是我们平时工作时最基本的一件事情，可是我最近才发现，原来我一直不会写邮件。写邮件是为了把我的想法传递出去么？不是，写邮件的目的是让收件人理解你的想法。这两句话的差别是什么？差别是谁是你的关注点。

如果是把我的想法传递出去，那么关注点在我。我把自己想说的话，都说完就好了，不对么？不对，我们忽略了一个问题就是，你想说的话，别人看懂了么？

你会说，看不懂是他的事啊，我的责任已经尽到了。而且他万一看不懂再问我呗。可是，如果这件事情，只对你来说是重要的，收件人其实是没有义务因为没有听懂来问你的。这样邮件就等于白写了。更多的情况是，你想传递的信息对收件人来说也是重要的，如果你的收件人是一个Team，上百个人，没有理解的人都来问你，一个人花1分钟问你，对他来说影响不大，对你来说，可是上百个1分钟呢？是不是想想都觉得可怕了。

所以写邮件时，仔细的思考下，收件人是谁，他想知道是哪些信息，怎么表达他才能理解，是否要补充背景知识，甚至包括怎样排版，都是需要考虑的问题。帮大家节省时间，其实就是帮你自己节省时间。

还有一点，我觉得也很重要。我们可能被鼓励成，把邮件写的非常详细，字数越多，越能体现自己的努力。可能boss 也会表扬这种现象，邮件写的长，不管怎样，至少工作态度好。我觉得这样的情况很可能是写邮件的人在自嗨，大家的时间都很宝贵，越是长的邮件，越少人会真正看。

7. 遇到超难的问题怎么办？

程序员一定会遇到难解决的问题，下次苦思冥想找不到解决办法的时候，可以试试这个方法。

大脑有两种思维模式，专注思维和发散思维。专注思维就像是我们平常解决问题，根据现象和逻辑进行推导。当我们在专注思维下，解决不了问题的时候，切换到发散思维，说不定就找到解决问题的办法了。若对这两种思维模式有兴趣可以去读下《学习之道》这本书。

怎么切换到发散思维呢？其实很简单，去茶水间喝杯茶，走动一下，听个纯音乐，都可以。就像我们常说的换脑子。

还有一种办法，是将你的问题，描述给另一个人听，有时讲着讲着，你就找到新的办法了。当我们在想问题的时候大脑的思维是网状的，在把思考转化为语言的时候，其实是把网状的思维作线性的连接。当大脑的神经元被重新线性连接的时候，你可能会发现，问题的解决方案就在旁边。所以，有时候我们找人讨论问题，并不一定需要别人给我们解决办法，最后办法是自己找到的。关于这一点，我深有感触。

好好利用发散思维，它可能让你解问题时有如神助。

最后祝广大程序猿&程序媛同胞都能开心工作，享受生活。

既然都看到了这里，那就点个赞再走吧:D