創始人回應說，他們反應過度，並且基於簡歷和麵試，他對新領導的技能有絕對的信任，這就是為什麼他將這個角色分配給這個人首先是首席開發人員。

負責人講話。這不是政府或政黨。您不能將任何人趕出去或進行暴動。

如果您不願意對此進行應對，那麼您確實有一個選擇。您可以團結起來，揚言要戒，除非有事發生。

我是說可以，不應該。有一個非常好的機會，那就是不能順利結束。您基本上是想將自己置於做出決定的老闆之前，而負責人不希望他們受到挑戰。

我想告訴您的“正確”事情是找到技巧鼓勵他看到你的思維方式。但是我不會那樣做。我是一名30年的高級開發人員，我可以告訴您，我在很大程度上已經適應了基本原則。不，我不喜歡這個人，是的，我接受建議。我擁護新技術等等。這個傢伙在很多事情上顯然是錯誤的。但是，我可以告訴您的是，當我著手進行某件事時，我確信自己會做出正確的決定，我會堅持下去。我不善於面對威脅，而且威逼或操縱甚至更糟。不在他職業生涯的現階段。他堅信自己是對的，並且他認為自己的經歷為他提供了支持。不幸的是，老闆也是。

老實說，這可能不值得您和您的團隊承受壓力。 我建議你們每個人都開始尋找一份新工作，找到工作後就離開。當一個人離開時，請確保他們告訴老闆原因。最終，他可能會得到這張照片。即使這樣，也不能保證。

運行嚴重的是，我不知道為什麼有人想要在那裡。問問自己，您告訴我們的內容中有什麼不代表產品最終會滅亡嗎？我確定你知道這一點。我對此事質疑創始人的基本知識。開發人員通常使非常糟糕的項目/程序經理。這是一套獨立的技能，他們需要相互平衡。這就像在說：“我們不需要單獨的測試人員，開發人員的測試效果很好。”兩者都是災難的秘訣。祝好運。我是說。

OP對情況的描述可能是單方面的。沒關係。

我是一家老齡開發人員（大約54歲），被帶到一家公司來統治而不是提供經驗。 （IT老闆實際上說的是“灰白的頭髮”，大聲笑。）總的來說，開發人員比我以前合作過的任何團隊都要熟練得多。他們教給我很多東西，尤其是謙卑！但是，我們發現了他們的技術巫術無法解決問題的地方，在某些情況下掩蓋了這些問題，最終使問題變得更糟。這是我真正能夠做出貢獻的地方。

您的領導聽起來很專制。聽起來好像老闆已經委託他了。所有者對開發人員不滿意，因此請了這個“精打細算的傢伙”來提高交付速度。

首先，請看一下您的員工。您是否有弱項-開發人員沒有“看到Matrix”？如果是這樣，請為他們找到公司中的新職位，或者為需要他們獨特技能的雇主提供很好的參考。

他討厭IDEs

I知道一些這樣做。它使我翻白眼，但最終我不在乎。如果人們使用 vi 進行製作，那就可以了。我愛我的IDE。第一部分上的紅旗。他是抄襲者嗎？我也對不關心樣式感到內gui，但這是因為我使用IDE立即使我的Python代碼PEP8兼容。但是他沒有使用IDE ...

作為一個註釋，以前曾通過每晚構建檢查樣式，此樣式自新線索到達以來就開始失敗。

他拒絕進行夜間構建以及自動測試的想法。根據他的說法，“任何專業開發人員無論如何都要手工測試他的代碼，因此沒有理由浪費時間編寫自動化測試”。據他介紹，每晚的建築也浪費時間。

這也會引發一個危險信號，但是出於與您預期不同的原因。在此人被雇用之前，所有者被告知多少次因為夜間構建失敗而無法執行X（提供演示，使用系統等）？如果業主認為每晚建造是問題怎麼辦？您認為他會告訴牽頭人做什麼？

但是我對牽頭人的態度感到擔憂。自動化測試非常了不起。像以前一樣，老闆可能不了解測試的價值，但他當然知道開發人員的薪水的Y％在為測試付款。當我來到我現在的公司時，“ 100％測試覆蓋率黑手黨”已經接管了開發人員，並且運營成本不斷上升。後來一個壞蘋果和開發人員再次怒吼。

