《打造Facebook》读后

清明小假,深圳大雨,窝在家把同事推荐的《打造Facebook》读完了。书真的很棒,和程序员的生活很近,感觉亲切,结合日常工作感触很多,此外还大大开阔了眼界。读过本书的同学应该对Facebook都有无限向往吧。

工程师的地位

以前就听说Google里的工程师地位很高,Facebook看来也不类外。这些都直接激发了工程师的各种主动、自发、积极、创新等。但我想也有很多公司里的工程师没有这样的幸运。就我所处的半导体行业,虽然工程师(指主要写软件,行业背景不多的工程师)的作用很大,但说到地位,和Google,Facebook还是也没法比。其实原因也显然易见,因为这个行业讲究背景,讲究经验,除非你的行业背景很深,很多工程师并没有太多发言权。即使是在我们善长的领域,比如前端设计等,也不是每次都可以说服那些定义需求的大佬们。这和互联网行业就有很大的不同。

地位如果别人不给,就自己争吧!如果想提高、想生长,就一定要给自己可以“折腾”的空间,如果没有也要创造。不是说一定要去学习艰深的行业知识(除非你喜欢),工作中总是会遇到问题,技术上的、流程上的,需要不断总结,运用各种手段、方法找到解决的方法。当你解决了问题,取得了一定的成绩,别人不说你的地位也高了。即使这家公司不给,别家也会给的。^_^

工具开发

开发中的工具是非常重要的!我想每个程序员都能体会。完善的Tool Chain会大大的提高工作效率,工作时的心情,会有进行艺术创作的快感。如果你改了行Code,等编译结果要5分钟,我想什么心劲都没了(这是几年前我的经历)。

像我们这种行业背景很深的公司,一般开发人员很难接触到真正的客户。所以就成就感来说,可能开发一个很Cool的工具来得更大一些。但我想使用工具还是要针对目前的大问题,像书中讲到Facebook的工具都是针对他们开发、运维中遇到的大问题,要有明确的目标,认定是值得投资的,特别是在人力资源本来就不多的情况下。

开发流程

Facebook的开发流程有很多Agile的元素,但没有看到书中强调他们使用了Agile,所以我想Agile是种自然的结果,特别是当很多聪明人在一起工作的时候。这几年的工作,也让我越来越体会到,传统的软件开发流程、项目管理本身就不适合现在的软件开发。比如产品经理提了一个很大需求,然后很多人参与讨论,制定Spec,甚至有几轮的Review,几周后终于被Boss finalize了。然后开发人员会根据Spec,做估算,做计划。开发终于开始了,可你很快会发现,几轮Review的Spec还是有问题,一个Demo Meeting之后,大伙各种建议,Spec被改,可能是小的,也可能大的。大的有些会影响你的计划,然后计划也改了。这中间我们浪费了很多资源!为什么不能在大方向有的情况下就开始做一个迭代呢,在开发中发现问题。因为很多问题(特别是细节)只有在动手之后才会发现,对着PPT很难发现什么。这样也许可以省掉几周的时间。

工作中的指导

以前读过《One Minute Manager》,很多做法和书中也有很多一样的。其实做为Leader或Manager就是要帮助下属定义明确的目标,然后及时的给反馈,不管是对的方面还是坏的。目标可以一起讨论,可以借鉴SMART原则,反馈则要根据实事,不要针对个人。

关于招聘

记住了书中那句“Hire Slow,Fire Fast”。人才对于一个技术团队实在是太重要了,一定要慎重,不能降低标准,即使慢点也是值得的。但当发现一个人不合适(观察的过程自然是较长期的),就一定要快!一团合气其实对双方都不好。但如果团队的领导年轻,有时候是很难告诉别人Bad News的,其实是不习惯之后可能的对抗,不管是激烈的还是冷的,所以一定要实事求是,摆事实,做到对事不对人。不适合在这个团队,在别的岗位可能就非常适合,公司就有这样的例子。

书中还有很多大开眼界的地方,比如Facebook的股票分配,天使投资等。下次有机会真想去Facebook看看。:)

 

《《打造Facebook》读后》有一个想法

  1. 断断续续读完了这本书. 书写的很流畅,一气惯成. 读起来挺有快感:)

    印象最深刻的是谈到创业公司员工卖出股票的经历. 学到了新东西, 原来公司给股票还需要交这么重的税.

    关于回国的部分,也可以看出来他也做了很长时间深入的思考.

    唯一有些意外的是, 题不对文. 题目是打造facebook. 而内容大部分写的是他的个人感受. 有些章节甚至和facebook都没有关系了.

发表评论

电子邮件地址不会被公开。 必填项已用*标注