是否应该要求高级程序员接任和指导初级开发人员？[关闭]

在一家旨在紧密联系和支持的商店中，高级开发人员与初级开发人员作为导师配对是否应成为文化的一部分？还是应该使这种指导更加有机和自发，即不是必需的，而是在没有人为鼓励的情况下得以发展？

我认为应该鼓励但不是必须的；老年人不应该分配给大三学生或其他类似的人，否则，您最终将进入迪尔伯特地区。“导师－受训者”关系的核心要求一定程度的友谊，以及对彼此的健康尊重。您不能仅仅通过告诉人们离开并“心理辅导”来达到目的。

将高级开发人员与初级开发人员作为导师配对是文化的一部分吗？

是。

有机的和自发的，即不是必需的，但可以在没有人为鼓励的情况下发展

它不会经常发生，无法真正帮助任何人。

在组织中具有现有关系的人们将被新人们视为集团或精英人士。集团通常不会崩溃。我们坚持与认识的人保持联系-这是人性的基本要素。

作为超过30年的顾问（有100项客户参与），我可以断言新朋友永远是局外人。它不是“文化”或“大气”的特征。这是人们工作方式的基本特征。顾问形成了自己的集团，因为老牌员工不会倾向于将他们包括在内。

建立指导的唯一方法是将新人加入团体。

“指导者”的传统含义在某种程度上违反了分配。您最好尝试分配朋友。

以我的经验，在第一周，一个月左右的时间里，指派一个新的团队成员来使用已建立的团队成员作为主要联系人是很好的。

应该要求高级开发人员指导初级开发人员吗？

绝对不。一些优秀的高级开发人员将成为可怕的导师，而个性的匹配是成功导师的必备条件。但是，我认为应该要求高级开发人员更好地对开发团队有所帮助。那可能是在旁进行原型设计，改进流程或实践，开拓新工具，向团队介绍技术材料，领导团队或其他。换句话说，他们应该对大于单个工作份额的事情负责。

还是应该使这种指导更加有机和自发，即不是必需的，而是在没有人为鼓励的情况下得以发展？

不，也不同意。我已经看到太多情况下，指导被认为是“有机的和自发的”，而且这种情况很少发生。我认为组织确实需要承担为导师提供传染性的责任，但这是不能强迫的。那很难，但是值得。我认为该组织可以执行以下操作：

• 潜在导师和潜在产品之间的非正式聚会
• 组织正式认可的指导方式和建议的建议方法和机会（例如，如果您所在的地方实际上对所有事情都有收费编号，请为指导船会议创建一个收费编号-阐明这是工作中可行的一部分）
• 对指导者的培训和支持
• 指导如何选择导师以及期望什么的指导
• 对指导者的指导，包括期望什么和提供什么
• 建议的（或强制性的）指导模式以及参与模板-例如，如果您事先知道自己的目标是每周聚会3个月，并希望帮助新开发人员起床，则更容易出手并进入公司。并不是说它不会发展成更多...但是它为人们提供了一个起点。

我认为，将其作为要求可能会适得其反，因为有些人只是没有这样的想法，并且会被这个想法完全拒之门外。话虽如此，您应该确定自己认为适合作为导师的人员，并就他们在导师中扮演更积极的角色（如果还没有的话）向他们求助。这种以身作则的方法可以流行并激发更多自发的指导。

您还可以安排定期进行的小组活动，这将有助于团队达成目标。这些活动可能完全是社交活动，例如团队午餐，也可能是结合了编程知识的活动，例如每周编程俱乐部。

您还可以在系统上进行常规的“小型事后验尸”，其功能类似于组代码检查。在小组环境中进行审阅的一个好处是，每个人都可以从反馈中受益，而不仅仅是编写原始代码的人。您可能需要让一些自愿接受准则判断的志愿者开始工作，并确保保持文明。

我从不喜欢初级和高级程序员一词。例如，我已经编程了一段时间，尽管我在某些领域有经验，但在其他领域却很环保。例如，我们正在迁移到WPF，尽管我有大量的Windows窗体应用程序经验，但是WPF仍然是我的新手和常识。因此，尽管我是一名“高级”程序员，但是您可以以“总”经验较少的方式聘请在街上工作的人，并且他们此时可能比我更好更快地编写WPF应用程序。

