特別節目·中文精讀

傑夫·阿特伍德:Stack Overflow 與 Coding Horror

Jeff Atwood: Stack Overflow and Coding Horror

Stack Overflow 聯合創始人聊程式設計師問答社群的興起、技術寫作與職業成長。

官方音訊00:00 / --:--
中文精讀由 AI 基於原始訪談改寫,非官方翻譯,可能存在偏差或錯誤;表述以原音訊與官方文稿為準。說明

2018 年,Stack Overflow 滿十歲。傑夫·阿特伍德(Jeff Atwood)在部落格裡寫了一篇紀念文章,標題大意是《Stack Overflow 長大後想成為什麼》。文章裡沒什麼慶功的味道,他花了大半篇幅解釋一件事:這個網站為什麼對新人這麼兇。

他自己先給了答案:Stack Overflow 從來就不是給初學者準備的。

這句話從一個把「幫程式設計師解決問題」做成全球基礎設施的人嘴裡講出來,值得琢磨。一個看起來應該張開雙臂歡迎所有人的問答網站,為什麼要刻意維持一種近乎冷淡的嚴格?答案藏在他對社群、對人、對軟體該怎麼被造出來的一整套理解裡。而這套理解比問答網站本身有意思得多。

驅動程式設計師的是解謎,錢和名聲排在後面

訪談開場,Lex 問了個看似簡單的問題:是什麼在驅動大多數程式設計師?名聲、財富、程式設計本身的過程,還是對社群的歸屬感?

阿特伍德的回答很短:是解謎。

他描述的那種狀態很具體。一個人把自己關起來,對著一個問題反覆敲打,用近乎蠻力的方式一遍遍試,直到它跑通。電腦太快了,人要算一輩子的東西,機器幾秒鐘跑完幾百萬次。程式設計師享受的正是這種用蠻力換答案的過程。聽起來不優雅,可這確實是很多人寫程式碼時最真實的快樂來源。

他舉了個例子。大部分程式設計師寫過的洗牌演算法其實有缺陷,那種樸素寫法會讓某些排列出現的機率明顯偏高。你要是在賭場幹活,正好碰上一個不太老練的程式設計師寫洗牌邏輯,後果可能很難看。這個問題怎麼被發現?不需要多聰明,把洗牌跑十億次,看看每種排列落進桶裡的分佈,答案自己就浮出來了。

蒙提霍爾問題(Monty Hall problem)是同一回事。三門問題裡該不該換門,直覺上讓人抓狂,你寫個程式跑一遍「永遠換」和「永遠不換」,兩組資料一對比,結論就擺在那兒。你想不明白沒關係,跑出來就行。

你不需要聰明,你只要用資料把它跑出來就行。(傑夫·阿特伍德)

這種「用實驗代替推理」的路子,其實也解釋了 Stack Overflow 後來為什麼會變成那個樣子。它服務的人群很明確:手裡有具體阻塞問題、需要可驗證答案、願意自己動手驗證。這類人不太需要安慰,需要的是能編譯透過的程式碼。

語言也是程式碼

阿特伍德說自己現在很少寫程式碼。Discourse 這家公司裡,他做的是管理工作。而他年輕時當程式設計師,最看不起的就是管理者,覺得那是一群自己什麼都不幹的人。

後來他的看法整個翻了過來。他發現一件挺有意思的事:語言本身就是程式碼。當你能夠清晰地指揮別人做事,你能完成的東西比一個人單幹多得多。寫程式碼是用一種形式語言告訴機器做什麼,說話是用自然語言告訴人做什麼,底層是同一個動作,只是抽象層級不同。

什麼樣的領導算好的?他給了兩條。

第一條是以身作則。這話聽起來是老生常談,但他講了個特別具體的觀察:有了孩子之後你會發現,孩子無時無刻不在看你,甚至在那些你已經看不見自己的地方。人最難看清的就是自己。你看別人一眼就能下判斷,看自己卻帶著巨大的偏見,而且往往對自己比對別人苛刻得多。

所以作為領導者,你得非常勤快地反問:我現在的行為,是不是我希望別人做出的行為?他說很多領導者在這件事上栽跟頭,做出來的決定傳遞出去的訊號完全是反的。

第二條是真正投入。他看重的是對問題本身的真實熱情,加班時長他並不在意。對解決方案有熱情的人,聽到反對意見會防禦;對問題有熱情的人,聽到更好的解法會興奮。這兩者的區別,幾天就能看出來。

他自己舉的例子是 Discourse 要解決的問題:怎麼讓一群人線上上溝通的時候,不至於退化成狼群互相嚎叫。怎麼處理 troll,怎麼讓人用完整的句子說話,怎麼讓人在討論裡不互相傷害,最後還能就某個議題達成共識。這些事聽起來瑣碎,可每一個線上社群每天都在面對。

自我認知從哪裡來

Lex 追問了個更尖銳的:你說人很難看清自己,那你怎麼知道自己哪些行為是錯的?尤其是那些你壓根沒做的事,同樣在傳遞訊號。

阿特伍德的回答分兩層。

第一層是機制。Discourse 有三個聯合創始人,他們在做決定之前會定期討論。多人討論的價值在於,誤解和盲點能被提前撈出來。至於單個人會不會犯錯,那幾乎不用討論。他對「一個領導者擁有絕對權威」這種結構評價很低。一個社群要是由一個人說了算,那個人總會有倒黴的一天,出事的時候整個社群跟著完蛋。所以他主張讓多個人共同承擔領導責任,彼此給對方反饋。

第二層更微妙。他說每個人心裡都有一個小聲音,你的直覺,你的良心,隨便你怎麼稱呼。大多數人是有道德感的,是想做對的事的。也許有極少數反社會人格不在乎,可絕大多數人希望別人覺得自己是個好人。你做的每個決定讓你感覺如何,這個訊號值得留意。

他同時承認這有副作用。程式設計師群體裡,那個「魔鬼」的聲音往往太響,自我批評過度,內向型人格尤其明顯。這就引出了更大的問題:當你必須做一個不受歡迎的決定時,怎麼辦?

答案是:把決策過程完整地講給別人聽。

這也是他反覆強調部落格和溝通重要的原因。直接甩一句「這是決定,執行吧」,沒人會服氣。換個說法:「我們為這個問題想了很久,中間發生了這些事,我們的目標是這個,我們看了這幾個選項,其中第二個更好。」對方的反應就會變成「行,我可能不完全同意,但我大概能理解你是從哪兒來的」。

關鍵區別在這裡:決定要讓人聽得出是從一個具體的人嘴裡說出來的,天上火雲裡砸下來那種感覺要儘量避免。如果你們的目標本來就不一樣,那達不成一致完全合理。這跟誰是壞人沒關係,只是出發點不同。

Stack Overflow 的誕生:一次投票和一堆失敗案例

回到源頭。2004 年,阿特伍德開始寫部落格 Coding Horror。名字來自史蒂夫·麥康奈爾(Steve McConnell)那本《程式碼大全》(Code Complete)裡的一個側邊欄插圖,畫的是一個標示危險的圖示。他特別喜歡那張圖,因為它說的正是程式設計的核心洞見:每次你寫下一行程式碼,都要想「我會怎麼把自己坑死」。人太容易犯錯了,所以你得在每一步都設計好,讓之後的自己不會把事情搞砸。

他專門寫信給麥康奈爾要授權使用這張插圖,對方同意了,而且一直同意到今天。

部落格寫了幾年,積累了大約四萬名訂閱者。他當時在一家制藥公司工作,程式設計不是公司的核心業務,身邊沒人可以聊技術。於是他把對程式設計的痴迷全部傾瀉到部落格裡。他給自己的定位是執行者,出點子這件事並不擅長。所以部落格寫著寫著,他想做點更大的事,又不知道做什麼。

轉折點是喬爾·斯波爾斯基(Joel Spolsky)。喬爾的想法很明確:有個叫 Experts Exchange 的網站,資料很好,體驗極差,像二手車銷售一樣想方設法騙你。他們決定做一個更好的版本。

Stack Overflow 這個名字是部落格讀者投票選出來的。他感慨,給東西起個好名字是電腦科學裡最難的問題之一。早期 beta 使用者幾乎全部來自他和喬爾的部落格讀者。這種重合來自他刻意的經營:先透過長期寫作建立一個小社群,然後邀請他們一起參與建設。當人們看到你在認真聽取反饋,他們會跟著你走。

你不可能聽取所有反饋,那是不可能的。但你確實在等我們的反饋,你在乎我們在做什麼。(傑夫·阿特伍德)

關於這段創業,他還講了一個反直覺的方法論:不要只盯著成功案例,去看失敗案例。所有人都盯著成功產品看,那些東西很無聊。真正有意思的是失敗的東西,因為那裡有人在實驗,有人在推進,只是最後沒成。他們失敗的原因,往往跟他們的想法本身的質量無關。

Stack Overflow 的設計是把一堆已知有效的元素拼起來,像個科學怪人:Digg 和 Reddit 的投票排序、維基百科式的可編輯、部落格式的署名歸屬感,再加上聲譽系統。聲譽系統來自一個關鍵洞察:同行的認可,是程式設計師最初做事的動力。老闆發的錢撐不了太久,同行說一句「這人真的懂」才有效。

嚴格本身沒什麼可追求的,它只是達成結果的手段

系統跑起來之後,他們很快發現一個現象:有些問題下面會有幾百個回答。一個程式設計問題怎麼可能有五百個答案?點進去一看,那些根本算不上問題,全是討論。「你最喜歡的程式設計食物是什麼」「你看過最好笑的程式設計漫畫是什麼」。這些早期被允許,後來全部禁掉。

判斷標準是什麼?他給了一條特別好用的線:這是不是你工作中真實遇到的問題?沒人上班上到一半說「我幹不下去了,因為我不知道最好笑的程式設計漫畫是什麼」。

第二條線關於學習方式。他把學習分成兩種。一種叫「意外學習」,像刷 Reddit 一樣,本來沒打算學,刷著刷著知道了樹蛙只活三年(這個資料是他隨口編的,他自己也承認)。另一種叫「有意圖的學習」,你遇到一個具體問題,需要圍繞這個問題把相關知識補齊,可能是理論,可能是編譯器原理,但都為目標服務。Stack Overflow 只服務第二種。

這套規則隨著時間越來越嚴,原因之一是聲譽系統自己帶來的張力。如果有人靠一個笑話或者一張別人的漫畫拿到五百個贊,其他程式設計師會不爽:憑什麼他靠別人的作品拿走聲譽?這跟寫出一條刁鑽的正規表示式、並附上詳細解釋說明為什麼會這樣、以後怎麼避免,完全不是一回事。後者的聲譽是應得的。

他打了個比方:嚴格的型別系統最終會贏。早期 Ruby 社群覺得動態型別很爽,不用宣告變數,出問題靠單元測試兜底。然後微軟的 C# 之父 Anders Hejlsberg 做出 TypeScript,硬給 JavaScript 套上嚴格型別,現在所有人都在說「我們上線 TypeScript 之後發現了五十個潛伏的 bug」。

嚴格並不意味著刻薄,也不意味著兇,它只是嚴格。他把這個區分講得很清楚,因為很多人在這一點上誤解了 Stack Overflow。

程式設計師為什麼會變得像電腦

訪談裡有一段特別有意思的推論。Lex 問,為什麼程式設計師有時候給人感覺很刻薄?

阿特伍德說,你想想程式設計師整天跟誰一起工作。如果你每天跟一群混蛋工作,你最後會變成什麼?混蛋。那麼,除了電腦,還有誰是世界上最大的混蛋?

電腦對你的廢話零容忍。你只要犯一個錯,一切就崩了。一個分號能讓太空任務失敗。你把這種環境內化之後,會開始覺得:哦,我的同事,也就是這臺電腦,嚴格得要命,一點情面不講,所以我也該這樣,因為我必須在所有事情上服從它的規則。

好程式設計師像電腦一樣思考,因為那是他們的工作。可如果你內化得太深,你自己就變成了那臺電腦。(傑夫·阿特伍德)

這就像偵探小說裡的套路:最好的偵探能像罪犯一樣思考,因為他們自己也沾了點罪犯的影子。程式設計師也一樣。你開始覺得「錯誤程式碼 56249」是個完全合格的報錯資訊,因為電腦就是這麼告訴你的。你忘了怎麼當一個人。

這裡沒有惡意,你只是失去了對「不嚴格」的耐心。你非常簡潔,非常不說廢話,非常「錯了,下一個」。別人問「你能幫我看看怎麼修嗎」,你的反應還是「錯了,下一個」。對電腦來說這很正常,可對面坐著的是個人。

向上抽象:從程式碼到人

作為一個寫了十幾年程式碼、後來又做了兩個大專案的人,阿特伍德說了一句聽起來很打擊人的話:要成為一個有效的程式設計師,你最終得停止寫程式碼。

他自己也知道這話對聽眾不友好,所以趕緊補充:寫程式碼這件事,會變成用越來越高階的語言在寫。

最早你寫彙編,硬編碼到具體架構上。然後有了 C,可以跨架構抽象,編譯到 ARM 或者 x86。再往上,Python、Ruby 這類解釋型語言。再往上呢?他想再抽象一層,比程式語言更高的抽象是什麼?

是自然語言。

你在用英文或者中文寫作、說話、激勵別人、給出方向、說「如果我們這樣做會怎樣」。這是最高層級的程式語言。他說自己意識到這一點的時候有點難受,因為這確實是很多程式設計師不願意接受的事實。Patrick McKenzie(也就是 patio11)寫過一篇很有名的文章講這個:把自己叫作「程式設計師」,在某種程度上是職業發展的天花板。

因為程式碼周圍的所有事情,比如人,才是真正難的部分。他在部落格裡早就反覆寫這個:程式設計更多是關於人,關於程式碼的比重沒那麼多。聽起來不合邏輯,可事實如此。這些人能不能彼此相處?能不能互相理解?你能不能跟我講清楚你到底在做什麼?你解決的是不是正確的問題?

他推薦了另一本經典:《人件》(Peopleware)。核心觀點是,軟體就是人。人本身就是軟體。

