湾区日报文章第42辑

目录

2015/11/27 第 411 期

测试消息推送是否让用户反感

文章描述了简单的实验,测试用户收到消息推送后是否反感,是否还继续用你的 app。不发消息推送,用户把你的 app 给忘了;发了没用的消息推送,用户直接把 app 给删了。难。

值不值得开放 API

愿景是美好的:尤其是社交网络,开放 api 后就能发动人民群众创造各种有趣的 app。现实是残酷的:1)第三方 app 成为主平台的竞争对手;2)没人用这些 api,维护成本太高不划算。

OKR 不是灵丹妙药

OKR 是硅谷流行的科技公司制定计划的一套理论,起源于 Intel,由曾在 Intel 工作过的著名风投 John Doerr 及其投资过的公司们(如 Google)发扬光大。小创业公司们也纷纷采用(滥用?)OKR。

采访 Drew Houston 的父母

18 个月开始阅读;2 岁半开始玩电脑游戏;8 岁用 bbs,然后开始做游戏与逆向工程其他软件;13 岁向某游戏公司报告安全漏洞;15 岁在机器人创业公司工作,移植代码到 Linux;23 岁创建 Dropbox。
"We taught our kids that it doesn’t matter what you do, as long as you’re passionate about it and follow through. If you commit to something, you finish it, even if you hate it. And we didn’t enable our children. They had to learn how to sink or swim, and the earlier they did it the better."

First Timers Only

这是写给开源项目维护者的建议:创建一些简单的小任务,给出具体的贡献代码的步骤,加上 first-timers-only 的标签,让还没有为开源软件贡献过代码的人有活干。
为开源软件提交代码最难的地方不是敲代码这件事,而是你要搭好开发环境,然后有一个合适的任务练练手;有了第一次提交代码的经验后,以后就好办了。

2015/11/28 第 412 期

Stack Overflow 与全民编程的时代

本文通过分析 Stack Overflow 的 1 千万个问题,总结了一些有意思的数据。“今天请病假,因为 Stack Overflow 挂了,我写不了程序啦!”哈哈
面试程序员最实用的方法:看会不会使用搜索引擎与会不会在 Stack Overflow 上找答案或问问题:)Stack Overflow 的用户群体不大,只针对程序员,但却是世界上访问量前 50 几名的网站。

扁平化管理不切实际

创业公司都喜欢跟风赶潮流,很多都标榜扁平化管理。但现实是,没有结构,没人能做决定,效率变得很低,出问题了没人负责。文章讨论了一些结构化管理(不一定是等级森严才叫结构化)的想法。

Test-Driven Development is Stupid

很激进的一篇文章,有短见的地方(作者 2014 年本科毕业,在读 phd,没有工业界工作经验)。但有些观点不错,比如强调好的设计很重要,用进化的观点来看软件设计;TDD 会让程序员畏惧代码重构,趋于保守,不敢改进已有的设计。
配合这篇一起阅读:Ruby on Rails 之父:TDD 就像禁欲主义教育一样不现实

Ruthlessly Prioritize

都在讲 work-life balance,仿佛工作与生活是分开的两个列表,每个列表都有一些按优先级排序的任务。其实现实中只有一个列表,工作与生活的各种任务都是混在一起的,要全局排序:)

风投的进化:采访 Reid Hoffman

风投也在与时俱进,变成一个平台:除了给钱以外,还提供各种增值服务,就像写程序调用 api 一样,比如帮创业公司招聘,提供 growth hacking/营销/产品设计的建议,俨然一咨询公司。

2015/11/29 第 413 期

Why I’m interested in Bitcoin

科技公司想要颠覆金融行业?那你就得完全绕过现有的陈旧的低效的金融机构,你得从头开始(bitcoin)。就像你如果想颠覆 Google 或 Apple,你就不能以这俩公司为平台搭建你的东西。

给公司命名的新思路

