Signal and Noise

Twenty Years of DHH’s Influence on Me

原文：https://mp.weixin.qq.com/s/qwzNUQEtUbdSh00ruIhJow 标题：信号与噪音：DHH 影响我的二十年 作者：张汉东（觉学社） 译者: Grok Bot

Original by Zhang Handong (觉学社) translate by Grok Bot Lately I have been using Omarchy in earnest. One day, sitting in front of the computer, I suddenly felt something very familiar. The last time I felt it this strongly was twenty years ago. In 2005 I had just graduated from university. That year, online, I watched DHH build a blog in fifteen minutes with Ruby on Rails. Looking back now, of course it was just an ordinary web app. Database, Model, Controller, View; a few commands; some conventions; and a blog was running. But for the me of that year, those fifteen minutes were almost a shock. It was the first time I realized: Software could be written like this. What happened afterward still looks a little unbelievable in hindsight. I left the Java community for Ruby. Because of Rails, I started using a Mac. I joined one of the earliest companies in China practicing Rails, and for the first time truly touched agile development. Then came Basecamp, 37signals, Getting Real, REWORK, “small and beautiful,” Remote, and a name I only really understood many years later: Signal v. Noise. Signal and noise. Twenty years passed. I thought those things had long become the past. Only recently, sitting again in front of Omarchy, did I suddenly realize: They had never gone away. They had already become how I judge technology, products, work, even life. This is not a memoir of jobs I have held. If I have to define it, I would rather call it: A twenty-year history of how one programmer’s technical taste was formed. And DHH has been appearing, faintly, all along that road.

In 2005, we were all learning how to make software complicated

The programmer’s world of 2005 was nothing like today. Java was at its zenith. J2EE, EJB, Struts, Spring, Hibernate, XML, every kind of Application Server… A young programmer just entering the industry barely needed to think about what to learn. The path was already paved. Learn Java. Learn design patterns. Learn layers. Learn enterprise architecture. Learn how to split a system into more and more layers. Then strive to become a more “professional” software engineer. I was on that path too. When you are young, it is easy to mistake complexity for sophistication. A system with more layers. An architecture with more patterns. A project with more configuration. Code written in a more abstract style. We would think: This is what real software engineering looks like. Back then I did not yet know what “technical taste” was. Because you have not seen enough. It is hard to tell: What complexity is necessary, and what is only complexity for its own sake.

Then I saw the fifteen-minute Rails demo

What truly changed me in DHH’s Rails demo was not “you can write a blog in fifteen minutes.” It was that, for the first time, I saw: Many things we took for granted might not need to exist at all. You might not need so much configuration. Programmers might not need to explain to the framework, at every moment, what they were about to do. A framework could assume first: You are probably doing something normal. And then make those normal decisions for you. Later Rails had a line that almost became common sense in software: Convention over Configuration. Hearing it today, it barely shocks anyone. But in that era, it meant a great deal to me. It was the first time I realized: Good technology is not necessarily giving programmers more power. Sometimes it is the opposite. Good technology takes some power away from you. More precisely: It takes away the decisions that were never worth your time to think about. Looking back now, that may have been when I first developed something like a real “technical aesthetic.”

Escaping from Java to Ruby

So I began escaping from the Java world toward Ruby. “Escaping” here does not mean Java was bad. Twenty years later, I understand better than I did when young why different technologies appear in particular eras. Java solved very real problems of that time. Enterprise software has the complexity enterprise software must face. But the me of that year had suddenly grown tired of one feeling: To do something that was originally simple, we first had to build a vast world. Ruby felt like the opposite. Ruby code did not feel like describing a machine. It felt more like expressing human intention. And Rails went further. It was not only a web framework. Behind it was a strong set of value judgments: A programmer’s time is precious. A programmer’s attention is precious too. If something can be inferred by convention, no programmer should have to declare it again and again. Today I feel more and more that this may have been the starting point of many later technical choices. From then on I gradually asked one question less: What else can this technology do? And began asking another: Why should I be doing this? The two questions differ enormously. The first cares about capability. The second begins to care about choice. And taste, very likely, begins with choice.

Because of Rails, I bought a Mac