他把這個邏輯推到底:一旦你的程式設計能力過了某個門檻,任何合理的工程問題你都能解決。你不需要從零寫演算法,那種事基本不會發生。所以技術問題很少是瓶頸。真正的瓶頸是「我的經理是個混蛋」,這個問題你沒法用程式碼解決,可它對你的傷害比「我們得用那個我討厭的框架」大得多。Dave 在角落裡寫著誰也看不懂的東西,Sam 天天提交爛程式碼,這些都沒那麼致命。真正讓整個團隊停擺的,是那個有毒的同事或者上級,所有人都被壓得喘不過氣,誰也沒法幹活。

心跳:迭代速度是軟體公司的核心競爭力

這是整場訪談裡最實用的一段。

阿特伍德說,Discourse 早期他和 Robin Ward 兩個人乾的時候,他意識到一件事:每當他跑去問 Robin 一個關於 Ruby 的蠢問題,Robin 就在花時間回答他,而這段時間本來可以用來寫 Discourse 的第一個 alpha 版本。對兩個人的時間都是浪費。解法很乾脆:去僱更多合格的程式設計師。至於「我要自力更生學 Ruby」這條路,他很早就放棄了。

然後他給出了一個判斷軟體公司健康度的指標。他發過一條推文,很多人喜歡:你想衡量任何一家軟體公司的核心能力,就看這樣一件事,從有人提出「我們產品裡這個詞該改一下,使用者會更清楚」,到這個詞真正改完、上線、送到使用者手上,需要多長時間。

這就是你的生命週期。這就是你的健康度,你的心跳。如果你的心跳特別慢,你基本上已經死了。(傑夫·阿特伍德)

他說得很重。如果一個詞的修改要花兩週甚至一個月,那這家公司就沒救了。這跟閒著沒事改詞玩是兩個概念,一個明顯更好的改動,所有人都同意,然後花了幾個月才上線。這意味著你沒法迭代,你什麼都做不了。

他也澄清了另一面:心跳快不等於要像蜂鳥一樣狂跳。重點是健康,是合理。可必須跳得起來。因為軟體開發就是這麼工作的:你做出改變,推上線,跟它相處一段時間,看看感覺如何,然後說「天啊,這主意太糟了」,或者「如果加上 Y 會更好」,接著繼續轉曲柄。你轉得越多,最終跑得比競爭對手越遠。一年之後你已經在幾英里之外,他們才追上來。

他還提到一個反直覺的點。使用者抱怨「軟體又變了」的時候,他的反應是「對,就該變,一直變」。可塑性恰恰是軟體最酷的地方。你反抗這個特性,等於在跟你所建造之物的本質作對。當然他也承認有些改動確實很爛,但總體而言,擁抱這種流動才是對的。

Discourse:社群應該擁有自己

講完 Stack Overflow,話題轉向 Discourse。為什麼一個做問答網站的人,要跑去做論壇軟體?

起因是 Stack Overflow 的邊界被看清了。它只適合那些答案可以被驗證的領域,有資料、有事實、有科學依據,或者有一本權威的知識典籍可以翻。一旦離開這個範圍,引擎就失靈。

他們做過實驗。Stack Exchange 網路允許使用者提議新的問答站點,票數夠了就開站。有人提議了「撲克」和「樂高」,結果慘敗。為什麼?這兩個領域太社交了。玩撲克的人真正想聊的是「我們抽什麼雪茄」「用什麼牌好看」「這手牌我該怎麼打」,樂高玩家想說的是「看我搭的這個,帥不帥」。這些都不是問題,是分享,是討論。

沒有人會因為「我拿到同花順時該怎麼辦」而被卡住。那算不上會阻塞你的問題,只是一個聚在一起聊天的機會。(傑夫·阿特伍德)

於是他轉向論壇。2012 年底到 2013 年初他重新看了一圈論壇軟體,發現從四年前他上次看的時候到現在,一點進步都沒有。這讓他很生氣,因為他喜歡那種一群人圍繞共同熱愛的東西聊天的社群,而他們居然沒有像樣的工具。

他講了一段經歷。很多創業者來找他,說「Jeff 我有個創業點子」。他第一句話總是「你為什麼要問我?我又不懂你這行。你為什麼不去問你的使用者,問對這個社群感興趣的人?」對方說「好主意,怎麼問?」這時候他就在心裡拉起了悲傷的長號,因為所有能讓創業者和使用者、客戶、受眾對話的軟體,全都爛得他不願意推薦給別人。

而那恰恰是創業者能拿到最有價值輸入的地方。Stack Overflow 自己就是這麼做的。他花了大量時間泡在 Meta Stack Overflow 上,那是公開的社群反饋站點。90/10 法則:90% 的反饋沒法用,可能是爛反饋、瘋反饋,或者你現在根本沒法執行的反饋。剩下 10% 是金子,是鑽石,是對核心產品的真正改進,而且不太難實現。其中他最喜歡的那 5%,是他完全沒想到的:「天啊,我從來沒想到這個,但這主意太棒了。」Stack Overflow 的很多功能就是這麼來的。

Discourse 的核心理念是興趣圖譜,跟 Facebook 的關係圖譜對立。Facebook 理解的世界是狀態更新:你的朋友在餐廳吃了飯。論壇圍繞的是一個具體興趣:我熱愛電動車,我熱愛特斯拉,我熱愛他們解決問題的方式、創始人的風格、設計的倫理。他引用 The Oatmeal 那篇關於特斯拉的漫畫,說那篇東西基本上就是所有興趣社群的起源神話:一個人把自己熱愛的東西挖到極深,然後分享出來。

他對自己的描述是:他是那種會對少數幾件事極度投入、然後一頭扎進去好幾年的人。廣泛地淺嘗不是他的方式,深入扎幾件事才是。論壇正好解鎖了這種體驗。

然後是那句最關鍵的話:

我不想要一個一切都屬於 Facebook 的世界,至少我不想要。我想要一個社群能夠擁有自己的世界。(傑夫·阿特伍德)

他打了個特別形象的比方。你每週四在 Barnes & Noble 書店聚會,某天書店說「你們走吧,你們買的書不夠多」,那你就完蛋了,因為書店擁有你。換到自己有聚會空間、有俱樂部小屋,你就能定自己的規則,決定聊什麼,產出比在書店角落裡擠著好得多。

他對 Facebook 的評價很有意思。他先誇:Facebook 的執行力非常強,收購 WhatsApp 和 Instagram 是極其聰明的決定,他們還免費送 VPN 軟體,間接把所有流量資料喂回給 Facebook,讓他們看到什麼在變流行。緊接著一句:Facebook 沒什麼道德指南針,Facebook 只在乎 Facebook。它不在乎你和你的問題,只在乎自己能做多大。

社群怎麼從零長起來

Lex 問了個很實際的問題:怎麼把一個社群從一個人做到一千人?運氣、技巧、時機還是堅持?

阿特伍德的答案回到他關於部落格的那套話。他引用一位他很敬佩的人的說法:所謂寫部落格,就是你必須有一些有意思的東西要說,而且用有意思的方式說,然後堅持十年。

「有意思的東西」意味著不是所有人都在說的東西。「有意思的方式」意味著一種帶娛樂性的表達方式。

然後是儀式感。你宣佈「我每週寫三篇」,然後你必須做到。因為在你堅持幾年之前,你根本到不了任何地方。這件事要花好幾年。如果你真的熱愛它,它就不會感覺像工作。

他特別提到寫作的一個技巧,說這可能是他能給的最好的寫作建議:

把文章大聲讀出來,讀好幾遍,讓它聽起來像你在說話。因為好文章的目標就是這個。(傑夫·阿特伍德)

好的寫作應該聽起來像你說的話,只是措辭稍微好一點,因為你有更多時間思考。它念出來要自然。

關於選題,他的方法是從舊書裡挖。世界上的有趣事物太多了,如果你一天想不出一個可以聊的有意思的點,那是你不夠努力。讀經典程式設計書是一條很好的礦脈,那些書裡提出的概念往往經久不衰,你可以拿幾句話出來,同意或不同意,比較兩個概念,或者討論「這在今天還適用嗎」。你不用假裝是自己的原創,可你有了一個可以持續聊下去的常青話題。

2007 年,有人出價大約八萬到十萬美元要買他的部落格。那是一年的工資,一次性到手。他猶豫過,跟人聊過,最後還是拒絕了。理由很簡單:賣了之後,這個部落格就不再屬於他了。

他給了一條他自己也不太愛給人建議、可覺得確實有用的原則:當你面對一堆選項時,選那個讓你稍微有點害怕的。跳崖那種害怕不算在內,要的是讓你緊張的那種。選安全的那個,通常意味著你沒在推自己,沒在選那個能讓你成長的東西。

對他來說,更可怕的選擇是說不。「不,我們就看看這事能走到哪兒。」因為這樣它還是他的。

他說,假如當年說了 yes,世界會多不一樣。可能就沒有 Stack Overflow 了。

關於未來:手機是文化變遷,AI 還沒到魔法

訪談後半段聊到未來。Lex 問了兩個方向:智慧手機和人工智慧,會不會根本改變程式設計這件事。

阿特伍德對智慧手機的判斷是:它帶來的主要是文化層面的轉變,程式設計層面的變動沒那麼大。2010 年之後,每個人都隨身帶著一臺電腦,這確實是巨大的社會變化,我們到今天還在消化它的正面和負面影響。他提到自己作為極客的夢想世界就是「人人隨時隨地都在電腦上」,然後補了一句「小心你許的願」。現在人人都有電腦了,可它沒能長成我們想象的烏托邦,電腦能被用來做很多未必好的事。

至於程式設計本身,他越來越相信 Unix 那套。命令列、基礎工具,這些東西在未來很長很長時間裡還是程式設計的樣子。他不相信會有什麼神奇的視覺化程式設計顛覆這一切。他甚至想不出手機上有什麼操作能跟程式設計直接對應,想半天也沒想出什麼。

關於人工智慧,他的態度是:這個概念被過度吹捧了。很多所謂的 AI,本質上是「人非常可預測」。他舉了 Discourse 裡的一個檢查:你一小時前從紐約登入,現在從舊金山登入,那就標記為可疑。那只是條啟發式規則,一小時跑兩千英里不合理。你可能用了 VPN,可這條規則建立在「人基本上不會到處移動」這個觀察之上,非常樸素。

他說好的軟體應該預判你的需求,比如 Google 預測你的通勤路線。電腦在這塊能做得更好,可他不太願意把它叫「完整的 AI」,那只是電腦變強了。現在人人有智慧手機,我們突然有了大量以前沒有的位置資料、通訊資料,餵給一些基礎的啟發式,再加點漂亮的演算法,就變成了對你需求的預測。就像一個朋友說「我看你到家了,要不要一起吃個飯」,因為這是我們這個點通常會做的事。

落到程式設計過程本身,他覺得 AI 確實有可能幫上忙,因為程式設計裡重複太多。他舉的反面教材是 Clippy,那個「看起來你正在寫一個 for 迴圈」的曲別針。他更看好的方向是「更好的樂高積木,更大的樂高積木」:庫本身就是這類東西。你不用自己寫 HTTP 請求庫,用一個久經考驗的現成的就行。WordPress 在他看來就是一個讓非程式設計師也能做出東西的工具,透過外掛,你可以把它變成任何東西,甚至有點瘋狂。他說未來可能更多是「粘合」而不是「真正的程式設計」,這是好事,因為你需要的大部分東西已經在外面了。

至於 Unix會不會一直被沿用,他的回答很乾脆:會。他年輕時是 Windows 的忠實信徒,覺得 Unix 是浪費時間。後來他完全翻轉:Unix 那幫人基本是對的,微軟和 Windows 在伺服器端和桌面端,至少在那個年代,基本是錯的。現在蘋果的桌面系統底層也是 Unix(Darwin)。他說,不管上面套了多少層外殼,剝掉一兩層,底下還是 Unix,這個狀態會持續很長時間。

他還順帶提了一句 Discourse 自己的架構。Discourse 就是客戶端程式設計,伺服器把一大碗 JavaScript 遞給你,剩下的排序、分頁、基本計算全在你自己的機器上跑。資料當然還是要從伺服器拿,可本地的算力用得越來越多。這是程式設計重心往客戶端偏移的一個例子。至於服務端那部分,他的判斷是 Unix 哲學會繼續贏下去。

為什麼 Discourse 不做廣告

聊到商業模式時有一段很有意思。Lex 提到,廣告在最理想的狀態下其實是在服務使用者,把使用者和他們感興趣的東西連線起來,這跟 Discourse 連線興趣社群的邏輯一致。

阿特伍德說自己對廣告持一個反常的看法:他其實同意這個觀點。如果廣告就是「把你會感興趣的東西推給你」,那挺好,甚至是件好事,透過看廣告來支援做這些工作的人也是合理的。

可他還是裝了 Adblock,而且裝得很不情願。原因很實際:現在的廣告太重,為了給你看廣告要載入三四十兆的東西。他說現在的廣告像當年的 Experts Exchange,等你做出 Stack Overflow 的時候,它就什麼都不是了。廣告技術領域公司多到離譜,一張圖上密密麻麻全是 logo,小到看不清。

然後他回到現實:非常非常少的 Discourse 站點能靠廣告模式活下來。太分散,太奇怪,給的錢太少,使用者還討厭它。理論上他同意「乾淨、快速、正好是你感興趣的廣告」很棒,可我們離那個理想狀態太遠了。連 Google 在重定向那塊也只是做得還行。

真正有效的是訂閱、Patreon、亞馬遜聯盟連結這類。有人點了一個連結去亞馬遜買了東西,站點拿 2% 到 5% 的佣金,他覺得這完全公平。你在他站點上看到一輛溜溜球,點過去,買了,他分一點,合理。他自己幫過一個站長,基本上算是付錢讓對方換到 Discourse,理由很直接:「這軟體太爛了,我沒法再來了。」同時他建議對方別再做使用者討厭的廣告,全力做 Patreon,做亞馬遜聯盟。那個人照做之後效果很好,尤其是對一個內容創作者來說,這條路走得通。

機械鍵盤是一種信仰物品

