本文总结了一些Mendicant大学深受好评的方法。希望这些经验能帮助更多本地团队和在线团队，这样会有更多优秀的场所供程序员学习和成长。

强调个人目标与团队兴趣

在小团队里，只讨论眼下全球流行的IT技术，却忽略小组内部正在做的工作，这是对精力和潜力的极大浪费。而将关注的内容与团队成员正在参与的项目或日常工作中面临的问题联系起来，这样则会更加有效。

与其对一般性的问题进行讨论和学习，不如找出团队需要解决的一些具体问题。可以自己克服这些障碍，通过整合手头的资源可以更加有效地找到相关学习资料，或者组织相关人员进行讨论。

实践的方法有很多，其中有一种方法很有意思：在每次会议一开始，让大家谈一谈自己正在做什么、对什么比较感兴趣，这样大家可以依据兴趣进行组合。对于在线讨论组，可以使用wiki或者定期的邮件列表摘要来达到类似的效果。

实行正式的代码审查

不要空谈想法或策略，最好办法是坐下来、打开编辑器并准备好代码进行审查。通过向别人讲解自己的代码，你能从中学到很多东西。可以毫不夸张地讲，任何向他人教授知识的过程都能产生价值，哪怕仅仅是讲解编程习语或者命名规范这样的小知识也是如此。
如果代码太过粗糙不能进行有效的审查，可以通过编写一个简单的例子来展示你正在学习的核心概念。讨论的内容越具体，在与别人的交流中获得有价值信息的可能性越大。

倾向有理有据的争论

在编程社区里，依据权威（“某某说过……，因此……”）和流行观点（“大家都是这么做……”）的争论非常普遍，但最终都会偏离想要表达的观点。幸运的是，讨论代码有一种更为有效的方法。

对于给定问题讨论解决方法，明确问题背景是最重要的。不了解问题背景，就不清楚解决这个问题是使用锤子还是推土机更合适。明确问题背景后，对于给出的解决方案就有了可讨论的依据。

至此，剩下的事情就是比较不同解决方案权衡利弊。打个比方，你可能会说：“Sqlite易于使用，因为它不需要数据库服 务器。但如果要处理GIS数据，你可能会选择PostgreSQL，因为PostGIS提供了很多有用功能”。这个说法虽然不是无懈可击，但比 “Sqlite很烂，一定要使用PostSQL”要好一些。

有时候，你只是想表达一些纯粹的个人偏好，这没有问题。但在这个时候，如果能有一些理性讨论而不只是抒发个人感情，会更好地表达你的观点。在某些情况下，这能让你避开宗教般的争论。