他認為版本控制幾乎是無用的……

最高順序。他是盡可能的錯誤。他對所有者的錢不負責任。

他誇大了代碼優化的重要性。

在過去，代碼優化可能會有所作為。現在，機器是如此之快，以至於它變得不那麼重要了。相反，我們現在需要擔心數據庫性能和網絡吞吐量。但是，相信我，他的“代碼優化”習慣很難改變。我必須讓自己不要預先優化。至少在這種情況下，除了所花費的時間外，他的行為沒有破壞性。 （您是否為他的“一半時間”提供了數字，或者這是誇張嗎？如果您在批評主管，則不允許誇張。您必須在病理上是客觀的。）

手工執行SQL，並拒絕ORM的想法。

有罪不罰！我不理解人們對SQL的恐懼。我不理解在混淆的ORM層下埋入SQL的方法，這種方法非常簡單。在這裡不能為您提供幫助：-D但是，請把所有SQL都轉儲到一個地方-不要在您的代碼中全部分發。

和五個開發人員中的兩個以前從未使用過SQL。

這是不可接受的。這是2016年。他們需要提高技能。

他拒絕使用框架和第三方庫，因為從頭開始編寫東西要容易得多。

這不是很清楚。原因是15年前的生活要輕鬆得多，因為業務要求要簡單得多。這就是問題所在。網絡是作為批處理系統發明的（填寫表單，提交表單，獲得回复，重複），現在我們試圖編寫行為類似於桌面應用程序的網絡應用程序。他的觀察是正確的，現在情況很難。但是他不知道為什麼。工具的複雜性是對更複雜的業務需求的回應。因此，他做出了錯誤的選擇。

我們正在使用AngularJS，它似乎還不錯。像所有強大的工具一樣，它可以用於善惡。

他認為移動設備（包括平板電腦）只是一種炒作，因此沒有理由浪費寶貴的時間來確保站點與那些設備的兼容性並進行響應式設計。該產品是公共Web應用程序，預計不會在移動設備上大量使用。

他又錯了。他們不是炒作。它們在這裡停留是因為它們很有用。但是企業不需要它。不要開發不需要的東西。這很昂貴。

響應式設計對於這個應用來說可能會很有趣，...

您是否付得起這麼有趣？為個人發展？如果這是一個好主意，則您應該應該能夠將該主意賣給所有者。否則，請不要花一角錢。仍然出售MSDN CD！）和書籍。

他錯了。互聯網對此非常有用。如果開發人員從Stackoverflow複製粘貼而不了解代碼的工作原理，那麼他們也是錯誤的。在開發進度表中是否有時間進行培訓和個人改進？當您總是在槍口下時，很難不自動複製粘貼。

雖然我的信息有限，但是這裡有很多問題。聽起來好像所有者沒有像他期望的那樣迅速得到他所支付的代碼。聽起來他聽說過很多他不在乎的事情的藉口。他專注於結果。如果我是正確的話，那麼您有一個自我傷害的傷口，並且已經重新打開了不止一次。該負責人是所有者對開發人員提出的問題的解決方案，並且由於他的信息有限，這是可以理解的。

我還會打賭，您經營的是非敏捷商店，要求定義不佳，會隨風而變化。開發人員和所有者之間沒有隔離層。除了該線索。

現在，您能做什麼？

1）訓練線索以使自動化測試和代碼管理成為可能。在他身上贏得信譽可能需要一些時間-店主可能已經告訴他員工有缺陷。看看您是否可以阻止他做出繁重的任務，例如“刪除所有無用的測試廢話並重新使用SVN服務器”。

2）繼續在個人級別上使用代碼管理。至少您可以從自己的錯誤中恢復過來。

3）不要告訴他您正在執行此操作。

3）在個人層面上繼續進行自動化測試（如果沒有其他要求，請進行單元測試）。像以前一樣，不要提起它，儘管不要將其隱藏。

4）與負責人一起確定實際的實際問題是什麼。開放的心態我敢打賭員工真的有問題。與負責人一起解決問題，而不是解決問題。

