2015/06/18 第250期

在 Imgur 学到的关于做产品的事情

一群人干有创造性的活,难免有争执;但有的人坚持自己的意见,只是为了维护自己的脸面,这种人要不得。应该找那种“Strong opinions, weakly held”的人。

"Try to create egoless ideation, where folks separate their self-worth from their ideas and are quick to support other’s (good) ideas. Strong opinions, weakly held."

Linus走了后Linux该怎么办

里面提到Linus亲自审阅测试别人提交的大的patch,亲测一个大patch需要10到25分钟,高峰时候一天审阅30个patch,是不是像皇帝批阅奏章一样:)

担心 Linus 走了后 Linux 该怎么办,这种感觉是不是跟几十年前很多人会担心毛主席走了后世界该怎么办一样?除了Linus以外,还有Kroah-Hartman等几个人仲裁代码,所以Linus觉得自己挂了以后,其他人是能承担起Linux的重担的。

The Product Death Cycle

产品没人用 -> 问用户到底需要什么功能 -> 做用户提议的功能 -> 产品还是没人用,进入死循环。不是简单地加功能就神奇地有人用了;提意见的用户未必是真用户,可能仅仅是声音大、瞎捣乱的罢了。

Code Review经验谈

所有很酷的(或自认为很酷的)公司都有 code review 的机制,code review 是政治正确的行为,有带新人、共享知识、保障代码质量等好处。但code review降低了开发速度,startup到什么阶段才需要引入code review机制?直到代码质量差到不能忍了?直到新人总是犯错?直到核心员工出车祸了代码顿时没人懂了?最早facebook的几个创始人直接在production服务器上改代码,版本控制基本靠放开嗓门喊;最终还是move fast了。

工程岗位培训

Esty 内部有一个对非技术人员进行工程培训的项目,教非技术人员用命令行、写简单代码、介绍系统架构、手把手地教你部署(真的)代码到(真的)生产环境中。

这种项目挺好的,增进了同事间的友谊、让非技术人员对工程师们的工作产生同理心(同情心?比如产品经理比较不会对工程师提出无理要求?哈)。还有一些公司(比如zappos)让全体员工入职的时候都要体验客服的岗位,亲自接客户电话,了解客户需求。