Looking back, this is even a little funny: A web framework ended up changing the computer I used. But that is exactly how it happened. Many developers in the Rails community used Macs. DHH used a Mac. The clean, restrained, beautiful product sensibility of 37signals strangely overlapped with Mac culture of that time. So I started using a Mac. For young programmers today, it is hard to imagine what it meant for a Windows programmer of that era to switch to a Mac. It was not merely changing an operating system. It was more like realizing for the first time: Tools themselves can have taste. What fonts look like. What windows look like. What animations look like. Where a button should sit. How much should appear on a screen. How software should treat its users. Even the overall feeling when you open a computer can be part of the design. Mac’s influence on me was not only making me an Apple user. It let me feel, very concretely for the first time: Beyond engineering, there is design. And design is not decoration. Design is not making something that already exists look pretty. Real design is first: Deciding what should exist. And: What should not.

Understanding agile for the first time

Because of Rails, I later entered one of the earliest Rails teams in China. That was also the first time I truly encountered agile development. Talk about Agile today and it is easy to think first of a set of processes. Scrum. Sprint. Standup. Story Point. Burndown Chart. Sometimes a company can execute agile more bureaucratically than waterfall. But when I first met agile, what moved me was not those things. It was a simpler idea: Software is not planned all at once; it grows gradually. Do a little. Look. Adjust. Let the real world keep entering the development process. Do not assume that at the start of a project you already understand everything. That affected me deeply. It was the first time it shook a superstition I had about “engineering” when I was young. I used to think: A good engineer should think everything through as early as possible. A good architect should be able to predict the future. A good system should have a complete design at the beginning. Later I slowly found: Reality is not like that. The ability you need is not accurate prediction of the future. It is: Giving the system the ability to face the future. Those two look alike; they are completely different. The former tries to eliminate change. The latter accepts change. Many years later, whether understanding Rust, type systems, boundaries, software architecture, or doing AI coding today, I find I am still learning the same thing: Do not try to control the entire future. Express the constraints that truly matter. Then allow the system to evolve.

Later I realized what I really liked was not Rails

When I was young I thought I liked Ruby. Later I thought I liked Rails. Still later I gradually realized: What attracted me may never have been any particular technology. It was the way of judging behind Rails. It was also the whole set of value judgments DHH and 37signals held about software, products, work, companies, and startups. 37signals is a strange company. It does not fully match the narrative that later became mainstream in Silicon Valley. No endless fundraising. Not treating headcount as a success metric. Not treating growing ever larger as a natural goal. Not believing every piece of software should become a Platform. Not believing a company’s final meaning is to dominate a market. While the whole world discussed: Grow. Scale. More. Faster. They kept expressing something else: Enough. A company does not have to become an empire. A product can solve only a few important problems. A team does not have to keep expanding. A founder does not have to sacrifice an entire life to a growth curve that only goes up. China later entered a huge wave of entrepreneurship. Startup, fundraising, growth, user count, valuation, IPO gradually formed a very powerful success narrative. I was inside it too, of course. But Basecamp and 37signals always left another possibility in my mind. Later we liked a phrase: Small and beautiful. I do not know if it fully captures them. But it did influence me for a long time. Not because I lacked the ability to grow large, and so comforted myself that “small is fine too.” But a more active question: Even if I can keep getting larger, is large necessarily what I want? “How to get big” is a business question. “Why must I get big” already approaches a life question.

Signal v. Noise

The blog of 37signals that influenced countless programmers was called: Signal v. Noise. Signal and noise. When I was young and saw the name, I only thought it was cool. Only later did I understand more and more that it is almost the mother theme of all of 37signals’ thought. What is Signal? What is Noise? When we first enter the industry, we always feel: More knowledge is better. More tools are better. More frameworks are better. More features are better. More free configuration is better. Bigger companies are better. More information is better. Knowing more people is better. Being able to do more things is better. But after living a little longer, you begin to find: The real difficulty in life was never obtaining more. It is recognizing: What is worth keeping. Software development is like that. Products are like that. Startups are like that. Life is like that too. And the most dangerous thing about noise is that it is usually not garbage. Things of truly zero value are easy to handle. You can throw them away directly. What is hard are those that are: “Pretty good too.” “Seems somewhat useful.” “Might come in handy later.” “Everyone else is doing it.” “Since the cost is low, why not do it while we’re at it.” This feature is also reasonable. That opportunity is not bad either. This technology is also worth studying. That person should also be known. This market seems enterable too. Each thing, alone, has a reason. So we keep adding things into systems. And keep adding things into our own lives. In the end we find: We are very busy. And may not know what we are busy with. So later I felt more and more: What Signal v. Noise really says is not: Do a little less. It is: Find the real signal.

