四年前,我在QCon上演讲了一个《建一支强大的小团队》提到了工程师文化(http://www.infoq.com/cn/presentations/Form-powerful-team),今天,我想在这里再写一篇关于工程师文化的文章,一方面是因为我又有了一些想法和体会,另一方面,因为我也正走在创业的道路。
毫无疑问,要建一个有浓重的工程师文化的团队或公司,所以有必要把自己的相关想法形有成白底黑字的“字据”,以供打自己的脸——“要是未来没有做到,这篇文章就打我未来的脸” || “这篇文章太幼稚了,未来的我会打我现在的脸”,当然,如果要打脸,我希望是前者。
为什么要工程师文化
看看最近二十年来社会的发展,计算机和互联网已经渗透到了这个社会的每一个角落,各式各样的计算机技术成为了整个世界发展的强大引擎,各式各样的创新,无论是业务创新还是技术创新,都是依托于技术的快速演进,技术成了解放生产力提高社会运作的效率的中坚力量。以美帝为首的技术创新公司着着实实的改变着这个世界和人类的生活和生产习惯。
今天,每个从事计算机行业的技术人员都应该感到幸运,因为,我们不但选对了行业,也出生在了正确的时代,可以感受到前所未有的刺激和变化,相比起我们的父辈,我们的人生,能经历这样的时代,实在是一种幸运。所以,选对了职业并出生在了正确的年代的我们,此时只需要思考的一个问题,那就是,我是否呆在了正确的地方用正确的方式做事?
在我看来,这个世界上有三种商业公司:
- **运营或销售驱动型的公司。**这类的公司以运营和营销见长,技术对于他们来说,更多的只是为了支持大规模的营销活动,以及成本上的控制,所以,基本上来说不太需要技术创新。这种公司最大的问题就是缺乏安全感。
- **产品驱动型的公司。**这类公司以产品见长,通过创造能提升用户生活体验的产品见长,技术对于他们来说,除了支持大规模的在线用户之外,他们会更多的去寻找那些为了增强用户体验,提高整个业务流程效率的技术创新。比如:UI的交互方面的,整个业务流程方面的。这种公司最大的问题,就是容易被别人模仿和抄袭。
- **技术驱动型的公司。**这类的公司相信技术能改变世界,他们更多的是用强大的工程技术来创造有颠覆性的东西,更多的是用各种自动化的技术取代人类。比如:近代的蒸汽机技术取代了大量的人工,数字技术取代了大量信息传递的人工,现代,这类公司还希望通过人工智能来取代愚蠢的人类来做决定。这种公司最大的问题就是可能做出叫好不叫座的东西。
这三种公司都可能成功,也都有问题,但是,无一例外,他们都需要强大的技术支撑,只不过,他们把技术所放在的位置不一样。
无论你有多么的看不起技术人员,你都无法否认,你今天的生活相当的依赖这帮工程师,没有他们,你恐怕都不知道怎么生活了。邓爷爷几十年前就说过——“科学技术是第一生产力” ,无论什么样的科学技术的理论要落地都会依赖于工程技术有多先进。
所以,在今天,作为一个IT或互联网公司,“工程师文化”不是一个问题,而是一个常识!
工程师文化的特征
我下面罗列的这些特征,来源于:Google的《重新定义公司》,我在Amazon的工作经历,37Signals的《Rework》,Quora上的 What Makes Good Engineering Culture? Slideshare上的 What Makes Good Engineering Culture,以及我最近这半年来的一些实践。
简单说来,我可以简单的把这多的工程师文化的总结成两大类:“自由” 和 “效率”。
本来还应该有个“创新”,但我个人认为,创新的前提是——在自由的环境下对提高效率的痴迷,就一定会发生创新。
创新不是凭空出现新的东西,其实,观察一下人类的发展史,不难发现,几乎所有的创新基本上跳出原来的思维模式用新的思维模式对原有问题的效率进行质的提升。比如:通信、交通、医疗、教育、生活……几乎全都是在优化效率。
所以,如果你的精神不自由,你很难跳出老的思维模式,你用老的思维模式你一定不会想到新的方法和方式,如果不是对效率的提升,这个创新可能会不接地气。
因此,我认为,工程师文化就是自由加效率!
自由
首先,工程师文化意味着创新文化,工程师都是有创新冲动的人,因为手里有创造技能的人通常都会有想创造点什么的冲动。而创新的源泉水来源于精神的解放,精神自由才会引发各式各样的奇思怪想,才会有常人觉得不可能的疯狂想法和想像力,而这些想法和想像力导致了创新。
精神上的自由具体表现在:
-
**自我驱动。**自己管理自己是最好的管理。最失败的管理就是家长和保姆式的管理。兴趣出发的工作才可能迸发出真正的动力。
-
**灵活的工作时间和地点。**工程师们更多的是脑力工作,而不是体力工作,工作上时间和地点的自由安排可以让工程师们的脑力工作更有效。Remote是一个很不错的工作方式,开源社区基本上都是这钟方式。和Remote有关的话题可参看37Signals的这本书《Remote》
-
**信息平等。**这意味着,全体员工得到的是原始信息,而不是被管理者们层层加工消化后的信息,信息的屏蔽很容易造成误解和完全错误的行为。信息的平等,大的包括战略、方向、目标、财务,小的包括文档、代码、和知识的共享等。
同样,也表现在意见表达上,任何人都有可能表达自己的意见和建议的平等机会,这样才会激发出更多的思路和思辩,从而有不同的更好的思路出现。而不是,大家都看到了问题,而没有人敢说。
在Google除了代码全员共享,还有Thanks God, It’s Friday的文化,每周五,高管们会出来,任员工提各种尖锐的问题,在Amazon,代码和文档基本上全员开放,包括财务报表也对员工开放。另外,除了所有的NB的Principle SDE隔三岔五都会有一个Principle Talk(有很多Talk相当令人开脑洞),还有Amazon内部的Up the River文化,每年会选出一批公司最聪明最有想法的人集思会,讨公司下一步的和战略,并可以把相应的KPI直接按给Senior VP。
-
**不害怕错误。**处理错误的正确的姿势是分析总结教训,而不是惩罚故障人。前者让人改善进步,后者让人萎缩不前。最大的错误就是不敢犯错,最大的问题就是不敢直面问题。
-
**宽松的审批系统甚至没有审批系统。**审批通常暗示着三件事,1)对人的不完全信任,2)繁琐的流程,3)思维上的束缚。这些都是创新和想像力的天敌。一个公司的监管、审批、流程越重,这个公司的活力也就越差。
-
**20%的自由时间。**这是Google公司提出来的,员工有20%自由的时间做自己想做的项目,Gmail就是这么出来的。
效率
工程师天生是追求效率的。有人说认为程序员花大量的时间做自动化的工具,还不如人肉的效率高,比如,写自动化的脚本花5个小时,而重复做这件事200次只花3个小时。有这样的理解的人根本不懂工程。
一方面,这个工具可以共享重用,更多的人可以从中受益,这次我花5个小时开发这个工具,下次只用1小时改一下就可以用在别的地方,这是着眼于未来而不是眼下的成本。更重要的是,这是一种文化,一种提高效率的文化,他会鼓励和激发出更多的这样的事情发生。
如果你因为一个程序员花大量的时间开发自动化的工具,而认为这个程序员没有效率,对之批评甚至惩罚的话,那么你就扼杀了提高效率的文化。
人类之所以比别的动物聪明就是会使用和发明工具,而古语也有云:“工欲善其事,必先利其器”,看看美军的装备你就知道战争工具的好坏有多重要了,**一个公司的强大之处在执行力,而执行力的强大之处在于你有什么样的支持工具。**这些,已经不是工程师文化,而是人类发展的文化。
针对于工程师文化来说,尤其是软件工程,提升工程效率的具体表现如下:
-
**简化。**简化不是简陋,简单的东西通常意味着用户更好理解,也意味着更容易的维护和运维。就像阿里推行的“小而美”,就像乔布期推崇的“没有产品手册简单易用的产品”,就像Amazon推行的Working Backwards里说的那样,一个新的产品或功能,产品经理需要写三个文档:媒体公关文、用户手册、常见问题,三个文档总共加起来不超过两页A4纸,且不准用任何图片说明,目的就是为了让产品简化和容易使用。
-
**残酷无情地推行自动化。**编写程序的最本质的目的就是自动化,看看人类发展史上自动化了多少东西。对于自动化来说,不仅仅只是消除人肉的重复劳动,更重要的是,很多事情人完全干不过机器。
比如:加一台机器,程序在秒级就可以完成,而人是永远不可能达到这样的速度的,再比如:电商中用程序管理数量巨大的订单的自动化系统,加再多的人都完成的不可能像机器那样完成的又好又快。
自动化需要大力开发提高生产力的工具,比如:持续集成,持续部署,自动化运维,基础自动化运维,甚至自动化的运营工具。(Amazon的软件工程中对自动化和简代相当迷恋)
- **避免无效率的组织架构和无效率的管理。**这体现在这些方面:1)扁平化的组织架构,2)努力用自动化工具取代支持型的工作,3)不超过10个人的全栈小团队,4)不按人员的技能分工而是按其负责的产品或功能分工
5)开会不是解决问题,开会是表决提案,6)通过产品的目标或信条Tenets来减少沟通和决策过程(Amazon里的每个部门,每个团队,每个产品都有自己的Tenets,这个Tenets标明了要什么不要什么,这样可以避免很多扯皮和难缠的trade-off的决择。
比如:AWS的几个信条:运维是最高优级的——这意味着只要是会让运维变得复杂的需求都可能会工程团队被拒掉,Throughput & Latency不能更差——这意味着,功能要为性能让路,因为性能变差了,用户就要买更多的资源)
- **正确的组件抽象。**抽象是简化的一部份,一方面,抽象意味着重用和通用,另一方面抽象意味着强大的扩展性,以适配各种可能性。最重要的是,抽象意味着技术能力的输出,无论是内部的其它团队还外部的团队。
比如:Google的MapReduce/BigTable/ProtoBuffer,FaceBook的Thrift,还有Amazon内部的WebService框架Coral Service、处理日志监控的Timber,以及全线AWS产品都用到的Amazon Lock Framework(一个分布式锁框架)……
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Go语言工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Go语言全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Golang知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注Go)
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
转存中…(img-t6WA1htz-1712968469904)]
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!