過去一年半里，我在為Mendicant大學（Ruby開發者線上大學）工作。我與同學和員工一起建立了優秀的線上學習社群。美中不足的是，由於一開始我們對Mendicant的定位是逐步發展，所以短時間內沒有達到我們預期數量的學員。
本文總結了一些Mendicant大學深受好評的方法。希望這些經驗能幫助更多本地團隊和線上團隊，這樣會有更多優秀的場所供程式設計師學習和成長。
強調個人目標與團隊興趣
在小團隊裡，只討論眼下全球流行的IT技術，卻忽略小組內部正在做的工作，這是對精力和潛力的極大浪費。而將關注的內容與團隊成員正在參與的專案或日常工作中面臨的問題聯絡起來，這樣則會更加有效。
與其對一般性的問題進行討論和學習，不如找出團隊需要解決的一些具體問題。可以自己克服這些障礙，通過整合手頭的資源可以更加有效地找到相關學習資料，或者組織相關人員進行討論。
實踐的方法有很多，其中有一種方法很有意思：在每次會議一開始，讓大家談一談自己正在做什麼、對什麼比較感興趣，這樣大家可以依據興趣進行組合。對於線上討論組，可以使用wiki或者定期的郵件列表摘要來達到類似的效果。
實行正式的程式碼審查
不要空談想法或策略，最好辦法是坐下來、開啟編輯器並準備好程式碼進行審查。通過向別人講解自己的程式碼，你能從中學到很多東西。可以毫不誇張地講，任何向他人教授知識的過程都能產生價值，哪怕僅僅是講解程式設計習語或者命名規範這樣的小知識也是如此。
如果程式碼太過粗糙不能進行有效的審查，可以通過編寫一個簡單的例子來展示你正在學習的核心概念。討論的內容越具體，在與別人的交流中獲得有價值資訊的可能性越大。
傾向有理有據的爭論
在程式設計社群裡，依據權威（“某某說過……，因此……”）和流行觀點（“大家都是這麼做……”）的爭論非常普遍，但最終都會偏離想要表達的觀點。幸運的是，討論程式碼有一種更為有效的方法。
對於給定問題討論解決方法，明確問題背景是最重要的。不瞭解問題背景，就不清楚解決這個問題是使用錘子還是推土機更合適。明確問題背景後，對於給出的解決方案就有了可討論的依據。
至此，剩下的事情就是比較不同解決方案權衡利弊。打個比方，你可能會說：“Sqlite易於使用，因為它不需要資料庫伺服器。但如果要處理GIS資料，你可能會選擇PostgreSQL，因為PostGIS提供了很多有用功能”。這個說法雖然不是無懈可擊，但比“Sqlite很爛，一定要使用PostSQL”要好一些。
有時候，你只是想表達一些純粹的個人偏好，這沒有問題。但在這個時候，如果能有一些理性討論而不只是抒發個人感情，會更好地表達你的觀點。在某些情況下，這能讓你避開宗教般的爭論。
尋找有效的練習和學習方法
每天都會湧現很多學習程式設計的新方法，它們被視作下一代革命性方法並受到推崇。同樣你也會發現，通常人們現在學習和討論的都是一些新技術。當然，這會讓你錯誤地認為很重要並且迫切想要學習。如果追隨他們，你會事倍功半因而不能踏實地做出有用的東西，到頭來你會發現這些技術不過是過往雲煙。
無論何時，儘可能地在學習新技術時為自己設定目標並動手實踐。如果可能的話，可以用較低風險的專案試驗新想法和新技術，這樣會對自己以後大有裨益。如果你確實要花一些時間進行刻意練習而不是邊工作邊練習，請確保練習的目標是為了實際需要或是為了解決實際問題。例如：採用程式碼套路學習一門新語言或者文字編輯器新特性是一個好主意，但如果想要通過程式碼套路來獲得意外收穫就是一個糟糕的想法。雖然有時候方法不對也能碰巧解決問題，但在你進步的過程中不應該只是碰運氣。
譯註：程式碼套路(code kata)：由Dave Thomas 發明該詞，源自日本空手道中的套路(kata)概念。程式碼套路是用來幫助程式設計師通過練習和重複來提高自己的程式設計技巧。
雖然上面提到的內容更多的是針對個人而不是在團隊練習，但同樣的目標也應當出現在你參與的任何團隊活動中。無論何時，儘可能根據需要分成專注不同技術的小組，這樣可以避免出現強迫一些成員練習或學習與其不相關或不感興趣的內容。我們可支配的時間和精力是寶貴的，應當小心分配。
值得注意的是，這個建議並不意味著只關注狹窄的和現實的目標。對於理論研究或經典課題的深入學習同樣適用，並且可以在團隊活動中開展。不要為了模糊不清的興趣去組織活動，將這些活動在某種程度上與個人內在目標聯絡起來是非常必要的。
在技術與社交之間建立良好的平衡
在任何組織裡，沒有交流很難建立起共同的文化，成員之間也不會分享自己的興趣。然而，迄今為止我見到過太多的使用者小組從像HackFest一樣的盛會變得平淡無奇。如果團隊的社交準則鼓勵這種行為，就不會有深入的討論和研究開始並延續下去。
譯註：HackFest：每年一度的Apple II程式設計比賽，對所有參加KansasFest課程的成員開放。
以我個人的經驗，可以在工作結束之後開展一些交流活動，或者將交流與工作安排在不同時間。線上社群也可以採取類似的方式，為工作和非正式交流分別設計一些活動。你不必像法西斯那樣刻意強調之間的區別，但在未來前進的道路上一定要始終持有清晰的目標。
建立參與和分享的團隊文化
瞭解你的團隊，不僅要看團隊成員在說什麼，更要看他們在做什麼。所以，儘可能地去突出團隊成員的貢獻，支援那些由積極協作完成的工作。不提倡由一個人完成主要工作，而其他人只是被動地接受資訊。
就個人而言，我更喜歡能夠碰撞出火花的討論以及類似Hackfest的活動。只要能夠專注於團隊成員正在做什麼，而不僅僅是重複別人說過或做過的事情都可以。同樣地，我認為只要結構合理並且舉止得體，組內討論也同樣可以非常有效。
線上團隊也可以通過程式碼審查、文章討論和問答的形式取得同樣效果。
無論是與網路團隊一起或是獨自一人，在提高程式設計水平的過程中都可以參與開源軟體開發和討論。儘可能地鼓勵你團隊的成員公開並分享他們的成果，這會產生巨大的不同效果，會形成一個積極鼓勵分享的氛圍。當然，並非每個人都有時間經營他們自己的專案，或者為其他專案做出可觀的貢獻（比如提交一個很大的補丁程式）。但是，只要你聽說某人提出一個bug或者報告了一個從未被發現過的問題，你就可以適時地坐下來，並且告訴他們如何編寫最小的示例重現問題並提交一個bug。有的時候，幾分鐘的指導就可以讓一些只會在推特上抱怨的人轉變成為開源專案的積極貢獻者。
瞭解社交習慣，切記不要排斥邊緣團體
許多技術團隊（線上團隊和本地團隊）都沒有做到斷絕一些相當令人尷尬的行為。雖然作為個體我們無法感受到這一點，作為團隊我們一直覺得容忍這種排斥行為是一種犯罪，而這種排斥在大多數其他社會場合都是不能被容忍的。請記住，儘管參加技術會議的程式設計師主體是異性戀的、中產以上、20到30歲之間的男性白種人，但這個世界上還有很多同樣熱情、能夠在技術上有建樹的人並不屬於這一型別。
這並不意味著需要過度地保持正確的政治方向或者放棄你的幽默感。這隻意味著，如果你不能在各種其他群體面前開一些玩笑或發表一些言論，你同樣要避免在程式設計師同伴面前說類似的話。還意味著，你同樣需要在溝通之前檢查一下自己對別人的文化假設。專注於別人能做什麼，而不是他們與你有多大差別。
我在這篇文章裡的大多數建議會自然地建立一種環境，這種環境能夠吸引比我們目前服務的社群更為廣泛的人群。但是我想在這裡呼籲重視這個問題，它的重要性實在不容忽視。社群的組織者需要特別記住這些問題，因為它們是針對團隊成員期望設定目標的絕佳機會。
在感到安全、受到歡迎和得到感激的氛圍中，人們能工作和學習得最好。如果你團隊中的每個成員都認同這種氛圍，你最終會比那些令人感到被邊緣化或沒有感激的團隊收穫更多。
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
任選一種支付方式
