什么是工程师思维
前言
在部分所谓的技术向导性公司，可能存在一些惯性思维，销售和产品经理会觉得自己没有话语权，开发工程师会觉得自己的地位高人一等。
这是不对的，推崇技术当然是正确的，但是健康的公司都必然是业务导向的公司，所有的技术人员如果希望有好的职业发展，也必然需要去理解业务。
什么才是真正的工程师文化？
从浅层意义上讲，工程师就是要实现业务的自动化。DON'T REPEAT YOURSELF! 某件重复的事情只做一个就好，以后不需要再重复做。
工程师的自动化思维体现的内在逻辑就是如何把问题 Close ，如何把问题彻底解决，而编码只是一种工具而已。
在我们日常的工作中，很多问题不需要我们用编码来解决，但是确实需要我们使用"彻底解决"的思维去完成。这种思维不限于工程师，同样适用于所有人。比如开餐厅需要解决的是服务质量问题，这一点海底捞就解决的很好，当时并不一定需要用编码的方式解决。对于我们需要的问题，如何彻底解决，这是一个值得我们深思的一个问题。
很多人喜欢待在自己的舒适区，习惯于做任务，每天重复相同的工作，就不符合我们所说的'工程师文化'。我们需要达到的状态是，今天⼲完⼀件事，明天开启新的事。
从两一个角度上看，工程师把这种问题 Close，彻底解决的思维，着重看的是自己工作的长期价值。如果我们只是在做事务，却没有在实质上解决这个问题，那么这件事情的长期价值就是零。
所以工程师文化也就是产品文化，把所有问题以一种自动化的方式解决，这才是我们应该推崇的工程师文化。
⼀个公司各个岗位是彼此协作的团队，⼯程师并不是特殊群体。销售、技术⽀持、产品、开发 ⼯程师每⼀个⻆⾊都是平等的。每个⼈都应该秉承⼯程师精神，把⼀个个问题 Close，让它不 要再发⽣。不需要显得很忙，忙不代表成就，真正的⼯程师⽂化应该是推动整个团队往前⾛， 每个团队成员都在成⻓。
系统思维和批判意识
从更层次上讲，工程师思维是一种系统化的思维，仅仅是编码和自动化是不够的，很可能我们在做的编码只是在实现某种事务性工作，而不是用系统或者结构化的方案来解决问题。
真正的工程师会系统的考虑的有效性。他们追求的是用更小的编码工作来结局更大的范围的问题。
少就是指数级别的多
现实中，⼀些⼯程师经常对于⾃⼰编写的代码形成⼀种情感依附，这是⼈之常情。⼀些⼈可能 会在你删除多余代码时提出抗议：“如果我们以后需要这个代码怎么办？”“我们为什么只是把 这些代码注释掉，这样稍后再使⽤它的时候会更容易吗？”“为什么不增加⼀个功能开关？”
这些都是糟糕的建议。
源代码的管理系统的中的回滚是很容易的，但是大量的注释代码则会造成干扰和混乱，尤其是我们还要继续演进的时，那些，由于功能开关没有开启而没有被执行的代码，更像是一颗颗定时炸弹一样等待爆炸。
极端地说，当你指望⼀个软件 24 ⼩时不间断服务时，在某种程度上来说每⼀⾏代码都是负 担。所以 SRE 需要推崇的实践是保证所有的代码⾏都有必须存在的⽬的。
从软件工程的角度上讲，传统意义的工程强调的是复制性，但是软件编码是一项不确定性很强的创新性工作，我们总是在不断的迭代出新的技术。所以软件工程是一件颇为复杂的东西，它需要在不确定性和复制性这对矛盾中寻找平衡。
所以优秀的工程是还需要有批判精神。经验当然是有价值的，但是过于相信惯例就会抑制创新能力。寻求本源，不迷信惯例和权威。以数据为指导，从根源触发去解决系统性问题。
总结
这里简单了解了什么是工程师文化，工程师文化，也就是产品文化，把所有问题以一种自动化的方式解决，这才是我们应该推崇的工程师文化。
需要达到的状态是善于把问题 Close，彻底解决的思维状态。简单的讲，今天⼲完⼀件事，明天开启新的事。
我们在平时的工作需要花点时间在项目工程上，如果我们只是在重复相同的重复性工作，我们的整个职业生涯不会有一个良性的发展。
重复性的事务工作虽然是不可避免的，这时候就需要我们用工程师的思维将问题提炼，以一种自动化的方式来解决毫无意义的重复性事务工作。
参考
【多任务处理】https://zh.wikipedia.org/wiki/多任务处理
【面向对象编程】https://www.liaoxuefeng.com/wiki/1016959663602400/1017495723838528
【许式伟的架构课】https://time.geekbang.org/column/article/89668
【什么工程师思维】https://boilingfrog.github.io/2024/04/24/什么是工程师思维/