如果你從事設計、插畫、動畫或任何創意領域的工作，遲早你會遇到同樣的難題： 你每天使用的軟體和電腦程式不僅僅是「工具」。它並非一台電腦，而是一個擁有自身規則、特性和特徵的完整生態系統。理解這些細微差別，就能讓你從使用電腦時舉步維艱，到感覺電腦彷彿在為你施展魔法。
除了鍵盤快捷鍵和一些零散的小技巧之外， 作業系統、程式設計、調試、「技術」文化和工作方式等方面的細節浩如煙海。 這會影響你作為創意人員所使用的應用程式的設計和功能。從內部了解這個世界，能幫助你更好地與開發團隊合作，提出更切合實際的需求…並產生更強大的創意，因為你知道哪些功能可以實現，哪些功能無法實現。
Unix、Mac、Linux，以及為什麼系統比看起來更重要。
對許多創意人士來說，經典的論點是 設計工作選擇Mac還是Windows？但在軟體領域，這種討論往往會更進一步：Unix 與其他所有系統之間的比較。 macOS 和大多數 Linux 發行版都繼承了 Unix 的概念，這使得它們成為開發和自動化任務的強大平台，而這些任務又會直接影響你使用的工具。
程式設計師經常說 “整個Unix系統就像一個大型開發環境”因為所有程式的設計初衷都是為了將終端機中各種功能強大的小型實用程式串聯起來：處理映像、自動匯出、啟動渲染腳本、管理伺服器或編譯程式碼，而無需依賴圖形化精靈。正因如此，許多高級創意套件、遊戲引擎和 3D 工具的設計都充分考慮了這類環境。
相較之下，Windows 系統在視覺上更直觀，也更人性化，但是 從歷史上看，它對深度開發和命令列工作不太“友好”。如今，這種差距已經大大縮小（WSL、PowerShell 等），但 Unix 文化仍然滲透到你使用的許多軟體中，而你甚至沒有意識到這一點。
身為創意工作者，你為什麼對這個有興趣？因為 能夠為您節省數小時的自動化程式、腳本和外掛程式通常都源自 Unix 世界。與已經掌握相關技能的團隊一起工作，通常會產生更強大、更穩定的工作流程，並且隨著專案的成長更容易擴展。
程式設計是一種罕見的混合體：邏輯、工程…以及大量的創造力。
從表面上看，程式設計似乎只是冷冰冰的計算，但實際上並非如此。 它巧妙地融合了數學、工程學和極富創造力的元素。就像你創作插圖或故事板一樣，開發人員會創建邏輯模組，以便軟體能夠完全按照設想運行。
大多數專業人士都認同這一點。 解決問題的能力和創造力與掌握一百萬種語言同等重要，甚至更重要。對於相同的功能，通常有很多種實現方式，就像設計封面或標誌有數千種方法一樣；關鍵是要找到最簡潔、最優雅、最易於維護的解決方案。
正因如此，創意團隊越來越重視理解這一點。 程式碼也是一種設計軟體架構決策、資料流和內部結構會極大地影響你對應用程式、外掛程式或網站的要求，而不會將專案變成無法維護的科學怪人。
沒錯，程式設計確實會上癮： 許多開發者都認為自己的作品是最好的邏輯謎題。規則和元素都由你自己決定，這非常符合喜歡從零開始創造事物的人的心態。
編譯、命令列和其他編碼“儀式”
如果你曾經聽到有人說“正在編譯”，然後端著咖啡離開座位，要知道… 這未必總是藉口，但卻是個完美的藉口。編譯是指將原始程式碼翻譯成可執行程序，在 C++ 等語言或大型遊戲引擎中，這可能需要幾分鐘甚至幾個小時。
在日復一日的日子裡， 這段整理時間可以用來喘口氣、複習概念，或是只是簡單地重置一下想法。在創意環境中，當你使用渲染引擎或大型遊戲建置時，也會發生類似的情況：在等待機器完成的停機時間內，許多團隊會利用這段時間討論想法、完善設計或審查任務。
與此相關的就是命令行，那個起初令人恐懼的黑屏，但一旦你掌握了它， 它變成了一種魔杖。你其實是在進行微型程式設計：你用腳本語言（如 Bash）寫指令來自動化那些在圖形介面中會很麻煩的操作。
對於高級創意人員來說，了解終端的四項知識可能非常有價值： 重新命名數千個檔案、批次轉換格式、啟動渲染腳本、行動備份或同步項目 無需觸碰滑鼠。這是另一種「與電腦溝通」並更接近程式設計師思維方式的方法。
程式碼的陰暗面：分號、bug 和無止盡的調試
軟體最殘酷的怪癖之一就是… 微小的東西也能摧毀巨大的東西。錯位的分號、缺少的括號或閉合位置錯誤的括號都可能毀掉數百行精心構思的程式碼，就像錯誤鎖定的圖層會毀掉整個 PSD 檔案一樣。
開發人員一天中的大部分時間都花在非常不起眼但至關重要的模式下： 偵錯錯誤尋找漏洞就像尋找藏在荒謬地方的生物：它們不總是導致程式崩潰，有時它們只會在特定時間觸發奇怪的錯誤，或者與某些數據一起出現或在某些設備上出現。
在你的世界裡，這意味著諸如此類的事情 有些工具只能處理一種類型的文件，有些動畫在你的電腦上看起來沒問題，但在生產環境中卻會崩潰，有些網站只能在特定的瀏覽器中運行異常。……令人驚訝的是，這些通常是程式碼中更深層錯誤的可見部分。
為了應對這種情況，大多數程式設計師都發展出了一套調試技巧： 使用日誌、圖形偵錯器、斷點和變數狀態列印輸出。甚至還會為發現某些特別難以發現的漏洞提供內部獎勵。這也是為什麼「快速」變更幾乎從來都不是真正快速的另一個原因。
沒錯，程式碼裡確實有幽默元素。很多註解都成了充滿諷刺意味的小藝術品： “// 魔法，請勿觸摸。”，“// 喝醉了，稍後修復”或“// IE 瀏覽器破解版（假設 IE 是一個瀏覽器）”這種戰壕式的幽默是開發者文化的重要組成部分。
懶惰、自動化和版本控制：偽裝的優點
聽起來可能很奇怪，但它正在開發中。 懶惰，如果理解得當，可以被視為一種職業美德。道理很簡單：如果某件事重複且需要手動完成，聰明的人就會想辦法將其自動化，這樣就不用再做了。正是這種「懶惰」驅動著腳本、插件、自動化操作和巨集的出現，而你每天使用這些東西時，卻往往不知道它們的來源。
在嚴肅的專案中，這種理念依賴另一個關鍵要素： 版本控制，其中 Git 堪稱絕對王者。多虧了 Git，團隊可以一起開發同一個專案而不會互相干擾，可以在不同的分支上測試瘋狂的想法，在應用程式一半功能崩潰時進行回滾，或者查看誰在何時修改了什麼。
對於與開發人員合作的創意專業人士來說，了解基礎知識至關重要。 什麼是提交、分支或合併？ 它很有幫助：它可以讓你追蹤開發進度，監控何時引入了影響你設計的更改，並更好地協調何時鎖定新功能以及專注於完善現有功能。
此外，這種自動化文化也適用於那些看似不那麼「技術性」的任務： 部署腳本、自動文件產生、每晚自動執行的測試、轉換資源、壓縮映像或生成版本的管道 無需人工幹預，即可在不同的設備上運作。這一切都源自於有人拒絕重複一百次相同的手工操作。
註釋、清晰的名稱以及對程式碼可讀性的執著追求
就像一份圖層命名清晰、分組有序的設計文件會受到無限讚賞一樣， 代碼需要秩序、上下文和良好的標籤。否則，它就會變成一片無法逾越的叢林，即使對於幾週前寫下它的人來說也是如此。
優秀的程式設計師非常重視兩件事： 有意義的名稱和評論，提供真實的背景信息呼叫變數 userAge o totalCost 它所表達的意義遠不止於此。 x o temp指出為什麼選擇特定的演算法或使用了什麼技巧，比註釋「// 將兩個數字相加」要有用得多。
實際上，這為專案創建了一種內部“技術腳本”，其他開發人員可以透過閱讀該腳本來理解專案內容。 每個模組背後的軟體設計決策當程式碼寫得當時，最好的註解有時就是程式碼本身，因為精心選擇的命名方式本身就能說明問題。
這種對清晰度的執著與你可能聽說過的一些概念非常契合，例如 程式碼整潔、重構或「不要重複自己」（DRY）原則所有這些理念都指向同一個方向：軟體應該易於理解、更改、測試和擴展，而不會破壞一切。
測試、TDD，以及為什麼「今天就讓它運行起來」還不夠
你使用的任何程式還有一個不太明顯但至關重要的方面： 測試生態系統背後的單元測試、整合測試、自動化測試或手動測試的存在，正是為了防止你請求添加的一個選項的微小更改悄無聲息地破壞系統的其他 20 個部分。
有些方法論，例如 TDD（測試驅動開發）， 首先編寫測試案例，然後編寫使測試案例通過的程式碼。這似乎有悖常理，但它迫使開發人員從一開始就思考所需的行為、邊界情況，以及如何驗證一切是否會隨著時間的推移而繼續正常運作。
對於創意團隊而言，這意味著一些非常具體的事情： 要求「對按鈕進行這個小小的改動」或「增加一個新效果」在測試和驗證方面確實會付出成本。並不是他們不想幫助你；而是因為任何修改，無論對介面來說多麼微小，都可能產生副作用，他們必須確保應用程式的其他部分不會崩潰。
此外，許多公司還會建立測試套件，在團隊成員睡覺或週末運行： 程式碼編譯完畢，執行了一系列測試，並審查了結果。如果出現問題，會在影響最終用戶之前很久就被檢測到…這其中也包括那些在製作過程中依賴這些工具的創意人員。
演算法、資料結構與速度：工具的隱形引擎
每一次文件搜尋、每一次瞬間應用的濾鏡，或是每一幅即使擁有數千個圖層也能保持流暢的畫布背後，都有一些你看不到的東西： 惡意選擇的演算法和資料結構使用列表、堆疊、佇列或字典（雜湊表）對效能有很大的影響。
例如： 如果你需要快速查找物品，字典比簡單的清單效率高得多。這樣一來，即使在大型專案中，您的編輯器也能在幾毫秒內找到樣式、符號或素材。像素、向量圖、3D網格或音軌的儲存方式也遵循同樣的原理。
當創意應用程式運作緩慢時，並不總是電腦的問題： 有時，瓶頸在於多年前做出的軟體設計決策。或者採取一些「臨時」的捷徑，結果卻永遠保留了下來，這在許多專案中都是很常見的。
這就是為什麼許多專業諮詢專欄都堅持… 避免過早優化，但要從一開始就選擇正確的演算法和結構。這種堅實的基礎實現了可擴展性：更多的圖層、更多的效果、更多的使用者、更多的設備…而不會導致系統崩潰。
程式設計師文化：怪異的笑話、二進制和“沒有湯匙”
如果你和開發人員一起工作，遲早會聽到這樣的話： “世上有10種人：懂二進制的和不懂二進制的。”這是一個經典的笑話，它利用了二進制的10等於十進制的2這個事實。這種技術幽默構成了一個完整的次文化：表情包、Reddit子版塊、對《駭客任務》、《星際大戰》、《星河戰隊》等作品的引用…
這句名言 “沒有湯匙” 人們常用《駭客任務》來比喻那種透過介面看清應用程式底層架構的感覺。當你掌握了程式設計技能，查看程式或網站就不再只是被動地接受資訊：你會開始想像它的模組、架構、各個部分之間的通訊方式，以及可能故障的地方。
人們也像討論蟲子一樣討論它們。 《星河戰隊》中的生物：外表雖小，卻能造成巨大的混亂。共同的語言能夠創造社群；幽默是一種應對龐大系統承載你的程式碼所帶來的壓力的方式。
對於創意專業人士而言，融入那種文化能讓與程式設計師的關係更加順暢： 理解他的笑話、他的典故和他的怪癖 它極大地促進了在討論截止日期、技術限製或臨時變更時的溝通。
程式設計師（真正）是如何學習的，這對你意味著什麼
另一個有趣的現像是，儘管有學位、訓練營和碩士課程， 程式設計中的大部分真正學習都是在實踐中發生的。它更像是一門手藝，而不是一門大學課程：你透過實踐來學習，破壞東西，修理東西，然後一遍又一遍地重複這個循環。
大多數開發者都認同一點： 你不需要記住所有內容。有官方文件、論壇、文章、書籍（例如《程式設計師應該知道的97件事》）以及大量的線上資源，例如： 西班牙語程式語言教程重要的是知道如何搜尋、選擇並將這些知識應用到具體問題上，就像你不可能把所有 Photoshop 快捷鍵都背下來，但你知道在需要的時候去哪裡查找一樣。
此外，幾乎所有人都建議專攻某一領域： 選擇一個領域（Web、行動裝置、後端、數據、電玩…）並深入研究。 與其試圖面面俱到地了解整個技術領域，不如深入鑽研。同樣的道理也適用於你：真正理解你所在創意領域的軟體運作原理，遠比對每個領域都略知一二卻一竅不通要強大得多。
許多內部調查也一再強調了導師和「結對程式設計」的重要性： 兩人一組進行編程，讓其他人審查你的程式碼，尋求幫助，並接受批評。就像你與他人分享故事板或情緒板並接受回饋以改進作品一樣。
開發工作的真實寫照：孤獨、專注與巨大的耳機
軟體團隊的日常工作與創意工作室有許多相似之處： 長時間面對螢幕，長時間集中註意力，以及對被打斷既愛又恨的複雜情感經常可以看到半數隊員都戴著巨大的降噪耳機，就好像那是強制性的工作頭盔一樣。
音樂成為提高生產力的工具： 用於建築思維的柔性列表，用於機械任務的更強大的工具，以及用於調試複雜漏洞的完全靜音工具。戴耳機不僅僅是一時興起：它是一種社交信號，表示“現在不要打擾我，我正在專注工作”，就像一些錄音室會在桌子上放置旗幟或小型物理信號一樣。
還有另一個不太為人所知的方面： 長時間獨自在電腦前工作會讓人感到孤單。許多資深程式設計師堅持認為，你不應該把自己當成機器人，培養程式設計之外的生活至關重要：嗜好、人際關係、體能訓練、休息。設計解決方案的大腦和設計介面的大腦是同一個，它們都需要空間。
同時，還有一個非常真實的現象叫做 程式設計成癮當你真正投入某件事時，很容易熬夜“只為了完成這門課”，甚至忘記吃飯、睡覺，或離開椅子。就像對待任何創造性的愛好一樣，你必須學會設定界限，避免精疲力竭。
心態、冒牌者症候群和良性競爭
大多數從事程式設計的人都擁有技術背景，但是 但這並不意味著具有「人文」背景的人不能接受再訓練。退伍軍人最重視的不是高中畢業文憑的類型，而是穩定性、學習能力以及一定的邏輯思考能力。
業界幾乎每個人都面臨著一個相當普遍的問題： 冒名頂替綜合症無論你的資歷多深，都可能出現「我懂得不夠多，我會被抓到，我勝任不了這項工作」的感覺。許多人會利用這種感覺來激勵自己不斷學習，只要它不會導致嚴重的焦慮。
競爭也是環境的一部分，但健康的競爭更像是… 同事之間存在“競爭”，看誰能最好地優化模組或編寫最優雅的程式碼。 這不像戰爭，不是看誰踩誰。一位你欣賞的程式設計師認可你的作品，就好比另一位創意人士欣賞你的插畫或錄像作品一樣。
在這種環境下，學會接受回饋至關重要： 受到表揚時，不要迷失方向；受到批評時，不要放棄。這個產業變化如此之快，總是會有一些你無法控制的技術，總是會有人在某些特定方面比你更了解，而接受這一點也是遊戲的一部分。
最耗時的部分：調試、應對挫折感以及決定何時切換
如果你只看最終結果，你可能會認為開發人員整天都在寫新功能，但實際上並非如此。 大部分時間都花在調試錯誤和調整現有事物。專案推進往往意味著要解決一些小漏洞，這些漏洞會阻礙系統其他部分的進展。
這會導致人們的挫折感顯著加劇： 難以發現的問題、無故失敗的建置、客戶提出的不可能的期限許多專業人士表示，他們曾經有過想要放棄一切、轉行的念頭，尤其是在從事複雜產品開發時。
他們推薦的策略聽起來很熟悉： 毅力、自我激勵、對優秀工作的自豪感，以及對這門技藝的真誠熱情。就像在任何要求很高的創意學科中一樣，這種混合體能讓你在事情進展不順利時再次嘗試，也能將那些停留在表面的人與那些真正優秀的人區分開來。
一定程度的員工流動也是很常見的： 優秀的候選人會不斷收到工作機會。這裡很多建議都指向同一個方向：尋找一家與你價值觀相符的公司文化，並且記住，在面試中，你也在評估這家公司。你會花很多時間思考它存在的問題；良好的人際關係和共同的價值觀遠比履歷看起來重要得多。
技術面試、團隊融入與溝通
在開發者社群中，技術面試相當有名……但同時也名聲不太好。許多資深開發者認為… 它們被過度高估了，考不好其中一項並不能說明你的潛力有多大。他們通常衡量的是壓力下的一系列特定技能，而不是你長期學習、協作和成功完成專案的實際能力。
取而代之的是， 軟技能往往能起到決定性作用。懂得如何溝通，在不理解的時候提出問題，接受回饋，與來自不同背景的人合作（如果你有創造力，例如你），並在緊張時刻保持冷靜。
加入公司時，對任何初級程式設計師來說最重要的建議是 不要害怕提問，但要認真思考後再提問。與導師安排固定時間解答疑問，除非緊急情況，否則避免打斷，並充分準備好你的問題。加入技術團隊時也是如此：你的溝通越清晰、越有條理，就越容易融入團隊。
在沒有指定導師的環境中，最明智的做法是 贏得有經驗人士的信任，並建立穩固的專業關係 與那個人合作。歸根結底，大型專案的成功不僅取決於程式碼和設計的質量，還取決於專案參與者之間的關係品質。
歸根結底，你每天使用的工具的魔力源自於一種相當人性化的融合： 不斷學習、會感到沮喪、有競爭意識、善於合作、會嘲笑奇怪的二元笑話，並逐漸將想法轉化為軟體的人當你作為一名創意人士，了解了這些奇思妙想和工作方式之後，就更容易用同樣的語言交流，提出實際可以實現的需求，並參與到讓計算機完全按照你的想像運行的近乎“神奇”的過程中。