除了取得一个好域名外,最好找一个在搜索引擎里结果很少的单词,这样你的新公司名字才比较有机会出现在搜索结果前列。比如 pets.com 是一个好域名,但 pets 作为公司名却不容易被搜索到。
在命名这件事情上(给公司,产品,或小孩命名),几乎不可能跟所有参与命名的人取得共识。所以说,"There are only two hard things in Computer Science: cache invalidation and naming things."

采访 Stripe 创始人 ceo(CS183C)

相当有思想的年轻人(1988 年出生)。谈到了 Stripe 这个创业 idea 的由来,跟自己亲弟弟一起创办公司的感受,为什么以 Stripe 作为公司的名字,公司管理方面的哲学,招聘等话题。
他很喜欢读书(尤其是历史书)。历史一再重演,读历史书就像玩游戏的时候看攻略,可以作弊:)现实中遇到的问题几乎都能在历史书里找到答案。

如何拯救即将延误的项目

最重要的是要 manage expectation,简化产品,专注于 end goal,而不是一长串的功能需求。千万不要增加更多开发人员,不能牺牲产品质量(功能少,但质量高),不要加班。
基本上,本文相当于简化版的“人月神话”-- 很多人说计算机技术更新换代很快,但其实原则性的东西是经得起时间考验,比如人月神话(1975 年出版),这本软件工程经典书籍;软件领域的工作者必读书籍。

Survive and Thrive

Justin Kan 觉得他们这帮人不是最聪明的(好吧,其他成功了的赚到钱了的人都这么说),他们的天赋只是比平均水平高一点(就读于哈佛,MIT,耶鲁),他们只是进入了高速增长的创业领域(互联网),并且能坚持到这个领域足够成熟的时候。Justin.tv 运营到第 5 年的时候才转型做游戏直播(twitch.tv)。
从 2006 年底开始,他们这群年轻人住在旧金山 Crystal Towers 公寓楼里,他们写出了一些网站:Reddit, Dropbox, Disqus, Weebly, Scribd, Justin.tv(后来的 Twitch.tv)。

2015/11/30 第 414 期

The day I became a millionaire

Ruby on Rails 之父 DHH 回顾自己银行账号的数字多了几个 0 后的心境。除了买了一辆兰博基尼以外,生活还是如此,继续做 Ruby on Rails,继续做 Basecamp(已做 10 几年了)。
与其他接触电脑比较早的小孩一样,也也是玩 BBS 长大的。
"Once you’ve taken care of the basics, there’s very little in this world for which your life is worth deferring. You’ve likely already found or at least seen the very best things (whether you know it or not). Make them count."

自己当老板:程序员为辞职创业所做的准备

不是那种高大上的巨额融资一夜成名速成独角兽的创业;而是小作坊/小咨询公司。用 10 个月时间做准备,大量阅读商业书籍学习技术以外的东西,开源节流,接私活,还完信用卡,拓广真实世界中的社交网络。

Lists

人们都喜欢 list,都喜欢诸如 buzzfeed 式的 listicle。但好像没有做得特别大的有社交功能的制作 list 的线上服务,让用户自己创建与分享自己的 list。

Intercom 的产品团队是如何运作的

很实在有料的文章,详细讲了做产品决策的几个准则,如何分配职责,如何制定计划,如何建设好的团队文化。很喜欢这种由一线工作者写的文章,而不是充满抽象理论缺乏实例的“专家”文章。
这个实践挺不错的:每周五下午 5 点,所有人在餐厅观看工程师们 demo 自己在过去一周做的东西。这样大家都能看到进度,工程师们也很乐于分享自己的杰作,也能锻炼演讲的能力:)

如何让团队里的工程师对工作不厌烦

长期做同一个项目会厌烦,维护 legacy code 会厌烦,做内部工具不光彩所以会厌烦,被别人(不懂技术的上面的人)瞎指挥会厌烦 --如何破解?本文为管理人员支招。

2015/12/01 第 415 期

How to fix a bad user interface

文中提到的 5 种 UI 状态很不错:Blank,Loading,Partial,Error,Ideal。
很多产品设计的时候只考虑最理想情况,出错信息则用编程系统默认的,比如直接让用户看到 java.net.UnknownHostException 之类的字眼:)