訪談最後聊到 Code Keyboard,阿特伍德自己參與設計的機械鍵盤。Lex 說自己用 Kinesis,樓上就有一把。

阿特伍德的坦白很有意思。他說機械鍵盤帶不來任何功能上的必需性,你在任何鍵盤上都能程式設計,甚至螢幕鍵盤也行(說這話的時候他自己都覺得可怕)。薄膜鍵盤也能用,只是手感很差,那種薄薄的橡膠膜,按下去沒有明確的反饋點。

它本質上是一種信仰物品。它真正表達的是:我在乎鍵盤,因為鍵盤是我和電腦溝通的主要方式。就像播客要用好麥克風一樣,你想要一把好鍵盤,因為它有明確的觸感反饋,你按下鍵的那一刻能清楚感覺到那一下咔噠。

它表明你關心基礎。因為你知道什麼讓你成為一個好程式設計師嗎?打字快。(傑夫·阿特伍德)

這句話他說得很認真。打字足夠快,能把腦子裡的想法搬到程式碼庫裡,本身就是一項核心技能。練打字真的能讓你成為更好的程式設計師。

更深一層,是那種觸感帶來的愉悅,最終反哺熱情。他說自己彈鋼琴,道理一樣,技術性的、觸覺性的東西會讓人開心。他提到機械鍵盤社群已經爆炸了,Massdrop 上可能有五百個鍵盤專案,他關注的一個前 Tech Report 作者每週都在發鍵盤圖,各種炫酷的鍵盤,多到他數不過來。

Lex 說自己有一堆溜溜球,阿特伍德說這正是他講的道理。技術上你只需要一個,可你就是喜歡很多個。機械鍵盤也是一樣。

他的結論是:這些非必需的、近乎宗教性的物品,恰恰構成了人之所以為人的那部分。它讓生活值得過。嚴格來說它們都不必要,可你想想,什麼東西是真正必要的呢?

一個普通程式設計師能從這裡拿走什麼

這場對話跨度很大,從演算法聊到領導力,從社群治理聊到鍵盤手感。如果只挑幾條能馬上用上的,大概是這些。

  • 遇到搞不懂的問題,先跑資料,別硬想。洗牌演算法、三門問題、任何反直覺的邏輯,寫個程式跑一百萬次,看分佈的桶,答案比推理可靠。這也是為什麼哪怕你已經在做管理,最好還是保留一點動手做實驗的能力。
  • 把決策過程完整講出來。帶團隊也好,在社群發言也好,別隻拋結論。講清楚背景、目標、你考慮過哪些選項、為什麼選這個。別人的反對往往會變成「我理解你的出發點,雖然不完全同意」,這跟「憑什麼」是兩種完全不同的對話。
  • 衡量所在團隊的健康度,看「改一個詞要多久」。從提出改動到使用者看到改動,這個時間就是團隊的脈搏。兩週以上就是警訊,一個月以上基本停擺。想辦法縮短它,比最佳化任何單點技術都更值。
  • 寫東西的時候,把稿子大聲讀出來。讀好幾遍,直到它聽起來像你在說話。這是區分「能讀」和「好讀」最有效的一招,成本幾乎為零。
  • 在重要選擇上,挑那個讓你稍微緊張一點的。跳崖那種冒險不算,要的是讓你心裡發緊的那種。安全的選項通常意味著原地踏步。當年拒絕賣掉部落格的阿特伍德,後來做出了 Stack Overflow。
  • 如果你是新手,別把 Stack Overflow 當學習平臺。它服務的是「有具體阻塞問題、需要可驗證答案」的人。新手真正需要的是實時螢幕共享、聊天、可以隨便玩的沙盒,這些它從來不提供。找錯工具,受傷的只會是你。
  • 想建社群,先寫十年部落格。這話不是比喻。先有值得說的東西,有有意思的說法,有穩定的節奏,然後邀請讀者一起參與建設,讓他們投票命名、參與測試。社群拉不來,只能長出來。
  • 開會前先問一句:我們聊的是問題還是解決方案?對解決方案有熱情的人容易防禦,對問題有熱情的人容易吸收。團隊裡這兩種氣氛的差別,幾個月就能體現在產出上。

最後那條關於鍵盤的建議,阿特伍德自己也承認它是非必需的。可他講得對:一把手感好的鍵盤,會讓你更願意坐在那兒多敲一會兒。而多敲一會兒,往往就是所有進步的起點。

整場訪談裡他說的最實在的一句話,可能是那句「你不需要聰明,你只要用資料把它跑出來就行」。這句話能用在演算法上,也能用在帶團隊上,還能用在寫作上。把想法變成可以跑的東西,看看結果,然後改。這可能就是他十幾年裡做的全部事情。

那場關於舊金山的對話,後來沒人再提

訪談裡有個細節容易被略過。阿特伍德講到 Discourse 裡那個異地登入檢測的時候,語氣很輕鬆:「你一小時前在紐約,現在在舊金山,嗯,這挺有意思。」他把這當作啟發式規則的一個平凡例子,用來論證所謂 AI 沒那麼玄。可這段話背後藏著一個更大的判斷:軟體對使用者行為的預測,大部分時候只是把人類的重複性寫成程式碼。

他說人非常可預測。你每天大致在同一時間起床,走同一條路去上班,在同一個便利店買咖啡。Google 預測你的通勤路線,靠的就是這份重複。它沒什麼魔法,只是把你的行為模式記住了。他說這更像一個朋友說「我看你到家了,要不要一起吃飯」,因為它知道你這個點通常幹這個。

問題在於,這套邏輯在社群產品裡會變得微妙。預測得準,使用者覺得貼心;預測得太準,使用者覺得被盯著。Discourse 是開源軟體,每個站點自己託管資料,這件事上他站在使用者這邊:資料在你自己手裡,你才有可能決定它被怎麼用。這又繞回他那個核心主張,社群應該擁有自己。

為什麼他總在誇對手

整場訪談裡有個反覆出現的模式,值得單獨說一句。他批評 Facebook 的時候,一定會先誇一句「他們執行力非常強」「收購 WhatsApp 和 Instagram 是極其聰明的決定」。他批評微軟早年的方向,緊接著承認 TypeScript 出自 C# 之父 Anders Hejlsberg 之手,是軟體史上最聰明的頭腦之一。他談到自己已經完全轉向 Unix 陣營,仍然會說蘋果的桌面系統底層也建在 Unix 上。

這種既能批評又能準確承認對方強項的能力,在技術圈並不常見。多數人一旦站定陣營,就會把對面的所有東西都歸為垃圾。他的做法更像一個工程師在評估方案:這個選擇在什麼條件下是對的,在什麼條件下是錯的。他討厭 Facebook 的道德取向,可他不會因此說 Facebook 的技術爛。這兩件事在他腦子裡是分開的。

這可能也是他做社群能做這麼久的原因。一個總覺得對手一無是處的人,沒辦法設計出一個真正好用的替代品,因為他不知道對手到底做對了什麼。

十年這個數字,他反覆提到過

把訪談裡散落在各處的「十年」串起來看,會發現一條挺清晰的線。

他說寫部落格要「堅持十年」,才可能到任何地方。Discourse 一開始他定的是五年計劃,很快就改成十年,因為三年才能把產品做成你想要的樣子,而第一版一定是爛的,可你還得先把它發出去。Stack Overflow 到 2018 年正好十年,他寫文章反思它長成了什麼樣子。學 Unix 的知識幾十年不失效,學人性的知識也同樣耐用。

十年在他這裡像是一個基本單位。短於這個尺度的事情,他沒太大興趣談成功或失敗。這個時間感跟當下技術圈的主流節奏差得很遠,今天的標準節奏是三個月做出 MVP,一年內找到 PMF,兩年內要麼規模化要麼死掉。他那套「三年才做出想要的產品,十年才算走完一輪」的說法,聽起來像是另一個時代的話。

可他自己給了辯護。他說你轉曲柄的次數越多,最終跑得越遠。轉曲柄這件事本身需要時間,而時間沒法壓縮。你能壓縮的只有每次轉動的週期,也就是他說的那個心跳。心跳快一點,同樣十年能轉更多圈。這可能就是他全部方法論裡最核心的一條:把迴圈週期壓到最短,然後一直轉下去。

演算法是這樣,跑十億次看分佈。寫作是這樣,每週三篇讀出來聽。社群是這樣,每次反饋都回應。公司也是這樣,一個詞的改動從想法到上線,越快越好。

這套東西樸素到有點無聊。可他在訪談裡從頭到尾沒換過別的說法。