并不是说我没有很多可以应用于WPF应用程序的优秀应用程序设计和体系结构经验，但是我知道自己的局限性。

我想您必须在某些时候愿意成为导师，而在其他时候则愿意成为导师。

如果您的团队成员在知道知识时不害怕成为指导者，而在需要知识时不惧怕其他人，那么您将获得丰硕的经验。

如果您可以营造一种开发环境，使开发人员谦虚，乐于接受新想法并在需要时帮助他人，那么sempai-kohai关系将自然而然地出现。

强制指导可能会创建一个种姓制度，开发人员可能会互相怨恨。最好在同一个级别上平等对待每个开发人员。

这个行业是非常不同的。感觉并不总是更好。

有时，年长者需要初中生的指导。

我曾经在两种方式都可以工作的环境中。

我失学的第一份工作是分配一名导师。我不喜欢这个人，当然我也不同意他的观点。我对被迫与他一起工作感到不满，我很确定我的老板犯了一个错误，但回想起来，我学到了很多东西。

快进了几年，现在我在一家公司里，以对每个人都对自己的态度对待开发人员。开发人员的截止日期很紧，几乎没有津贴给那些花时间陪伴他人以展示绳索的开发人员。我觉得很可惜。我看到初级开发人员如何为我所做的同样的事情而苦苦挣扎，但是如果没有指导者来帮助他们，这会花费很多时间。

我之所以被誉为“导师”，是因为新员工“似乎很感激我能够为他们提供的帮助”。据我所知，这是一种花哨的HR方式，我愿意忍受平庸的生产力审查，因此我可以做正确的事，这是使初级开发人员能够有效地完成工作并迅速改善。

我认为这是我们初级员工应得的，并且借助事后的洞察力和经验，我认为我工作的第一家公司以及指导我的那个人比我当时想的要多得多。

所有这一切都是漫长的说法，虽然我希望您不必指派导师，但这可能是在工作中散布的唯一公平的方法。如果您不这样做，则应让这样做的人应得的。这不是一件容易的事。它需要人际交往能力和工程技能；而且很费时间。

应当期望高级开发人员能够超越编写代码的范围。但是，对于每个高级开发人员，他们的前进方向都不应该相同。

有些非常适合指导。其他人不是，应该追求一些其他高层目标，无论是计划和实施体系结构改进，评估新技术还是规划和领导过程改进（例如持续集成，TDD等）。

基本上，大四的人不应该只是比大三的人削减密码几年的人。应该是谁愿意并且有能力承担其他责任，这将有助于团队的成功。指导初级人员很重要，但这不是唯一重要的事情，也不是每个人都适合的事情。

强制进行这样的指导会适得其反，因为人类很自然地反对强迫活动，行动和关系。更好的方法是奖励做得好的辅导员，从而使人们想辅导。

当然，这带来了在这种情况下测量“好”的问题。一个不完美但易于实现的解决方案可能是让新来者在一年后（可能是匿名的）写下帮助他们融入公司和/或代码库的前三名人员的名字。之后，您可以奖励名字被提及最多的人。但是，货币奖励在这里行不通。最好找到某种社会奖励。

团队领导结构，导致代码审查应尽力而为...

您将有一名高级职员负责一个或多个初级人员。我不认为这应该是自发的帮助，而应该是一个正式的过程。从某种意义上说，高级成员将对新员工产生的工作质量负责。这种方法（至少）有两个好处：指导年长者管理风格，并确保大三生产生高质量的代码。

编程取决于一切。但是，我绝对希望资深开发人员指导新员工（无论他们是否是初级员工）为他们提供最佳的培训。

不可以，因为这意味着高级开发人员和初级开发人员的数量始终是相同的。我可以看到鼓励那些想要成为导师的高级开发人员，但是强制配对可能是一个非常糟糕的主意。支持导师关系的想法很好，不应该在这里抛弃。

在这里，人为鼓励并不是一个坏主意。告诉所有初级和高级开发人员，无论他们有什么宗教信仰和适得其反，他们都将成为受训者和导师。

