如果要編寫“一般開發技巧”列表怎麼辦？然後，您可以一次與所有人共享它，而不必不斷地提出未經請求的建議。

然後，您還可以將其贈予未來的學生，並希望他們從第一天開始就可以開始。

您的研究小組每週開會嗎？如果是這樣，您可以在每次會議開始時花5到10分鐘的時間來研究您認為會有所幫助的工作流程/開發技巧。如果您的小組沒有定期開會，那麼可能僅出於此目的而實施一些會議是值得的。剛開始時學生可能不喜歡這種方式，但是淨生產率的提高將使所有人受益。另外，您不必指出多個學生的個人效率低下（至少不是那麼頻繁）。

我在教書時會採用類似的方法，但這更適合於本科生。我將討論諸如如何/在何處申請獎學金和實習，進入研究生院的提示，應對工作場所的政治問題以及不時進行的一些簡單工作流程之類的事情。學生們評論說這非常有益。

我喜歡@Nate Eldredge提出的一系列一般開發技巧的想法，但是我認為僅此一項可能會有一些缺點。編寫涵蓋所有內容的真正高質量的內容可能會很耗時。有些學生甚至可能沒有看過（但是這些學生可能也不注意在會議上說的話）。其他學生可能只有在實踐中看到您的建議後才能理解。這實際上是前幾天發生在我身上的。我知道Emacs的Tramp，但從不了解如何實現。我看到了一條帶有動畫.gif的推文，演示了它的工作原理，此後我每天都在使用它。也許在會議上討論這些事情並逐步建立一系列的開發技巧可能會很好。

您還可以提出一些小組要求，使您的生活更輕鬆。例如，您可能要求小組使用Dropbox（或類似方式）共享文檔，並且在此過程中可能會鼓勵他們將其用作自己的材料。 （起初，您可以將開發技巧文檔保存在Dropbox上的共享文件夾中！）我確實認為親自指出效率低下可能是值得的，但您絕對必須挑剔自己的戰鬥，並且不時這樣做。

編輯

一些評論表明，OP的一些建議“在客觀上是錯誤的”，但我認為這錯過了點。如果一位更資深的研究人員認為自己的小組可以更有效率，即使沒有完美的工作流程，也很可能值得分享。通過Dropbox共享代碼可能不是最好的解決方案，但肯定比來回通過電子郵件發送文件更好。 （我什至不確定OP是否建議該組在Dropbox上共享代碼；這只是一個示例）。同樣，學生可能會對小組（甚至小組負責人）提出建議，並且可以通過將所有人聚集在一起來充實這些建議。

有一條評論還建議不要參加Vim / Emacs的聖戰...但是學生首先了解Vim，Emacs，其他編輯器/ IDE及其功能嗎？我當然不知道這些是碩士生，與編輯一起發展技能會極大地幫助我（我不在STEM領域，因此這些工具並不常見；我不確定OP的領域，但這只是一個例子）。您絕對可以在不參加聖戰的情況下討論功能。僅僅接觸可能會帶來極大的好處。

與João的方法相比，我的方法要微妙得多。與其直接告訴他們該怎麼做，不如告訴他們我的工作流程，同時回答一個類似的問題。確保在您自己的計算機上執行此操作，請勿在其他人的PC上“驅動”。

一個示例是用大的代碼窗口向他們展示您的“開發方法”。當他們看著您正在做什麼時，請使用快捷方式或CLI。您可以說“ foobar為我節省很多時間”之類的話，但不要太多。希望工作流程效率更高的學生自然會選擇適合他們的方法。

“您可以將一匹馬帶到水里，但不能讓他們喝水” >

就我個人而言，這是我在開始工作時告訴我的學生的內容，括號中是我的理由。

1. 使用Dropbox / GDrive /您準備什麼進行備份（如果在提交前1週丟失工作，則很費勁）。

2. 在學院服務器中為項目文檔設置一個Wiki（如果以後不做筆記，您將不知道在論文中寫什麼）。

3. 使用Mendeley用於參考管理（花時間編寫.bib或撰寫論文，由您選擇）。頁文檔。）

4. 使用虛擬機作為其工作環境，並進行定期備份（不要浪費時間一次又一次地進行設置）。

5. 發送電子郵件給CC中的兩位主管，並始終使用“全部答复”來處理與工作相關的電子郵件（如果我不知道您在做什麼，我將無法為您提供幫助。）

6. 經常出現在實驗室中（只需與高級研究人員交談，您便會學習實現目標的最快，最聰明的方法）。

7. 向我發送進度報告經常（如果您你不要求評論，我不知道你的工作是否準備就緒。

ol>

（可選）

1. 如果他們能夠負擔得起，則為他們的筆記本電腦提供SSD（耐心的價值超過金錢）。
ol>

要阻止自己指出每件事，這很容易：這是他們的工作，也是他們的選擇做一個好與否。用Morpheus的話說：“我只能給你看門。你是必須走過的門。”

