編程：思考或打字，思考和打字
”如果你思慮不周，你也許會認為編程只是一行一行把代碼語句敲進電腦里。“——Ward Cunningham 在《程序員修煉之道:從小工到專家》中的序言提到。
軟件開發包含很多需要深入思考的內容，諸如設計、解決問題、找出最佳算法，學習新語言，重構混亂的代碼，使其變得整潔而優雅等等。
當你嘗試去做一件你從沒做甚至從來沒有人做過的事；或者你以前做過，但毫無疑問不想再犯類似的錯誤，而需要去思考一個更好的方法；或者你嘗試去理解其他人寫的代碼以便修改；或者你正在查找一個討厭的BUG。所有這些都會占用大量的時間，但最終并不會產生很多代碼。
同時軟件開發中也有許多需要大量打字而不需要過多思考的工作。比如當你很清楚需要做什么并且如何做時，但是在工作完成之前，你需要編寫大量的代碼， 因為你之前做過類似的東西，所以僅僅需要再做一遍，用另一種腳本，適應另一種屏幕，另一種報告，另一種除了思考之外的所有東西；或者工作中大部分需要思考 的工作已經有人為你做好了，他給你提供了程序線框圖，精確向你描述這個程序看起來的樣子，給人的感覺以及數據的流動，或者提供了詳細的API說明，所以， 你要做的事僅僅是把這些思考的結果敲進屏幕同時確保不要犯太多錯誤。
調試程序是思考型工作（Debugging is thinking）。而修復BUG、使其通過測試、發布主要是輸入型工作。早期的設計和開發，決定使用的技術并設計框架，是艱難的思考型工作，而基于此開 發三個、四個或100個的適應屏幕或報告的程序是輸入型工作。用戶體驗和原型設計是思考型的工作，而將其實現（包括CRUD、適應不同屏幕的配置）卻是輸 入型工作。找到一個酷的移動應用點子是思考型工作，而實現它卻是輸入型工作。解決一般的業務問題需要大量的編碼，而通過軟件優化業務流程去需要大量艱難的 思考。
所以，思考型工作的人和輸入型工作的人做著不同的工作，并且需要用不同的方式管理。
有時候編程就是在打字輸入
”我們首先是打字員，然后才是程序員。“——Jeff Atwood, Programming Horror
許多業務程序本質上是很膚淺的。大量的數據庫表和文件充斥著大量的元素和數據，大量的增刪改查頁面、報表相互之間有許多的相似之處；大量的集成工作 把不同屬性的不同點映射統一，從而使其滿足約束并在操作上獨立對待。功能需求上冗長的列表，通過一大堆的問題確保每個人都理解需求，許多細節描述用來備忘 和追蹤。銀行、保險、政府、會記、財務報表和賬單、庫存管理和ERP系統、CRM系統，企業內部應用、簿記系統、記錄系統等等都是如此。許多在線門戶和商 店也一樣。一些維護型工作，如平臺升級、系統集成和移植、稅收變化等也是如此。
你是在建造一幢房子、一座橋、一個百貨商場，或是改造其中之一。大項目經常不斷滋生各種問題，通常要花費大量時間去解決。很多輸入型工作需要做，但是其中有一部分之前已經做過很多次了，那些工作涉及類似的問題，所以你可以應用熟悉的模式、被證明可靠的工具和工作方法。
“我昨天看了你電腦程序的源代碼，它看起來很簡單；只是打了很多字，其中一半還拼寫錯誤。還有，別再讓我抱怨你那過渡使用的冒號了。” —— 《The Pointy Haired Boss sees some actual code》
一旦設計確定，絕大部分工作都被充分理解并考慮了所有的細節，剩下的就是管理和協調程序員去把這是代碼敲出來。這是一種經典的項目管理流程：預算、計劃、跟蹤成本和調整、管理計劃。這是關于邏輯、規模、一致性和效率的問題，確保工作在正確的軌道上運行。
思考！思考！思考！
其他的問題，比如設計一個游戲引擎、交易算法、物流或在線風險管理系統、優化一個實時控制系統，這些工作需要的思考都大于輸入編碼。這些系統有著高 標準、非技術性需求（可擴展性、實時性能、可靠性、數據完整性和正確性）和復雜的邏輯，但是他們集中在解決一系列緊密結合的問題。只有很少一部分聰明的程 序員可以思考那些問題并實現。當然，編碼工作仍然需要去做，特別是“外圍”部分，框架、管道、布線方式等，但是核心的部分通常只有非常少量的代碼，尤其是 在拋棄失敗的試驗和原型之后。
這就是軟件的奧秘所在，有版權或專利的算法和設計的洞察力是一個成功系統的核心。這種工作需要花費大量的時間去研究、需要無數次的設計原型、需要解決問題的能力，要么需要過硬的技術，要么需要深刻的領域知識，又或者要求二者兼備。
編碼輸入和思考是不同種類的工作
工作的性質以編碼為主，還是以思考為主，影響著你的團隊需要的人員數量和類型。這會改變人們之間如何合作，以及你如何取管理團隊。編碼可以被外包，但思考不行。你需要認識到哪些問題可以通過編碼解決，而哪些不行，以及什么時候思考型工作轉變為編碼輸入型工作。
思考型工作可以也應該交給一個小而精的專家團隊，或者干脆托付給一個天才。在思考設計或思考復雜問題、反復試驗的階段，你不需要太多的人。做這種工 作的人需要完全沉浸其中，在這段時間里，他們會開展探索性研究，也可能會犯錯誤，他們會學習，在遇到困難時，也許僅僅會盯著屏幕發呆（其實是在思考啦 ^_^）。
這個階段極其重要，因為在此所犯的錯誤通常都是致命的（終結項目或職業生涯級別的錯誤）。比如選擇了錯誤的技術平臺；假設了錯誤的實時系統的可容忍延遲；花費大量的時間去尋找（或者根本找不到）高可靠性的方案；挑選了錯誤的人員或者嘗試去解決錯誤的問題；使項目失去了節奏。
管理此類工作需要尋找最優秀的人才，確保他們有正確的信息和工具，讓他們專注，同時要觀察外界的風險，以確保他們不被打擾。
思考型的工作是不可預知的。不存在“復制粘貼”的方法，因為你根本不知道從哪“復制和粘貼”。你不可能估計此類工作，因為你根本不知道有多少事務是你所不知道的。但是你可以設置一個時間限制，嘗試尋找規定時間內的最佳方案。
編碼輸入型工作是可預知的。你可以同時也不得不去估計這類工作。訣竅在于把所有需要編碼的工作的列出來，并為工作中所有可能遇到的錯誤和變化做出估 計。它們通常會隨著項目的進行而快速增加，諸如程序員的粗心大意、錯誤理解了需求、遺漏了測試、簡單的“復制粘貼”，這些都會導致現在和將來的成本增加。
編碼輸入是一種工人式的工作。雖然一些高級開發者在他們厭煩前可以媲美一個大團隊的工作，但是你不需要專家，那些理解所用語言和工具的基本原則、細 心并且愿意服從指示、耐心的人都可以勝任此類工作。管理一群“打字員”需要不同的方式和技巧：你需要嘗試變成一個政客、一個外交家、一個后勤人員、一個標 準制定者、一個管理員、一個經濟學家的角色。你是在管理項目和人員的風險，而非技術。
一段時間后，一旦大部分“我們不確定我們需要且如何去做”的艱難工作被解決了、一旦未知的事務被逐漸掌握，思考型工作就轉變為了輸入型工作，這時候就需要去填補細節并使流程跑通。
當系統的用戶增加，不得不去處理更多的接口、地點、本地化、電子郵件、摘要、支持和承諾時，你就需要開展更多的輸入型工作。系統保持增長，但是大部分的問題都是熟悉且可解決的。有大量的代碼可供查找、學習和復制。你需要的是能夠從中挑選所需和打字快的程序員。
思考和編碼/輸入
思考和編碼都是軟件開發的重要組成部分。
在《編程不僅僅是打字》一文中。Brendan Enrick解釋了結對編程有用的原因：這可以讓兩個程序員同時各自專注在思考和編碼兩個方面。
”兩個人都在思考，但思考的內容不同。一個開發者擁有鍵盤，并且沉浸其中（這種開發者需要一定的打字速度），他依照當前的代碼邏輯進行編碼而不是整個應用的結構。一段時間后，他編碼的速度就會提高。
在結對編程中不實際編碼的人把所有的時間都專注在思考上。他的腦子中具有編碼者工作的清晰流程，但并不關心實際編程語言的語法，實際的編碼者才需要關心語法。這種在編碼者身后坐著的人，更像是一位向導，他必須確保工作進展在正確的道路上，并使用最有效的方式去實現它。“
成為一位優秀的開發者比單純的編碼輸入更出色，而成為一位得力的編碼輸入者也比簡單的敲擊鍵盤更優秀。這意味你必須有很好的基礎：掌握足夠的編程語 言特性，知道用什么工具以及如何使用，要會讀代碼，當然也要知道如何寫代碼（同時要寫得快）；學會控制你的工具、知道使用哪種編碼更快，這樣你就更加靈 活，這些都是接替一個開發者所必須的。最后，不要低估編碼輸入的重要性，也不要讓那些本該是輸入型的工作變成思考型的工作。
原文鏈接：http://swreflections.blogspot.com/2013/10/programming-thinking-or-typing-thinking.html