如果公司内部有一个如何处理指导的框架，那就太好了。但是，如果不存在，那么密钥在导师和受训者之间会有一些不同的时刻：

1. 现状-现在在哪里？指导者可能会提供协助解决当前面临的挑战？
2. 未来状态-想要什么：提示，解决方案，要问的问题，问谁？
3. 回顾-进行更改的有效和无效方法是什么？
4. 未来的变化-将来会尝试比以前更好的尝试吗？

至少这些是我可以看到并从逻辑上采取合理的自上而下方法的状态。其他人可能想要更有机和自由形式的东西，它们也可以工作。关键是要了解如何使双方拥有一些应通过这种关系中的交流练习磨练的技能。双方都应从关系中受益，建立这种关系应该有一些共同的基本规则，因为反馈在这里很重要。

一个人花多少时间在这个问题上是一个公平的问题，实际上必须看一下正在做的事情，以及花多少时间来发展技能和建立人际关系是可以接受的。我可以看到有些夫妇希望每周花一个小时来完成这项工作，而另一些夫妇可能想要一天几个小时来完成这项工作。不要忘记，尽管不在正式的指导关系中，但大四和大三可能还会有其他的互动。

我已经看到了几种不同的指导制度尝试。我最喜欢的是高级开发人员要执行的一组特定任务，以帮助初级开发人员，这为不需要指导的指导铺平了道路。例如，在头六个月内指派一位高级开发人员一对一的代码审阅者可能非常有用，并且很可能会导致指导。我不喜欢的人感觉自己很忙，似乎与工作无关，例如每周与您的导师见面半小时。当导师关系的两个成员通常在一周之内不相互交流并且与彼此的项目没有任何关系时，这尤其令人讨厌。感觉非常强迫和敏感，而不是专注于专业发展。您想要的最后一件事是使导师关系像辅导会议。

IME，您不能指望建立的导师关系，因此，至少要在一对正常配对业务活动（代码审查，调试，结对编程等）中将高级开发人员和初级开发人员配对，才能提供潜在的指导者。首先，是个好主意。理想情况下，高级成员应该自愿担任该职务，并且应该能够体会到一些个人利益。在我目前的公司中，高级开发人员几乎是他们项目的负责人，而好处是他们正在建立自己的项目团队。在另一家公司，导师经常调查管理轨迹。

我认为每家雇用年轻开发人员的公司都应该有某种合理有效的指导计划。但是我不确定默认职位应该是每个高级开发人员都应该这样做，原因很简单，因为许多开发人员，无论他们的开发水平如何，都很难接受指导。不幸的是，它随领土而去。如果您愿意，我们中有些人不是好人。

另一方面，在有擅长此事的人那里，他们应该得到认可，而不是冒黑标，因为当他们向某些新手解释IDE的一些简单本地化问题时，他们的实际开发成果下降了，哦，例如，使用了NotePad和Javac。

这需要一些平衡的管理。我不确定这很普遍。

对于任何指导工作，管理层都必须意识到这一点很重要，并为此分配时间，并积极鼓励这一工作！

对于100％预定有任务的任何人，实际上没有时间进行或接受指导，而且这种情况不会发生。

通常，导师船是从高级领导过渡到团队负责人或经理的良好阶梯。在PDP（个人发展计划）或贵公司使用的绩效计划中，将指导与进步联系起来更为有效。将他们的加薪和职业发展至少部分地与他们传递知识和培养新开发人员的能力联系在一起，这是建立强大的IT员工的关键，该员工可以应对管理和人员流动的变化。提供关键目标并与员工合作以帮助他们改进是领导力成长的一部分。对于那些认为将老年人的评估与成长的一部分的初级表现联系起来是不公平的。在大多数情况下，您并不是在谈论减薪，而是在减少加薪或减慢进度。

当我第一次加入团队时，我有一个所有者和一个首席开发人员给我指导。我可以问他们任何一个，他们都会回答。但是，我很有礼貌，不要一直困扰他们，除非我只是无法及时解决。

效果很好，但是再说一次，您可能需要有幽默感的好人才能使它起作用。