如何上线一个 Mac App 并成为全球第一的付费 App

PDF Expert 是 Readdle 的第一个 Mac 上的 App。他们没有拉风投,所以从一开始就得赚钱。他们在上线新产品方面还是挺有经验的。怎么做到的?打怪练级,踏实地做了 8 年的 iOS 开发。

成为一个“technical enough”的产品经理

互联网/软件行业的产品经理一般要或多或少有点工程背景(工程类的学位),技术上不用懂得太深,但也要 "technical enough"。那怎样才算 "enough"?请阅读原文:)

Radical Candor:当好领导的秘诀

当手下做得不好的时候,领导有责任提醒他/她。听起来很简单的事情,但很少领导这么做。好领导得能 caring personally & challenging directly。
文中举的这个例子不错:Sheryl Sandberg 纠正手下在 presentation 的时候说了太多的 "呃(um)" --"When you say um every third word, it makes you sound stupid." 够直接的。

优化图片加载速度

本文是采访 imgix 的 Kelly Sutton 的笔记,有一些最佳实践。imgix 处理图片的机器是 Mac Pros,而不是装 Linux 的 PC:投资在机器上的钱,每 $1 在 Mac Pros 上能比在 Linux 机器上处理更多的图片。
imgix 网站上有专门介绍他们的 Mac Pros 机房,非常酷。

2015/12/02 第 416 期

如何区分独角兽与驴子

文章提出:一个独角兽若满足这个不等式则是真的独角兽 LTV/CAC > 3(LTV 是你能从一个用户身上赚多少钱,CAC 是争取用户需花多少钱)。给出了一些实例分析,比如 Evernote 不是真独角兽。
该不等式适用于直接向用户收费的公司,而不适用于不向用户收费(或间接收费)的公司,比如靠广告为生的,或还没有稳定收入的。

做好产品,有好的设计,引起 Apple 的员工的注意(开 WWDC 的时候结交 Apple 员工,或通过 Facebook 投放广告到旧金山或 Cupertino 地区),对 App Store 宣传的时间点有所了解(比如 8 月 9 月返校大拍卖,11 月 12 月是 holiday 主题)。

Unlimited Vacation 意味着什么

很多科技公司都实行无限休假天数的政策。该政策看起来对员工是好的,但实际操作起来往往对员工不利,1. 员工不敢请假,不知道该请几天;2. 员工离职了公司也不用支付没用完的假期的那部分工资。
当然,如果公司文化不错,这种“无限休假天数”的政策实施起来也有皆大欢喜的时候。这篇文章有这方面的讨论,读一下。

三个小故事

Justin Kan 分享了 Justin.tv 创业初期的三个“失败”的小故事,以及从中学到的经验教训。
当年人手不够,每个创始人掌握一个系统的开发与运维,如果那人休假或死去,其他人就玩不动那个系统。有次,一创始人 Kyle 在 Tahoe 休假,他负责的系统挂了;其他创始人打他电话打不通,因为他当时在睡觉。十万火急,其中一创始人灵机一动,电话订餐,让送餐的人送去一句话给 Kyle:网站挂了。Kyle 睡眼惺忪打开门,得知网站挂了后,45 秒内运行重启的脚本,修复成功!

2015/12/03 第 417 期

Features Tell, but Benefits Sell

向用户宣传你的产品不应该宣传功能,而应该宣传用户用了产品后会有什么好处。卖 iPod 的广告词 - 专注功能:“容量 1GB 的 MP3 播放器”;专注用户需求:“把 1 千首歌赚到你口袋里”。哪个广告词好?
"People have little interest in purchasing a bed. What they want is a good night's sleep."

The Beggar CEO and Sucker Culture

本文对“为何我的员工工作不够努力(竟然不加班)”这个问题的吐槽。美国 IT 公司加班没有加班费,加班就意味着免费劳动;你这个 ceo 是乞丐吗?要你的员工捐献他们的时间(也能换成钱的)给你?
可怕的愚蠢的公司文化:创业公司就不能朝九晚五,一周没有工作满 60 个钟头就应该感到惭愧,一定得比老板晚回家,不敢在一天工作满 8 小时后就回家只好在公司消磨时间消磨满 10 个钟头其实什么也没做只是不敢早回家。