I have grown more and more fond of deleting

Young programmers usually love creating. Add an abstraction. Add a feature. Design an architecture. Introduce a framework. Write more code. These things produce a strong sense of completion. As I age, I have grown fonder of another verb: Delete. Delete code. Delete layers. Delete process. Delete features. Delete configuration. Delete meetings. Delete things that sound good but are not that important. I even think this may be where my technical taste has changed most clearly. When young, I judged whether a system was advanced by what it “had.” Later I preferred judging a designer’s level by: What it dares not to have. Why does a good product have only so few buttons? Why does a good API expose only these concepts? Why does a language deliberately disallow some things? Why does a team decide not to do a certain business? Why does a person actively give up an opportunity that looks fine? These questions slowly became the same question for me. Because design, much of the time, is: Refusal.

From Ruby to Rust looks far; it is not that far

Later my technical path led to Rust. On the surface it looks like a huge reversal. Ruby is dynamic. Free. Extremely expressive. Emphasizing Programmer Happiness. Rust is strict. Restrained. Often first making programmers feel “unfree.” Someone who fled to Ruby because he was tired of Java’s heaviness, more than a decade later, went deep into Rust. But I feel more and more: In my technical aesthetic they never truly conflicted. What Ruby taught me then was: Do not let accidental complexity of the machine pollute human expression. What Rust later taught me was: Complexity that truly matters should not depend on human memory to maintain. Ruby was subtracting. Rust was drawing boundaries. In the end both try to do one thing: Let programmers put their attention on problems that truly matter. Ruby told me: You do not need to think about these things. Rust told me: You cannot afford not to think about these things. On the surface, complete opposites. But good technical taste was never pursuing simplicity everywhere. It is knowing: Where things should be simple. And: Where you must never pretend they are simple. That is one of the biggest changes in how I understand the word “simple,” from 2005 to today. Truly good simplicity is not the absence of complexity. It is: Complexity placed correctly where it belongs.

Twenty years later, DHH appears again on my computer

Then time arrived at today. Lately I have been using Omarchy deeply. The first time I seriously used it as a daily system, I soon felt a strange familiarity. Not because every technology in Omarchy is new. On the contrary. Much of what is in it already existed in the Linux world. Arch Linux. Hyprland. Terminal. Neovim. All kinds of command-line tools. All kinds of open software. Omarchy did not invent Linux. Just as Rails never invented databases, HTTP, MVC, or web applications. What is special is still: Someone made choices for you.

Linux never lacked freedom; it lacked judgment

The Linux world has always had a freedom that I both love and find exhausting. You can choose the distro. Desktop environment. Window manager. Terminal. Shell. Launcher. Status bar. Editor. Font. Theme. Under every component, dozens of configuration styles again. That is of course one of the most charming parts of Linux. But freedom has another side. Every “you can choose for yourself” ultimately means a decision you must make yourself. When there are only three or five such decisions, it is called freedom. When there are three hundred, it can easily become noise. The Linux world never lacked excellent software. What it often lacked was: Someone willing to stand up and say: like this. Use this for that. Not that. Shortcuts like this. Windows work like this. The terminal should be like this. Default software is these. Together they should feel like this. Not that other choices are bad. But: Choice itself must happen.

Rails and Omarchy are really the same kind of work

