題:
問“為什麼?”不會自鳴得意或不專業
Juggerbot
2017-08-07 17:30:14 UTC
view on stackexchange narkive permalink

我是一個小型團隊中最初級的軟件開發人員。自己不到一年的經驗,我自然會花很多時間嘗試嚮導師學習盡可能多的東西。

但是,在確定適當的禮節方面,我遇到了一些麻煩: ?不會顯得不專業。要澄清的是,這不是我的第一份工作,因此在專業環境中進行對話或電子郵件通信也不是問題。相反,它更多是軟件開發的技術方面。

我認為大多數SO讀者都知道很少只有一種代碼實現。有時甚至沒有“最佳”方法。但是必須有人打電話。無論是開發人員會議,代碼審查,甚至只是我要問,一位資深開發人員都會決定“讓我們這樣做”。我想知道做出決定的理由是我的本性之一,尤其是考慮到該知識對於我自己的職業發展是必要的。但是,我發現很難在不聽起來像是在猜我,自大還是自大的情況下要求提供更多信息。在大多數情況下,我不知道一種或另一種方式帶來的好處,但是偶爾,它們會以我認為不太理想的方式為基礎。

愚蠢的例子:

其他開發人員:“好吧,為此,我們將進行 if(字符串a ==字符串b)。”

  • 為什麼用它代替...?
  • 那......
  • 我曾經讀過7年前的一篇SO文章,推薦 if(string a.Equals ...

我不會建議我比他們中的任何一個都了解,但我擔心我會那樣做。我要補充一點,沒有人對此發表任何評論。相反,我收到了好評,稱讚了我的意見。但是對我來說,我這樣做的方式有時聽起來很浮躁。那麼,是否有任何建議在外交上要求作出決定背後的理由而又不質疑某人的能力?

雖然這可能是獲得一些一般準則和示例腳本的好問題,但我建議您也諮詢您的經理或您認為是指導角色的人員,以獲取一些反饋。您可以將其表述為“我要確保我不會問太多問題/以一種粗魯的方式這樣做?”。我敢肯定,他們會告訴您您想得太多,但是省心是一件很棒的事情,這也使他們有機會向您指出一些您可能尚未考慮的資源或發現方法。
我認為這更適合於軟件工程SE,以便獲得關於如何在初級階段充分掌握軟件工程師世界的更有針對性的建議。
ive發現,軟件開發人員比其他行業的人員對問題的要求更高,因此,如果您不了解某人的邏輯,則直言不諱似乎很正常。
高年級和初中級已經有幾年了,而我最喜歡的同事們總是問“為什麼”-不管他們的年限如何。這也是我學習新東西的一種方式。
很多人都害怕因為完全相反的原因問“為什麼”:他們認為有明顯的缺席之處,即使這種想法是完全正確的,對他們的質疑也會顯得愚蠢。
在所有工作場所(不僅僅是SE)中都會發生這種問題。這可能完全不是您的機智,而是信任。即使是最高級的人,有時也會對自己的能力缺乏信心,他們也沒有為知識水平未知的人提出的嚴苛詢問做好準備。在某種程度上,它可能威脅到他們,並會促使冷魚做出反應。在嘗試類似大膽的“為什麼?”之類的東西之前,嘗試更多的對話方法,進行比較和對比,提供一些背景知識。特別是,讓這些人有時間認識您。
順便說一句,在幾乎每種編程語言中,“ if(string a == string b)”都是錯誤的;)(例如,[此處是對Java的解釋](http://www.thejavageek.com/2013/07/27/與等號和賦值運算符的字符串比較/))
願意問“為什麼?”相對於與我合作過的許多開發人員來說是一個巨大的進步。
小時候,您可能會被告知“魔術詞” *請*和*謝謝。*在這種情況下,“魔術詞”通常是“我不明白為什麼X”的某種形式,或“我不明白為什麼X而不是Y”,而不僅僅是禿頭的“為什麼X?”即使您*知道*所告訴的內容完全是錯誤的,假裝您不理解它還是更好的,並希望這種解釋會使錯誤對其他人顯而易見。如果那行不通,那麼您可能必須停止“變得很好”並挖深跟鞋。
只是說:“您能解釋為什麼嗎?”只要您使用非攻擊性的語調,就可以繼續前進。
只需說“聽起來不錯,但是出於好奇,我們為什麼選擇這個標準?”因為它傳達了以下信息:1)您承認標準(“聽起來不錯”),2)表示您知道多種方式(“為什麼要使用此標準”),以及3)表明您只是在尋求解釋而不是質疑原因(出於好奇)。另外,還有@Jan'splite'K。基本上是正確的,我認為[這可能是原因](https://dotnetfiddle.net/AOQ4Ex)。
有時,您也可以插話您想了解該決定的理由,以便您自己能夠在有人問您的情況下進行辯護。
如果您以前從未在辦公室工作過,怎麼可以成為專業軟件開發人員呢?
為什麼?(看看我在那裡做了什麼)
@Jan'splite'K。我的目的是使偽代碼更容易被任何人閱讀,因為我們在Workplace上,而不是在技術社區上。
我*強烈*建議您觀看所有哥倫布。在鏡子或網絡攝像頭上練習印象,直到可以完美拉出為止。
作為一個在他的領導下工作了幾年的開發人員,並且有一些實習生和(更多)初級開發人員可以提供指導,我非常希望您能與我一起工作。我本人不得不向某人解釋“為什麼X”的經歷或見識的次數是巨大的。也許這也是“因為我是荷蘭人,所以我們傾向於比其他社會更突然,即使我們無意無禮或無禮。我建議您的語氣和對您的表情感興趣或懷疑的表情是這裡最重要的事情。如果他們不尊重有興趣的人提出的問題,請找一份新工作。
九 答案:
Joe Strazzere
2017-08-07 18:08:35 UTC
view on stackexchange narkive permalink

那麼,有沒有建議可以在外交上要求作出決定的理由,而又不會質疑某人的能力?接受他們的建議,然後還詢問該建議背後的原因。

他們:這樣做。

您:好的,我會的。謝謝。我想問一些有關此的問題,以便我可以更好地學習如何自行做出正確的決定。現在是討論它的好時機嗎?

聽。尋求理解,不一定達成共識。不要爭吵。有時甚至接受為所有事物尋求最佳解決方案並不總是很重要。很多時候,迅速變得“足夠好”更為重要。

評論不作進一步討論;此對話已[移至聊天](http://chat.stackexchange.com/rooms/63593/discussion-on-answer-by-joe-strazzere-asking-why-without-coming-across-as-smu)。
這個!作為指導者,我可以告訴您,並非總是有很好的理由。有時候,原因是為了保持一致性,這就是第一個人做到這一點的方式,而現在一切看起來都是這樣。話雖如此,我鼓勵我的下輩們問為什麼(直率地)。他們知道作為回報,即使他們不是他們希望的那樣,我也會告訴他們答案,例如“為什麼這樣編碼?”我的回答可能是“有一個主要的生產問題,它在10分鐘內被編碼,請不要更改”
Southpaw Hare
2017-08-07 19:31:59 UTC
view on stackexchange narkive permalink

老實說。您的同事可能理解。

批判性思想家最有效和令人欽佩的素質之一就是願意問為什麼。。這是最有效的方法之一。學習,以及利用具有不同想法的各種不同人的優勢的主要方法。 當您比其他人更了解和比他們更了解時,以及當您不確定哪種情況時,此功能都非常有用。

至少,您可以以您不知道和不想學習的類型來表達您的問題。但是,您可能會比想像中的其他方式更舒服地問問題。 您的同事可能不如您想像的那樣具有判斷力-他們不了解一切,他們可能承認這一事實並重視您的意見。不要害怕放兩分錢;大多數人不會為此而咬你的頭。

+1詢問“為什麼?”可以使您的同事重新評估他們的決定,加強其正確性或暴露弱點。在最壞的情況下,您可能會被告知諸如“因為管理層如此說”,而在最好的情況下,您可能會發現其他人認為理所當然的問題。
通常,您會聽到“我不知道”,“這是我的第一件事”或“我更喜歡這樣”。
GargantuChet
2017-08-08 00:46:04 UTC
view on stackexchange narkive permalink

通常措辭可以使您清楚地表明,您試圖填補空白而不是挑戰別人的方法。

我在職業生涯的早期工作過的一位PM經常會提出以下問題:“您能幫助我理解為什麼我們需要使用ASCII模式進行傳輸嗎?” 。很明顯,他並不是以自己為專家,而是在試圖理解一個話題或思路。我喜歡這個表述,並且仍然會不時地回到它。如果您認為此人是一個故意的選擇,這將很有用。 “我很困惑。我一直只使用快速排序,但是我們在這裡使用插入排序。您能解釋一下原因嗎?”

如果您已經有了理論,那麼二元問題可以最大程度地減少中斷。 “您使用插入排序是因為大多數輸入數據已經預先排序了嗎?”如果您認為感嘆詞仍然太突然,可以選擇以“僅檢查我的理解”開頭。這樣,您的同事就可以決定是要簡潔回答還是要花一些時間討論。

很難詢問可能是任意的事情,但是您也可以提出這樣的問題。 “我經常看到點等於,我不確定它是否等於雙重等於。這是一種風格選擇還是我錯過了一些東西?”再次,它可以讓其他人決定做出多長時間的回應,而不會強迫他們捍衛任意決定。

除非要澄清您的問題,否則我將避免引用其他培訓或工作場所。那是非常罕見的,因此當它懷疑不提時就不提。

也給其他人機會,使會議重回正軌。 “我想更多地了解在嵌入式設備上進行分類的不同方法。我們現在有時間還是應該推遲查看更多的代碼呢?”好的會議協調員將結束主要主題,邀請與會人員對側邊欄不感興趣的人離開,然後為您的主題重新打開地板。

這是我最近學到的一項技能,對我的互動影響很大。
為這個答案+1(除了“我很驚訝”),在我的耳邊,這種聲音確實極具挑戰性!
我認為在適當的情況下(即當手頭的解決方案似乎偏離了標准或傳統的做事方式時,“我很驚訝”)(不會感到冒犯或煩惱)預期...”),詢問者對常用的技術有一些合理的了解。
公平。當您懷疑正在發生您忽略的聰明事情時,“我很驚訝”很有用。“我很驚訝。我沒有看到對數據進行排序的代碼,但是您的程序始終按正確的順序排列結果。您知道我缺少什麼嗎?”這可能使該人員有機會討論其SQL層的默認順序,LDAP VLV查詢的使用等。我們都使用思維模型來了解系統的工作方式。當您說“我很驚訝”時,是恰當的:讓我們剎車,我的思維模式不起作用,我想在繼續之前找到問題。
Jack Parkinson
2017-08-07 18:06:04 UTC
view on stackexchange narkive permalink

有幾種方法可以解決這個問題,但對我來說,我發現最好的方法是

  • 您能向我解釋一下嗎? > p>

  • 您能否快速闡明該部分的用途?

  • 此行的目的是為了 XYZ ?還是其他?

通過這樣的問題,您會自動將您的上級置於權威位置:您不是在質疑為什麼他們在做某事,你在問他們如何做。問為什麼可以(即使不是有意地)將它們放在後腳上,讓他們感到防禦。通過提出這樣的問題,您就不會挑戰他們。您還會顯得渴望理解而不是自大,這是您提到的主要問題。

始終把壓力放在學習而不是嘗試分析代碼上。如果開發人員可以給出合理的理由說明為什麼他們要完成自己的工作,請感謝他們並繼續前進。如果您仍然覺得自己的想法更好,可以按如下所示進行介紹:

  • 我知道了,謝謝您的解釋。

  • 好吧,謝謝。我看過以前使用過的其他方法,您認為這會是更好的選擇嗎?

請確保您有證據,研究和對您的問題有非常清楚的了解,以支持您可能有的任何建議。如果明確提出了兩個理由,那麼一個人應該能夠對它們做出客觀決定。

但是正如Lilienthal所說,從某種意義上來說,“閱讀房間”非常重要。如果您發現有人對您的建議感到沮喪或煩惱,請與您所報告的人談談如何最好地提出這些問題(如果有的話)。即使您知道更好的解決方案,但如果您覺得它會讓您陷入某人的壞書中,那麼在某些情況下,讓它滑動可能會更好。

最後的說明:我是一個經驗很少的實習生,但是我覺得通過採用這些實踐,我能夠對系統的更改提出建議,而不會顯得自高自大。重要的是要認識到您的觀點是有效且可以使用的,但您仍在學習中。通過在這兩種態度之間取得平衡,合理的開發團隊不會遇到任何問題。

Steve Jessop
2017-08-08 20:14:06 UTC
view on stackexchange narkive permalink

首先,接受正面反饋。如果您因某件事而受到稱讚,而沒有任何警告,那就繼續做吧!

話雖如此,為避免發生冒犯或不適的情況,您在這裡可以做的主要事情就是做好以下準備:做出決定的人真的不知道為什麼他們偏愛A而不是B,並且可能不在乎對此提出嚴格挑戰。尤其是在以下情況下會出現這種情況:

  • A或B都可以工作,因此都不能立即排除兩者,並且
  • A和B之間的區別並非如此非常高興對A對B進行詳細的擴展分析是合理的,並且
  • 有經驗的開發人員具有支持A的本能,或者最熟悉A,或者認為A與當前的觀點最一致或在現有代碼中進行實踐,或者A遵循一些經驗法則,該經驗法則通常很好,但與該特定情況不相關,並且
  • 有經驗的開發人員不容易精確地對此進行量化。

有時候,作為一名經驗豐富的開發人員,真正打破這些預感並分析決策背後的原因是一件好事。有時候,作為初級開發人員,將其全部擺在您面前是個好習慣。有時,初級開發人員的知識摘要比經驗豐富的開發人員的知識更準確,相關性更高,理想情況下應該逆轉決策。有時,有經驗的開發人員會在判斷初級開發人員可以糾正的理由方面犯了一個錯誤。但這仍然浪費時間來猜測太多次要的決定。經驗豐富的開發人員所擁有的“經驗”中有很大一部分正在自信地呼籲採用“足夠好”的解決方案,以避免在騎車脫落和Burridan的屁股風格情況下陷入困境。

因此,如果您擔心自己會遇到挑戰性的決定,而又不想以這種方式遇到,我建議:

  • 同意A。即使討論最終還是選擇了B,也沒有必要通過對抗性辯論來達成該決定。
  • 提出替代方案為“我已經看到人們有時會選擇B代替”。避免“我的意見是B會更好”。
  • 問,“是否有某種東西意味著B在這裡不起作用或比A差?”或“在什麼條件下B才是最佳解決方案?”。避免使用“您選擇A的原因是什麼?”
  • 如果沒有令人滿意的解釋,但是A基本上沒什麼問題,那麼就結束吧,“好吧,我們正在使用A,因為這是一種解決方案,知道會起作用”。避免使用“這樣,B可能比A更好,但無論如何我們都在做A,因為我們不願意為正確評估B感到煩惱?”
  • 詢問,”通常來說,我們如何確定A和A之間B?”。避免使用“如何確定B在這裡不會更好?”
  • (高級用法):詢問哪種測試用例與這種情況相關,應將其添加到套件中以進行追踪請注意A和B之間的實際差異。請當心,這很諷刺,但有時“測試案例是什麼”問題恰恰是使該差異正式化所需要的,並且至少是一個實際問題:我們需要什麼測試?

此外,即使您同意該決定,您也應該對推理感興趣(並表現出興趣)。有時,原因會與您的預期或您自己的推理有所不同,並且您從中得出的結論和得出的結論一樣多。如果您還同意時要求推理,那麼您就表明您最關心的是改進推理,而不是得出結論。

當然,當您實際上認為高級開發人員正在嚴重錯誤且他們的決定需要進行更改,那麼您可能會更具挑戰性。這適用於不適用的情況。

最後,請記住,實際上有很多開發人員對下屬進行的激烈討論感到滿意。尤其是如果您願意接受“因為有人必須打個電話而那個人是我”作為答案,那麼一切就此結束了。如果您與之交談的人給人以享受辯論的印象,那麼您不必擔心。如果他們看起來像在5分鐘後開會,並且需要離開房間,也許這不是要求完全證明 a == b 之間差異的最佳時機, a.equals(b) a === b

dlb
2017-08-07 20:46:35 UTC
view on stackexchange narkive permalink

人們了解學習曲線,他們也都經歷了它。有些人脾氣暴躁,秘密或過於急躁,但大多數人會傾向於理解並知道,如果他們一次解釋推理,而您聽了,他們大多數事情將不需要多次解釋。實際上,大多數有經驗的人都希望您提出問題。他們實際上並不希望您只是對做事的方式說服他們,而是希望您考慮一下。從某種意義上講,您會認識到一些人不願意花時間,而另一些人卻太忙。不那麼願意,您只需要即時學習個性。在繁忙的工作日程中,我總是發現有禮貌,“當您有時間時,我們可以花幾分鐘時間和談話...”往往效果很好。

機智的措辭總是如此對我來說很難,實際上我傾向於學習當問問題時更好的指導者。當您是幫助別人的人時,您會聽到他們對某些人的對抗。一個有經驗的人通常會開放思想。坦率地說,我們都想學習,當您到達不再學習的地步時,這是一項無聊的工作。但是,一個人也不希望他們所說的一切受到挑戰。經驗豐富的程序員已經學到了很多對與錯的方法,儘管他們喜歡新的想法,但他們不希望入門級人員告訴他們所做的一切都是錯誤的。對我來說,無論是問還是被問,我都發現“為什麼您會發現A比B更好的方法……”是一種好方法。這個人可能有正當的理由,並且在現實生活中可能與教科書所說的完全不同,因為他們可能從未嘗試過B。

我曾經有過的最好的導師之一,幾乎總是用“你怎麼看?”來回答這個問題。他會首先讓我回答,因為顯然我認為B是更好的方法,並且他希望我努力做到這一點。一旦我完成,他經常會說類似的教科書答案,但是實際上,這就是我們為什麼要這樣做的原因。其他時候,是的,沒嘗試過,讓我們嘗試一下。不過,他不僅要我發表意見,還要求他先回答,因為他要我首先考慮各種選擇,而不僅僅是接受他的回答。

everyone
2017-08-08 13:22:01 UTC
view on stackexchange narkive permalink

如果您擔心自己聽起來不太自在,那麼一個簡單的解決方案是先“降低自己”。

“我不太了解-聽說x也是一種好方法,為什麼這種方法更好?”

”我對此有點麻煩:可以您向我解釋了x與之相比有多糟糕?”

johnweeder
2017-08-09 00:30:20 UTC
view on stackexchange narkive permalink

也許可以稍微軟化它“為什麼要那樣做?”或“為什麼呢?”在25年多的時間裡,我沒有遇到很多冒犯“為什麼?”的開發者。

您遇到的問題是,當您不問“為什麼?”時暗示“您做錯了”。這就是“為什麼要那樣做”之間的區別。和“你為什麼不這樣做呢?”

Carlos Ferreira
2017-08-11 19:23:49 UTC
view on stackexchange narkive permalink

我質疑為什麼沒有任何危害,我認為您需要考慮是否是提出問題的適當時間。

心境/關鍵時刻/壓力大sprint

如果人們因工作而感到壓力大或非常忙碌,除非對理解原因至關重要,否則我會做筆記並在更合適的時間提問。

相關性

例如,了解人們為什麼使用if(a == b)真的很重要嗎?

或if(a.equals(b))嗎?

我以後可以自己挖這個嗎?也許您可以按自己的時間查找它?

在我看來,這是人們將您視為不專業或自鳴得意的關鍵時機,因為您可能會浪費別人的時間來處理瑣碎的事情由你自己。

有時候人們之所以會做某事,是因為他們有特定的原因,無論是技術上的,堅強的信念還是僅僅是習慣的力量。有時候,人們不會為您的特定決定提供幫助。這就是它的運作方式。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...