ODTM: One Decision That Matters

为什么奥巴马/乔布斯/扎克伯格等人常穿同一套衣服?因为他们有一堆一样的衣服,每天不用费脑子决定到底穿哪一套,每天就能少做一个决定。把精力用在做有真正重要的决定上。
时间不值钱的人会想,不就是穿什么衣服这么简单的决定,怎么会费脑子呢?Loser 们总是以为别人的时间跟自己一样不值钱,所以总会霸道地占用别人生命里宝贵的时间(可能是生命里的几分钟,可能是几小时,可能是几天,或更多)。

The 100-Hour Rule

大家都知道 1 万小时定律。本文提出一个“速成”版的 100 小时定律:创业过程中人手不够(专家也不会加入你的小破公司的),创业者们得投资时间去学习陌生的领域(招聘/销售/营销/编程/设计等)。

如何愉快地为开源项目贡做贡献

开始一个全新的开源项目是愉快的,全新的代码;一开始有人用你参与的开源软件是愉快的。但愉快地坚持下来却不容易:修 bug 没有加新功能光彩;开始要面对网上匿名的人毫无理由的抱怨与咒骂。如何保持正能量?

2015/12/04 第 418 期

Employee Equity is Broken, Here's Our Fix

Amplitude 新政策:任何员工都可以在离开公司的 10 年内行权(而不是大部分创业公司实施的 90 天,也不用像 pinterest 那样得工作满 2 年才行)。本文也可当做创业公司股权科普文章来读。
创业公司员工的股权充满陷阱,步步惊心:)

采访 Hadoop 缔造者

大名鼎鼎的 Doug Cutting。谈到了 Hadoop 生态系统的进化,谈了 Spark 与 Kafka,谈了基于开源项目起家的创业形势,以及他个人认为的下一个“创业热点”。

如何识别那些听起来不错其实很糟糕的创业 idea

文章总结了一些 pattern 让大家可以模式识别似是而非的创业想法,比如那种不专注且横跨多个市场 50 合一大礼包瑞士军刀型的产品,看起来能一口气解决多个问题,其实啥也解决不了。

制作部落冲突的公司 Supercell 成功的秘诀

一天进账 500 万欧元。一夜成功的案例?不,之前他们已经创办了一家手机游戏公司,并发展到 400 个员工,攒够了经验值,2010 年再创业,走了弯路犯了错误总结了经验教训,才有了后来的部落冲突。
游戏是创意作品,像电影音乐一样,很少有人能每个作品都大卖,更不用说能持续大卖的了。Supercell 就只做三款游戏(也有内部试验新的 idea,但主打的只有三款),着眼于长久发展,细水长流。
"Focus is not the things you do, it's the things you say no to"

多个创始人的创业公司如何分股权

来自 Y Combinator 的建议:平分股权。不能因为“我比你年龄大”/“我先想出来的的 idea”/“我先做了 2 个月”/“我放弃的工作的薪水比你高”等烂理由就想占大头。执行力比 idea 更重要。
而且,创业是持久战,没有 8 年 10 年甚至 10 几年的努力,也不能说是“创业成功”;你比别人先做了 2 个月,放到 10 几年的时间轴上看,其实也不算什么。几个创始人凑到一起,万里长征还没开始就开始为股权的事情内讧,太幼稚了。

2015/12/05 第 419 期

何为 Web 2.0(2005)

Tim O'Reilly 于十年前写的经典长文,现在看来依然收获良多。第一次互联网泡沫破灭后,生存下来的互联网公司以及当时为数不多的新生代公司所展现出来的特点,定义了所谓的 Web 2.0。
还记得十年前的互联网吗?写 blog 是很酷的事情(LiveJournal?),RSS,P2P,长尾效应/世界是平的,用户参与,Google 的一切都是最酷的,XML 很流行(SOAP?!),AJAX 很新很酷,perl 之外几个“新”的动态语言开始流行起来,sourceforge 与开源运动等。

