軟體系統建置以及撰寫程式碼以支援此項工作是一項複雜的任務，它在各種不同的情況下被廣泛實踐，因此似乎很難一概而論。然而，人類天生就有分類事物的傾向，所以還是存在一些共通點。我有時候會對程式設計師進行分類，有很多種方式可以思考如何對程式設計師進行分類，例如依據使用的程式語言、架構層級，甚至是其他技術專長。但我想到的這種分類方式對我來說似乎更具基礎性，它是關於程式設計師如何思考和組織他們的工作。
三種程式設計師類型
無論你使用什麼語言，在很大程度上無論你的經驗水平如何，以及大多數情況下無論你所創建的軟體的性質如何，在我看來，程式設計師可以分為三種類型。這三種類型分別是程式員（coder）、軟體開發人員（software developer）和軟體工程師（software engineer）。
程式員
程式員將要建置的內容的詳細描述轉換為實現它的程式碼。我認為他們將自己的主要技能視為能夠使用程式設計語言。然而，這種世界觀存在一些問題。程式員表現得好像理解他們正在處理的問題並不是他們真正的問題，這對於寫程式碼的行為來說是次要的。他們抗拒測試自己的程式碼，因為他們認為那也不是他們的工作。
在功能較差的組織中，程式員經常成為一種「學得的無助感」的受害者。例如，他們可能會說：「我不能把時間花在設計上，因為這不在計畫中。」「我不能更改那個程式碼，我的老闆不讓我這樣做。」「我們必須使用那些工具，因為架構師說我們必須這樣做。」
在我工作過的一個組織中，一位程式員告訴我一個故事。他在程式碼的某個區域工作時注意到一個導致錯誤的問題，於是他修復了這個錯誤。後來，一位專案經理過來告訴他刪除這個錯誤修復，因為這個錯誤修復不在計畫中。在另一個組織中，我正在與團隊中一位相當資深的開發人員一起進行一些重構，我說我們可以為此創建一個新類，他的整個身體語言都改變了，他有點癱坐在座位上。我問他怎麼了，他回答說：「我們必須更改五個配置檔案，並提出一個新增新類的請求。」
很明顯，在這兩個例子中，這些行為都是由組織文化強加給程式設計師的，迫使他們扮演程式員的角色，而不是其他角色。在第一個例子中，即使開發人員試圖做正確的事情，並渴望更像軟體開發人員那樣工作，承擔更多的責任，而不是僅僅作為一名程式員，但這種情況仍然令人沮喪地普遍存在。更可怕的是，在這樣的環境中工作的人開始認為這是正常的，從而進一步加強了這種觀念。
如果你曾經說過：「這不是我的錯，是別人沒有把需求搞對。」那麼你可能更像一個程式員。程式員經常利用對他們工作的外部控制作為一種藉口，來避免做他們真正不想做的事情，例如：「我不能寫測試，因為我的老闆不讓我這樣做。」許多組織都是這樣組織工作的，但在我40多年的專業軟體開發生涯中，我從未見過這種方式能很好地工作。當然，程式員可以生產系統，但這些系統從來都不是人們喜歡的、聰明的或易於處理的。
軟體開發人員
軟體開發人員對自己的工作承擔更多的個人責任。他們將自己的工作視為使用軟體作為工具為他人解決問題，而不是將一些預定的解決方案轉換為程式碼。你可以將此視為他們的工作主要是系統的設計以及所有相關的事情。
我職業生涯的大部分時間都將自己視為一名軟體開發人員，而且大多數時候我仍然這樣認為。對我來說，程式員和軟體開發人員之間的區別非常明顯。在任何情況下，我都不認為圍繞程式員組織軟體開發比圍繞軟體開發人員組織軟體開發更好、更有效。如果你將軟體開發視為不僅僅是將特定解決方案簡單地轉換為程式碼，你總是會得到更好的結果。然而，這個錯誤仍然非常普遍。
問題在於，也許甚至大多數大型組織都認為這是擴展軟體開發所必需的。然而，這實際上是21世紀版本的泰勒主義（Taylorism），這是一種所謂的科學管理哲學，在20世紀30年代基本上就已經被否定了。泰勒主義是一種相當基本的嘗試分解工作的方法，是導致早期生產線的思想的一部分。它在某種程度上適用於不太需要創造力的工作，而這與軟體開發不太一樣。
例如，如果我製造一個輪子，你安裝這個輪子，我們可以各自專注於並且非常擅長我們各自但相關的專業。但這裡顯然存在某種技術合約。我生產的輪子需要與你需要安裝的任何東西配合使用。因此，當該合約可能發生變化，我們需要比泰勒主義更具創造力的東西時，它就會崩潰。我不能自由地改變我的輪子的設計，因為你、我以及生產你要安裝輪子的車軸的人都被輪子和車軸的設計所束縛。
事實上，這甚至對於像輪子和車軸的設計這樣相對穩定的東西也不能很好地工作。精益製造證明，有比泰勒主義更有效的組織工作的方法。我們希望人類在遇到不可預見的問題時能夠自由地以不可預測的方式改變事物，並在遇到問題時解決問題。這在現實中要有效得多。這就是從程式員到軟體開發人員的一步。軟體開發人員感到有責任並且有自由根據自己的判斷糾正事情。
事實上，DevOps狀態報告稱，這種自由和主人翁意識是高績效團隊的主要預測因素之一。我認為，隨著AI程式設計的發展，程式員和軟體開發人員之間的這種區別可能變得更加明顯。AI非常擅長將詳細的指令轉換為程式碼。但是，要充分理解眼前的問題，以便能夠提出創造性的解決方案，甚至提出那些詳細的指令，仍然是一項困難的工作，需要更多的洞察力和理解，也許需要更多的專業知識。這比僅僅寫程式碼要困難得多。程式設計語言不是困難的部分，如果是的話，那麼你就是一個初學者。理解問題和解決方案的設計是困難的部分，這是我們應該專注於在有或沒有AI協助的情況下變得優秀的地方。
軟體工程師
軟體工程師和軟體開發人員之間的最後一個區別更具體，可能也更受我個人偏見的影響。但我認為軟體工程師有兩個定義性特徵。
首先，他們將科學理性的方法應用於問題解決。我在我的書《現代軟體工程》中描述了這些原則。
其次，由於這一點，他們能夠在每次小的更改後確定他們的系統的可發布性。第二點可能聽起來有點具體，但DORA的DevOps狀態報告中的數據表明，統計上來說，持續交付是組織我們工作的最有效方式。它只是更快地生產出更好的軟體。我們在做的過程中更有樂趣，以這種方式工作的公司賺的錢更多。
如果工程真的是關於做有效的事情，那麼就我們所知，持續交付是最有效的方法。因此，使持續交付成為可能的技術、文化和組織學科確實代表了軟體開發的真正工程學科。CD是指你的軟體始終處於可發布的狀態。因此，將工程定義為知道你的軟體是可發布的，對我來說似乎是一個合理的稱呼。
軟體工程師的第一個定義性特徵也很重要，那就是理性的科學式思維。現代工程學實際上是科學的實踐分支，因為這是最有效的方法，而工程學最終是最實用的學科。如果它不起作用，那就不是工程。否則，你的橋樑會倒塌，你的宇宙飛船會墜毀，或者你的軟體會以同樣壯觀的方式失敗。
因此，如果我們想把事情做好，擁有一個問題解決模型，有組織地進行是至關重要的。無論如何，我對優化學習的五個實踐是我對該模型應該是什麼的建議。當你不知道一個好的解決方案應該是什麼時，你如何解決一個問題？實際上，你如何解決任何複雜的問題？因為這就是複雜問題的定義。你不知道解決方案應該是什麼。你通過採用一般的問題解決方法並擅長它來做到這一點。
總結
我的這三個類別並不是基於任何科學或研究。這些是我的主觀意見，但我確實發現它們在對團隊在追求卓越的旅程中的位置進行分類方面很有用，有時在弄清楚他們在未來的旅程中可能需要考慮下一步做什麼方面也很有用。
作為一個在軟體背景下經常談論軟體工程的人，我經常受到人們的挑戰，說我們所做的不是工程。總的來說，如果我從字面上理解他們，我不得不同意。大多數軟體開發並不是作為工程來實踐的。就我所見，可悲的是，大多數都是組織成程式員團隊。程式員和程式員團隊比軟體開發人員多得多。軟體開發人員和軟體開發人員團隊比軟體工程師和軟體工程團隊多得多。即使我們稱人們為軟體工程師，他們大多數也不符合我對軟體工程師應該是什麼的定義。
但我也認為，建立程式員團隊是組織事情的最佳方式，這並沒有真正的爭論。沒有經濟上的論點或產品上的論點。程式員不會比軟體開發人員或工程師更快、更便宜地構建更好的系統。我認為將軟體開發分解為專案管理的程式設計任務是一項徒勞的工作，會生產出更差的軟體，速度更慢。因此，無論在什麼情況下，這都不是一個更好的選擇。
感謝您的觀看。如果您喜歡今天的內容，請點贊。如果您真的喜歡，為什麼不考慮通過加入我們的Patreon社區來支持我們呢？我還要感謝我們的Patreon社區的持續支持。非常感謝，再見。