软件开发者的工作不是“写代码”，而是解决业务问题，“采用的新框架”常常不能解决业务问题。
我们与人一起工作，只是有时候写代码而已，所以人际关系是这份工作的重要组成部分。
软件开发人员也是人，他们和所有人一样都会受到认知偏差的影响。可以读读关于认知偏差、FAE(fundamental attribution error，基本归因错误)、特别是Kahneman 的书。
“别人”写的代码几乎总是无法理解或着写得很差，但并不总是因为代码真的写得不好。有时候这些“别人”就是过去的我们。
有时候在不改变代码的情况下也能解决问题。
每一个新框架的出现，是因为前端开发者面临的问题我们没有理想的解决方案。每一个成功的新框架都有其创新之处，所以得想想“这个框架/库如何改变我的工作”这个问题。
用户也是人。我们的产品和我们的失败都可能直接影响他们的生活，对你行为的后果要三思。
人与人并不相同，人们的思维方式也不同：有时候我们认为困难的东西从商业人士角度看来可能很容易。这是我们必须解决而不是逃避的矛盾。
勇于改变需要改变的，接受那些无法改变的，用智慧来分辨其中差异。
软件开发者不“只是写代码”，而是参与开发过程。所以如果公司在使用敏捷(Agile)，你必须对其认真对待，最起码也要对其保有尊重。
代码评审(Code review)是软件开发过程的重要组成部分。对代码评审有所疏忽就不能成为优秀的软件开发人员。
作为软件开发者，我们对自己部署的代码要负责。我们也负有道德上的责任，不要做不道德的事。
有时候对开发人员来说不重要的事情却有极高的商业价值。商业是一个好的角度，不要逃避它。
很少有公司关心你的个人成长。如果公司对你目前的水平不满意，他们一开始就不会聘用你。
对截止时间(deadline)负责。如果在截止时间前完成不了，你必须重新沟通新的截止时间。
任务有两种复杂性：内部和外部复杂性。内部复杂性不可避免，因为这是任务本身;外部复杂性来自重新架构系统过程中异常决定的后果。要格外注意外部复杂性超过内部复杂性的情况。
如果开发者在写代码或架构系统时选择容易而不是好的解决办法，他欠下的技术债迟早有一天是要还的。
会议或者聚会的价值在于在场的人，其次是交谈内容。
总结
希望小U老师的这篇分享可以帮助到大家，让大家在编程上更进一步。