Uber 的数据库大迁移

从 SQLAlchemy+Postgres 迁移到自家基于 MySQL 上开发的 NoSQL。数十个工程师,耗时 8 / 9 个月的开发与准备,在按下按钮的当天早晨 6 点,工程师们全体到公司报到,以防迁移过程出问题。

没有主页的线上媒体

主要通过社交平台或者其他第三方发布平台分发不同格式的原创内容,不需要有官网/或官网访问量不那么重要了。在这个趋势下,媒体公司/平台提供商/风投们该如何应对?

有效地开会

很实用的有效开会小窍门:1. 要有一个主持会议的人;2. 一开始就要声明本次开会到底是要做什么决定;3. 开完会必须要有 action items;4. 如果在规定时间内提前结束会议,那就立刻散会吧。
很多人定了 1 小时的 meeting,即使 40 分钟完事了,也要在那里磨蹭满 1 小时才走,霸占了会议室又浪费了与会同事宝贵的时间,简直是谋财害命:)

To Get More Creative, Become Less Productive

公司需要给员工足够的时间与空间才能有创新。慢下来,才能有创新。但公司评估员工主要还是看 productivity(一味求快/任务清单)。

2015/12/06 第 420 期

The Power of the Marginal

Paul Graham 写于 2006 年的文章(早年的文章确实不错)。Outsider(小人物,车库里的创业者)为什么可以改变世界,战胜 Insider(大公司,有身份的人)?
贯穿全文的案例:Steve Jobs 与 Steve Woz 在车库创业;Woz 还曾想把 Apple 原型的设计卖给他的雇主惠普,如果卖成了,就不用创业了,就没有以后 Apple 什么事了。惠普当然是看不上这种低劣的业余产品。后面都是历史了。

Apple 不同产品线的定位

很大开眼界的文章,分析与揣测 Apple 的营销策略,进而推测 Apple 的产品策略。Tim Cook 当 CEO 后的主旋律:增加产品线(Watch),对同一产品线则增加型号(iPhone/iPhone plus/iPhone 5c)。
Watch 能让你快速浏览消息推送进而少用 iPhone;iPhone 能做的事情越来越多屏幕越来越大让你少用 iPad;iPad 性能越来越好屏幕越做越大让你少用 Macbook;Macbook 是笔记本电脑让你不用台式电脑(iMac);可怜的 iMac:)趋势:小设备能做的事情越来越多,用户花在大设备的时间越来越少。

Linkedin 创始人采访 Linkedin CEO(CS183C)

Reid Hoffman 采访 Jeff Weiner。2008 年,在 Linkedin 发展到将近 400 人的时候,Reid 用了超过 30 小时面试(对话)Jeff,最终 Jeff 到 Linkedin 当 CEO。

从 Google 与 eBay 的系统架构学到的经验

本文是根据 Randy Shoup(以前在 Google/eBay 工作过)做的报告做的笔记。里面的一些小故事小八卦挺不错的。
小故事:App Engine(GAE)除了给外部用户用,也给内部其他组用。其他组滥用 GAE,造成 GAE 消耗过多计算资源。于是 GAE 组就向公司内部其他组收费。在收费的压力下,其他组就有动力改进 client code,避免 GAE 消耗过多计算资源。大公司里每个组就像一个个小公司一样,有时竞争/有时合作,互为客户关系。

The Manager as Debugger

原文被墙,iPhone 用户推荐使用
湾区日报 App
免翻墙读文章,或者看打印出的 PDF 文件。

文章讨论了好的 engineering manager 与善于 debug 的工程师的相似之处,都要从多个角度对系统进行观察进而深入理解,遍寻蛛丝马迹,力求从根本上解决问题。
Managing teams is a series of complex, black boxes interacting with other complex, black boxes. These black boxes have inputs and outputs that can be observed, but when the outputs aren’t as expected, figuring out why requires trying to open up the black box and see what is going on inside.

评论(没有评论)