選擇一些重要的東西，並將其視為“最佳實踐”，（對我來說，明智的選擇文件和變量名或具有一些標準似乎比編輯窗口或鍵盤快捷鍵的大小重要得多）。給出一些規則或示例，這些規則或示例可以顯示實際操作中的準則，然後繼續進行，並對這些準則有些挑剔。

其他事情-（使用更大的編輯窗口，快捷方式）實際上並不是最佳實踐的“重要”。站在學生的肩膀上說，按那個鍵等確實很煩人，如果向他們扔了太多的信息/細節，可能會令人不知所措。 （哪些細節很重要，這是否對您有所幫助？）而且，實際上他們可能有充分的理由在一段時間後做出不同的選擇（他們可能會發現其他更適合其“樣式”的快捷方式，或者如果您覺得有用的話）

但是，話雖這麼說-節省時間的技巧對初學者並不是很明顯，這是事實，我發現最好的方法是讓某人玩首先使用工具，以便它們可能會遇到一些挫敗感。但是，大多數情況下，只需回答基本問題，如果還有關於“簡便”的操作方法的特定問題，然後告訴他們，然後再進行-一對一的操作一個用來說明您將如何指出自己的做法以及如何避免特定的挫敗感的任務，但是，此時，讓他們選擇如何以他們認為最好的方式做就可以了。您正在幫助他們。

雖然我沒有參與培訓codi的學生ng，我們必須對新手用戶進行設備培訓，該設備有些技巧，並且要成為專家需要很長的培訓時間，因此該過程具有一些相似之處。

請選擇幾乎不可商議的方面，因為它們很重要。當新手繼續選擇忽略您給他們的提示時，不要過多地冒汗，這些提示通常是專家通常發現的“有用”策略來使自己的生活更輕鬆。

@haff在評論中建議：

如果您的研究小組每週舉行一次會議，那麼您也可以在每次會議開始前花5分鐘左右的時間來演示開發/工作流程黑客。

一個有趣的想法！現在，讓我們對其進行一些更改：

花一些小組會議時間（不一定是5分鐘，並且不必每次會議），讓學生有機會分享自己的時間工作流hacks 。

請提前在電子郵件中告知他們，以便他們考慮自己想要的工作hacker。分享或演示。換句話說，不要驚訝於他們。並且允許個人選擇不共享某些內容。

此外，您還可以舉行一些研討會類型的會議，有人自願在演示椅上，進行一些代碼開發或即時測試，例如就像音樂系的大師班一樣然後邀請學生進行建設性評論，目的是讓每個學生都找到值得讚美的東西。如果他們想就如何更有效地進行調試提出一些建設性的建議，那很好，但是主要目標應該是學習向同行提供積極反饋。

它與讓所有學生來自教授的學習和建議相比，來自同伴的學習和糾正的效果要高得多。

我認為提出建議沒有錯。畢竟，您正在教他們，並且就如何改善它們的工作方式提供建議似乎並非不合理，特別是如果建議是客觀地提高效率。

我完全同意，如果確實對學生沒有意義，強迫學生以某種方式工作可能不是一件好事。當然，我的經驗是，與有經驗的人一起工作（不管是否在正式的教學環境中）最有用的事情之一是，他們將知道很多有用的技巧，這些技巧在直觀上並不一定是顯而易見的。

一旦提出建議，您就可以讓他們決定是否要對其採取行動，但是至少他們可以掌握信息。

TL; DR：區分“技巧和竅門”和“指南/良好實踐”。給出提示，並嘗試實施後者。

如果您遇到的情況是可能的，則可能需要組織一個小型演示文稿。諸如“ EditorX提示和技巧”之類的東西。在這裡，您可以與他們分享一些更好地使用編輯器的提示和技巧，而無需特別指出任何學生。

這與行業沒有什麼不同。我是一名軟件工程師，我們每週進行一次講座，在該講座中我們將演示該領域有趣的事情。每隔幾週，就會有一些小技巧和技巧的演示。鼓勵每個人都這樣做。

對我來說，這種方法的好處是您可以通過一個小型演示使其他人看到的好處（例如，更快的開發）。您還將使他們好奇地尋找可以共享的更多提示和技巧。

所說的是關於技巧和竅門的，還有其他一些東西，不僅僅是技巧和竅門，而是應應遵循的準則和良好實踐。是否使用快捷方式是完全可選的，或者您意識到IntelliJ（IDE）中有零延遲鍵入設置，並且想要使用它。但是另一方面，我們擁有諸如版本控制，明智的變量名，保留一些文檔等功能，這些是他們真正應該做的。他們的使用方式再次在“技巧和竅門”部分中，但是他們至少應該知道使用它的好處，並強烈建議這樣做。