I suddenly understood Rails again. The most important thing about Rails was never how much power it gave programmers. It was that it dared to decide for programmers. Convention over Configuration. Twenty years later, I feel another sentence is even hidden behind that one: Opinion over Options. Judgment over options. A good tool does not necessarily lay every possibility in front of the user. A tool with real taste sometimes should have its own judgment. It should say: I know a hundred ways exist here. I have looked at some for you. I have stepped in some pits for you. This is the combination I think worth keeping. Use it this way first. Go do what you really want to do. DHH later liked to call this Omakase. The most interesting part of Omakase is not that the ingredients are finer. It is: You give up part of your right to choose. You sit down and tell the chef: I leave it to you. Behind that is trust. I believe you have seen more than I have. I believe you have already made many comparisons. I believe you have your own judgment. So I do not need to relive the whole process of choosing. Rails is like that. Omarchy is like that too. Only twenty years ago DHH picked a combination out of the complexity of web development. Twenty years later he again picked, from Linux’s nearly infinite possibility space, a set he thought most worth keeping. So I suddenly felt: Omarchy itself is an OS-level practice of Signal v. Noise.

Omarchy: catching signal from Linux’s noise

The traditional Linux world has almost everything. That is its greatest place. And also where it most easily produces noise. Countless distros. Desktop environments. Window managers. Terminal emulators. Status bars. Packages. Configs. Themes. Forums. Wikis. Posts. Everyone will tell you: “Actually you can replace this too.” “This approach is lighter.” “That approach is more Unix.” “People who really know Linux should configure it themselves.” “Your dotfiles should…” The information is not wrong. The tools are not wrong. The only question is: Where did my attention end up? Twenty years ago, the exhaustion Java gave me was: To finish something simple, I had to handle too much complexity that should not have been mine. Twenty years later, another exhaustion traditional Linux gives me is: To own a computer that is fully mine, I seem to need to answer first a mass of questions I do not really care about. The two worlds look completely different. The feeling they give me is very similar: Too much noise. And what DHH does seems not to have truly changed in twenty years. He is not constantly adding more choices to the world. He walks into an existing vast space of possibility, picks some, deletes a great deal, combines what remains, and then tells you: Try this. I feel more and more that this is a very scarce ability.

What is truly expensive is not creation, but filtering

For a long time the tech industry had a subconscious: More choices equal more power. A framework that supports 30 configurations is stronger than one that supports 3. Software with 100 features is stronger than software with 10. An OS that lets you change everything is freer than one that made many decisions for you. But today I feel more and more: Once choices are already enough, the marginal value of adding more falls fast. What becomes truly expensive is something else: Filtering. Judgment. Combination. Deletion. And someone willing to bear the risk of: “I will make this decision for you.” Creating a choice is not hard. Facing a hundred choices that are all fine, and keeping only five — that is hard. It needs knowledge. Experience. Judgment. And finally something hard to quantify: Taste.

Twenty years ago, because of DHH, I went toward Mac

Then I suddenly saw a very interesting circle between Mac and Omarchy. Twenty years ago, because of Rails, DHH, and that community, I started using a Mac. Mac then made me realize for the first time: A computer is not only a collection of hardware, OS, and applications. It can also be something designed as a whole. Someone decided the fonts for you. The windows. The defaults. The interactions. What should be exposed. What should be hidden. That completeness deeply influenced me then. Twenty years later, again because of DHH, I began seriously returning to Linux. Not because I suddenly disliked Mac. But through Omarchy I began to see on Linux another thing I like very much: Strong, complete personal judgment. It does not feel like a system debated out by a huge organization through endless committees. It feels more like someone who has also written code for decades compressed his engineering experience, aesthetic, habits, and tradeoffs of these years into one computer. Then handed it to you: This is the way I find comfortable now. Today, that kind of thing attracts me even more. Because I no longer need a system to prove to me: “I can do everything.” I would rather know: What the person who designed it chose to keep. And: Why he dared delete the rest.

Perhaps taste itself is a kind of compression

If I had to define “technical taste” today, I might say: Taste is a capacity for compression. You have seen enough. You know a hundred possibilities exist here. But in the end you can compress them to: Just these. People without experience facing ten choices often feel all ten matter. People who have been through a lot may grow simpler instead. Because they know: Nine of them do not matter that much. That is also why many truly excellent works look unusually simple in the end. Not because the designer did not know other possibilities. On the contrary. Because: He knew enough, so he dared to delete. Simplicity never equals ignorance. Often, real simplicity is compression after enormous complexity.

AI makes this problem more extreme

