簡評：這是《黑客與畫家》的作者 paul graham 的一篇經典文章。程式設計師作為抽象系統的創造者遵循 maker's schedule。寫**時需要整塊連續的時間思考，如果工作常常被幾個會議打斷，那一天下來根本做不了任何實質性的事情。程式設計師特別討厭開會的乙個原因是 —— 他們的日程跟其他人不太一樣，會議對程式設計師的消耗太大了。
schedule 一般分為兩種，我們姑且稱它們為 maker 的日程和 manager 的日程。比如說老闆就屬於 manager 日程，具體體現在待辦事項中，每天都以小時為單位。當然如果有需要的話可以一連幾個小時來完成某項工作，但大多數時候，每個小時每個時間段都有不同的事情等著你。
這樣的時間安排，要會見某人其實不是個問題，你只需要在日程中找個空檔，預定事項就搞定了。
大多數 ceo 或高層管理者都是採用 manager's schedule。但是程式設計師或者作家這類以創造進而輸出的人，普遍採用的是另一種日程安排 —— maker's schedule，他們更傾向於用個大半天的時間進行單一任務的工作。你不能以 1 小時為時間粒度，這個時間頂多起個頭，是寫不出什麼好文章或者優秀**的。
當你身在 maker's schedule 時，會議簡直就是一場災難。乙個會議就能毀掉整個下午，分成兩段的時間實在太過瑣碎以至於完全不能推動任何事情的進行，而且你的大腦還得想著不要忘記開會。
當然啦，對於管理者來說，會議不算什麼問題，反正以 manager's schedule 安排，下乙個小時總要做點什麼事情，區別不過是做什麼事情罷了。但對於程式設計師來說，你就總得惦記著。
會議於 maker 而言，就像引發異常機制（throw an exception），它不僅讓你進行任務間的切換，還改變了你的工作模式。
geek 的工作效率（翻譯 @aceyclee）
通常，會議一般至少消耗半天，要麼上午，要麼下午，總有一整塊時間會被腰斬。而這會帶來連鎖反應，導致會議會影響一整天的工作。如果知道下午的時間要泡湯了，那麼早上我就很難元氣滿滿地開始幹點什麼。聽起來可能有點矯情，但如果你也從事程式開發或者寫作這樣強輸出型別的工作，你摸著良心告訴我是不是這樣。比如今天你有一整天的時間可以用來工作，沒有人打擾，你會不會覺得很開心。反之，要是時不時有人打斷你，你是不是也很沮喪。夫戰，勇氣也。一鼓作氣，再而衰，三而竭。情緒低落是幹不好活兒的。
儘管兩種日程安排都能正常工作，但一旦二者相遇，問題就來了。管理者們按照 manager's schedule 工作，如果有需要，所有人都得按他們的時間表辦公，畢竟人家是領導。但，聰明的領導人會懂得如何協調，他們知道這類員工需要整塊的時間投入生產。
《黑客與畫家》的作者 paul graham 比較特殊。儘管幾乎所有他認識的 vc 都採用 manager's schedule，但他所在的公司 y combinator 仍然按照 maker 的日程工作。包括 rtm 和 trevor，因為他們一直都是 maker，jessica 也不例外，不過她是因為要跟其他人保持一致。
之後可能會出現更多以 maker's schedule 行事的公司，這並不奇怪，就像幾十年前他們也能夠拒絕將牛仔褲換成西裝。所以公司創始人們也許會抵制，或者至少推遲向經理人的方向轉變。
那麼我們又是如何採用 maker's schedule 來為眾多創業公司提供諮詢服務呢？
答案是以辦公時間這一概念在 maker 的框架內模擬出乙個經理人的日程。每週我會留出幾大塊時間來接待 founders，這部分時間通常會在我的工作日末尾。同時我寫了乙個程式來確保乙個時間範圍內的會議能安排在一起。這樣創業者們在工作結束後來訪，就不會打斷我的工作（除非他們的下班時間也和我一樣，才會妨礙到對方，但他們往往是有求而來）。因而，儘管事項繁忙，但整塊的辦公時間依然能覆蓋一整天，不會被打斷。
90 年代時，正值 paul graham 創業，他還嘗試了另一種劃分時間的方法 —— 每天從晚飯開始程式設計知道凌晨三點，因為夜深人靜沒人打擾。然後睡到中午 11 點再去上班做那些「生意上的事」，直到晚餐。
事實上，這樣他每天都有兩個日程：maker 以及 manager。
處在 manager 身份時，可以做些身為 maker 不想做的事情，比如會見客戶，或者和一些人小聚以增進對彼此的了解。畢竟日程裡有空檔時可以去做這些事情，也許還能變成幫助別人的機會。
但如果你採用 maker 的日常，那這種會面方式的代價可就特別大了。假如每個人都以為我們用 manager 的日程，然後介紹一些覺得我們應該見上一面的人，或者給我們發個訊息提議喝杯咖啡什麼的。要麼我們去見面，於是放棄了半天的工作時間；要麼我們婉拒，但很有可能會冒犯到對方。
一直以來我們都還不太明白上述問題的產生，我們理所應當地以為非此即彼，如果不放棄原有的安排就可能會冒犯對方。但現在我就突然清楚了，這是因為兩種不同的工作日程。當大家能理解這兩種工作方式的衝突時，問題也就稍稍能得以解決。
對於 maker 而言，我們願意妥協，我們也知道有些會議是非常必須的。而我們所訴求的，也僅僅是希望 manager 能明白，這種妥協所付出的代價。
打斷工程師 程式設計師的真實代價
很多時候，我發現自己需要向程式設計界以外的人反覆解釋為什麼隨意的打攪乙個程式設計中的程式設計師是多麼的討厭。我需要費力的向他們解釋什麼是 流 境界 程式設計師陷入深深思考和理解乙個問題時，乙個 乙個提問，甚至一句 你好 都會像一聲炸雷似的將程式設計師從 盜夢空間 裡驚醒 夢境中建好的一切建築都會立刻...
譯 好程式設計師的五聲「吶喊」
通常程式設計情況下，會導致軟體專案變壞的一些列反應 原文 the five shouts of good programmers 在任何一天，在這個世界上都有軟體專案正在失敗，這很常見。常見到當軟體產品按照預期發布時人們都會感到吃驚。這不是什麼新鮮事，基於被廣泛引用的standish group的c...
譯 x86程式設計師手冊02 基本的程式模式
chapter 2 basic programming model 基本的程式模式 介紹模式下的記憶體組織。資料型別的定義。能被程式使用的暫存器組。介紹棧。解釋字元操作。定義指令部分。解釋位址計算。介紹應用程式可以使用的中斷和異常。這章描述80386的應用程式環境，正象處理器在保護模式下執行時乙個彙...