5）與負責人討論各種開發主題，例如瀑布和敏捷的好處。兩者都不是完美的。向他問諸如“在什麼情況下自動測試值得”這樣的問題？如果他給出了一個令人懷疑的答案，請問他，儘管如此，像Google這樣的成功公司如何成功地發展起來。建立信任。同意問題與症狀。這並不總是那麼容易，尤其是當您覺得他像哥斯拉並把您的作品拆散時。

他有機會不能妥協。他將粉碎自動化測試。代碼管理適用於粗心的人。我的路還是高速公路。

但是，如果到了這一點，就該離開了。在沒有工具的商店中工作，我的意思是軟件和軟件工程工具-不會建立您的簡歷。您將開始以腐爛線索的方式開始腐爛。在這種情況下，繼續前進。

25年的IT生涯改變了他的態度

對不起，我不能工作。

您真正的問題不是沒有能力的首席開發人員。與您描述的實際問題相比，該問題微不足道：

您的創始人對無能*的陌生人的信任程度超過了對現有僱員的信任程度。

您需要弄清楚團隊如何失去信任，以及如何贏得信任。如果在僱用陌生人之前做到這一點會更容易。現在這很難了，因為任何好的工作都會歸功於新的團隊領導，而任何糟糕的工作都會歸功於你們所有人-因此您無法通過更加努力地解決它。

有我只有兩件事可以想到，以改善此工作的情況：

1. 找到一名調解人。是否有多個創始人或類似董事會成員的人？
2. 也許信任問題是可見性問題。在這種情況下，任何有助於提高知名度的東西都會對您有所幫助。例如。使sprint演示足夠令人興奮和有趣，以至於創始人實際上可以參加並了解團隊的狀況和進度。
ol>

---

*儘管OP提出的大多數觀點不一定陌生人無能為力，他在5人團隊中進行版本控制和持續集成的方法肯定可以。

這個答案可能是不利的，有些人認為這很愚蠢，但是...

第一個危險信號是幾年來，創始人對該技術的技術水平感到不滿。員工

員工是否試圖糾正這種不滿？

第二個危險信號是五個開發人員中從未使用過SQL的代碼>

如果開發人員不熟悉核心技術並且真正了解ORM掩蓋了什麼，那麼很難創建一個有效的系統。

很難想像我在這個行業工作了25年，您呢？你做了什麼？您已經成為代碼猴子三年了。閉嘴，你，白痴！沒人在乎您的意見，一個******。實際上是說出來的，但是我會以其面值來相信您。

但是，請考慮一下我提到的第一個危險信號

為此，我補充：你們已經知道創始人多年的不快樂了！！

這是怎麼回事？信息洩露給了你？

我傾向於認為這個人正在精確地做他被雇用要做的事；鍛煉身體。

鍛煉身體並不是指採用新手的壞習慣，而是要讓您脫離舒適區來進行更深入的學習。

幾年來，創始人對員工的技術技能感到不滿，最近他聘請了一位高級開發人員擔任技術主管和項目經理的雙重角色。他是唯一接受面試的人，也是唯一決定聘請此人的人。

聽起來像創始人不信任你。

不過，在兩個月的時間裡，車隊對他的形像變得不那麼欣賞了。我有機會與該團隊的五名成員中的三名進行了交談，他們都強調了三個問題：

• 根據他們的說法，這傢伙是個混蛋，對其他成員不尊重團隊。最近有一次他引用團隊中的初級程序員的話非常有說服力：“我在這個行業工作了25年，您呢？你做了什麼？您已經成為代碼猴子三年了。閉嘴，你，白痴！

聽起來好像你只是在講故事的一個方面。我可以想像一些情況，我可能需要自己殺死一個年輕人，而我已經知道了。只是在這裡扮演惡魔的擁護者，但聽起來他很受激。挑釁是什麼？

• 過去，所有團隊成員都做出決定。當成員不同意時，他們將一起討論所有問題並達成協議，或者至少向不同意的人解釋原因。

顯然，過去的做法並沒有產生創始人想要的結果。