Then AI arrived. These years I have increasingly let AI write code. And AI pushed this problem to a new extreme. Rails once sharply lowered the cost of creating web software. AI pushes the cost of “creation” itself down several more orders of magnitude. Before, whether a feature was worth doing still had implementation cost to filter for you. Someone suddenly said: “How about we add another dashboard?” An engineer said: Two weeks. Often that feature simply vanished. Today is different. You tell an agent: Make a dashboard. Add search. Add filters. Add charts. Add export. Ten minutes, a few dozen minutes later, they may all already be there. So a natural filter once hidden inside engineering cost is disappearing. In the past many bad ideas died because they were too expensive. Today they will not. AI can very cheaply turn every “why not also…” into code. What we used to worry about was: Programmers cannot write it. What may be more worth worrying about in the future is: Programmers can write everything. AI can generate features. Generate code. Generate architecture. Generate docs. Generate UI. Generate agents. Generate tests. Generate plans. Even give you five answers at once. So something counterintuitive happens: The stronger generation becomes, the more important Signal v. Noise becomes. When Generation gets cheaper, Judgement gets more expensive. When the ability to create approaches infinity, what becomes scarce is: What should not be created.

In the AI era, humans may become signal filters again

So I more and more like another way of understanding future software development. In the past we understood programmers as: Producers of code. In the AI era that role is changing. AI can increasingly handle generation. Compilers, type systems, tests, and evidence systems can handle verification. Then one extremely important thing remains for humans: Judging what is worth letting into the system. That is, finding Signal. Drawn as a very simple process: The real world has infinite possibility. Humans first make a judgment. Leave Signal. AI turns that Signal into an implementation. Compilers, tests, type systems filter the implementation a second time. So there are actually two completely different filters. The upper filter is for: Value. The lower filter is for: Correctness. AI can help us create more and more things. But “what is worth creating” remains a very hard question. It may even be more important than before.

I finally understand what Rails taught me

Twenty years ago I thought Rails taught me: How to build web apps faster. Later I thought it taught me: Convention over Configuration. Still later I thought it taught me Programmer Happiness. Today I feel more and more: What Rails first taught me was something more fundamental: Human attention should not be wasted. Do not make me handle complexity that is not worth handling. Do not make me make meaningless decisions. Do not lay every possibility in front of me and call that freedom. A good tool should help me: Leave limited attention for problems that truly matter. Sitting again in front of Omarchy now, I see the same thing.

Twenty years on, what DHH really influenced may not be any one piece of software

Looking back now, I can barely say exactly: Which article of DHH’s, which version of Rails, which Basecamp feature, or which sentence from 37signals truly changed me. They have long mixed together. Rails. Mac. Agile. Basecamp. Getting Real. REWORK. Remote. Small companies. Small teams. Small and beautiful. Enough. Signal v. Noise. And DHH’s way of judging — always sharp for decades, sometimes deliberately keeping distance from the industry mainstream. When young I saw these as many opinions. Later I gradually found: What long contact with one person’s thought finally changes in you is often not the opinions themselves. It is his: Way of judging. Everyone else is doing it — why must I? Technically possible — why should we? The company can keep expanding — why must it? The market thinks success looks like that — why should I accept it? A system can give me a hundred options — why should I own all hundred? Everyone talks about efficiency. But what does efficiency finally serve? These questions slowly enter a person’s intuition.

Technology eventually becomes a person’s character

If I summarize technical growth from 2005 to today, I am less and less willing to describe it by: How many languages I mastered, how many frameworks I used, how many projects I did. Because those things all go out of date. Java’s era came, passed, and returned in new forms. Ruby once stood in the spotlight, then slowly stepped aside. Rails changed the whole world of web development, but many young programmers today may no longer feel the shock of that year. Mac went from a geek choice to a common developer machine. Agile went from a rebellious idea to a whole set of enterprise processes. Startups went from idealism to industry, then through wave after wave. Now AI is rewriting software development again. Technology always changes. But some things remain. I believe more and more: Technology eventually becomes a person’s character. What languages you like. What tools you choose. How you understand software. How you see complexity. What defaults you are willing to accept. When you are willing to say no. How you face growth. How you allocate your attention. Over time, they slowly become how you handle life’s problems. In 2005 I watched DHH build a blog in fifteen minutes. I thought I was seeing a new web framework. So I learned Ruby. Used Rails. Bought a Mac. Touched agile. Entered another community. Then began reading Basecamp and 37signals, and touching a software, startup, and company culture not quite like the mainstream. Twenty years passed. I walked through many technologies. From dynamic languages to Rust. From writing code myself to increasingly letting AI write code. From Windows to Mac. And now, sitting again in front of Linux. Too many things changed in between. But today, using Omarchy, I suddenly realize: There are many things here that are not worth your time. Simple. Is not simple. It is: Someone handled complexity for you. Someone saw a mass of noise. Then picked from it the signals he thought most worth keeping. My twenty years of technical growth may have been learning the same thing all along. In an ever noisier world, tell signal from noise, then let the noise pass.

