48 | 事务与工程：什么是工程师思维？

精选留言(19)

• 

  humor

  “经验当然是有价值的，但过于相信惯例就会抑制创新能力。”
  对于这句话不理解哎，许老师帮忙看一下啊
  1、什么是过于相信惯例呢？如果对于一个问题，已经有了一个经过验证的惯例解决方案了，那我们还需要再去尝试其他非惯例的解决方案吗？如果去尝试其他解决方案可能会导致费时费力，最后使用的解决方案的效果有很大的可能还不如惯例解决方案。
  2、创新能力与经验是呈负相关的吗？很多公司都很强调创新能力，那为了拥有比较强的创新能力，我们是不是就应该不去学习前辈的知识经验惯例了呢？但是不学习知识经验的话，可能连最基本的问题都解决不了了。

  作者回复: 1、是否应该创新与你的目标定义有关。如果你觉得花费几天时间从杭州到上海已经很好了，那么马车就足够了，但是4个小时你就得创造汽车，如果50分钟就要创造高铁。
  2、学习前辈经验不能局限于技能本身。汽车和高铁并不是无中生有产生，也是前辈经验的产物。有种学习叫迁移学习，把旧经验应用到新领域中，大部分创新由此而来。

  2019-10-11

  

   9
• 

  往事随风，顺其自然

  这个工程师地位问题，我要说句，看在什么公司，互联网还是传统行业，传统行业很低下

  2019-10-11

   1

   5
• 

  靠人品去赢

  不是工程师强势，是不强势可能被搞死，一张嘴两三天白干了。你突然来了个灵感要求立刻马上，你有没有考虑对现有业务的影响，工程的复杂度。
  实际上赚钱的业务部门才是真的强势，还是要听人家话的，按照人家的来。但是脱离事务型工作，确实有的时候是一种脱离舒适区的感受，成长是一件逆人性的事。

  2019-10-12

  

   3
• 

  CoderLim

  1、用系统化结构化的方案 close 问题；
  2、反思自己做的是新事，还是简单的重复；
  3、代码只是工具。

  2019-10-11

  

   3
• 

  张裕

  重复性的事务确实是很多人的舒适区，很多时候会成为工程化改进的阻力，比如在测试部门推广测试自动化，在研发推广全栈开发。老师能不能分享下在推行工程师文化时的一些经验？

  作者回复: 谈收益和目标，不从技术出发

  2019-10-11

  

   2
• 

  日拱一卒

  1. DRY，Don't Repeat Yourself。
  2. 做事要平衡短期价值和长期价值，重复性的事务工作，没有长期价值，但往往是“舒适区”。
  3. 工程师文化或者说工程师素质，不仅仅局限在软件开发领域，想一想工程师出现的时间，要远早于软件开发。
  4. 工程师素质强调的是解决问题，而且是永久的高质量的解决问题，这在任何领域都是普适的。

  2019-11-18

  

   1
• 

  丁丁历险记

  我作为一个客户，可以保证，七牛的销售是绝对有地位的，几年前去找气流的时候，服务热情满满。现在再去找七牛，基本上对你爱搭不理。

  作者回复: 有可能是客户交接出了问题？可以加我微信（xumingyu07）我们聊一下。

  2019-11-08

  

   1
• 

  Geek_88604f

  工程师文化是大众文化还是精英文化，不知道老师是倾向于哪一种？因为从现实情况来讲大多数公司中的工程师只负责某个模块或微服务的开发，他可以引入新技术把模块的开发工作到极致，但是可能缺乏全局视眼而没有往更高的层次发展。
          从另一个角度来讲，主要靠经验积累的技术工作是否属于老师讨论的工程师文化的范围？（例如:芯片行业的核心设备光刻机，其核心中的核心是光刻镜头，出人意料的是该镜头并非高精尖的机器打造的，而是人工打造的）
          另外，工程师文化和工匠精神有什么区别和联系，老师能不能谈谈这方面的看法？

  作者回复: 我觉得工程师文化不在于精英还是大众，在于思维方式。也许有人还不太擅长彻底解决问题，但是需要建立彻底解决问题的思考方式，以此获得不断改善的机会。工匠精神强调的是追求极致，工程师文化不只是要极致，它更在意极致的可复制性和代价。光刻镜头不能机械打磨，只是临时状态，并不代表以后不能，坚持这种想法这就是工程师文化。

  2019-11-05

   1

   1
• 

  葫芦娃

  从小受的奉献精神教育，对个人职业发展有时候反而有害。应该花更多时间在有价值的事情上，解决问题同时提升自己，而不是脏活累活，实际上公司没人在乎你的苦劳，尤其传统行业

  2019-10-12

   1

   1