文稿由本站用語音識別模型(基於官方釋出音訊)機器轉寫,可能有識別錯誤,人名與數字請以音訊為準。
[00:00:00] The following is a conversation with Jeff Atwood, he's the co-founder of Stack Overflow and Stock Exchange websites that are visited by millions of people every single day. Much like with Wikipedia, it is difficult to understate the impact on global knowledge and productivity that these networks of sites have created. Jeff is also the author of the famed blog Coding Core and the founder of Discourse and Open Source Software, a project that seeks to improve the quality of our online community discussions. This conversation is part of the MIT course on artificial general intelligence and the Artificial Intelligence Podcast, if you enjoy it. [00:00:41] Subscribe on YouTube, iTunes or your podcast provider of choice. Or simply connect with me on Twitter at Lex Friedman spelled Frid. And now here's my conversation with Jeff Atwood. Having co created and managed for a few years, the world's largest community of programmers and stack overflow 10 years ago, what do you think? Motivates most programmers. Is it fame, fortune, glory, process of programming itself, or is it the sense of belonging to a community? [00:01:31] It's puzzles, really. I think it's this idea of working on puzzles independently of other people and just solving a problem, sort of like on your own, almost. Although, you know, nobody really works alone in programming anymore. But I will say there's there's an aspect of sort of hiding yourself away and just sort of beating on a problem until you solve it. Like brute force basically to me is what a lot of programming is, is like the computer so fast. [00:01:59] Right. You can do things that would take forever for a human, but you just do them like so many times and so often that you get the answer right. [00:02:07] You're saying just the pure act of tinkering with the code. Yes. [00:02:10] This is the thing that drives most probably the joy, the struggle, balance within the joy of overcoming the brute force process of pain and suffering that eventually leads to something that actually works well. [00:02:24] Data is fun to like. There's this thing called the the shuffling problem, like the naive shuffle that most programmers write has a huge flaw. And there's a lot of articles online about this because it can be really bad. If you're like a casino and you have an unsophisticated programmer writing your shuffle algorithm, there's surprising ways to get this wrong. But the neat thing is the way to figure that out is just to run your shuffle a bunch of times and see like how many orientations of card you get. [00:02:47] You should get an equal distribution of all the cards and with the naïf method of shuffling, if you just look at the data, if you just brute force and say, OK, I don't know what's going to happen, you just write a program that does it a billion times and then see what the buckets look like of the data. And the money hall problem is another example of that, where you have three doors and somebody gives you information about another door. [00:03:08] So the correct answer is you should always switch the money hall problem, which is not intuitive, and it freaks people out all the time. Right. But you can solve it with data. [00:03:15] If you write a program that does the Monty Hall, you know, game and then never switch is then always which is just compare, you would immediately see that you don't have to be smart. Right. You know, to figure out the answer algorithmically. You can just brute force it out with data, say, well, I know the answer is this because I ran the program a billion times and these are the data buckets that I got from it. [00:03:33] Right. [00:03:34] So empirically find it. But what's the joy of that? So for you, for you personally, outside of family, what motivates you in this process is? [00:03:44] Well, to be honest, I don't really write a lot of code anymore. Like what I do, a discourse is like managerial stuff, which I always kind of despised. [00:03:52] I like as a programmer, you think of managers as people who don't really do anything themselves. [00:03:57] But the weird thing about code is like you realize that like language is code, like the ability to direct other people lets you get more stuff done than you could by yourself. [00:04:06] Anyway, you said language is code language is meaning communication with other humans. Yes, you can think of it as a systematic. So what is it like to be. What makes before we get into programming, what makes a good manager, what makes a good leader? Well, I think a leader, it's all about leading by example. First of all, like sort of doing and being the things that you want to be. Now, this can be kind of exhausting, particularly have kids, because you realize that your kids are watching you like all the time, like even in ways that you've stopped seeing yourself, like the hardest person to see on the planet. [00:04:37] Just really yourself. Right. What do you see other people and make judgments about them but yourself, like you're super biased. You don't actually see yourself the way other people see you often. You're very, very hard on yourself in a way that other people really aren't going to be. [00:04:49] So, you know, that's one of the insights is, you know, you've got to be really diligent about thinking like, am I behaving in a way that represents how I want other people to behave? Right. Like leading through example. There's a lot of examples of leaders that really mess this up. Right. Like they make decisions that are like, wow, that's why, you know, it's just it's a bad example for other people. So I think leading by example is one the other one, I believe is working really hard. [00:05:15] And I don't mean like working exhaustively, but like showing a real passion for the problem, like, you know, not necessarily your solution to the problem. But the problem itself is just one that you really believe in, like with discourse, for example. [00:05:27] The problem that we're looking at, which is my current project, is how do you get people in groups to communicate in a way that doesn't, like break down into the howling of wolves? Right. Like, how do you deal with trolling? Not like technical problems of how don't you people to post paragraphs? How do I get people to use bold how to get people to use complete sentences, although those are problems as well. But like, how do I get people to get along with each other. [00:05:48] Right. Like and then solve whatever problem it is they set up to solve or, you know, reach some consensus on discussion or just like not hurt each other, even like maybe it's a discussion that doesn't really matter. But are people like, yelling at each other? Right. And why write like that's not the purpose of this kind of communication. So I would say, you know, leadership is about, you know, setting an example, you know, doing the things that represent what you want to be and making sure that you're actually doing those things. [00:06:12] And there's a trick to that, too, because the things you don't do also say a lot about what you are. [00:06:17] Yes. So let's pause on that one. So those two things are fascinating. So how you have as a leader, is that self-awareness? You just said it's really hard to be self-aware. So for you personally or maybe for other leaders, you've seen her look up to, how do you know the both of the things you're doing are the wrong things to be doing, the way you speak to others, the way you behave and the things you're not doing. [00:06:39] How do you how do you get that signal? [00:06:40] There's two aspects that one is like processing feedback that you're getting. So how you get feedback. Well, right. Are you are you getting feedback right? Like, so one way we do it, for example, a discourse. We have three co-founders and we periodically talk about decisions before we make them. So it's not like one person can make a mistake or like, wow, that's you know, there can be misunderstandings, things like that. So it's part of like group consensus of leadership is like it's good to have, I think, systems where there's one leader and that leader has the rule of absolute law are just really dangerous in my experience for communities, for example, like if you have community run by one person, that one person makes all decisions. [00:07:12] That person's going to have a bad day. Something could happen to that person. You know something? You know, there's a lot of variables. So like, first, when you think about leadership, have multiple people doing leadership and have them talk amongst each other. So they're giving each other feedback about the decisions that they're making. [00:07:27] And then when you do get feedback, I think there's that little voice in your head, right. [00:07:31] Like or your gut or whatever you want to put it in your body. I think that voice is really important. Like I think most people who have any kind of moral compass or like want to do. Most people want to do the right thing. I do believe that. I mean, there might be a handful of sociopaths out there that don't. But most people, they want other people to think of them as a good person. Why wouldn't you? [00:07:50] Right. Like, do you want people to despise you? I mean, that's just weird, right? So you have that little voice, that sort of the angel and devil on your shoulder sort of talking to you about like what you're doing, how you're doing, how does it make you feel to make these decisions? Right. [00:08:01] And I think having some attunement to that voice is important. But you said that voice also for I think there's a programmer situation, too, where sometimes the devil on the shoulder is a little a little too loud. So you're a little too self-critical for a lot of developers, and especially when you have introverted personality. How do you struggle with a self-criticism or the criticism of others? So one of the things of leadership is to do something that's potentially unpopular or people doubt you and you still go through with the decision. [00:08:33] So what's that balance like? [00:08:36] I think you have to walk people through your decision making, right? You have to this is where blogging is really important and communication is so important. Again, code language is just another kind of code is like here is the program by which I arrived at the conclusion that I'm going to reach right now. [00:08:48] It's one thing to say, like this is a decision, its final deal with it. Right. That's not usually satisfying to people. But if you say, look, you know, we've been thinking this problem for a while. Here's some stuff that's happened. Here's what we think is right. Here's our goals. Here's we want to achieve. And we've looked at these options and we think this of the two options is the best option. People be like, oh, OK, right. [00:09:07] Maybe I don't totally agree with you, but I can kind of see where you're coming from. [00:09:09] And like, I see, it's not just arbitrary decision delivered from a cloud of flames in the sky. Right. It's like. A human trying to reach some kind of consensus about, you know, goals and their goals might be different than yours, that's completely legit, right. But if you're making that clear, it's like, oh, well, the reason we don't agree is because we have totally different goals. Right. Like, how could we agree? [00:09:28] It's not that you're a bad person, it's that we have radically different goals in mind. When we started looking at this problem. [00:09:33] And the other one you said is passion so or hard work. Sorry. [00:09:37] Well, those are tied together to me in my mind and say hard work and passion. Like for me, like I just really love the problem discourses setting out to solve, because in a way it's like there's a there's a vision of the world where it all devolves into Facebook basically owning everything and every aspect of human communication. [00:09:52] Right. And this has always been kind of a scary world for me first, because I don't I think Facebook is really good at execution. [00:09:57] I got to compliment them. They're very competent in terms of what they're doing. But Facebook has not much of a moral compass in terms of Facebook cares about Facebook, really. They don't really care about you and your problems. What they care about is how big they can make Facebook right. [00:10:11] Is you talking about the company or just the mechanism, how Facebook works? [00:10:15] Kind of both really like and the idea with discourse. The reason I'm so passionate about it is because I believe every community should have the right to own themselves. Right. Like they should have their own software that they can run that belongs to them. That's their space where they can set the rules. And if they don't like it, they can move to different hosting or, you know, whatever they need, they need to have it can happen. [00:10:33] But like this this idea of a company town where all human communication is implicitly owned by WhatsApp, Instagram and Facebook. And it's really disturbing, too, because Facebook is really smart. Like I said, they're great at execution buying and WhatsApp and buying Instagram were incredibly smart decisions. And they also do this thing on, if you know. But they have this VPN software that they give away for free on smartphones and it indirectly feeds all the data about the traffic back to Facebook so they can see what's actually getting popular through the VPN. [00:11:00] Right. They have low level access to the network data because users have let them have that. [00:11:05] So they'll take a small pause here. First of all, discourse, can you talk about can you lay out the land of all the different ways you can have communities? So there's stack overflow that you've built. There's discourse. Yeah. So Sackhoff is kind of like a wiki Wikipedia you talk about, and it's a very specific scalpel, very focused. So what is the purpose of discourse and maybe contrast that with Facebook. First of all, say what is discourse. [00:11:33] Yeah, start from the beginning. Well, let me start from the beginning. So Stack Overflow is very structured wiki style Q&A for programmers. Right. And that was the problem we first worked on when we started. We thought it was discussions because we looked at like programming forums and other things. But we quickly realized we were doing Q&A, which is a very narrow subset of human communication space. [00:11:52] So when you started Psychoville, you thought you didn't even know the Q&A. Now, it would be you and I. [00:11:58] Well, we didn't know we we had an idea of like, OK, these are things that we see working online. We had a goal. Right? Our goal was there was this site experts exchange with a very unfortunate. [00:12:08] Thank you for killing that site. Yeah, I know. Right. Like, a lot of people don't remember it anymore, which is great. Like that's the measure of success. When people don't remember the thing they were trying to replace, then you've totally won. So it was a place to get answers to programming questions, but it wasn't clear if it was like focused Q&A, if it was a discussion, there were plenty of programming forums. So we weren't really sure. [00:12:26] We were like, OK, we'll take aspects of Digg and Reddit like voting. We're very important reordering answers based on votes, wiki style, stuff like being able to edit post not just your post but other people's post to make them better and keep them more up to date ownership of blogging of like, OK, this is me saying, this is my voice. You know, this is the stuff that I know. And, you know, you get your reputation accrues to you and it's peer recognition. [00:12:50] So you asked earlier, like, what motivates programmers? I think peer recognition motivates them a lot. That was one of the key insights of stack overflow is like recognition from your peers is why things get done initially. Money, not so your boss, but like your peers saying, wow, this person really knows their stuff has a lot of value. So the reputation system came from that. So we were sort of Frankensteinian a bunch of stuff together in stack overflow of like stuff we had seen working and we knew worked and that became stack overflow. [00:13:19] Over time we realized it wasn't really discussion. It was very focused questions and answers. There wasn't a lot of room on the page for. Let me talk about this tangential thing. It was more like, OK, is it answering the question? Is it clarifying the question? Or could it be an alternative answer to the same question? Because there's usually more than one way to do it in program. There's like, say, five to ten ways. [00:13:38] And one of the patterns we got to do early on and stack overflow is there are questions where there would be like hundreds of answers. [00:13:43] We're like, wow, how can there be a programming question with five hundred, two hundred, five hundred answers? [00:13:50] And we looked at those and we realized those were not really questions in the traditional sense. They were discussions. It was stuff that we allowed early on that we eventually decided wasn't allowed, such as what's your favorite programming food? You know, what's the funniest programming cartoon you've seen? And we had to sort of backfill a bunch of rules about like, why isn't this allowed? Such as is this a real problem you're facing? Like nobody goes to work and says, wow, I can't work because I don't know what the funniest programming cartoon is. [00:14:14] So sorry. Compile this code now, right, it's not a real problem you're facing in your job. That was reenroll. And the second like what can you really learn from that? [00:14:22] It's like what I call accidental learning or Reddit style learning where you just like to just browse some things and. Oh, wow, you know, did you know tree frogs only live three years? I mean, I just made that up. I don't know. That's true, but I didn't really set out to learn that. [00:14:34] I don't need to know that. Right. It's an accidental learning. It was more intentional learning where like, OK, I have a problem and I want to learn about stuff around this problem having. Right. [00:14:42] And it could be theory. It could be compiler theory. It could be other stuff. But I'm having a compiler problem. Hence I need to know the compiler theory, that aspect of it that gives me the the gets me to my answer. Right. [00:14:53] So kind of a directed learning sphere to backfill these rules as we sort of figured out what the heck it was we were doing. And this system came very strict over time. And a lot of people still complain about that. And I wrote my latest blog entry, What to Stack Overflow Want to be wanted to be when it grows out, celebrating the ten year anniversary. Yeah, yeah. [00:15:09] So ten years and that system has trended towards strictness. There's a variety of reasons for this. One is people don't like to see other people get reputation for stuff as they view they view as frivolous, which I can actually understand because if you saw a programmer got like 500 upvotes for funniest programming cartoon or funniest comment they had seen, and it's like, well, why do they have that reputation is because they wrote the joke? Probably not. I mean, if they did, maybe or the cartoon. [00:15:33] Right, they're getting a bunch of reputation based on someone else's work. That's not even like programming. It's just a joke. Right. It's a related opinion. So you begin to resent that. You're like, well, that's not fair. And it isn't. At some level they're correct. I mean, I empathize because, like, it's not correct. [00:15:46] Your reputation for that versus here's a really gnarly regular expression problem and here's a really, you know, clever, insightful, you know, detailed answer laying out, oh, here's why you're seeing the behavior that you're seeing here. [00:15:58] Let me teach you some things about how to avoid in the future. That's that's great. Like, that's gold, right? [00:16:01] You want people to your reputation for that. Not so much for. Wow, look at this funny thing I saw. Right. Great. [00:16:06] So there's this very specific Q&A format and then take me through the journey towards discourse and Facebook and Twitter. So you start at the beginning that stack overflow evolved to have a purpose. So what is discourse, this passion you have for creating community for discussion? Where does that when was that born and how? [00:16:27] Part of it is based on the realization the stack overflow is only good for very specific subjects where there's sort of it's based on data, facts and science, where answers can be kind of verified to be true. Another form of that is there's the book of knowledge, like the tome of of knowledge that defines like whatever it is. You can refer to that book and I'll give you the answer. There has to be it only works on subjects where there's like CIMMYT clear answers to things that can be verified in some form. [00:16:53] Now, again, there's always more than one way to do it. There's complete flexibility in system around that. But where it falls down is stuff like poker and Lego like we had. If you go to stock exchange dotcom, we have an engine that tries to launch different Q&A topics. [00:17:07] Right. [00:17:07] And people can propose Q&A topics, sample questions. And if he gets enough support within the network, we launch the Q&A site. So some of the ones we launch were poker and Lego and they did horribly. Right, because, I mean, there might still be there lingering on in some form, but it was an experiment. This is like a test, right, in some subjects, works super well in stack engine and some don't. But the reason Lego and poker don't work is because they're so social. [00:17:31] Really, it's not about, you know, what's the rule here in poker? It's like, well, you know, what kind of cigars do we like to to to smoke while playing poker or, you know, what's what's a cool set of cards to use when playing poker or you know what some strategies like, say, I have this hand come up with some strategies I could use. It's more of a discussion around like what's happening, like with Lego, you know, same thing like here's this cool Lego set I found. [00:17:51] Look how awesome this isn't like. Yeah, that's freaking awesome, right? It's not a question. Right. There's all these social components, the discussions that don't fit at all. Like we literally have to disallow those and stack overflow because it's not about being social, it's about problems that you're facing in your work that you need concrete answers for. [00:18:06] Right. Like you have a real demonstrated problem that's sort of blocking you in something nobody's blocked by. You know, what should I do when I have a straight flush? Right. [00:18:13] Like, it's not a blocking problem in the world. It's just an opportunity to hang out and discuss. So discourse was a way to address that and say, look, you know, discussion forum software was very, very bad. And when I came out on Stack Overflow in late early twenties, early 2013 or early 2012, it was still very, very bad. I expected it improved in the four years since I last look, but it had not improved at all. [00:18:39] And I was like, well, that's kind of terrible because I love these communities of people talking about things that they love. You know, they're just communities of interest, right. And there's no good software for them. Like startups would come to me and say, hey, Jeff, I want to you know, I have this startup. Here's my idea. And the first thing I would say to them is like, well, first, why are you asking me? [00:18:59] Like, I don't really know your field. Right, necessarily. Like, why aren't you asking, like the community, like the people that are interested in this problem, the people that are using your product, why are you talking to them? And then they say, oh, great ideas like how do I do that? And then that's when I started playing sad trombone because I realized all the software involving. Talking to your users, customers, audience, patrons, whatever it is, it was all really bad, you know, it was like stuff that I would be embarrassed to recommend to other people. [00:19:23] And yet that's where I felt they could get the biggest and strongest, most effective input for what they should be doing with their product. Right. From their users, from their community. Right. That's what we did on Stack Overflow. [00:19:34] So what we're talking about with forms, the what is it, the dark matter of the Internet. It's still I don't know if it's still, but for the longest time, it has some of the most passionate and fascinating discussions. And what's the usual structure? There's usually what it's it's linear, so sequential to post to one after the other and there's pagination. So there's 10 posts and you go to the next page in that format still is used by like we're doing a lot of research with Tesla vehicles and there's Tesla Motors Club Forum, which is extremely, really wanted to run that actually they pinged us, but I don't think we got it. [00:20:13] But I really would like to go on that one. But they've started before even 2012, I believe. I mean, they've been running for a long time. It's still an extremely rich source of information. So what's broken about that system and how are you trying to fix it? I think there's a lot of power in in connecting people that love the same stuff around that specific topic, meaning Facebook's idea of connection is just any human that's related to another human right, like like through friendship or, you know, any other reason. [00:20:42] Facebook's idea of the world is sort of the status update. Right. Like a friend of yours did something ate at a restaurant. Right. Whereas discussion forums were only around the interest graph. Like, I love electric cars specifically. I love Tesla. Right. Like, I love the way they approach the problem. I love the style of the founder. I just love the design ethic. There's a lot to like about Tesla. If you saw the oatmeal, he did a whole love comic to Tesla and it was actually kind of cool because I learned some stuff. [00:21:10] He was somehow great. Tesla cars were specifically like how they were built differently. And he went into a lot of great detail. That was really interesting to me. That oatmeal post, if you read it, is the genesis of pretty much all interest communities. I just really love this stuff. Like for me it goes right. Like I'm into the auto communities and there's these interest communities are just really fascinating to me. And I feel more connected to the local communities than I do to, you know, friends that I don't see that often. [00:21:33] Right. Like, to me, the powerful thing is the interest graph. And Facebook kind of dabbles in the interest graph. [00:21:40] I mean, they have groups you can sign up for, groups and stuff, but it's really about the relationship graph. Like this is my coworker, this is my relative. This is my friend, but not so much about the interest. So I think that's the linchpin of which forums and communities are built on that. I personally love like I, I like I said, leadership is about passion. [00:21:59] Right. And being passionate about stuff is is a really valid way to look at the world. And I think it's a way a lot of stuff in the world gets done. Like I once had someone described me as he's like, Jeff, you're a guy who you just get super passionate about a few things at a time and you just go super deep in us things. [00:22:15] And I was like, oh, that's kind of right. That's kind of what I do. I'll get into something and just be super into that for a couple of years or whatever and just learn all I can about it and go super deep in it. And that's how I enjoy experiencing the world. Right. Like not being shallow on a bunch of things, but being really deep on a few things that I'm interested in. So forums kind of unlock that right. [00:22:32] And you know, you don't want a world where everything belongs to Facebook. At least I don't. I want a world where communities can kind of own themselves, set their own norms, set their own rules, control the experience, because community is also about ownership. Right. Like if if you're meeting at the Barnes and Noble every Thursday and Barnes and Noble says, get out of here, you guys don't buy enough books. Well, you know, you're kind of hosed, right? [00:22:51] Barnes and Noble owns you, right? [00:22:53] Like, you can't. But if you have your own meeting space, you know your own clubhouse, you can set your own rules, decide what you want to talk about there, and just really generate a lot better information than you could like hanging out at Barnes and Noble every Thursday at three p.m.. Right. So that's kind of the vision of discourse is a place where it's fully open source. You can take the software, you can sell it anywhere. [00:23:14] And, you know, you and a group of people can go deep on whatever it is that you're into. And this works for startups, right? Startups are a group of people who go super deep on a specific problem. Right. And they want to talk to the communities like, well, I installed this course. Right. That's what we do. It is. That's what I did. A stack overflow. I spent a lot of time on metastatic overflow, which is our internal, well, public community feedback site and just experiencing what the users are experiencing. [00:23:39] Right, because they're the ones doing all the work in the system. And they had a lot of interesting feedback. And there's that 90 10 rule, like 90 percent of the feedback you get is not really actionable for a variety of reasons. It might be bad feedback. It might be crazy feedback, it might be feedback you just can act on right now. But there's ten percent of it. That's like gold. It's like literally gold diamonds where it's like feedback of really good improvements to your core product that are not super hard to get to and actually make a lot of sense. [00:24:01] And my favorite is about five percent of the stuff I didn't even see coming. It's like, oh my God, I never even thought of that. But that's a brilliant idea. Right. And I can point to so many features of stack overflow that we drive from metastatic overflow feedback and meta discourse. Right. Same exact principle of discourse. Know we're getting ideas from the comedians like, oh, my God, I never thought of that, but that's fantastic, right? [00:24:20] Like, I love that relationship with the community from having built these communities. What have you what have you learned about what's the process of getting a critical mass of members in a community? Is it luck, skill, timing, persistence? What is is it the tools like discourse that empower that community? What was the key aspect of starting for one guy or gal and then building it to two and then ten and one hundred and a thousand, so on? [00:24:45] I think we're starting with an end of one. I mean, I think it's persistence and and also, you have to be interesting. Like somebody I really admire once said something that I always liked about blogging. He's like, here's how you blog. You have to have something interesting to say and have an interesting way of saying it. Right. And then do that for like ten years. So that's the genesis is like you have to have sort of something interesting to say. [00:25:08] That's not exactly what everyone else is saying. And an interesting way of saying, which is another way of saying kind of entertaining way of saying it. And then as far as growing it, it's like ritual. You know, like you have to like say you're starting a blog. You have to say, look, I'm going to blog every week, three times a week, and you have to stick to that schedule. [00:25:24] Right. Because until you do that for like several years, you're never going to get anywhere. Like, it just takes years to get to where you need to get to. And part of that is having the discipline to stick with the schedule. And and it helps, again, if it's something you're passionate about, this won't feel like work. Like, I love this. I could talk about this all day, every day. Right. You just have to do in a way that's interesting to other people. [00:25:44] And then as you're growing the community, that pattern of participation within the community of like generating these artifacts and inviting other people to help you, like, collaborate on these artifacts, like even in the case of blogging, like I felt in the early days of my blog, which I started in 2004, which is really the genesis of Stack Overflow. If you look at all my blog, it leads up to stack overflow, which was I have all this energy in my blog, but I don't like 40000 people were subscribing to me and I was like, I want to do something. [00:26:07] And then then I met Joel and said, Hey, Joel, I want to do something, take this ball of energy from a blog and do something. And all the people read my blog. [00:26:13] So that's like, oh, cool, you're involving us. You're saying, look, you're part of this community. Let's build this thing together. Like they pick the name. Like we voted on the name for Stack Overflow on my blog, like we came naming a super hard first all the hardest problem in computer science. Coming with a good name for stuff, right? Yeah, but you can go back to my blog. [00:26:31] There's the poll where we voted and Stack Overflow became the name of the site and all the early beta users were audience of my blog plus Joel's blog. Right. So we started from like, if you look at the genesis, I was just a programmer who said, hey, I love programming, but I have no outlet to talk about it. So I'm going to blog about it because I don't have enough people to work to talk to about it, because at the time I worked a place where, you know, programming wasn't the core output of the company. [00:26:54] It was a pharmaceutical company. And I just love this stuff, you know, to an absurd degree. So I was like, I'll just blog about it and then I'll find an audience and eventually found an audience, eventually found Joel and eventually built Stack overflow from that one core of activity. Right. But it was that repetition of feeding back in feedback from my blog comments, feedback from Joel, feedback from the early stack overflow community. When people see that you're doing that, they will follow along with you, right. [00:27:19] There's a cool you're here in good faith. You're actually, you know, not listening to everything because that's impossible. [00:27:23] That's impossible. But you're actually, you know, waiting our feedback and what you're doing because. And why wouldn't I? Because who does all the work on Stack overflow me, Joel? No, it's the other programmers that are doing all the work, so you've got to have some respect for that and then, you know, discipline around. Look, you know, we're trying to do a very specific thing here on Stack Overflow. We're not trying to solve all the world's problems. [00:27:44] We're trying to solve this very specific problem in a very specific way, not because we're jerks about it, but because these strict set of rules help us get really good results. Right. And programmers, that's an easy sell for the most part, because programmers are used to dealing with ridiculous systems of rules like constantly. That's basically their job. So they're very. Oh, yeah, super strict system of rules that lets me go. I want that's programming. [00:28:06] Right. That's what Stack Overflow is. [00:28:08] So so you're making it sound easy. But in 2004, let's go back there. In 2004 you started the blog coding or was it called that at the beginning. [00:28:18] At the very beginning, it was one of the smart things I did. It's from a book by Steve McConnell, Code Complete, which is one of my favorite programming books, still probably my number one programming book for anyone to read. One of the smart things I did back then, I don't always do smart things when I start stuff. I contacted Stephenson. Hey, I really like this. It was a sidebar illustration indicating danger in code, right? [00:28:37] Coding horror was like, watch out. [00:28:40] And I love that illustration because it spoke to me because I saw that illustration go, oh my God, that that's me. Like, I'm always my own worst enemy. Like, that's the key insight in programming is every time you write something, think, how am I going to screw myself? [00:28:51] Because you will constantly write so that the icon was like, Oh yeah, I need to constantly hold that mirror up and look and say, look, you're very fallible, you're going to screw this up. [00:29:01] Like, how can you build this in such a way that you're not going to screw it up later? Like, how can you get that discipline around making sure at every step I'm thinking through all the things that I could do wrong or that other people could do wrong, because that is actually how you get to be a better programmer. A lot of. Times, right, so that sidebar illustration, I loved it so much and I wrote Steve before I started my blog and said, hey, can I have permission to use this? [00:29:22] Because I really like the illustration. And Steve was kind enough to give me permission to do that and continues to give me permission. So really, that's awesome. [00:29:30] But in 2004, you started this blog. You know, you look at Stephen King, his book on writing, or Steven Pressfield War of Art book. I mean, it seems like writers suffer. I mean, it's a hard process of writing, right? [00:29:47] That there's going to be suffering. I mean, I want to hit you like, well, the work is suffering, right? Like doing the work. Like even when you're every week, like, OK, that blog post wasn't very good or, you know, people didn't like it or people write said disparaging things about it. You have to like have the attitude is like, you know, no matter what happens, I want to do this for me. [00:30:04] Right. It's not about you. It's about me. I mean, in the end it is about everyone, because this is how good work gets out into the world. But you have to be pretty strict about saying, like, you know, I'm selfish in the sense that I have to do this for me. You know, you mentioned Stephen King like his book on writing, but like one of the things I do, for example, when writing is like I read it out loud, one of the best pieces of advice for writing anything is read it out loud, like multiple times and make it sound like you're talking, because that is the goal of good writing. [00:30:33] It should sound like you said it with with slightly better phrasing because you have more time to think of what you're saying. But like, it should sound natural when you say it. [00:30:39] And I think that's probably the single best writing advice I can give it. Just just read it over and over out loud. Make sure it sounds like something you would normally say. It sounds good. [00:30:48] And what's your process of writing? So there's usually a pretty good idea behind the blog posts. [00:30:54] So ideas. Right. So I think you got to have the concept that there's so many interesting things in the world like I mean, my God, the world is amazing, right? [00:31:04] Like, it's you can never write about everything that's going on because it's so incredible. [00:31:08] But if you can't come up with, like, let's say, one interesting thing per day to talk about, then you're not trying hard enough because the world is full of just super interesting stuff. And one great way to to like mine stuff is go back to old books because they bring up old stuff that's still super relevant. And I did that a lot because I was like reading classic program books and a lot of the early blockbuster like, oh, I was reading this program book and they brought this really cool concept and I want to talk about it some more. [00:31:30] And you get the I mean, you're not claiming credit for the idea, but it gives you something interesting to talk about that's kind of evergreen, right? Like you don't have to go. What should I talk about? So we'll just go dig up some old classic programming books and find something that. Oh, wow, that's interesting. Or how does that apply today? Or what about X and Y? Or compare these two concepts to pull a couple of sentences from that book and then sort of play off of it. [00:31:50] Agree or disagree that so in 2007 you wrote that you were offered a significant amount of money to sell the blog. [00:31:59] You chose not to. What were all the elements you were thinking about? Because I'd like to take you back. It seems like there's a lot of nonlinear decisions you made to life as. So what was that decision like? [00:32:11] Right. So one of the things I love is the Choose Your Own Adventure books, which I loved as a kid. And I feel like the early programer books because they're they're all about if then statements, right, if this than this. And they're also very, very unforgiving. Like there's all these sites that map the classic choose your own adventure books. And how many outcomes are bad? A lot of bad outcomes. So part of the game is like, oh, I got an outcome. [00:32:31] Go back one step, go back one further steps, like, how did I get here? Right. Like it's a sequence of decisions. And this is true of life. Right. Like every decision is a sequence. [00:32:40] Right. Individually, any individual decision is not actually right or wrong, but they lead you down a path. [00:32:45] Right. So I do think there's some truth that so this particular decision, the blog, I'm fairly popular. There's a lot of RSS readers that I discovered and this guy contacted me out of the blue from this, like, bug tracking companies like, oh, I really want to buy your blog for, like, I think it was around one hundred thousand dollars, maybe like eighty thousand. But it was it was a lot. Right. And like and that's, you know, at the time, like I would have a year's worth of salary all at once. [00:33:09] So I'd really think about like, well, you know, and I remember talking to people the times like, wow, that's a lot of money. [00:33:15] But I don't know, like I really like my blog. Right. Like, do I want to sell my blog because it wouldn't really belong to me anymore at that point. [00:33:21] And one of the guidelines that I like to I don't like to give advice to people a lot, but one of the pieces of advice I do give, because I do think it's really true, it's generally helpful, is whenever you're looking at a set of decisions like, oh gosh, I do A, B or C, you got to pick the thing that's a little scarier in that list because not, you know, not like jump off a cliff. [00:33:40] Scary. But the thing that makes you nervous, because if you pick the safe choice, it's usually you're not really pushing, you're not pushing yourself. You're not choosing the thing that's going to help you grow. So for me, the scarier choice was to say, no. I was like, well, no, let's just see where this is going. Right? Because then I own it. I mean, it belongs to me. It's my thing. [00:33:57] And I can just take it and some other logical conclusion. Right. Because imagine how different the world would have been that I said yes and told the blog, it's like there probably would be stack overflow. Yeah. You know, a lot of other stuff would have changed. So for that particular decision, I think it was that same rule. Like what scares me a little bit more do the thing that scares you. Yeah. Speaking of which, startups, I think there's specifics, some more general questions that a lot of people will be interested in. [00:34:22] You've started stack overflow, you started discourse. So what's the is one, two or three guys, whatever it is in the beginning, what was that process like? [00:34:34] Do you start talking about did you start programming? Do you start like where the birth and the catalyst that actually. [00:34:41] Well, I can talk about in the context of a stack of and discourse. So I think the key thing initially is there is a problem, something there's some state of the world that's unsatisfactory to the point that, like, you're upset about it. Right. Like in that case, it was experts exchange. I mean, Joel's original idea, because I approached Joel is like, look, Joel, I have all this energy on my blog. I want to do something. [00:34:57] I want to build something. But I don't know what it is because I'm not I'm honestly not a good idea person. I'm really not unlike the execution guy. I'm really good at execution, but I'm not good at, like, blue skying ideas, not my forte, which another reason why I like the community feedback because they blue sky all day long for you. Right. So when I can go in and cherry pick a blue sky idea from community, even if I have to spend three hours reading to get one good idea, it's worth it man. [00:35:18] But anyway, so the idea from Joel was, hey, experts change. It's got great data, but the experience is hideous, right? It's it's trying to trick you. It feels like a used car salesman. It's just bad. So it's like, oh, that's awesome. It feeds in a community. It feeds into like, you know, we can make creative commons. So I think the core is to have a really good idea that you feel very strongly about in the beginning that like there's a wrong in the world that we will an injustice that we will right through the process of building this thing for discourse. [00:35:42] It was like, look, there's no good software for communities to just hang out and, like, do stuff. Right, like whether it's problem solving, whatever forms are such a great building block of online community. And they're hideous. They were so bad. Right. It was embarrassing. Like, I literally was embarrassed to be associated with the software that we have to have somewhere to be proud of. It's like this is a competitive threat. Reddit, this is competitive Twitter. [00:36:03] This is competitor with Facebook right now. I would be proud to have the software on my site. So that was the genesis of discourse was feeling very strongly about there needs to be a good solution for communities. [00:36:17] So that's step one Genesis when I feel super strongly about right. And then people galvanize around the idea, like Joel was already super excited with the idea. I was excited about the idea. So with the forum software I was posting on Twitter, I had research as part of my research. I start researching the problem and I found a game called Forum Wars, which was a parody of forum. It's still very, very funny of like form behavior circle, like I would say twenty three. [00:36:41] It's age. Some like behaviors are a little different in there of Twitter, but it was awesome. It was very funny and it was like a game is like an RPG and it had a forum attached to it. So it was like a game about forums with a forum attached like this is awesome. Right. This is so cool. And the founder of that company or that project wasn't really company contacted me. This guy, Robin Ward from Toronto is hey, you know, I saw you been talking about forums and like, I really love that problem space. [00:37:04] It's like I'd still love to build really good form software because I don't think anything out there is any good. And I was like, awesome at that point. I was like, we're starting a company because like, I couldn't have wished for a better person to walk through the door and say, I'm excited about this, too. Same thing with you. All right. I mean, Joel is a legend in the industry, right? So when he walks around, I'm excited about problems like me, too, man. [00:37:22] We can do this. Right? So that to me is the most important step. It's like having out of your super excited about and another person, a co-founder. Right. Because, again, you get that dual leadership right. Of like, am I making a bad decision? [00:37:34] Sometimes it's nice to have checks of like, is this a good idea? I don't know. Right. [00:37:39] So those are the crucial seeds. But then starting to build stuff, whether it's you program prototypes. So there's tons of research, there's tons of research like what's out there that failed because a lot of people look at successes. Oh, look at how successful X is. Everybody looks at the successes. Those are boring. Show me the failures, because that is what's interesting. That's where people were experimenting. That's where people were pushing. But and they failed. [00:38:00] But they probably failed for reasons that weren't directly about the quality of their idea. Right. Yeah. So look at all the failures. Don't just look what everybody looks at, which is like, oh, gosh, look at all these successful people. Look at the failures, look at the things that didn't work, researched the entire field. And so that's the research that I was doing that led me to Robin Wright, was that. And then when we for example, we did a stack overflow, we're like, OK, well, I really like elements of voting in Digg and Reddit. [00:38:25] I like the Wikipedia. Everything's up to date. Nothing is like an old tombstone that has horrible, outdated information. We know that works. Wikipedia is an amazing resource. Blogging the idea of ownership is so powerful. Right. Like, oh, I wrote this and look how good Joe's answer is. Right. Like all these concepts, we were all together researching all the things that are out there that were working and why they were working and trying to, like, fold them into that. [00:38:47] Again, that Frankenstein's monster of what stack overflow is. And by the way, that wasn't a free decision because there's still a ton of tension in the stack overflow system. There's reasons people complain about stack overflow because it's so strict. Right. Why is it so strict? Why do you guys always close to my questions? [00:39:01] It's because there's so much tension that we built into the system around, like trying to get good, good results out of the system. [00:39:07] And, you know, it's not a free that stuff doesn't come for free. Right. It's not like we all have perfect and. And nobody will have to get their feelings hurt or nobody will have to get downvoted like that, it doesn't work that way, right. [00:39:21] So this is an interesting point and a small tangent. You're right about anxiety. So I've posted a lot of questions and answers and Steckel and the questions, I usually go to something very specific to something I'm working on. [00:39:36] This is something you talk about that really the goal of Stack Overflow isn't about is to write a question. Not it's not about you. It's about. The question that will help the community in the future, right, but that's a tough sell, right, because people are like, well, you know, I don't really care about the community. What I care about is my problem, my problem. And that's fair. Right? It's sort of that, again, that tension, that balancing act if we want to help you, but we also want help. [00:40:02] Everybody comes behind you. Right. The long line of people are going to say, oh, I kind of have that problem, too. Right. And if nobody's ever going to come up and say, I have this problem, too, then that question shouldn't exist on stack overflow because the question is too specific and even that's tension. Right. How do you judge that? How do you know that nobody is going to have this particular question? So there's a lot of tension in the system. [00:40:22] Do you think that anxiety of asking the question, the anxiety of answering that tension is inherent to programmers is inherent to this kind of process? Or or can it be improved? Can be Happyland, where the that tension is not quite so harsh? [00:40:41] I don't think Stack Overflow can totally change the way it works. One thing they are working on, finally, is the ask page had not changed since 2011. I'm still kind of bitter about this because I feel like you have a Q&A system. And what are the core pages in a system? Well, first of all, the question on the answers and all the also the ask page, particularly when you're a new user or someone trying to ask a question, that's the point at which you need the most help. [00:41:03] And we just didn't adapt with the times. But the good news is they're working on this, from what I understand. And it's going to be more Wizzard based format. And you could envision a world where as part of this Wizard based program, when you're asking questions like come up with a good title, what a good word to put in the title. One word that's not good to put in the title is problem. For example, I have a problem. [00:41:21] Oh, you have a problem. OK, a problem. That's great, right? Like you need specifics, right? Like it's trying to help you make a good question title, for example. That step will be broken out, all that stuff. But one of those steps in that wizard of asking could say, hey, I'm a little nervous. You know, I've never done this before. Can you put me in a queue for, like, special mentoring? [00:41:40] Right. You can opt in to a special mentor. [00:41:42] I think that would be fantastic. Like, I don't have any objection to that at all in terms of being an opt in system, because there are people there like, you know, I just want to help them. I want help a person no matter what. I want to go above and beyond. I want to spend like hours with this person. It depends what their goals are. It's a great idea. Who am I to judge? Right. [00:41:59] So that's fine. It's not precluded from happening. But there's a certain big city ethos that we started with, like, look, we're New York City. You don't come to New York City and expect them to be. Oh, welcome to the city, Joe. How's it going? Come on in. Let me show you around. That's now New York City works, right? [00:42:14] I mean, and, you know, again, New York City's a reputation for being rude, which actually I don't think it is, having been there fairly recently. It's not rude. People are just like going about their business right now. Look, look, I have things to do. I'm busy. I'm a busy professional, as are you. [00:42:27] And since you're a busy professional, certainly when you ask a question and ask the best possible question. Right. Because you're a busy professional and you would not accept anything less than a very well written question with a lot of detail about why you're doing it, what you're doing, what you researched, what you found. Right. Because you're a professional like me. Right. And this rubs people sometimes the wrong way. [00:42:46] And I don't think it's wrong to say, look, I don't want that experience. I want. Just a more chill place for for beginners, and I still think sackfuls is not was never designed for beginners. Right. There's this misconception that, you know, even Joel says something. Oh, yes, stack overflow for beginners. [00:43:01] And I think if you're a prodigy, it can be right. But it's not really representative. Right. Like, I think as a beginner, you want a totally different set of tools you want, like live screen sharing, live chat. [00:43:13] You want access to resources, you want a playground, like a playground you can experiment in and like test and all the stuff that we just don't give people, because that was never really the audience that we were designing for. That doesn't mean it's wrong. And I think it would be awesome if there was a site like that on the Internet or a stack of realizing, hey, you know, we're going to start doing this. That's fine, too. [00:43:32] You know, I'm not there. I'm not making those decisions. But I do think the pressure, the tension that you described is there for people to be, look, I'm a little nervous because I know I got to do my best work. Right. [00:43:41] The other one is something you talk about, which is also really interesting to me, is duplicate questions or it's a it's a really difficult problem that you highlight super, super hard. [00:43:54] And like, you can take one little topic and you could probably write 10, 20, 30 ways of asking about that topic. And there will be all different. I don't know if there should be one page that answers all of it. [00:44:07] Is there a way that stack overflow can help disambiguate, like separate these duplicate questions or connect them together? Or is it a totally hopeless, difficult, impossible task? I think it's a very, very hard computer science problem and partly because people are very good at using completely different words and always amazed me. On Stack Overflow, you'd have two questions that were functionally identical. And one question had like zero words in common with the other question like, oh my God, from a computer science perspective, how do you even begin to solve that? [00:44:38] And it happens all the time. People are super good at this, right? Accidentally at asking the same thing in like 10, 20 different ways. And the other complexity is we want some of those duplicates to exist, because if there's five versions with different words, have those five versions point to the one centralized answer? Right. It's like, OK, this is duplicate. No, no worries. This here's the here's the answer. You want it over here on this. [00:44:59] This this you know, the prime example that we want to have, rather having ten copies of the question and the answer, because if you have ten copies of the question you answer. This also devalues the reputation system, which programmers hate. As I previously mentioned, you're getting reputation for an answer that somebody else, ah, gave. It's like, well, it's an answer, but somebody else sort of gave that answer. So why are you getting a reputation for the same answer as the other guy who gave it four years ago? [00:45:21] People get offended by that. Right. So the reputation system itself adds tension to the system in that the people who have a lot of reputation become very incentivized to enforce the reputation system. And for the most part, that's good. I know it sounds weird, but for most parts I look strict systems. I think to use technology, you have to have the idea that, OK, strict systems ultimately work better. And I do think in programming you're familiar with loose typing versus strict typing. [00:45:46] Right? The idea that you can declare a variable, not declare a variable, rather just start using a variable and OK, I see it's implicitly an integer. Bam, awesome. Duqu equals five. Well Duqu is now an integer five. Right. And you're like, cool, awesome. Simpler. Right. Why would I want to worry about typing. And for a long time, like in the Ruby community, they're like, yeah, this is awesome. [00:46:02] Like you just do a bunch of unit testing, which is testing your program's validity after the fact to catch any bugs that that that strict typing of variables would have caught. And now you have this thing called typescript from Microsoft, from the guy who built C sharp enders, who's one of the greatest minds in software development. Right. Like in terms of language design and says, no, no, no, we want to bolt on a strict type system to JavaScript because it makes things better. [00:46:23] And now everybody is like, oh, my God, we we deployed TypeScript and found fifty latent bugs that we didn't know about. [00:46:29] Right. Like, this is super common. So I think there is a truth in programming that strictness. It's not the goal. We're not saying be super strict. The strictness is correct. No, it's no no strictness produces better results. That's what I'm saying. Right. So strict typing of variables. I would say you almost universally have consensus now is basically correct. Should be that way in every language. Right. Ducci equals five should Shariat error because. [00:46:55] No, you didn't declare you didn't tell me that Duqu was an integer. Right. That's a bug. Right. Or maybe you mistype you type deck. Right. Instead of Duqu. Right. You never know. This happens all the time. Right. So with that in mind, I will say that the strictness, the system is correct. Now, that doesn't mean cruel. That doesn't mean mean. That doesn't mean angry. It just means strict. [00:47:12] OK, so I think where there's misunderstanding and people get cranky. Right. Like in other question you asked is like, why are programmers kind of mean sometimes, well who to programmers work with all day long? [00:47:22] So I have a theory that if you're in a job and you work with assholes all day long, what do you eventually become? An asshole, an asshole? And what is the computer except the world's biggest asshole? Because the computer has no time for your bullshit. The computer, the minute you make a mistake, everything comes crashing down. Right. One semicolon has crash space missions. Right. So that's normal. So you begin to internalize that. You begin to think, oh, my coworker, the computer. [00:47:50] Is super strict and kind of a jerk about everything, so that's kind of how I'm going to be because I work with this computer and I have to accede to its terms on everything. So therefore, you start to absorb that and you start to think, oh, well, being really strict arbitrarily is really good. And error of error. Code five six two four nine is a completely good error message because that's what the computer gave me. Right. [00:48:11] So you kind of forget to be a person at some level. And you know how they say great detectives internalized criminals and kind of are criminals themselves, like this trope of the master detective is good because you can think like the criminal. Well, I do think that's true of programmers. Really good programmers think like the computer because that's their job. [00:48:29] But if you internalize it too much, you become the computer. You kind of become a jerk to everybody because that's what you've internalized. You're almost not a jerk, but you have no patience for a lack of strictness. [00:48:40] As you said, it's not out of a sense of meanness. It's accidental. But I do believe it's an occupational hazard of being a programmer is you start to behave like the computer. You're very unforgiving. You're very terse. You're very wrong. Incorrect. Move on. It's like, well, can you help me? Like, what could I do to fix not wrong. Next question. [00:48:59] Like, that's normal for the computer, right? Just fail next. Right. Like out of you remember. And Saturday Night Live, like in the nineties they had this character was an IT guy. Yeah. The move guy move. [00:49:12] Was that Jimmy Fallon. No. No. Who. Playdom. OK, yeah. I remember move. Right. And he had no patience for you. Might have been mad TV actually or TV might have been. [00:49:22] Might have been. But anyway that was the that's always been the perception. Right. You start to behave like the computer. It's like, oh, you're wrong. [00:49:28] Out of the way. You know, you've written so many blog posts about programming, about programs, programming, programmers. What do you think makes a good let's start with what makes a good solo programmer? Well, I don't think you should be a solo programmer. [00:49:46] I think to be a good solo programmer, it's kind of like what I talked about. Well, not on Mike, but one of the things John Carmack, one of the best points he makes in the book, Masters of Doom, which is a fantastic book. And anybody listening this who hasn't read it, please read. It's such a great book is that at the time they were working on stuff like Wolfenstein and Doom, like they didn't have the resources that we have today. [00:50:08] They didn't have stack overflow. They didn't have Wikipedia, they didn't have like discourse forums. They didn't have places to go to get people to help them write. They had to work on their own. And that's why it took a genius like Carmac to do this stuff, because you had to be a genius to invent from first principles. A lot of the stuff he was he was like the hacks he was coming up with were genius, right. Genius level stuff. [00:50:27] But you don't need to be a genius anymore. And that means not working by yourself. You have to be good at researching stuff online. You have to be good at asking questions, really good questions that are really well researched, which implies, oh, I went out in research for three hours before I wrote this. Questions like, that's what you should be doing because that's what's going to make you good. Right? To me, this is a big difference in programming. [00:50:45] And like the 80s versus programming today is like you you kind of had to be by yourself back then. Like, where would you go for answers? I remember in the early days when I was a learning visual basic for Windows, like I would call the Microsoft helpline on the phone when I had like the program because I was like, I don't know what to do. So I would like go and call. And they have these huge phone banks and like, can you imagine how alien that is now? [00:51:06] Like, who would do that? Right. Like, that's crazy. [00:51:08] So there was just nowhere else to go when you got stuck. Right. Like I had the books that came with it. I read those study those religiously. I just saw a post from Steve Sinofsky that said this C++ version seven came with like 10000 pages of written material because where else were you going to figure that stuff out? Go to the library when you didn't have Wikipedia, you didn't have, you know, read it, you know, in order to go to answer these questions. [00:51:36] So you've talked about through the years, basically not having an ego and not thinking that you're the best programmer in the world. And so it was kind of just looking to improve to become a better programmer than you were yesterday. So how have you changed as a programmer and as a as a thinker designer around programming over the past? Was it fifteen years really of being a public figure? [00:52:04] I would say the big insight that I had is eventually as a programmer, you have to kind of stop writing code to be effective, which is kind of disturbing because you really love it. And but you realize like being effective at programming, at programming in the general sense doesn't mean writing code. A lot of times you can be much more successful by not writing code and writing code in terms of just solving the problems you have, essentially hiring people that are really good and like setting them free and like giving them basic direction. [00:52:31] Right. Like on strategy and stuff, because a lot of the problems you encounter aren't necessarily solved. You like really gnarly code. They're solved by conceptual solutions, which can then be turned into code. But are you even solving the right problem? I mean, so I would say for me, the main insight I have is to succeed as a. Programmer, you eventually kind of stop writing code that's going to sound discouraging probably to people hearing, but I don't mean it that way. [00:52:56] What I mean is that you're coding at a higher level language eventually, like, OK, so we're coding an assembly line, right? That's the beginning. Right. You're hard coded to the architecture. Then you have stuff like sybaritic. Wow. We can abstract across the architecture, write code. I can then compile that code for arm or, you know, whatever, you know, sex or whatever else is out there. And then even a higher level than that. [00:53:15] Right. Like you're looking at like Python. Ruby interpreted languages. And then to me as a programmer, like, OK, I want to go even higher. I want to go higher than that. How do I abstract higher than language. It's like, well you abstract in spoken language and written language. Right. Like you're sort of inspiring people to get things done, giving them guidance. Like what if we did this, what if we did this. [00:53:32] You're writing in the highest level language that there is, which is for me, English. Right. Whatever your spoken languages. So it's all about being effective. Right. And I think Patrick McKenzie, patio lesson on Hacker News and works at Stripe has a great post about this of how calling yourself a programmer is a career limiting move at some level. Once you get far enough from your current. I really believe that. And I again, I apologize. [00:53:57] This is sound discouraging. I don't mean it to be. But he's so right because all the stuff that goes on around the code, like the people like that's another thing. If you look at my blog entries is about, wow, programming is about people more than it's about code, which doesn't really make sense. Right. But it's about can these people even get along together? Can they understand each other? Can you even explain to me what it is you're working on? [00:54:18] Are you solving the right problem? People? Right. Another classic program book, which again, up there with code complete, please read Peopleware it's that software is people, right? People are the software first and foremost. So a lot of the skills that I was working on early in the blog were about figuring out the people parts of programming, which were the harder parts, the hard part of programming. [00:54:37] Once you get a certain skill of a programmer, you can pretty much solve any reasonable problem that's put in front of you. You're not writing algorithms from scratch, right? That just doesn't happen. So any sort of reasonable problem in front of you going to be able to solve. But what you can't solve is our manager is a total jerk. [00:54:52] You cannot solve that with code that is not a code solvable problem, and yet that will cripple you way more than, oh, we had to use the stupid framework I don't like or or you know, Sam keeps writing bad code that I hate or, you know you know, Dave is off there in the wilderness writing God knows what. Right. These are not your problems. Your problem is your manager or a coworker is so toxic to everybody else in your team that, like, nobody can get anything done because everybody's so stressed out and freaked out. [00:55:17] Right. These are the problems that you have to attack. Absolutely. [00:55:20] And so as you go to these higher level abstractions, as you've developed as a programmer to hire high level abstraction, go into natural language, you're also the guy who kind of preached, you know, building it, you know, diving in and doing it and like, learn by doing. Yes. [00:55:38] Do you do you worry that as you get to higher, higher level abstractions, you lose track of the lower level of just building is like, do you worry about that? You know, even not maybe now, but ten years from now. 20 years from now? Well, no. [00:55:57] I mean, there is always that paranoia and oh, gosh, I don't feel as valuable since I'm not writing code. But for me, like when we started the Discourse Project, it was Ruby, which I didn't really know. Ruby, I mean, as you pointed out, and this is another valuable observation stack overflow. You can be super proficient. For example, C Sharp, which I was working in. That's why we built Stack Overflow and and still is written and then switched to Ruby. [00:56:15] And you're a newbie again, right? Like I'm but but you have the framework. I know what a for loop is. I don't recursion is. I know you know WesTrac stack traces. Right. Like I have all the fundamental concepts to be a programmer. I just don't know Ruby. So I'm still on a higher level. I'm not like a beginner beginner like you're saying. I'm just like I need to apply my programming concepts already know to Ruby. [00:56:35] Well, that is a question that's really interesting. So looking at Ruby, how do you go about learning enough that your intuition can be applied? [00:56:43] Well, that carried over. That's all trying to get to is like what I realized when I started with just me and Robyn. [00:56:47] I realized if I bother Robyn, I am now costing us productivity, right? Every time I go to Robyn, rather than building the the our first alpha version of discourse, he's now answering my stupid questions about Ruby. Is that a good use of his time? Is that a good use of my time? The answer to both of those was resoundingly no. Right. Like we were getting to an Alpha and it was a pretty much OK, we'll hire more programmers. [00:57:11] Right. Like we eventually hired Neil and then eventually Sam, who came in as a co-founder. I actually was Sam first, then Neil later. But the answer to the problem is just hire other competent programmers, not like teach now. I shall pull myself up by my bootstraps and learn Ruby. But at some point, writing code becomes a liability to you in terms of getting things done. There's so many other things that go on in the project, like building the prototype, like you mentioned, like, well, how do you if you're not writing code has a focus on like what? [00:57:40] What are we building? Well, first, basic mockups and research. What do we even want to build? There's a little bit of that that goes on. Then very quickly get to the prototype stage, like build a prototype. Let's give. Right on the prototype, really, really rapidly, that's what we with this course and that's what we demoed to get our seed funding for this course was the the alpha version of discourse that we had running and ready to go. [00:57:59] And it was very it was bad. I mean, it was I'll just tell you, it was bad. I have we have screenshots and I'm just like embarrassed to look at it now. But it was the prototype we were figuring out, like, what what's working, what's not working, because there's such a broad gap between between the way you think things will work in your mind or even on paper and the way they work. Once you sit and live in the software, like actually spend time living and breathing. [00:58:20] I was so different. So my philosophy is get to prototype and then what? You're really optimizing for speed of iteration, like how you can turn the crank, how quickly can we iterate? That's the absolutely critical metric of any software project. And I had a tweet recently that people liked and I totally this is so fundamental to what I do is like if you want to measure the core competency of any software tech company, it's the speed at which somebody can say, hey, we really need this word in the product change of this word. [00:58:47] Right. Because it will be more clear to the user like what we like instead of respondents reply or something. But there's some from the conception of that idea to how quickly that single word can be changed in your software rolled out to users. [00:58:58] That is your life cycle. That's your health, your heartbeat. If your heartbeat is like super slow, you're basically dead. No, seriously, like if it takes two weeks or even a month to get that single word change, there was, oh, my God, this great idea, that word is so much clearer. I'm told me like a super like everybody on board for this change. It's not like let's just change a word because we're bored. [00:59:18] It's like this is an awesome change. And then it takes months to roll out. [00:59:22] It's like your dead. Like you can't iterate, you can't how you can do anything right. [00:59:27] Like so anyway, about the heartbeat, it's like get the prototype and then iterate on it. That's that's what I view is like the central tenet of modern software development. That's fascinating. You put it that way. It's actually so I work, I build autonomous vehicles. [00:59:39] And when you look at what maybe compare Tesla to most other automakers, the site, the whatever the heartbeat for Tesla is literally days now in terms of they can over the air, deploy software updates to all their vehicles, which is markedly different than every other automaker, which takes years to update a piece of software. [01:00:04] And so and that's reflected in everything. That's the final product that's reflected in really how slowly they adapt to the times. [01:00:13] And to be clear, I'm not saying being a hummingbird is the goal either. It's like, you know, in a heartbeat. It's like so fast. It's like you're winning, you know, you're just freaking out. But like it is a measure of health. You should have a healthy heartbeat. It's up to four people listening to decide what that means. But it has to be healthy. It has to be reasonable because otherwise you're going to be frustrated because like, that's how you build software. [01:00:30] You make mistakes, you roll it out, you live with it, you see what it feels like and say, oh, God, that was a terrible idea. Oh, my gosh. This it could be even better if we did y right. You turn the crank and then the more you do that, the faster you get ahead of your competitors ultimately because you're its rate of change. Right. Delta V. Right. How fast are you moving. [01:00:48] Within a year you're going to be miles away by the time they catch up with you. Right. Like that's the way it works. And plus users like as a software developer and I love software that's constantly changing because I don't understand. People get super pissed off when, like, oh, they changed the software on me. How dare they? [01:01:02] I'm like, yes, change the software, change it all the time. And that's that's what makes this stuff great, is that it can be changed so rapidly and become something that that is greater than it is now. Now, granted, there are some changes that suck. I admit I've seen it many times, but in general, it's like that's what makes software cool, right. Is that it is so malleable, like fighting that is like weird to me because it's like, well, you're fighting the essence of the thing that you're building. [01:01:27] Like, that doesn't make sense. You want to really embrace that, not not to be a hummingbird, but like embrace it to a healthy cycle of your heartbeat. Right. [01:01:33] So you talk about that people really don't change. That's true. That's why I probably a lot of the stuff you write about in your blog probably will remain true. [01:01:43] There's a flip side of the coin. People don't change. So investing and understanding people is is like learning Unix in 1970 because and nothing has changed. Right. Like all those things you've learned about people will still be valid thirty four years from now. Whereas if you learn the latest JavaScript framework, that's going to be good for like two years. Right, exactly. [01:02:01] So but if you look at the future of programming, so there's a people component, but there's also the technology itself. Do you what do you see as the future programming? Will it change significantly or as far as you can tell, people are ultimately programming. And so it will not it's not something that you foresee changing in any fundamental way. [01:02:25] Well, you're going to go look back on sort of the basics of programming. And one of things that always shocked me is like source control. Like I didn't learn anything about source control when I graduated college in nineteen ninety two. But I remember hearing from people like as late as, like 1998, 1999, like even maybe today they're not learning source control. And to me it's like, well how can you not learn source control that is so fundamental to working with other. [01:02:49] Programmers working in a way you don't lose your work, like just just basic stuff, the literal bedrock software development is source control. Now, you compare today like GitHub, I like Microsoft, but GitHub, which I think was incredibly smart acquisition, move on their part. Now they have anybody who wants, like, reasonable source control to go someone. GitHub is all set up for you. Right. There's tons of walkthrough, tons of tutorials. [01:03:10] So from the concept of like has programming advanced from, say, 1999, it's like, well, hell, we have GitHub. I mean, my God. Yes, right. Like, it's it's massively advanced over over what it was. Now, as to whether programming is significantly different, I'm going to say no. But I think the baseline of like what we view is like fundamentals will continue to go up and actually get better, like source control, because that's one of the fundamentals that has gotten, I mean, hundreds of orders of magnitude better than it was 10, 20 years ago. [01:03:39] Those are the fundamentals. Let me introduce two things that maybe you can comment on. So one is mobile phones. So that could fundamentally transform what or what programming is or maybe not. Maybe you can comment on that. And the other one is artificial intelligence, which promises to in some ways to do some of the programming for you is one way to think about it. So it's really what a programmer is, is using the intelligent that's inside your skull to to do something useful. [01:04:13] The hope with artificial intelligence is that it does some of the useful parts for you where you don't have to think about it. So do you see, Smartphone's, the fact that everybody has one and they're getting more and more powerful as potentially changing programming and do you see as potentially changing program? [01:04:29] OK, so that's good. So smartphones have definitely changed. I mean, since, you know, I guess 2010 is when they really started getting super popular. I mean, in the last eight years, the world has literally changed. I, like everybody carries a computer around and that's normal. I mean, that is such a huge change in society. I think we're still dealing with a lot of the positive negative ramifications of that. Right. Like, everybody is connected all the time. [01:04:51] Everybody's on the computer all the time. That was my dream world as a geek. Right. But it's like, be careful what you ask for, right? Like, wow, now everybody has a computer. It's not quite the utopia that we thought it would be. Right. Computers can be used for a lot of stuff that's not necessarily great. So to me, that's the central focus of the smartphone is just that it puts a computer in front of everyone granted a small touch screen, small touch screen computer. [01:05:14] But as for programming, like, I don't know, I don't think that I've kind of over time come to subscribe to the Unix view of the world when it comes to programming. [01:05:21] It's like you want to teach these basic command line things. And that is just what programming is going to be for, I think a long, long time. I don't think there's any magical, like visual programming that's going to happen. I just I don't know. I've over time, I've become a believer in that Unix philosophy of just you know, they kind of had to write with Unix. That's going to be the way it has for a long, long time. [01:05:44] And we'll continue to, like I said, raise the baseline. The tools get better, it'll get simpler. But it's still fundamental going to be command line tools, you know, fancy ideas. That's kind of it for the foreseeable future. I'm not seeing any visual programming stuff on the horizon because you're going to think like what do you do on a smartphone that be directly analogous to programming? Like, I'm trying to think. Right, like and there's really not much. [01:06:07] So not necessarily analogous to programming, but the kind of things that the kind of programs you would need to write. My need to be very different. Yeah, and the kind of languages I mean, but I probably also subscribe to the same just because everything in this world might be written in JavaScript. [01:06:31] Oh yeah, that's that's already happening. I mean, discourse is about discourse is itself. JavaScript is another bet on that side of the table, and I strongly believe that. [01:06:39] So I would say smartphones have mostly a cultural shift more than a programming shift. Mm hmm. Now, your other question was about artificial intelligence and like sort of visus predicting what you're going to do. And I do think there's some strength to that. I think artificial intelligence kind of overselling it in terms of what it doing. It's more like people are predictable, right? People do the same things like let me give an example. One one check we put in a discourse that's in a lot of big commercial websites is say you log in from New York City now and then an hour later you log in from San Francisco. [01:07:09] It's like, well. Hmm, that's interesting. How did you get from New York to San Francisco in one hour? So at that point, you're like, OK, this is a suspicious login at that point. So we would alert you was like, OK, but that's not I. Right. That's just a heuristic of like, how did you in one hour get two thousand miles. Right. [01:07:26] That doesn't mean you grabbed maybe you're a VPN. [01:07:28] There's other ways to happen, but that's just a basic prediction based on the idea that people pretty much don't move around that much like they may travel occasionally. But like nobody. I mean, unless you're a traveling salesman that's literally travelling the world every day, like there's so much repetition and predictability in terms of things you're going to do. And I think good software anticipates your needs, like, for example, Google, I think it's called Google now or whatever. [01:07:50] Google thing is, it predicts your commute and predicts based on your phone location, like where are you every day? Well, that's probably where you work, that kind of stuff. [01:07:57] I do think computers can get a lot better at that, but I hesitate to call it like full blown A.I. It's just computers getting better. At first of all, they have a ton of it because every has a smartphone. Now, all of a sudden we have all this data that we didn't have before about location, about like, you know, communication and feeding that into some some basic heuristics and maybe some fancy algorithms that turn it into predictions of anticipating your needs. [01:08:18] Like like a friend would be like, oh, hey, I see your home. Would you like some dinner? Right. Like, let's go get some food, because that's usually what we do this time of day. Right. In the context of actually active programming, do you see ideas improving and making the life of programming is better? [01:08:32] I do think that is possible because there's a lot of repetition in programming, right? Oh, you know, Clippy would be the bad example of. [01:08:38] Oh, I see. It looks like you're writing a for loop, but there are patterns in code, right. Like and actually libraries are kind of like that. Right. [01:08:45] Like rather than go, you know, code up your own HTTP request library, it's like, well, you'd use one of the existing ones that we have that's already troubleshoot. Right. It's not I persay. [01:08:56] It's just, you know. Building better Lego bricks, bigger Lego bricks that have more functionality in them so people don't have to worry about the low level stuff as much anymore, like WordPress, for example, to me is like a tool for somebody who isn't a programmer to do something. [01:09:11] I mean, you can turn WordPress into anything. It's kind of crazy, actually, through plug ins. Right. And that's a programming persay. It's just Lego bricks stacking WordPress elements. Right. A little bit of configuration glue. So I would say maybe in a broader sense what I'm seeing, like they'll be more gluing and less like actual programming. [01:09:29] And that's a good thing, right? Because most of the stuff you need is kind of out there already. [01:09:33] You said 1970s Unix, DCP and these kind of old. [01:09:41] Remnants of of the early birth of programming remaining with us for a long time, like you said, Unix in itself, you see ultimately, you know, this stuff just being there out of momentum. [01:09:58] I kind of do. I mean, I was a big believer in windows early on. I was a big you know, I was like Unix. What a waste of time. But over time, I completely flipped on that where I was like, OK, the Unix guys were right. And pretty much Microsoft and Windows were kind of wrong, at least on the server side and on the desktop. Right. You need a go, you know, and stuff. [01:10:13] And yeah, the two philosophies like Apple built on Unix, effectively Darwin and on the desktop is a slightly different story. [01:10:19] But on the server side where you're going to be programming now, it's a question where the programming is going to be is going to be a lot more like client side programming because technically discourse is Clydeside programming the way you get discourse. We deliver a big bowl of JavaScript, which is the next cue locally. So are you really using a lot more local computing power? We'll still retrieve the data. Obviously, we have to display the posts on the screen and so forth. [01:10:39] But in terms of like sorting and a lot of the basic stuff, we're using the host processor. But to the extent that a lot of programming is still going to be server side, I would say yeah, the Unix philosophy, definitely one. And they'll be different veneers over Unix. But it's still if you if you peel away one or two layers, it's going to be Unix for a long I think Unix one. I mean, so definitively it's interesting to hear you say that because you've done so much excellent work on the Microsoft side in terms of backend development. [01:11:08] Cool. So what's the future hold for Jeff Atwood? [01:11:12] I mean, the discourse continuing, the discourse in trying to improve conversation on the Web while this course is what I read, is originally called a five year project, then really quickly revised that to a 10 year project. [01:11:24] So where we started in early to 2013, that's when we launched the first version. So we're still, you know, five years in. This is the part where it starts getting good, like we have a good product now, discourse, there's any any project you built in software. It takes three years to build what you want it to build anyway. Like this one is going to be terrible, which it was. But you ship it anyway because that's how you get better at stuff. [01:11:44] It's about turning the crank. It's not about V1 being perfect because that's ridiculous. It's about V1. Then let's get really good at one point one one point two, one, four, three. Like how fast can we iterate? And I think we're iterating like crazy on discourse to the point that, like, it's a really good product. Now we have serious momentum. And my original vision was I want to be the WordPress of discussion, meaning someone came to you and said, I want to start a blog. [01:12:06] Although the very question is kind of archaic now. It's like who actually blogs anymore? [01:12:10] But I wanted the answer to that to be it would be WordPress normally, because that's the obvious choice for blogging most of the time. But if someone said, hey, I want to I need a group of people to get together and do something, the answer should be discourse, right? That should be the default answer because it's open source. It's free, doesn't cost you anything. You control it, you can run it. Your minimum server cost for discourse is five bucks a month. [01:12:33] At this point. They actually got the VPs prices down. It used to be ten dollars a month for one gigabyte ram, which we're are dependent. We have a kind of heavy stack, like there's a lot of stuff in discourse. You need postgrads, you need retests, you need Ruby on rails, you need a sidekick for scheduling. [01:12:51] It's not a trivial amount of stuff because we were architected for like, look, we're building for the next ten years. I don't care about shared hosting. [01:12:57] That's that's not my model. [01:12:59] My idea is like, hey, you know, eventually this is going to be very cheap for everybody and I want to build it right. Using again, you know, higher, bigger building block levels. Right. That have more requirements. [01:13:09] And there's a WordPress model of what press dot org or perhaps dot com is their central hosting for discourse or. [01:13:15] No, there is we're not strictly segmenting into the open source versus the commercial side. We have a hosting business. That's how discourse makes money as we host discourse instances. And we have a really close relationship with our customers of the symbiosis of them giving us feedback on the product. We definitely wait feedback from customers a lot heavier than feedback from somebody who just wanders by and gives feedback. But that's where we make all our money. But we don't have a strict division. [01:13:39] We encourage people to use discourse like the whole point is that it's free, right? Anybody can set it up. I don't want to be the only person that hosts discourse. That's absolutely not the goal. But it is a primary way for us to build a business. And it's actually kind of a great business. I mean, the business is going really, really well in terms of hosting. So I used the word Google Research as a company that is basically funded on advertisements on Facebook. [01:14:03] Let me ask if you can comment on it. I think advertisement is best, so you'd be extremely critical on what ads are. But at its best, it's actually serving you, in a sense, is giving you it's connecting you to what you would want to explore. So it's like related posts to related content is the same. That's the best of that investment. [01:14:25] So discourse is connecting people based on their interests. It seems like a place where advertisement at its best could actually serve the users. [01:14:37] Is that something that you're considering thinking about as a. Way to bring to financially support the platform. That's interesting because I actually have a contrarian view of advertising, which I kind of agree with you. I recently installed that blocker like reluctantly because I don't like to do that. [01:14:53] But like the performance of the ads, man, like they're so heavy now and like, it's just crazy. So, like, it's almost like a performance argument more than like I actually am pro ads and I contrarian. I have a contrarian viewpoint. I agree with you if you do ads. Right, it's charming stuff you'll be interested in anyway. I don't mind that. That actually is kind of a good thing. [01:15:11] So plus I think it's rational to want to support the people that are doing this work through seeing their ads. And but that said, I run Adblock now, which I, I didn't want to do, but I was convinced by all these articles like 30 or 40 megabytes of stuff just to serve you ads. [01:15:27] Yeah, it feels like ads now are like the experts exchange of whenever you start to stack overflow, it's a little bit it's all there. [01:15:35] So many companies and ad tech, though, it's embarrassing. Like you can do that if you see this logo charts of like just the whole page is like you can't even see them. They're so small. There's so many companies in the space. [01:15:43] But since you brought it up, I do want to point out that very, very few discourse sites actually run using an ad supported model. It's not effective. Like it's too diluted, it's too weird, it doesn't pay well and like, users hate it. So it's a combination of, like, users hate it. It doesn't actually work that well in practice. Like in theory. Yes. I agree with you, Finn. Clean, fast ads that were exactly the stuff you would be interested in. [01:16:05] Awesome. Were so far from that, though, right? Like Google does an OK job, the retargeting and stuff like that. But in the in the real world, discourse sites rarely can make ads work. It just doesn't work for so many reasons. But, you know, it does work is subscriptions, Patreon affiliate codes for like Amazon of like just oh here here's a cool click and then you click and go to Amazon. They get a small percentage of that, which is fair I think. [01:16:32] I mean because you saw the yo yo on that site and you click through and you bought it. Right. That's fair for them to get five percent of that or two percent of that. Whatever it is, those things definitely work. In fact, a site that I used to participate on a lot, I helped the owner one things I, I got them switched to discourse. I basically paid them to switch to discourse because I was like, look, you guys going to switch? [01:16:50] I can't come here anymore on this terrible software. [01:16:53] But I was like, look, and on top of that, like, you're serving people ads that they hate. Like you should just go full on Patriot because he had a little bit of hatred on full Patreon. Do the Amazon affiliates thing, Phryne, Amazon links that you posted and just do that and just triple down on that stuff. And that's worked really well for them and this creator in particular. So that stuff works, but adds I mean, definitely not working, at least on discourse. [01:17:17] So last question. You've created the code keyboard. I've programmed most of my adult life and a Kinesis keyboard. I have one upstairs now. Can you describe what a mechanical keyboard is and why is it something that makes you happy? [01:17:32] Well, you know, this is another fetish I don't really like. It's not required. You can do programming on any kind of keyboard, but even like an on screen keyboard. Oh God, that's terrifying. [01:17:40] I like but you could touch I mean, if you look back to the early days being there were chick lit keyboards, which are I mean, those are awful. Right. But what's a chick flick you were. Oh God. OK, well it's just like thin rubber membranes or the rubber ones. [01:17:52] Oh no. Superbad, right. Yeah. So it's a fetish item. All it really says is, look, I care really about keyboards because the keyboard is the primary method of communication with the computer. [01:18:00] Right. So it's just like having a nice mic for this, this podcast. You want a nice keyboard, right? Because it has very tactile feel. I can tell exactly when I press the key, I get that little click. So, oh, it feels good. And it's also kind of a fetish. I was like, wow, I care enough about programming that I care about the tool, the primary tool that is coming out of the computer. [01:18:18] Make sure it's as good as it feels good to use for me and like, I can be very productive with it. So to be honest, it's a little bit of a fetish item, but a good one. It indicates that you're serious. And in case you're interested, it indicates that you care about the fundamentals because you know what makes you a good programmer, being able to type really fast. Right. Like this is true. Right? So a core skill is just being able to type fast enough to get your ideas out of your head into the code base. [01:18:41] So just practicing your typing can make you a better programmer. It is also something that makes you well, makes you enjoy typing the actual act. [01:18:53] Something about the process, like I play piano, it's technical, just a tactile feel that ultimately feeds the passion. Makes you happy right now. [01:19:03] Totally. That's it. I mean, and it's funny because artisanal keyboards have exploded, like Masteroff is gone ballistic with this stuff. There's probably like five hundred keyboard projects on Masteroff alone. And there's some other guy I follow on Twitter. I used to write for this, the site, the tech report way back in the day. And it's like every week he's just posting, like, what I call keyboard porn of like, just cool keyboard. Oh, my God. [01:19:21] This, like, really cool, right? Like that's like how many keyboards this guy has got, like me with yo yos. [01:19:26] How many yo yos you have, how many do you need. Well, technically one, but I like a lot. I don't know why. So same thing with keyboard so yeah they're awesome. Like I highly recommend anybody who doesn't have a mechanical to research it, look into it and see what you like and. It's ultimately a fetish item, but I think these sort of items, these religious artifacts that we have are part of what makes us human like that. [01:19:47] That part's important. It's kind of makes life worth living. [01:19:50] And, yes, it's not necessary in the strictest sense. But anything necessary, if you think of. Yeah, right. Like and so. [01:19:58] Yeah, we're not so sure. [01:20:00] Jeff, thank you so much for talking to. Yeah. You're welcome. [01:20:03] Thanks for having me.

本集資源與出處