根据2017年中国软件开发白皮书指出，目前Web开发群体5成以上为全栈开发者。
微信小程序这种轻型“App”给大家带来了无限期待，而这些需要一个懂得掌握前端、后台等技术的全栈型开发工程师来掌控。
短视频的悄然兴起，成为互联网领域新的经济增长点，而全栈开发工程师是直播以及短视频平台不可或缺的技术支持。
从各大名企的招聘现状来看，不仅仅是国内的BAT大厂，90%的FLAG公司都已声称只招Full Stack Engineer（全栈工程师）。
随着互联网 的发展，众多创业科技公司不断涌现，初创公司不能像大公司一样招聘过于细分的人才，更需要独当一面的全栈开发工程师。
很多人会提到，大公司“专家”（精通一个领域）、小公司“全栈”。
实际上，全栈不是一个岗位，而是一种思维方式，从多角度多方位去思考问题，去研究一个新的领域，从而解决一个新的问题。
在遇到问题的时候，不会给自己提前设置极限，而是愿意尝试各种不同的方式方法从而找到最优解。
真正的全栈工程师就是市场上所说的一专多能的“T”型人才。
专的一面能够解决自己岗位的难题，广的一面，理解自己同事所在岗位的技术工作，减少沟通成本，这才是真正的全栈。
要注意的是：现在很多专家也逐渐转型为全栈，因为单纯依靠于一个领域的技术而存在的专家已经很少了，技术专家们必须依据于公司的需求去开拓不同的领域。
搜集近一年的IT行业就业缺口及就业方向发现，目前全栈开发工程师人才每日缺口10000人，未来还将保持持续增长，全栈风口已来势不可挡。
市场缺口大注定人才供不应求，岗位薪资也自然水涨船高。相对于前端、后端，全栈工程师的薪资更胜一筹。
成为全栈工程师并不难
首先需要了解的是，全栈开发工程师就是掌握PHP、Web前端、H5、小程序的多面型人才，能利用HTML5、CSS3、JavaScript、ES6、jQuery、PHP、MySQL、Node、Vue等多种技能独立完成产品开发。
梳理关键词：前端、后端、服务端编程、语言与框架。
看到这么多技术一些人可能会被吓退，其实成为全栈工程师并不是很难。
前面已经提过，一专多能并不是样样精通，而且市面上样样精通的全才只是零星存在，所以成为全栈工程师，首先要掌握其中几门关键技术。
主要分为两个方向：
前端开发：JavaScript、HTML5 CSS3
后端开发：Java
很多人都想成为全栈工程师，但是复杂的编程语言在实战时极容易踩坑。
基本的知识点学习是成为全栈工程师的基础，但是也需要一定的实践，如果没有实战项目的锻炼，没有亲自搭建网页，就无法验证学习成效。
很多人通过啃书的方式一页一页学习时，发现学习效率极低，还没有思路；想找老师进行辅导时，培训费用普遍过万，可能一些发烧友都不舍得花高价去学习，更别说一些小白、兴趣爱好者了。
想必大家都听说了，这两天关于中国平安一个产品经理因奇葩需求和程序员爆发肢体冲突的事件在朋友圈被刷屏，更有现场打架视频在技术群里疯传。
在这里先带大家简单文字回顾下事情经过，N次打架视频和截图就不给大家放出来了，相信大家都在技术群和朋友圈里亲眼目睹过了（当然，没看过的朋友可以找我微信私聊），最重要的一点是为了社会和谐。
「 肢体冲突的起因 」
以下是网上流传的本次打架事件的文字叙述：
「 事件的处理结果 」
事情的起因大概就是这样，先不讨论本次事件中pm提出的需求是否合理，程序员能否实现，本身这起办公室冲突事件的发生，引起了圈内很大的热议，“成功地”推上了互联网热点头条，同时也给中国平安公司的名誉带来了负面影响，最后涉事的两位外包人员惨被双双开除。
很多看过现场视频的网友是这样分析的，秃头的是程序猿，没秃头的是产品，假装劝架的是运营和设计，看戏的是测试，拍这个视频的应该是商务，pm下次记得戴安全帽提需求。
分析地头头是道，活脱脱一个国内社会看热闹不嫌事儿大的缩影，也是厉害。
「 如何向外行解释内情 」
可能一些非软件行业内的吃瓜群众，想不通为什么程序员和产品经理要干架？我完全可以通过一张表情图合集，来生动形象地告诉你，一家软件公司的项目是如何上线的。
「 打架是不对的 」
看完这张图，我们再来说说pm和coder打架的事儿
年轻人血气方刚，一言不合就互怼，借用孙红雷在电视剧《征服》里的一句台词：不气盛，还叫年轻人吗？
但是，以暴制暴是不对的，朋友，毕竟就算打赢了也是真的疼啊。
在乱提需求的前提下，至少得练得跟我一样吧。
不然，还真不一定打得过我，说一下我三大项的数据吧：
卧推：90kg 深蹲：140kg 硬拉：160kg
「 冲突的根源是什么 」
先来说说很多公司的现状：产品经理和“老板们”关起门来开了个会，赶出原型和UI图，之后交给程序员们的就是“圣旨”，“反正我们就这么定了，你照着开发吧。
程序员说：目标是需求，技术只是手段。
产品经理说：目标是用户，需求是方式。
立场不同，定位不同，矛盾就来了。
产品经理永远是用户需求的代名词，自以为是研发人员的上帝，动不动就要改需求，他们觉得好像很简单的事情，殊不知给程序员添了多大的麻烦。
技术和产品撕逼，无非就是以下几个原因：
1，产品没有想明白，然后来来回回的改；
2，开发没有理解清楚需求，开发东西和产品的要求有出入
3，产品的需求有问题
4，技术的时间不够用
所以说，一个不懂项目管理的程序员不是好程序员，一个不懂软件开发的产品经理，不是一个好的产品经理。
程序员和产品经理似乎天生就有不可调和的矛盾，和平共处很难么？
「 说点掏心窝儿的话 」
就这次事件，土叔我不站队，也不说谁对谁错，抱着一颗同理心，我分别来站在程序员、产品经理，以及项目管理层的角度，给coder、pm，以及manager分享几点我的小想法。
「 给程序员的建议 」
程序员和产品经理干架其实需要理性，查查他的经历，要分析下他懂不懂技术，懂的话有多懂。
一般很懂技术的产品经理是不和程序员干架的。
懂一点，但是就拿出来说事的这种，一般和程序员关系不好。
一点都不懂的产品经理有的谦卑，有的不懂装懂乱说一通。
对于懂一点，就拿出来说事的这种，就要想法设法在技术上反问他，让他觉得自己其实真的知道的很少。
这时候再动之以情，说明自己做这个的难度。
对于不懂装懂的产品经理，就俩字：你来。
还剩下一种是不讲理的，对于这种不讲理的就只有一句话，我他娘的意大利炮呢？
玩笑归玩笑，土叔在这里分享几点走心又走肾的建议：
做好需求更改的准备，提高代码的扩展性和可维护性；
预留出修改bug和需求的时间；
对需求理解透彻再开始写代码；
代码不要写死，防止需求变动。
「 给产品经理的建议 」
好多pm搞不懂，为什么产品经理频繁更改需求会令程序员小哥哥们烦恼不堪？我想，大多时候是因为你们pm平时在工作中的这些口头禅吧：
1.「先做出来看看吧」
2.「我就要这种效果，怎么实现是你的问题」
3.「这应该很简单吧，不就是XXX，然后XXX吗」
4.「这个需求，先这样这样，再那样那样，用XX技术很快就搞定了」
5.「你就说能不能做吧」
6.「我有一个绝妙的idea，什么都准备好了，就差一个写代码的了」
7.「这个需求老大已经同意了，你照着做就是了」
产品经理频繁的需求变更，和程序员有限的工时是存在矛盾的，除非让程序员加班。特别是上次的变更刚刚改完，这时又提出再次修改，朝令夕改，一步一步很巧妙地惹恼了程序员。
程序员最讨厌朝三暮四的产品经理了。
如何与单纯的程序员共处，土叔的走心建议要不要听一下：
1. 不要随时打扰，尤其在他们戴着耳机的时候；
2. 传达「要做什么（What）」，还有「为什么这么做（Why）」；
3. 学习基础开发知识（比如 HTML/CSS），方便彼此沟通；
4. 不要让他们成为最后知道的人，一起讨论可以少走弯路；
5. 尽可能用数据说话；
6. 配合工具（哪怕是纸笔）来表达你的想法；
7. 提供有用工具给他们参考（比如 AniCollection）；
8. 做好设计规范（个人很喜欢 Mavel 的 Styleguilde）；
9. 尽可能和他们坐在一起；
10. 他们可能羞于/不善于表达，多给一些耐心；
11. 不要不好意思发问，其实他们都很热心解决问题；
12. 不要问那些 Google 一下就能找到答案的问题，节约双方时间；
13. 缕清用户流程，不要让他们来处理你的工作内容；
14. 想清楚产品可能出现的各种状态（404、零数据、极端用例、转场……）；
15. 该你决策就由你来决策，不要分担责任；
16. 相信他们的技术水准（如果他们确实不会，他们会学）；
17. 勇敢承认你的错误；
18. 记得给他们展示用户/客户的反馈；
19. 改需求不要超过 3 次，再改就先跪下；
20. 就算月饼被抢了，也要友爱和睦相处。
「 给项目管理层的建议 」
其实，谁都有想不到的地方，和想不明白的东西。但是自己都没有搞懂之前就觉得只有自己是对的，那就只能撕了。
在我们公司的团队里，程序员和PM一起讨论需求，勾画原型，提出自己不同角度的不同理解，让程序员更接触“原始需求”，能参与到产品的生命线里会更好，毕竟每个人都有思考能力，不是机器，一张需求甩过来就照做的程序员不是好的程序员。
在产品需求会议上，允许程序员参加并发表意见，这样可以从技术的角度及早发现产品功能中存在的问题，从而避免后期需求的频繁改动。
这也是大多数比较有经验的互联网公司的常规做法。最后说说自己：
今年是2018年，腾讯20周年。我30周岁，刚好在腾讯工作满8年。
我从来没有想过自己会在同一家公司工作8年。因为4年足以读完大学，6年能让小孩读完小学，8年漫长得不可思议。
2010年，我刚大学毕业，加入腾讯。那一天，学生思维的我，不免以学生的尺度定计划：三年的时间，我应该足够从这一所“社会大学”毕业吧。
因此，我追赶时间，以这个截止日为目标，第一年学习高效地完成工作，第二年学习带新人，第三年学习影响力，翻译了一本前端书，和一本设计书。
我一步步从助理UI工程师晋级到高级UI工程师，先是积极响应需求，后来主动找事情做。我低着头，做事情非常“用力”，自信能把交给我的事情都做得很好。
我的博客文章80%都是头三年写的，现在回头看有很多幼稚的想法，但持续想和写才能提高。反过来说，要是现在还觉得好，那才糟糕。
二、
2013年，三年之痒。我开始觉得日常工作毫无挑战，考评时连续“优秀”跟“超出预期”拿到手软，但与此同时，也迎来新的工作挑战。
那时，我的领导问我以后的发展意向，是想继续研究技术深度，还是管理团队。我说如果有机会，尽量管理团队吧。
因为以我的理解，并不存在两种选项。这个问题就像“给你加工资，好不好啊”一样没有意义。学而优则仕，骨干不去领导团队，可能有点不负责任（现在想来很自恋，呵呵）。
虽然给了领导这样的答复，也开始进行正式的管理培训，但我内心还恋恋不舍想保留一点匠人心态。
个人能力要继续提高，我就开辟新的赛道：影响力。
2014年我认真地投入到写作练习中，在“26岁总结”中写下这段文字：
“在很多场景下我们都需要写作，我们要写短小的RTX，长一点的邮件，以及更长一点的分享文章、博客和专栏。关于写作，我觉得最有趣的一个事实是，优秀的写作者跟平庸的写作者所能达到的效果相差百倍以上，比优秀程序员和平庸程序员之间的差别还大。”
“优秀的写作者的RTX就是能让对方明白他的目的，并且像施了魔咒一样去合作。优秀的写作者的邮件能让接受者感兴趣，清晰地知道信息。优秀的写作者写的博客能用一段话击中读者心理，情不自禁点右上角的“分享到朋友圈”……这种效果100个平庸的写作者都达不到。”
“写作者需要的除了文笔，还有逻辑思维、数据分析、麦肯锡金字塔理论、心理学等等几乎所有的知识……”
每个人每天都要阅读微信、朋友圈、新闻、读书、知乎、小视频……关于写作对个人能力的的重要性，我认为怎么强调都不为过。因为广义的写作、演讲和设计，它们有一个共同的关键内核，就是搞清楚你的听众是谁，他们已有哪些信息，缺乏哪些信息，你要以怎么样的顺序来传达你想让对方做的事情。讲得邪乎点，它们都是一种“心理操纵术”。
那怎么才能学好写作（或者演讲，或者设计）呢？
答案无趣但有效：持续写。
反复阅读写出来的文字，毫不吝啬地删除无用的信息，重新再写。
达芬奇说过一句话：“Simplicity is the ultimate form of sophistication（简洁是终极的复杂）”。海明威每天写作之前都会把前一天的稿再改一次。
我也这样做，一开始在自己博客上写水文、在豆瓣写书评，感觉不够。2014年2月，我加入豆瓣专栏计划，需要每周写一篇超过3000字的专栏文章，结束后能获得200元鼓励金。我就像一个缺乏运动的人，强行把自己推入马拉松赛道。
我的前几篇写的很业余，错别字、口水话、病句、缺主语、串主语、一逗到底、唠唠叨叨、层级和顺序不对……那也还是要写。几个月后，20篇文章的专栏完结了，我的文字水平稳定从30分提升到50分，接近及格。
因为专栏内容相对新颖（可能是国内首批系统写“全栈工程师”的思考的专栏），慢慢积累一些读者并每周追看。读者宽容并热情地在评论区给我纠错。
后来，人民邮电出版社的责编在豆瓣上看到了我，就约我写稿。他说我写的东西已经很多，也有一些脉络，可以再整理一下出书。又是一个新的挑战。
先答应再说吧。
写书的过程只能说勉力支撑，因为只有50分的文字水平，却要输出80分的质量。把第一章整理好之后发过去，收到返回的修正稿，变成了另一篇文章。责编很专业，没有吐槽，只是做客观订正。
我羞愧难当，因为痛恨给人添麻烦。我记住修改过的问题种类，文法上字斟句酌，保证同类的不再犯。
因为责编会看出文字上的问题，然后给我修剪枝丫，但保持大树根基稳定就是我自己的责任，对读者的责任。我还买来《麦肯锡教我的写作武器》，更系统地学习写作。
经过好多轮的校对，我终于可以坦然说出，差不多达到基本的标准了。后面的事情我在“我出书了”中也都写了。2015年8月，我的书出版了。我在豆瓣上也慎重给《Web全栈工程师的自我修养》打了4星。
三、
写作成长磕磕碰碰的同时，管理之路也迂回曲折。试着带一段时间团队之后，我在2014年正式成为团队管理者。
当时对于团队管理的职责抱有几个不成熟心态：
- 管理比写代码更容易掌握，践行起来也更轻松。
- 管理者门槛较低，相较于工程师缺乏核心竞争力，以后跳槽我还是要以工程师身份来定位。
- 我喜欢专注做事情，不适合做管理。
- 在工程师团队中，我要以最强的技术和努力来赢得尊重，我要有能力解决他们都解决不了的问题。
因此，从2014-2016虽然也通过努力收获了一些个人成长，但对团队领导来讲其实我是不称职的。
有一个明显不称职的表现就是，每到员工考核期间，我就很纠结痛苦。我不希望有员工拿低于预期的考评，也害怕面对下属沟通面谈，当面对着他说你的绩效低于预期。
我能自律勤奋，但我很难改变自己的观念。最难的是，我甚至不知道自己是否应该改变自己的观念（瞧，这就是为什么改变观念是最难的），还是说退回去做一个还不错的工程师好了。
我在这个观念段位大概停留了两年多，经过断断续续的实践、阅读、观察和自省，我终于升级了。期间纠结和思考过程可以从2014到2016的博客文章中可见一斑。
总之，升级后的我认为：
- 管理比写代码（或任何一门硬技能）更难于掌握，这是我跟一些技术专家沟通得到的共识。硬技能的学习可以通过读书、培训班，甚至网络视频来学习，然后持续练习，越来越熟练，直到产生一个输出物。这非常简单，只要掌握了学习的方法，几个月就能学习一门硬技能。而管理的学习需要真实观念的转变，这个观念改变可能需要几年时间。
- 管理的核心观念是“管理者必须善于做有效的决策”。
- 管理者要注重组织对外的贡献。基于贡献来衡量每个人的绩效。
我开始积极与团队沟通，日常中看到不符合要求的输出，我就会直截了当地说“这不行，达不到基本水准”。
虽然比较严格，但也没有看到团队氛围下降的情况。因为从员工角度来讲，虽然乐于处在一个人际关系融洽的团队中，但更大的述求是加入一个充满专业人士的团队。每人都能从其他人身上学到特定知识，每人表现都是专业的。
我不再担心员工考核，因为它是一个有效的管理工具。有些无法用言语传达到的信息，可以通过绩效考核来传达。而且平时对于低绩效的员工就要做好预期管理，言行一致员工就不会困惑。
四、
2017年，我慢慢成为一个资深的管理者。又一次对工作驾轻就熟时，再次迎来新的挑战——转换岗位，领导腾讯微云UX设计团队。
我喜欢这个挑战，一方面它确实是一个“很大挑战”，受虐症的我无法拒绝。另一方面我一直处于产品流程中偏后的位置，但也对前置的思考很感兴趣。
因此，我梳理了自己面临的挑战：
- 之前领导的团队都是工程师，而现在的团队由交互设计师和视觉设计师组成。虽然管理的基本法是相通的，但新团队的成员还需要更多熟悉。
- 自己的设计专业能力不够，尤其是在视觉上，无法给到“怎么做”的建议。
- 新的UX设计团队面临比以前更复杂的外部关系。
- 如何帮助下属专业晋升。
但我也有我的优势：
- 能轻松地理解版本管理、多平台特性、开发挑战等“工程”难题，然后管理好风险。
- 参加了三年多设计部的管理会，对设计的“味道”有感觉，或者说品味远远高出实现能力。
- 在UI方案上，我有用户同理心，不只是从“好看”来评判设计。
- 我的演讲呈现能力和写作能力可以提升团队。
唔，也不全是坏消息嘛。那就开始做吧！
前半年仍然是勉力支撑（哭），但因为团队都在看着自己，不自信也要自信起来。
工作之余多体验各种APP，收集UI、运营、营收、品牌等方面的案例，进一步提升“产品力”。老婆平时在使用新的APP，或者被活动吸引付费时，我就会在边上观察她的行为。看到精彩处，我还会请求暂停，截图发给我。
总之，我希望自己的专业成长能快速补上权限扩大带来的差距。
慢慢地，有一些“腾讯微云用户体验不错”的口碑了，在自己能影响的范围内，使用我能调用的资源，慢慢地补齐漏洞，提升体验。
但仍然能力有限，有时候会出现仓促出的方案不合理的情况。这时更加如履薄冰，不是怕外部批评我，而是怕连累授权给我的上司，和被我能力所限的团队。加上腾讯微云也是一个有历史包袱的产品，所以仍然离自己心中的理想产品差很多。
团队成长上的挑战同样很大。
我仔细观察每一个人的优缺点，用人所长。与此同时我还要横向去看部门其他设计师的输出，不希望相对独立的产品导致了封闭的专业氛围。这将是接下来花半年到一年重点要解决的。
我对现在这个挑战，还远远没到驾轻就熟的状态，可能还需要两年以上时间来消化，所以有时工作会觉得比前几年加起来还累。
我时常以山本耀司的话给自己打鸡血：
我从不相信什么懒洋洋的自由，我向往的自由是通过勤奋和努力实现更广阔的人生，那样的自由才是珍贵的、有价值的。我相信一万小时定律，我从来不相信天上掉馅饼的灵感和坐等的成就。做一个自由又自律的人，靠势必实现的决心认真地活着。
勤奋和努力只是基础，以大多数人的努力程度之低，还根本谈不上拼天赋。
疲劳和兴奋交替，成就和挫折并存，曲折前行，比轻松混日子更有趣。
五、
回头看，这八年来，我从来都只是“短暂地胜任”自己的工作。每当我觉得能够驾轻就熟地处理目前的日常，就会迎来新的挑战。
想到这一点，我突然悟到一种“佛性”的工作哲学：
每当你能胜任当前的工作，就会迎来更高难度的挑战。
每一个能胜任当前工作岗位的人，都会被提拔。继续胜任，那就继续提拔，直到不能胜任。
因此，不用特别在意自己的头衔、权限和职级，外部的认可是你能力的反馈。你没有被提拔，大概率是因为还不胜任当前工作。如果完全胜任还没有被安排更有挑战的工作，要么自己找事情做，要么跳槽转岗。
反过来说，自知自己能力还达不到岗位要求也不用担心，不胜任是常态，以胜任为目标就好啦。
对于职场马拉松来说，心态放松，保持作息，持续养成好的习惯，学习好的方法和观念，这才是最重要的。
「 结尾 」
身在江湖，谁都不易，只要换个角度思考，互相多点体谅，这种矛盾自然就可以化解。
文章最后，如果想彻底解决pm和coder的矛盾冲突，马叔有个不成熟的终极方案，朋友们不妨一听：
产品/UI每天给程序员提任务，程序员每天给产品做任务。
如果同一个人可以分饰产品/UI和程序员两角，那么他就会变成永动机。
这款永动机有个广为人知的名字，叫做独立开发者。