• 

  Aaron Cheung

  需要关注业务导向

  2019-10-11

  

   1
• 

  Dimple

  一个公司各个岗位是彼此协作的团队，工程师并不是特殊群体。销售、技术支持、产品、开发工程师每一个角色都是平等的。每个人都应该秉承工程师精神，把一个个问题 Close，让它不要再发生。不需要显得很忙，忙不代表成就，真正的工程师文化应该是推动整个团队往前走，每个团队成员都在成长。
  
  这段话我要分享给公司的同事，其实大家都是平等的，都是为了团队而努力，并不存在所谓的优越感

  2019-11-26

  

  
• 

  Eternal

  但是我们必须清楚，在 SRE 所扮演的角色中，一定数量的事务工作是不可避免的，这其实是任何工程类工作都具有的特点。少量的事务存在不是什么大问题。但是一旦事务数量变多，就会有害了。如果事务特别繁重，那就应该非常担忧了。如果花在工程项目上的时间太少，你的职业发展会变慢，甚至停滞。我们可以鼓励那些做脏活累活的人，但仅仅限于在这些工作不可避免，并有巨大的正面影响的时候才会这样做。没有人可以通过不停地做脏活累活实现自己的职业发展
  
  这段话印象最深刻

  2019-11-23

  

  
• 

  丁丁历险记

  未能深入理解，流水账笔记先记起来。
  面对现实的复杂性。
  事物性工作，低风险，低压力，事物数量变多就不好了。
  不可避免，有正确意义时做。
  
  健康公司，业务导向。
  工程师，业务自动化，编码只是一个工具。
  舒适区，不符合工程师文化。
  每天做新的事情，旧的是否有效解决。彻底解决的思维，看中的是自己的长期价值。
  把一个个问题，close 真正的工程师，推动前进。
  少是指数级的多。
  注释代码混乱，功能开关是炸弹。
  
  复制性， 不确定性中平衡。 寻求本源，不迷信权威。
  
  工程师思维起到关键支撑。

  2019-11-08

  

  
• 

  随心而至

  1提高效率，Don’t repeat yourself
  比如，处理单个文本的时候，会不会想到正则表达式；处理多个相似文本，会不会想到用程序解决
  2.知其然，知其所以然。
  既可以一层层抽象上去，在更高的层次解决问题；也可以一层层展开，在更低的层次理解问题，

  2019-10-29

  

  
• 

  小助手

  这一章哲学性比较强了，
  理解起来有些难。。
  和拜佛求经一样，
  很难凭空顿悟，
  需要一些经验做基础。。。
  
  留做日后反复参悟吧。。。

  2019-10-24

  

  
• 

  小名叫大明

  从我的经历看，做到商务，开发，产品平等基本是不可能的。
  
  举例如下:
  
  项目型的公司，商务签单就是一个项目，如果有一个比较着急，原本3个月的排期所有程序员加班可以2个月完成［伴随bug多］，那么好，以后都是这个标准了，你要再说三个月，人家会说"上次两个月就完成了，这个也着急" （矛盾的本源可能也不是这里，矛盾的本源是工期压缩，所有人加班，待遇什么也不会变，身体垮了，身体垮了不能加班只能请你离开）
  
  

  2019-10-15

  

  
• 

  侯永强

  许老师，看了新的大纲。此前目录中有一篇:《架构范式，基于日志redo undo 设计》。很期待您能补充这么一篇内容

  作者回复: 这块会揉在架构思维中讲

  2019-10-13

  

  
• 

  ky

  工程师以系统化的方式寻求较为彻底的解决方案，软件编码是手段之一，可能也是当今世界最为通用强大的手段。工程师需要不断迭代，不断改进系统以增强事务解决能力。技术的复杂与新奇不足以过于沉醉，能够用来解决问题的思路方才是价值。

  作者回复: 👍

  2019-10-12

  

  
• 

  leslie

  老师今天的课程中“以批判精神、坚持以系统化的思维来把彻底解决问题”这个好像有点说不通吧？是不是编辑又弄错了；不过我觉得“以批判精神、坚持以系统化思维来把问题彻底解决”这倒是真正的工程师思维这确实是工程师思维的真谛；虽然这个做不到极致，不过我觉得可以做到“以批判精神、坚持以系统化思维来把问题解决且无典型隐患”。
       工程师的自我批判精神是必须的：自我批判自我否定-人才能进步；记得大学时参加新东方英文培训时老俞讲的最多的就是自我批判自我否定、相互批判相互否定，然后大家就进步了。一个Team一个技术团队要想强大就必须如此。纵然其中的一类就是在伤害另外一类，案例见得太多听的太多了。

  2019-10-12

  

  