現在，所有重要的決定都由首席開發人員專門做出。即使所有五個團隊成員都認為一項決定沒有道理，也不能質疑或討論這些決定。

再次，聽起來像是創始人的不信任投票。他引進這種人是有原因的。聽起來像是因為要鞭策其餘人員。

1. 他討厭IDE，自動完成功能以及旨在幫助程序員更快地編寫代碼的功能，並聲稱團隊應該使用Notepad ++來提高生產力。雖然這在不同情況下是有意義的，但很難想像C＃開發人員會突然放棄Visual Studio for Notepad ++。
ol>

如果您是一名快速的程序員，IDE可能會減慢您的速度。 Notepadd ++在快速編碼方面優於某些。想法是先編寫代碼，然後將其放到IDE中進行快速校正，而不是不斷中斷。

1. 他不重構代碼，並且不關心樣式（在他自己的代碼中不一致），原因是“他只關心真正重要的事情”。附帶說明，以前曾通過每晚構建檢查樣式，此樣式自新線索到達後就開始失效。
ol>

商店標準是與創始人討論的事情，尤其是因為您要在夜間構建中運行它。但是，再次閱讀，似乎是創始人不信任您。

1. 他拒絕了夜間構建以及自動構建的想法測試。根據他的說法，“任何專業開發人員無論如何都要手工測試他的代碼，因此沒有理由浪費時間編寫自動化測試”。據他說，夜間構建還浪費時間。
ol>

他是正確的自動化測試，並不能說明一些傻瓜乾的事是天才。我個人已經破壞了幾個通過自動化測試的程序。

1. 他認為版本控制主要是無用的，並且似乎誤解瞭如何使用版本控制。這導致了他獨自開發功能三到五天的情況，並且當他最終做出更改時，他確實為所有衝突“埋下了伏筆”。如果其他團隊成員抱怨他們的代碼被刪除了，他邀請他們重寫它。在某些情況下，其他成員也這樣做，從而刪除了主要開發人員的代碼。他看起來很驚訝（似乎他不知道如何使用svn log或diffs），然後再次進行了更改，抱怨“它們神秘地丟失了”，並指責SVN搞砸了。
ol>

這裡的每個人都錯。沒人備份嗎？如果他在版本控制方面遇到麻煩，那麼團隊的責任就是團隊合作，而不僅僅是給他一個艱難的時期。

1. 他高估了代碼優化的重要性。他的方法是正確的，即他運行了探查器，確定了瓶頸並加以修復；問題在於，沒有非功能性的性能要求，也沒有元素表明用戶可能認為該應用程序運行緩慢（並且託管在低級開發VM上，該應用程序感覺非常靈敏）。另一方面，他幾乎花了一半的時間來優化代碼。
ol>

沒有辦法誇大代碼優化的重要性。代碼優化的目的不是要確保其今天正確運行，而是要對其進行優化，以便您不會在三年後就解決某些可以通過代碼優化避免的問題。

如果您只關心用戶今天的快樂，那麼明天您將讓他們敲門。

1. 他手工編寫了所有SQL，並拒絕了ORM的想法。應該注意的是，當前產品基於Microsoft的ORM實體框架，五個開發人員中的兩個以前從未使用過SQL。
ol>

五個開發人員中的兩個應該被解僱，然後。如果您依賴ORM，那麼您將永遠無法掌握並手動修復問題。我開始明白為什麼他沮喪地稱呼某人為“代碼猴子”。 ORM很好，但如果要超出ORM的限制，則需要了解SQL。

1. 他拒絕框架，第三個黨庫，因為從頭開始寫東西要容易得多。他決定放棄除jQuery之外的所有JavaScript庫和框架，聲稱在15年前開始使用JavaScript進行編程時，沒有框架，而且生活變得容易得多。
ol>

他是對的。框架和第三方庫都有局限性，如果您不了解並自行進行修復，則說明您也不了解代碼。爭論可以是任何一種方式。但是，如果團隊中沒有人可以不使用框架進行編碼，那麼您的團隊將非常虛弱。