教學（學術環境）時，我這樣做的方式是強制使用這些東西。我不確定您是否可以在自己的位置上執行此操作，但如果可能的話，我會這樣做。您可以為您的小組設置一些“準則”嗎？如果是這樣，請執行編碼指南，並將其記錄在某處。在該文檔中放入任何相關內容，例如，如果您需要蛇皮盒或駱駝皮盒。給出一些有關如何提出好的變量和類名的提示。強制推送到git（svn，..）並顯示良好提交消息的示例。

（一種強制執行良好代碼風格的方法可能是使用一種檢查語法，變量名模式等的工具。對於許多種語言，都可以使用一些良好的linters）

我教過的人並不總是看到這些東西的好處-但最終轉了180度。看到準則得到尊重，讓學生真正看到這樣做的好處，我感到非常高興。

我同意，這是一個過程，但是如果您不指出“錯誤”，他們將如何知道可以改進這些錯誤？

就我個人而言，我一無所獲，到目前為止一切正常。我也想弄清楚這一點，並記住當他們在第一次嘗試時就確實做了一些事情時向他們表示祝賀（否則，您似乎過多地關注負面反饋）。

當然，這是重要的是要記住，最終這不是您的決定。您提出各方面的利弊，然後他們決定。另一種說法是，您最多只提到三次：）

我建議您像擔任劇院導演一樣來學習編程技巧的這一部分。

告訴您的學生，您將需要一些時間來觀察他們每個人的工作，然後給他們做筆記。

觀察一個學生並做筆記。在觀察過程中保持沉默。

觀察後，“給您筆記：”進行對話，您可以告訴學生對他們的工作的觀察，並提出改進建議。這樣，您就可以以結構化的方式提供建議，而不會them瑣。一定要告訴他們他們沒有在此標記或分級。

您還可以鼓勵他們彼此做到這一點。

我將嘗試回答您實際上是在問他們的問題-即關於您而不是您的學生的問題

如何阻止干擾學生的低效率但不是錯誤的工作？

...和...

最好的方法，但是如果學生不使用它們，一定會感到不安嗎？

（我的回答嚴格來說是關於未要求的建議，例如您的情況。當你的學生問你如何提高水平時，這顯然不適用。）

不幸的是，你對自己的問題有很深的認識。有兩個事實可以使像您（或我）這樣的人擁有非常有效的 stuff 技巧，並因目睹其他人緩慢緩慢地進行舉動而感到非常不高興-無論出於何種原因，不一定與

1. 並不是所有的技術（使用編輯器，上傳工具或其他工具）都適合每個人。您可能會發現非常明顯的事情（例如，按下大多數Emacs熱鍵，能夠在編輯過程中設想從手指直接流傳出良好的實時鍵盤宏等）對於其他人來說是完全不可能的。通過長時間的思考和認真思考，或者通過直觀地找到與您的大腦連接方式相匹配的事物，您可以掌握自己的技術。這不一定適用於其他人。因此，VI / Emacs，Windows / Linux，PC / Mac戰爭等。
2. 並非每個人實際上都能接受建議，無論出於何種目的，並出於不同的原因將其應用於自己的工作。實際上，根據我在所有生活場所（大學，工作，家庭，朋友）的經驗，只有極少數人能夠接受任何未徵求的建議任何。
ol>

現在。對於這兩個事實，我將不作具體說明，因為有很多事實，這並不重要。只是一個例子：“ 1”。對方可能只是不知道他的“思想程序”可能與編輯器的工作方式不符，依此類推。對於“ 2.”，您可能只是無法用他們需要聽的話來解釋它，他們可能被驕傲等所阻擋。也許還有很多其他原因，但是我的回答根本不是那些原因。當然，對於其中許多人來說，有辦法解決。但是，您會總是最終陷入痛苦的境地，因為您非常想幫助，但他們只是不願意。

如何阻止

做到這一點。當他們做無效的事情時要耐心地坐。是。顯然，您可以向他們展示您的工作方式，但是坦率地說，如果您在同伴環境中工作，他們只是通過觀察您就可以看到它們。您無需從中做出任何“事情”。他們是學生，應該動腦筋。如果他們花了很長的時間看到您的工作非常快，他們應該能夠確定正在發生什麼事情。關鍵是不是您需要做某事。不是您負責的是您。

如果他們看到您工作很快，那麼他們可以自由地

• 詢問您如何做。
• 對此感到不好
• 與他們的朋友坐在一起，並“比較筆記”。
• 買些書，並仔細閱讀，不管它是什麼。
• 下載您使用的工具並加以解決。
• 或者完全不用理會它，並堅持使用它們的緩慢性。

以及其他可能的事情。

如果他們不使用提示，如何不為所動

不感到不安的秘訣是從頭開始思考，並消除可以以某種方式改變的想法。你永遠無法改變另一個存在。您可以哄他們，強迫他們，以身作則或以其他方式領導，您可以享受確實有所改善的情況，但是您不能真正地使發生變化。純粹的邏輯，變得神經質是零意義。這是一種不現實的情況。如果您接受一切不變，那麼肯定會感到緊張。