大部分程序员的工作总结就是
负责了XX模块
开发了XX模块
然后成果是
性能提升了X%
客户没有再投诉
或者就是“按时完成任务”
上面的总结不能说有问题 当时想要升职加薪来说不够好 因为不能让人发现你的亮点
建议按照以下格式写总结
发现问题-分析问题-解决问题-显示成果
这就和写简历的star原则的核心思想类似
对于初级程序员 日常最多的就是解决问题
基本就是我用了什么方式解决了什么问题得到了什么结果
想要体现出自己的优秀 就要说明问题的复杂、方法的独特、结果的优秀
关键是要体现解决问题的方法
因为问题一般都是指派好的 结果也不会有降维打击 换一个人也能解决问题
这个时候解决问题的方法才能体现一个人的不同（所以业务代码的算法、设计模式 各种语法糖才是关键） 所以可以说代码重构、逻辑重写等等 但是没必要把加班加上 真没必要
但是实际情况是没有那么多篇幅和时间去把自己做的每一件事都说清楚 只能挑最重要的去写 其他的工作都只能归类为“其他”
在上面的归纳基础上如果发现篇幅还是太多 那么说明这个人应该是一个中级程序员的阶段 已经是一个小组长或者单独负责了某个业务模块
做的事情变多了，总结里写不下，又想展示自己的能力 要怎么办呢
还是刚才的三个方面
问题 方法 成果
方法不能无限制的升级，否则就变成了高射炮打蚊子
成果也不太能显示亮点，不可能修了个BUG 结果成果是公司上市
所以比较容易拓展的是问题，问题更复杂通常代表着能力更强。
通常的办法是将手中的问题整合，放进一个更大更复杂的问题里
比如我这个月做了一个需求，下个月又做了一个类似的需求，解决需求不是什么亮点，但是我可以做一个框架，一次性解决以后遇到的所有类似的需求。此时实现框架相对于单纯的实现需求是更为复杂的
有了复杂的问题后，除了讲解决方案，也可以讲复杂问题是怎么来的，也就是分析问题，还是原来的例子，将两个需求整合为一个框架后，进一步实现行业内同类型的需求，这就做出了一个有亮点的通用框架，业内一般称呼这种框架为xx引擎，比如流程引擎、编排引擎等，名字不一而足，但都是代指同一个东西
能做到这个地步，不但能说明一个人有能力，也能说明一个人有技术视野，已经算团队内的技术骨干了
做的引擎多了会发现行业内的东西就这么多，翻来覆去就是造*，此时还要总结就是要说明问题是怎么来的
技术专家要总结说我为什么要做一个流程引擎，通常要说明是因为发现了流程不足，会导致开发效率降低，BUG率升高等等，这都属于通过解决已经发生的问题进行总结
再上一步的专家进行总结时，就要换句话，从行业趋势进行解读，说规避了什么问题，总之就是别人有的我们也有，别人做到的我们也能做到
在说了方法、发现问题、分析问题后，还剩下一个能优化的点就是展示成果
成果的展示离不开数据的支持，但是数据一般不单纯指数字，还包括合适的指标，这个指标要能跟目标对应起来
比如中级程序员要提升接口吞吐量x% 那么他选择的指标就应该是吞吐量
但是技术经理的目标可能是降低it成本，那么他选择的指标应该是it成本而不是单机吞吐
另外许多人习惯单纯的列出数字或者列出技术方案，而不对自己的总结进行解读。
比如说画质相比去年提升了1.5%，这个数据除了证明你没有说谎之外，没有其他的意义。从听众的角度上看，提升了1.3%还是1.5%甚至5%都没有什么区别，这就需要你对自己的总结有一个概念上的概括，比如说“使用的方案是行业内最新的方案”，或者“画质已经和youtube持平”，这种一句话就能定性的结论
常见的总结问题：
①自己做了不少但是总结里没有体现
简单说目标小、手段low、成果说不清楚
大部分技术不错但是迟迟得不到晋升的程序员都属于这一类
②自己啥也没做但是总计里一套一套的
简单说目标虚、手段花、用成果掩盖问题
这类人一般叫PPT架构师 比较能忽悠
上述两种问题其实都是公司面临的问题，对于个人来说，最重要的是总结要面向自己，总结应该要把自己做的事情放在一个大的框架里，而不是把做的事情零零散散简单合并在一起，前者能降低“边际成本"，只管来看，总结是对于自己未来发展的指导，晋升、面试都是总结的附带产物