PS:

这篇文章是为了首届 Omarchy 大会中国场 的宣传, 而连夜写就的,发布时间是 凌晨4点, 可以想见当时 老张的心情;

老张: 张汉东, 中国最活跃的 Rust 布道师, 编撰的教程, 在某平台上签约费都是几十个的; 从中文翻译为英文, 全程丢给 Grok , 也没有校对, 感觉哈, 很可能是老张根本就是先写了英文的, 再机械翻译为中文的; 行文短句流畅的就像 笑来老师;

俺本人非常认同这篇文章中对自身技术生涯回顾的行为, 以及行文的流畅, 排比的合理, 术语的丰富, 结构的对称, 以及得出的结论之一:

人生最后拼的还是品味

品味, 这词由 Jobs 引领, Graham 强调, LLM 们证明…现在叕重新回到热榜;

但是, 翻译过来就是: 老张不才, 技术生涯和 DHH 们一直神交不断, 从没落后 ..从JAVA 到 RoR 再到 Rust, 以及现在的 Omarchy , 都不自觉的和领域大佬们有相同的品味;

有选择固然好, 但是, 选择太多了就等于没有选择; 所以, 有贤能为所有人作出选择,是需要大智慧大能力大品味的;

于是俺的反应, 这..不就是 1984 中那位"大兄弟"嘛?

一个世界
一种品味
一位领袖

唉嘛…这好象哪里有不对了吧…

因为知识的足够多, 才敢尽情删除, 才能为大众作出选择 .. 但是, 并不必然是最好的选择吧?

比如, 这次 Omarchy 的爆火, 并不是因为组合起来的那一组老技术: Arch, Hyprland …

而是因为发起人 DHH 以及一系列高度话题化的社区行为, 看起来非常像 OpenClaw 一系列改名, 以及最短时间里变成 github 上星标最多的项目,并火速卖身入 O 社的过程; 毕竟, Omarchy 最大的亮点是 agentic OS, 可以自我优化的 OS;

那为什么选择了 Arch 作为基座, 而不是 NIX? 文件系统为什么没上 ZFS? …

太多思絮挤在缓存中提取不出清晰的断言;

只能相信, 后真相时代, 一切都等等才能知道结局;

无论一个人的品味有多高, 都不可能也不应该给整个儿世界作出所有判定/选择; Linux 之所以伟大, 并不是给出过多选择, 而是保卫了 GNU 的承诺:

Freedom is not free

以及 信号和噪音 并不是同一类事务吧?

• 信号是有信源的, 是事先注入数据的
• 噪音是后天形成的, 各种因素混入造就的

Linux 世界以及真实世界的各种选择, 并不是噪音, 而是信号; 而替大家作出选择, 并公开宣传这就是最好的组合, 这才是噪音, 只是包装的高级了些;

进一步的, 俺相信的是, 世界上自然形成的一切, 在没有被发现/引导/编译/…出各种关系进而形成新事实前;

都是噪音, 从噪音中识别出信号来的过程, 是人为的, 将自己发送的信号 ,重新还原的机械过程;

而我相信的另外一种信号是: 噪音本身足够丰富复杂时, 可能在高大尺度或是更高维度上, 才能重新编译/还原出这些自然信号本身内在的结构整体包含的智能/数据/…

就像 ted chiang 小说 呼气 中对智慧本身空间结构的阐述…

|> 260904 日糟: 1/4(每天吐糟不应超过4次)

NN 6317

      _~^--~_
  \/ /  * ☉  \ (/
    '_   𝟂   _'
    ( '--#--' <

...act by ferris-actor v0.2.4 (built on 23.0303.201916)