1. 他認為移動設備（包括平板電腦）只是大肆宣傳，因此沒有理由浪費寶貴的時間來確保站點與這些設備的兼容性並進行響應式設計。該產品是公共Web應用程序，預計不會在移動設備上大量使用。但是，響應式設計對於此應用程序可能非常有趣，因為即使在台式機上，它也將同時顯示在19英寸顯示器和大型高分辨率顯示器上。
ol>

根據您所說的一切，聽起來他已經被帶到了乾淨的房子裡。如果移動設備不是該應用程序的主要參與者，那麼花費太多時間就是浪費。雖然在桌面上可能是“很不錯”，但不一定要推出。

1. 他請團隊要求停止使用Internet（尤其是StackOverflow）並依靠他們的大腦，脫機文檔（我什至不知道Microsoft仍在銷售MSDN CD！）和書籍。
ol>

好

團隊成員向公司創始人抱怨了他們在這三個問題上的新領導。回應說他們反應過度，並且基於他的簡歷和麵試，他對新領導的技能有絕對的信任，這就是為什麼他首先將此人指定為首席開發人員的角色。

團隊應該怎麼做：

• 要么將領導帶出團隊或公司，要么

• 還是強迫他改變對團隊的態度？

與他一起與一起工作而不破壞他的一舉一動如何？？

坦白地說，鑑於您發布的內容，他已經被帶到干淨的房子裡了，聽起來似乎不合理。

所有者對您的表現不滿意。您應該以這個人的建議為代價。我們的文物有一些經驗，我們知道這些書永遠不會教您。但是，您的團隊並沒有將其視為學習和成長的機會，而是擁有巨大的嘶嘶聲。

因此，我不知道您的團隊成員向您的老闆投訴領導開發人員的時間有多長。但是，您與他們進行了圓桌討論嗎？向上司介紹領導開發人員遇到的問題，並讓他站在故事的一邊。

戒菸應該是最後的選擇。

我在這裡還沒有看到的“皺紋”。對於那些有豐富經驗的人，他們對不及時了解最新進展持防禦態度是很常見的。我曾經和人們談論VB6與奇妙的.Net有多麼可怕的方式相同，那時那些人只是在重複他們已經聽說過的關於VB6的事情，而對此卻並不太了解。

正如您所說，領導者所說的很多事情都是正確的。但這並不意味著它們都是您所說的。也許25年的先生可以開闊自己的胸懷，並以最佳狀態綜合自己的方法，但如果他害怕自己不夠完美，又否認自己害怕，那是不可能的。就我而言，這是這裡的實際問題。初級人員可能還有其他問題（例如，缺乏專業知識），但這似乎是其中的根本問題。

如果每個人聚在一起並以坦誠的態度解決恐懼，那麼他們應該開始朝著更加積極的方向前進。我不能說聽起來像是很有可能，但這是需要做的。

所有者需要聘請人事經理

其他答案暗示了這一點，但是房間裡的大象卻是，所有者（可以理解）似乎很難成功地完成諸如僱用之類的人事職能例如，培訓，解僱等。所有者配備了一個表現欠佳的團隊，忍受了好幾年，然後聘請了25年的資深人士來解決問題，然後在25年的資深人士無法解決問題時僱用了顧問。所有者似乎並不知道如何管理企業的人事方面。沒關係，有些人以此為生，這就是為什麼大多數組織都設有人事經理的原因。所有者需要租用一份數據。 這將使所有者騰出精力專注於業務的戰略方面，因此這是雙贏。

也許OP可以幫助進行面試（畢竟，所有者似乎在這方面需要幫助）？

1. 整個團隊是否都與該開發人員交談過，並試圖解釋諸如版本控制和IDE之類的好處？坦率的討論可能會有所幫助

2. 我同意侮辱其他開發人員是不專業的，對此應該向他作出有力的解釋。詢問他是否為其他人採用相同的語氣感到高興

3. 問他是否在國內承受任何壓力或是否患有糖尿病等健康問題導致他易怒

4. 請問他是否樂於變得古老，並且脾氣暴躁，並且精神萎縮，因為他不了解新知識。

5. 如果所有其他方法都失敗，則將記錄他的所有錯誤以保存您的皮膚，並記錄與他的對話

ol>