DHH 和 Hey Way：一个程序大神的独立思考

发表于 2023-10-31 更新于 2026-03-04 本文字数： 4.5k 阅读时长 ≈ 4 分钟

20231031-dhh-and-the-hey-way

今天不小心刷到一条推送, 提出CloudExit是趋势, 如 X celebrates 60% savings from cloud exit

大跌眼镜, 遂仔细研读了文中内容. 发现并非夸夸其谈, 而是真正进行了一年多的实践, 有真正的数据.

神奇的人

直接在 https://dhh.dk/ 里看DHH的个人简介吧.

编程大神: Ruby on Rails的作者
作家: 久负盛名的的作者
企业家: 创办了 37signal 公司, 旗下两款产品, hey
LeMans赛车手
超级奶爸

不由地想起了之前不小心翻到的另外一位神人lihaoyi的博客: How to conduct a good Programming Interview

高山仰止~

神奇的事业

2个都是重复发明的轮子, 但竟然都能活的不错:

Basecamp: Project management software, online collaboration
- 是个项目管理工具.
Hey
- 看起来就是个邮件服务器+客户端, 在有 Gmail 等成熟方案下, 实在没预料到会有这种必要重复发明轮子. 但他们自己是这么说的:
- We didn’t reinvent the wheel, only email.
- 而且被证明也是个不错的商业模式.

神奇的价值观

build to last

在浮躁的互联网世界中特立独行的存在.

详细参见:

个人也非常认同他们的哲学观点:

服务到底: 在迭代如此之快, 运维存量是如此性价比之低的

充满人文关怀: HI > AI

[RECONSIDER – Signal v. Noise](https://signalvnoise.com/posts/3972-reconsider)

RECONSIDER – Signal v. Noise

respect your legacy

Ta-da List – Until the end of the internet – Signal v. Noise

serve the customer

“All companies have customers. Lucky companies have fans. But the most fortunate companies have audiences. An audience can be your secret weapon.”

Rework  - Jason Fried

与Apple的纠纷: Apple vs. HEY, antitrust, and monopoly

对于Apple强制介入支付: Our CEO’s take on Apple’s App Store payment policies | HEY

他们的理由是导致他们无法更好地服务用户. 个人也比较关注最终的后续.

最终的结果: Apple, HEY, and the path forward

You can no longer help the customer who’s buying your product with the following requests: Refunds, credit card changes, discounts, trial extensions, hardship exceptions, comps, partial payments, non-profit discounts, educational discounts, downtime credits, tax exceptions, etc.

You can’t control any of this when you charge your customers through Apple’s platform.

So now you’re forced to sell a product - with your name and reputation on it - to your customers, yet you are helpless and unable to help them if they need a hand with any of the above.

cloud exit

当然, 也有部分争议

在大家普遍认为上云是未来的, 选择了CloudExit这条路:
- 20230915 CloudExit Summary: Our cloud exit has already yielded $1m/year in savings
- Twitter is Still Up | REWORK

fxxk serverless&microservices

care the people

满满的人文关怀

Caring about costs is cool

At 37signals, we celebrate cutting costs on everything but people and their wellbeing. Don’t spend money on vendors that you could spend on employees. Vote with your dollars for a lean ship that can sail for as long as it pleases. Control thy costs, matey!

do not stress on the metrics

在大家都强调数字化运营, 他却反其道而行, 强调直觉. Making decisions without needing to rationalize every call with a depth of data. 并且能够认识到, 这么做是多么luxury的一件事儿.

The luxury of working without metrics

There are a million metrics you can use to track the health of a subscription software business like ours. Customer life-time value, cost of acquisition, cohort retention, revenue churn, net promoter score, funnel conversion rates, to name but a few. All useful calculations, but I can’t tell you what bliss it’s been to steer 37signals without them for twenty years.

Half the charm of making something to me is in letting your fingers drive the direction. Without articulation. I’ve always loved the German word fingerspitzengefühl for this concept. Making decisions without needing to rationalize every call with a depth of data.

But where I find folly is in believing that if you don’t stress the numbers, you can’t expect to see them rise. The greatest myth in management is that you can’t manage what you don’t measure. It’s hot or cold outside regardless of how many digits of precision your thermometer is showing.

Insights

The part of the business book I’ve enjoyed the most is the countless illustrations of how Musk applies his “algorithm”. A methodology for shipping everything from electric cars to Mars rockets to flamethrowers to humanoid robots. Quoted in full:

Question every requirement. Each should come with the name of the person who made it. You should never accept that a requirement came from a department, such as from “the legal department” or “the safety department.” You need to know the name of the real person who made that requirement. Then you should question it, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirements less dumb.
Delete any part or process you can. You may have to add them back later. In fact, if you do not end up adding back at least 10% of them, then you didn’t delete enough.
Simplify and optimize. This should come after step two. common mistake is to simplify and optimize a part or a process that should not exist.
Accelerate cycle time. Every process can be speeded up. But only do this after you have followed the first three steps. In the Tesla factory, I mistakenly spent a lot of time accelerating processes that I later realized should have been deleted.
Automate. That comes last. The big mistake in Nevada and at Fremont was that I began by trying to automate every step. We should have waited until all the requirements had been questioned, parts and processes deleted, and the bugs were shaken out.