解决问题：工程师思维
大多数情况，软件工程师的形象都是在电脑屏幕前实现某个产品的或系统，或者去解决某个棘手的技术问题， 但是这并不是这个工作的全部。
与程序员的区别
软件工程师的称呼意味着：你不能仅仅只是会写代码。
这个岗位称呼的差异其实也等同于说**「编程」和「软件工程」是两回事，「编程」指编写代码的活动，而「软件工程」则是在此基础上再添加时间这一维度**。正如三维的立方体不等同于二维的正方形，距离不等同于速度，「软件工程」也不等同于「编程」。
很多人认为程序员和软件工程师是同一职位的不同的称呼，我在这里并没有使用程序员这个称呼，因为在我看来两者有着本质的区别：
内在驱动的差异
工程师靠兴趣、好奇心和对事物的热爱内在驱动，主动积极前进，而不是工作的压力和薪酬的激励，工作的过程就是实现自我的方式。非工作狂，这是另外的话题
有人写程序的动力是获取成绩、金钱、升迁，这样的动机下，编程工作会变的枯燥无味，在工作中只喜欢简单/容易的任务，最好可以直接复制粘贴，改下能过关就可以开心下班，下班后也不想多看一眼代码。
有时候为了生活，不得不这样，并不是每个人写程序都会一腔热血，他的人生目标也不是成为一个伟大的工程师，写程序仅仅是谋生的手段，这样没有问题，尊重每个人的选择，但是寻找一份热爱并可以长期投入的职业真的是很幸运的事情，我觉得应该努力去尝试找到它。
不过对于很多公司来说，程序员/工程师/开发者的称谓并没有区别，所以关键还是：自我要求和追求目标的差异，所以也不用过于纠结称呼的区别。许多人的职业道路都是从学校或者小作坊进入大公司或是早期创业公司，在这个过程中大概率会经历从「程序员」到「软件工程师」的角色转变。
具备工程师思维
开发人员：“你看，在我这里是好的” --- 同事： 😓
写一段在 ”本地运行没有问题” 的代码是很容易，软件行业的难度在于规模和复杂性问题。
工程层面关注的是 ”为了什么“、”怎样实现“、”评价好坏的标准是什么“。把软件开发纳入工程范畴，意味着不仅要考虑软件功能的实现，还要考虑：
- 与基础理论的关系（比如数学、算法、计算机体系架构、存储/网络等理论）
- 与生产过程的关系（软件的构建环境、发布流程等）
- 与人的关系（用户/开发人员，需求管理，工作协同）
- 与成本的关系（不仅是实现、维护的人力成本，还有资源的消耗/维护成本等等）
所以，工程师思维可以简单归类：
- 拥有技术思维和视角：有架构设计和交付能力，性能因素亦不可忽略；
- 产品思维：产品或服务的起源是用户价值的创造；
- 工程思维：构建产品本身的流程机制、工具链和文档和社区亦不可或缺；
- 成本意识：在实现目标价值的情况下，开源节流；
- 解决问题的能力：把未知问题转化为已知问题，大问题分解为小问题，模块化系统思维；
- 懂得取舍（Trade Off），在多维度中寻找平衡；
📌 关于工程思维更通俗的解释，这篇文章是极好的，有点长，你可能需多点耐心：
- 工程思维：https://mp.weixin.qq.com/s/Wlvh53qI8ugUoQ2eSwOPdQ
题外话：“贬义” 的工程师思维
软件行业，工程师思维有时候会是贬义词，这个研发团队与产品最终用户之间的矛盾有关系，用户经常抱怨软件工程师不说人话，做出来的系统不人性化，不符合直觉，完全是工程师思维。
如果工程师的心思只想尽快交差了事，做事的时候不主动思考，再好的产品开发流程也没有办法覆盖所有细节，在这种开发环境中做出来的东西只是一堆功能的拼凑，与公司的价值观和经营理念也有很大关系。
对于工程师个人来讲，工作态度的不同很大程度上来自于自我驱动的差异。
软件工程师的自我修养
希望上面的文字有助于帮你构建「如何成为软件工程师」的职业原则与行动指引。
软件工程师能够创造出一些特别出彩的东西——无论是从技术角度还是商业角度去看。在兴趣驱动下，更愿意积极主动的花费时间深入研究技术、或某种工具、语言等。更渴望知道 “Why”，不盲从，有质疑和反叛精神亦是软件工程师的底色（黑客精神）。
在我看来，软件工程师是连接商业世界和代码世界的桥梁，而不仅仅一个闷头搞代码的搬运工。一个软件工程师的职业生涯非常重要的一步就是不再想着“我擅长什么语言”，而是开始考虑 “什么方式（编程语言、工具 🔧 等）最适合解决这个特定项目和客户的问题？”
同时，软件工程师有更多的工作选择灵活度，如果你不仅是非常优秀的软件工程师，而且还很有商业洞察和分析能力，那你还是非常稀缺的初创公司合伙人的绝佳人选，亦或者对编程技术这条道路兴趣盎然，那就寻找机会、继续深造往技术专家/架构师层面前进。
从程序员到工程师，以及到更高的职业目标，这个过程并不能一蹴而就。如果你想保持一个较长的职业生涯，并把当作终身事业来对待，这意味着你要保持持续学习和阅读、折腾的习惯，这点需要一定过的心理准备。
以此自勉。
基本素养和“软“技能
这部分的内容并不是标准答案，这里将软件工程师该拥有的基本素养和“软“技能进行汇总阐述。
持续学习
软件行业的变化速度对于持续学习有极高的要求，你的学习动机一定要非常清晰，升职加薪没有问题，但是如果缺少更深层次的动机，你很快就会对变化产生无力感，如果你有很强烈的解决问题/创造物品的原动力，为了解决问题你在持续的学习和深入，这种热情和学习动力会持续更久，而你也逐渐会成为知识的驾驭者，持续学习会从态度转化为一种基本能力。
持续学习不是指无脑的学习大量知识，而是你逐渐认清自己的兴趣和能力范畴，有目标的持续深入学习，拓展能力边界，这对很多人来说是一个痛苦且漫长的过程。
逻辑分析和抽象思考
探究事物本质和如何运转的原理，把代码看作自己非常重要的资产，有持续学习习惯；
在学习和模仿的过程中，逐渐拥有优秀的逻辑分析能力，能够对业务逻辑进行合理的抽象和拆分；
随着工作和项目经历的丰富，你对如何组织代码和设计业务架构逐渐有所得，逐渐面对软件行业很多规模性、复杂度、高可用性的问题，你在学习如何权衡决策的艺术。
工具思维
人类发展的历史，也是人类如果使用工具导致社会进步的历史。
有时候我发现，无论在我们个人生活或者工作中，我们其实都是在寻找各种工具、软件来解决问题，最后如果实现找不到我们就自己造一个，极端的情况，我们在寻找工具的路上越走越远，忘记了最初要解决的问题。
工具思维的简单总结就是需要意识到并理解工具可以带来重要的作用，教会别人捕鱼很重要，但是让制造一个工具，让不会钓鱼的人也可以轻松捕鱼价值更大，但是不被工具细节束缚或盲目选择。
在生活和工作中，工具思维有助于帮我们我们行程一些做事的方法论或决策流程（框架），对于工程师来说，追求卓越的工程实践，自动化事物需要工具思维的帮助。
如果最后你能深刻意识到，思维本身亦是一种工具，你对工具思维的理解可以说非常到位。
协作与沟通
可能有人觉得程序员不需要和别人沟通，一个人专心写代码就可以工作，这绝对是个误解，对于程序员可能会少一些面对面的沟通，但是在工作中，与他人沟通绝对是非常大的一块内容。
- 较好的英文阅读能力，能够使用英语进行日常工作及邮件、文档编写；
- 团队合作和业务理解能力，如何去沟通和理解需求，如何对任务的进行反馈、组织对细节问题（需求 or 技术）的研讨和分享，都要求工程师有良好的书面和语言表达能力；
- 代码 Review 更是强调参与、沟通，协作和沟通是否做好，决定了团队整体的技术氛围；
抛出政治和民族主义考虑，我还是很希望未来是一个技术无国界的世界，大家都可以参与开源社区的构建，能随时阅读和学习优秀的开源系统代码，这些可以让我们和全球有趣的小伙伴一起创造，希望未来不要太糟糕。
文档能力
文档和演讲时知识输出和学习非常重要的两种方式（一种总结能力的体现）。
但是很多工程师的文档能力很糟糕，我目前不太清楚这块是个人性格、能力的问题，还是整个企业工程师文化导致的，可能两者都有。
解决问题的能力
你身边有些朋友看起来非常能解决问题，无论是简单还是复杂，他们总是能热心的投入精力，探索各种方法，最后找到问题的解决方案，这种能力是天赋吗？有几个方面的原因：
-
你是否停止了思考和学习？或者搜索引擎已经完全让你放弃了主动尝试解决问题的欲望；
-
经常折腾和实践必不可少，动手能力是前提，很多知识实践之后才会成为你的；
-
作为工程师，要学会正确向其他人提问和对经验进行总结（Note or Blogs）；
你清楚的知道问题的本质是什么，一般也就有了解决方案。
-
要解决复杂问题，学会分层或者分模块拆解思考，基础知识扎实的重要性也在这里体现；当然知识的广度也非常重要；
-
学会分享见解和帮助他人；
最后，保持一个健康的身体和强健的体魄是必要的。