现在是2020年10月，真正意义上的工作应该算是17年毕业后的时候，到现在差不多工作了三年多的时间，想总结一下这三年里学到了什么，又有哪些不足。算是做一个反思，同时也是一个自我激励。
工作前三年，应该算是从一个新手到程序员的入门阶段，这三年的工作时间算是有不少经验和血泪的教训。这三年应该算是有一个特俗意义的阶段。
站在我现在的这个角度来看，我其实是主要想分两个方面来聊一下，第一个是非技术的方面，我们俗称软技能；然后第二个方面是技术方面，也就是硬技能，解决线上问题以及编码的能力。
这两个能力在工作上应该是相辅相成的。硬技能决定你在完成工作的，而软技能可以帮你把握你前进的方向。可以说硬技能决定你的下限而软技能可以决定你的上限，决定你可以走的有多远。
在平时工作中，你遇到一个业务需要完成。当你拿到这个业务之后，能够帮助你决定现在需要做什么，帮助你决定你要怎么做才能够完成这个目标，如何将其拆解成一个个可执行的小任务，然后再遇到问题之后如何通过沟通以及找到可以帮助你解决这个问题的人一起去完成这个目标。这些问题都算需要通过软技能去完成，因为这个时候单凭你的技术技能是无法保证完成这个事情，你需要通过沟通去寻求更多的资源，同时也要一个跟其他人argue的能力，包括不限于产品以及其他域的研发。不要觉得这些行为不利于团队氛围，记住你们的共同目标是完成这个产品，在不违反大前提下，内部的反馈和讨论会促使产品往更好的方向走。通过沟通推动项目落地，如何推动多部门之间的合作
保持成就感
1、快乐。工作带来的成就感，会告诉你原来你也可以做到。工作带来的钱，也会让你和家人安全与满足。
2、获得价值。别人喜欢你的产品，安心的把订单交给你，甚至除你以外没有他选。这种认同感，能让你很高兴，也会希望能一直创造价值。
在拉伸区练习
向上管理的能力。
作为你的leader或者老板，你需要时时刻刻保持沟通。在拿到一个新的需求的时候，保持你现在需要做哪些事情以及风险点可能在哪些地方，如果觉得哪些地方存在你推进不了的地方，然后让你的老板去推进这个事情。这个是找老板帮助解决问题的场景，有时候你也应该去帮助你老板解决一些问题。比如现在遇到一个非常紧急的问题，但是此时人手不够，恰巧此时你对处理这方面非常有经验，你可以主动将这个活给扛下来。当你感觉到你抗下这个活对你感觉到不公平，其实 你跟你老板是一个整体，是捆绑在一条船上的，一荣俱荣一损俱损，直接点的就是跟绩效挂钩。当你这个Team的绩效足够好，蛋糕足够大，那么必然会使你可以分得更多的蛋糕。
说到向上管理，周报是一个很好的渠道。我每天早上的时候会通过Things 将今天要做的一些事情给罗列清楚，在晚上下班的时候会花5分钟的时间去思考今天做了哪些事情，同时将一些开发工作中临时插入的事情记录到Notion。然后每周五的时候会将Notion的工作记录汇总起来，通过周报的形式给老板交代清楚这周做了哪些事情，帮助了别人哪些事情，包括你本职之内以及本职以外的事情。不然的话会导致你在后续的考核失去一些有力的证据。同时在周报里你可以写出你对于工作的一些想法和建议，可以不光是好的一面，吐槽批评也是可以的。
工作日志
写工作日志的习惯，是从读研究生的时候开始的。经过数次迭代，工作日志目前分为几部分：
- 第一部分是时间开销，详尽记录每天所做的事和所用的时间，这样可以对这一整天是怎么过的有一个清晰而准确的认知；
- 第二部分是完成事项，用来记录每一天做了哪些工作，每一项工作具体做了哪些内容；
- 第三部分则是复盘总结，对每天工作中遇到的问题以及解决的思路、方法进行记录，把自己的思考和行动的过程记下来，有助于反思和进一步的改进。
定期总结复盘
前面的工作日志，为定期总结提供了准确的数据，从而可以对每个星期、每个月所做的工作进行整理、回顾，并对自己解决问题的思路和方法进行反思。
工作了才发现，各种事情都是在实践中学习的，不可能先完全学会了再动手去做，因为去做的时候才会发现自己并没有“学会”。
很多事情只有亲自去做了，才能发现自己存在的问题，才能对自己的思路和方法进行改进，所以并不是“学以致用”，而应该是“用以致学”。
工作内容的整理、总结其实还是次要的，最关键的，是发现自身存在的问题，并加以针对性的改进，这样才能越做越好，而不是总在同一个地方摔倒。
疏通链路，沟通先行。在做一个具体的项目的时候，你需要将你这个功能的所有链路都梳理清楚，以及数据扭转的过程，需要思考清楚,预知这个功能需要依赖哪些具体的部门,不然的话，当你真正遇到这些跨部门的问题之后，再去找对方沟通，这个时候在开发中期或者末期，他们根本没有任何的时间去处理这个问题，而且你的这个问题也不会是他们最高优先级的事情，就算是本迭代处理也意味着需要一定的时间以及工作量去解决，那么此时此刻，你的工作就会被彻底阻塞住了。为了避免这样的问题发生，你应该在迭代早期跟跨部门的人员沟通清楚，你有这样的需求，这样的话给他们一定的缓冲时间去解决这个问题，等到你开发到这块内容的时候，就可以去找对方要这些东西了。这个例子也从侧面反映了沟通大于编码，在某些时刻，决定你成败的往往最不是代码这一块，因为代码是你可以主动控制住的，你可以控制意味着你具有主动权。但是第三方以及其他团队的人超出你控制的范围，尽量通过你的努力和方法将不可控制转变为可控制的。这样你便拥有更多主动权。从侧面说明软技能可以决定你走的方向是否正确。
最后的话，我想推荐一本书《软技能，代码之外的生存指南》，这本书从职业，自我营销，学习还有生产力等多个方面去告诉你如何提高你的软技能。虽然有一点成功学的味道，但是其中介绍的一些方法还是具有指导意义。