沒錯，我們都在說謊。你可能也在說謊。讓我來證明給你看😉
哦，我現在腦子裡有很多文章選題，都是些非常令人興奮的選題。不過這週真是忙得不可開交😅 我終於完成了JSNation演講的準備工作，與此同時，又出現了兩個絕佳的機會——一個是職業上的，另一個感覺就像兒時的夢想成真☺️ 但我現在還不想說得太早，以免不吉利。
為了避免聽起來好像我的所有事情都一帆風順——我最近也收到過幾份拒稿通知。都是我真正想投的！但說實話，這就是遊戲規則的一部分。一個會議可能今年拒絕你的演講，明年卻欣然接受你的另一個演講。
所以，是的，真正的大話題還得再等等🙂 但這並不代表這個話題就無關緊要。
現在到處都在談論人工智慧，好像它能解決我們所有的問題似的。但正如我們已經看到的，沒有人類就沒有人工智慧，每個「智慧」模型背後仍然有人類的參與——至少目前是這樣😉
這或許可以解釋為什麼，實際上，編碼代理確實能加快開發速度……但遠沒有許多人預期的那麼快。一些研究甚至表明，它們反而會降低開發人員的效率。
因為真正的問題往往不在於程式碼本身，而在於編寫或產生程式碼的人。
不幸的是，我們每個人都會以某種方式說謊。有時是對別人說謊，有時是對自己說謊。
有些開發者謊稱自己知道自己在做什麼
我認識的最優秀的開發人員之一曾經向我坦白過一件事。
這傢伙真是天才，公司爭相招攬的那種工程師。他目前負責優化LLM的驅動程序，一路晉升，即便是在如今這個「科技危機」時期，當他考慮換工作時，仍然有很多工作機會可供選擇。
然而，每次他加入新計畫時，他都覺得自己像個十足的白痴。
其他人似乎都很有效率。大家都在處理工單，寫程式碼，自信地推進專案。而他卻坐在那裡，盯著程式碼庫，疑惑地想著：
這裡到底發生了什麼事？
我們到底在建造什麼？
為什麼會這樣運作？
為什麼我們要用這種方式實施，而不是用其他方式？
然後他開始問問題。
通常情況下，結果證明沒有人真正知道自己在做什麼，為什麼要這樣做，甚至不知道自己一開始是否就解決了正確的問題。
這讓我想起一個老笑話，講的是伐木工人砍伐森林。最後，領隊爬上最高的樹，環顧四周，然後大喊：
“夥計們！我們砍錯林子了！”
下面的工人們也大聲回應：
“誰在乎呢？我們取得了巨大進展！”
說實話，再多的LLMs學位也救不了我們。尤其是在我們連正確的問題都沒問出來的情況下。
有些人謊稱自己會做某件事。
這基本上是前一個問題的延伸。
一位經驗不足的開發人員接手一項任務，自信地說：
“是的，我知道該怎麼做。”
不幸的是，它們通常意味著：
「我希望我能想辦法解決這個問題。」😅
實際上，他們可能不知道如何解決這個問題，該使用哪些工具，哪種架構比較合理……甚至不知道該寫什麼提示才能從編碼代理那裡獲得有用的幫助。
但他們不敢問。
因為他們在團隊面前會顯得如何？經理會怎麼想？技術主管又會怎麼想？
最好的情況是：他們最終會提出問題……只是為時已晚。
最糟糕的情況：他們根本不問，直接送來完全錯誤的東西。而這種情況往往根本沒被發現，因為…
有人在說謊說自己有時間
現在我們進入高階和領導領域了😅
動機各不相同。有些人將自我價值建立在「可靠」這個角色之上。另一些人則害怕失去地位、影響力，甚至工作。
所以他們不斷承擔更多：
-
最困難的任務
-
無止盡的會議，
-
改進，
-
估算值，
-
與支持者討論，
-
與企業進行討論，
-
程式碼審查
-
建築設計決策，
-
文件.
說實話，總有東西會壞掉。
人不是鋼鐵做的。沒有人能永遠保持百分之百的狀態。
然後會發生什麼事？
人們在通話中開始心不在焉。程式碼審查變得匆忙。文件悄無聲息地被束之高閣。
但他們仍然拒絕承認——無論是對別人還是對自己——他們只是工作量過大了。
有些開發商會在專案所需時間上說謊。
我經常在水平較高的初級和中級球員身上看到這種情況。
他們自信滿滿地拋出一些極度樂觀的預測，簡直令人啼笑皆非。
當然——如果他們能連續工作八小時不間斷，應用程式不包含任何遺留程式碼，不存在任何極端情況，而且沒有其他人與系統互動……那麼這個估算或許真的會是正確的😄
然後到了迭代評審會議，突然間，所有人都震驚地發現團隊並沒有交付所有東西。
但這並非估算的唯一問題。
我曾經和一位特別幽默的高級開發人員共事。
他把估算奉為圭臬。在計畫會議上，他將極力捍衛自己的數字，堅持這項具體任務絕對極其複雜。團隊其他成員通常覺得沒那麼糟糕，但最後為了結束討論，我們還是會妥協。
然後——至少有三次——他親自接手了他之前嚴重高估的任務……並在大約一個小時內完成了它。
這基本上意味著，估算討論本身花費的時間比實現功能的時間還要長😅
這次經歷改變了他的行為嗎？
絕對不是。
有些人謊稱自己什麼都懂。
這些可能是最危險的。
我會避開那些說類似這樣話的人：
“只能使用這項技術，其他一切都是垃圾。”
請在此插入你最喜歡的聖戰：
Angular 對比 React，Java 對比 Python，Rust 對比其他任何語言 😄
我自己從來不那樣寫作。即使我發表的文章標題是「我愛Tailwind，我一點也不後悔」 ，我仍然會談到它的缺點，並解釋它哪些地方完全不合理。
如果有一天我開始聲稱某種技術在所有情況下都完美無缺，請留言說：
「西爾維亞，立刻去摸摸草地。」😅
說實話，我一直很想知道這種絕對的確定感是從哪裡來的。
因為這些人並非全是付費網紅。有些人似乎真的對科技界的爭論投入了真情實感。還有一些人可能只精通某一方面技術，所以對其他技術一竅不通就覺得「不好」。
雖然這種行為在科技界有影響力的人中非常普遍，但在公司內部也絕對能看到。
問題在於，這種盲目自信會嚴重損害專案。人們不再質疑決策，其他開發人員也不敢發表意見。利害關係人會想當然地認為「自信的人」一定是正確的，只因為他們聽起來很有把握。
最好的情況：你最終會得到一個令人討厭的開發人員，他對框架的了解遠勝於對實際業務領域的了解。
最糟糕的情況：你最終會得到一個糟糕的技術堆疊選擇和一團亂麻般的架構，而這一切都靠著自負勉強維繫。
人就是…人
當然，我也不是無辜的。
我過去也用過很多類似的謊言。也許我現在年紀大了，也許更明智了一些，又或許我只是更容易識破這些伎倆。
但我肯定還在某個地方說謊。也許對別人來說不是——也許對我自己來說是。
因為我們在軟體開發中遇到的許多問題根本不是技術問題，而是根深蒂固的人為問題：
-
自我，
-
缺乏安全感
-
害怕顯得愚蠢
-
害怕承認錯誤
-
害怕說「我不知道」。
說實話，我也沒有什麼靈丹妙藥。我們不可能要求每個開發人員都接受三年的心理治療才能參加迭代計劃會議😄
但我注意到一件事。
很多時候，承認自己不知道某些事情，在計畫過程中公開討論不確定性，或簡單地說：
“抱歉，我還是不太明白。您能再解釋一遍嗎？”
這並不會讓別人覺得你是個程度更差的開發者。
很多時候，情況恰恰相反。
團隊內部的溝通突然改善了。其他人也開始提問。對話變得更加坦誠。問題也更容易被發現。
說真的，至少試試看一次吧，你可能會感到驚喜🙂
那麼……在你的團隊中，你最常看到開發人員撒哪些類型的謊？
原文出處：https://dev.to/sylwia-lask/every-developer-is-lying-about-something-and-ai-wont-fix-it-4im0
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
