過去一年半里，我在為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歲之間的男性白種人，但這個世界上還有很多同樣熱情、能夠在技術上有建樹的人并不屬于這一類型。
這并不意味著需要過度地保持正確的政治方向或者放棄你的幽默感。這只意味著，如果你不能在各種其他群體面前開一些玩笑或發表一些言論，你同樣要避免在程序員同伴面前說類似的話。還意味著，你同樣需要在溝通之前檢查一下自己對別人的文化假設。專注于別人能做什么，而不是他們與你有多大差別。
我在這篇文章里的大多數建議會自然地建立一種環境，這種環境能夠吸引比我們目前服務的社區更為廣泛的人群。但是我想在這里呼吁重視這個問題，它的重要性實在不容忽視。社區的組織者需要特別記住這些問題，因為它們是針對團隊成員期望設置目標的絕佳機會。
在感到安全、受到歡迎和得到感激的氛圍中，人們能工作和學習得最好。如果你團隊中的每個成員都認同這種氛圍，你最終會比那些令人感到被邊緣化或沒有感激的團隊收獲更多。
