ReThought (二): 如何照顾团队中的新人

当我们在说照顾的时候，我们实际上是在给新人减压。当我们在说容忍犯错的时候，我们实际上说你可以犯一两个错误。减压更像是在塑造一种更好的学习体验，或者说更愉快地学习方式。

学习与构建系统

学校的时候，学习倾向于理论性的学习。

工作的时候，学习倾向于应用性的学习。

两种不同方式有着不同的区别，即一个广度，一个深度。

在构建系统的时候，通常我们需要一个基本能工作的系统，其次在系统不断开发的过程中。我们对于深度了解的需求已经变得比广度更为重要。

故而，在一个以产品为主的开发团队中，在早期他们更需要那些有广度和速度作为支撑的开发人员，在后期则需要以深度作为支撑的开发人员。

两种人才可以在不同的时期发挥着重要的作用。

在《认知设计》一书中，提到了下面的学习体验，即"流"(Flow)。而在我们学习的过程中，我们也会有类似的学习过程。

Flow

如在早期我学习Emcas和GNU/Linux的时候，也曾经放弃过，虽然在当时我已经读过Linux内核。然而，在应用之前进行理论学习并没有卵用。

通常我们会有类似于下面的学习体验，对于一本书来说有下面的体验似乎也是一件很不错的事:

在最开始学习的时候，我们需要一点理论基础，以及我们需要学点什么。
然后，我们需要构建一个简单可用的系统，以获取信心。如果我们在这一步没有想象中，那么简单，那么我们可能会放弃学习。或者等到某个时期成熟的时刻，如在我开始学习《设计模式》的时候，那么本书的高度太高了。直到有一天，我了解到了一本叫《Head First设计模式》的书，才重新把GoF的书看了一遍，发现其实也没有想象中的难。
接着在我完成了某个功能之后，那么我可能继续学习某个理论，用于支撑我的下一步计划。
在那之后，我觉得这一步可能也不是那么难，因为已经有了前面的基础。如果在一步失败的时候，那么我们可能会继续寻找某些可靠的方案，又或者是理论支撑。
。。。
直到有一天，我们来到了一个瓶颈的前面，现有的方案已经不满足我们的需求。对于这个问题，我们可能已经没有一个更好的解决方案。于是，我们可能就需要创建一个轮子，只是在这时，我们不知道怎样去造轮子。
于是我们开始学习造轮子。
....

只有当我们保持一个学习的过程，才会让我们在这一步步的计划中不会退缩，也不能退缩。

在前面，我们已经说了足够多的废话，来支撑我们的标题。

在上篇《如何构建理想的开发团队》中我们说到了一点，即结对编程。在结对编程中会存在至少三种模式:

Coach模式。在我现有的经验里，这个模式对新人会帮助比较大。通常来说，我们是要分解任务，然后带领新人一步步完成任务。或许你注意到就是上文中说到的那个心流的过程。在这个过程中，很容易明白这是怎样的情况。
导航模式。在一步中，有经验的人更多的是充当观察模式。有时，当新人不知道往哪个方向就知道提示。当新人犯错时，最好看着ta犯错。
Pair模式。理想的结对编程便是在这样的模式之中。而要达成这样的目标需要两个人之间有很好的默契，以及在某方面相接近的能力。在一步中，如果可以平衡好两人的步骤，那么对新人的自信心想必是有很大的帮助。

采用结对编程不仅可以提高新人的水平，对于老人的能力也是很大输出。即之前别人输入我们脑子中的想法，我们需要再传递出来。对于程序员这一类人必然会有很大的提高，如果你不擅长表达的话。

所以，我们所说的照顾实际上是一个更好的学习体验。

很我时候，我们总是局限于第二步，故而无法更好地指导他们完成工作。