如何帮助挣扎的新手做得更好？
我一直是我公司旗舰产品中唯一的开发者和事实上的“高级开发者”（一个.NET WinForms应用程序，但并不相关）。 就在最近，他们带来了一位具有新的计算机科学学位的“新手”开发人员。 没有源代码控制，unit testing，软件维护等方面的经验
我最近为他分配了一小部分工作，使自己得到了充分的帮助，只是在速度和质量方面都发现他的产出缺乏很大的帮助。 我尽量不要过于苛刻，所以我给他的唯一预先指导是描述我更新（但他没有）的任务的wiki文章，关于新技术（比如IPC）的几个代码示例，并且我分解了把这些任务分成几个FogBugz案例（他没有提供原始的估计，实际的时间或评论，直到我告诉他我会放什么）。 他很less提出问题，当他提出这个问题的时候，他似乎像是要求一样遵循我的build议，常常没有理解，甚至是错误的。
所以……我完全同情你不知道该怎么做的情况，不敢提问。 我知道这是我的责任，要做得更好，但没有人给我任何指导，所以我没有什么经验来看待更好的工作。 幸运的是，他正在休假一个星期，所以我有一些时间来思考如何改进这个过程。 以下是我想到的一些项目，但我愿意接受build议和批评：
- 问最后一次迭代的哪一部分是最困难的。 问什么部分花费比预期更多的时间。
- 做一些配对编程。 我已经提出了这个build议，他似乎对这个想法持开放态度，但是每次开始时，我都倾向于接pipe，因为他打字速度不够快。 我必须努力工作。
- 在检查工作之前先进行一次代码审查。（我们这次不是因为他的假期。）代码审查将突出显示以下项目。
- 要求所有公众成员评论。 （他的代码没有被评论。）
- 要求他删除所有未使用的代码。 （粗略的回顾显示他没有。）
- 要求他在完成每一个FogBugz案例时提交代码，并且/或者修改与编码时发现的不同的案例。
- 要求他将原始估计值input到FogBugz中，并切换“正在工作”的标记以使他保持任务。
虽然代码审查的内容是具体的和技术性的，但我更关心的是他能够成为一名自我启动者，并在需要时提出要求/得到指导。 我不认为FogBugz的要求（6和7）是严格的规定，但似乎他需要跟随这些要求才能使他走上正轨。
此外，我知道我需要提高自己的辅导/培训技能，尽可能提高自己的编码技能。 当“高级开发人员”没有参加正式的代码审查，或者没有接手通过一对编程会议时，有什么build议可以开始？
我的冲动是更新他已经检查的东西，但我知道我应该保存这个代码审查。 我希望他检查工作，所以我可以开始编码使用他所检查的部分。所以，即使我认为它不令人满意，我应该使用他检查的内容吗？
那么，你应该花这么多时间来解决这个问题。
我会build议这些事情：
- 让他阅读代码完整 。
- 对待他像一个高级程序员，但检查他所做的每一步，直到你看到好的结果。
- 不要接pipe，否则他不会学习。 让他犯错误，然后让他修好。
- 他应该总是做出估计。 然后让他承认，当他的估计是错误的。
- 总是鼓励他去思考 。 新鲜的CS学生很难想到; 他们像机器人一样编码。
给他一些基本规则，比如：不要两次写同样的代码，如果你这样做，检查你的devise等等。
另外请记住，他害怕你，尽可能向他学习。 你可能忘记了他正在学习的东西，所以你需要推动他提出问题，并确保他这样做并不愚蠢。
在六个月内，他会做好准备！ （离开并寻找更好的有偿工作:-)）
以下是在日本处理的一些build议。
首先让他设置他的工作环境（给他一个星期做），然后告诉他是谁，并给他一个同事的邮寄地址列表。 1周不会对他施加很大的压力，在他的前5天内他会实现一些有形的东西
在他的第一个星期五，带领球队喝了几杯酒，点菜车或迪斯尼乐园（大约一个小时的路程）。 这取决于你的口味和新商人喜欢什么。 这将帮助他了解团队，并且看到他们在个人层面上的互动，这将帮助他感觉像是家庭中的一员。 这样，他会更加自信地接近别人的帮助。
接下来让他做2-3周的基本编码。 在他的第一个星期，每天给他5个非常小的任务。 基本的嘶嘶声水平的东西。 并在每天结束时进行代码审查。
在他的第二到第三周，他有一个玩具项目（有一个真正的截止date）。 在他未来的工作领域，但不是实际项目的一部分。 这样他就有一个沙箱可以工作，而不用担心打破别人的工作。 与他一周两次审查代码。 在完成之后，让他把自己的作品展示给团队。 这将给他无比的信心。
现在，在他的基础训练的第一个三个星期以后，再与队一起喝酒或乐趣。
他已经通过了启蒙仪式（心理上非常重要）。
现在让他开始真正的项目，但是给他一个星期的时间来阅读代码并提出问题。 在本周中旬和本周结束的安排会议，所以他可以向团队提问，而不必像他打断任何人。
现在，你有一个快乐，好奇和自信的新人，做所有其他人都在这里build议的东西:)
做一些配对编程。 我已经提出了这个build议，他似乎对这个想法持开放态度，但是每次开始的时候，我都倾向于接手，因为他打字速度不够快：
这绝对不行。 这可能不会帮助他认为他有学习的空间。
在他离开的时候不要对他的工作做很多改变。 那会让他感觉很糟糕 相反，当他回来的时候，要努力重构（不惜一切代价避免打字）。
突出他所做的一切（他只是做了第一个改变 – 这是一个值得庆祝的巨大成就），而且只有当你与他谈论他可以改进的地方之后，才能加强对他的好处更改。
将来，不要让人们首先检查未经审查的代码（根据您的观点3），只有在审核中突出显示的所有问题都得到解决后才允许检查更改。
NB。 我从来没有做过任何pipe理，所以这只是描述如果我是另一个人，我希望你如何处理这种情况。
不久以前，我是一个新手，我记得感觉如何，还有那些我不太喜欢的东西和帮助我的东西。
提示：
-
不要把他放在他是该项目的唯一程序员的项目上。 把他放在一个主要的开发者的位置，然后给他分配一些可以在很短的时间内完成的小任务。 估计可能需要16个小时的工作而不是80个小时的工作可能会更容易。 现在他可能不敢给出估计，因为他不想给你一个“错误的答案”。 他害怕他会告诉你32小时，当你预计8或什么。 大声笑我总是害怕这一点。
-
检查前检查代码是好的，但他自己解决问题。 如果你对他的代码做了重大修改，可能会让他感觉不好。
-
我不会推荐配对编程。 我一直想要自己弄清楚，当我把事情做好的时候，我得到了所有的荣誉。 而是随时提供给他，让他可以提问。 与项目中的其他编码人员在同一个房间是非常重要的，尤其是对于一个新手程序员。 结对编程可能会晚一些，但作为一个新手，我想自己工作。
-
在我看来，知道何时提出问题本身就是一种技巧。 你不想过多地缠住你身后的那个人，但是你又不想在谷歌上search半天，而当你身后的那个人立即知道答案的时候，你最终会转动你的车轮。 鼓励他自己找答案，但如果找不到就不要害怕求助。
-
他明确需要学习评论代码。 回顾其他民族的法典将教会他的重要性。 他需要学习编写“自我logging代码”。 通过使用好的variables名称和经过深思熟虑的，易于阅读的编码技术，“什么”应该被自动logging。 有时需要注释来告诉“为什么”代码是以某种方式写的。
-
让他做代码评论是好的。 也许你和他配对，你和他可以和他一起看看别人的密码。
-
不要太频繁地接pipe键盘。 一分钟也没关系，但是如果他是一个程序员，他最好学会尽快打字，练习是唯一的方法。
-
就像上面提到的其他人一样，他会喜欢听到他做得很好，所以当你看到他喜欢的东西时，一定要告诉他！
你想让他达到你的专业标准？ 大。 你需要教他什么。 从指导的angular度看，不要把所有的规则放在同一时间。 每天都工作一次。 随着时间的推移，他会到达那里，或者摆脱他。
从列表中缺less一件事是代码评论。 是的，你应该检查他的所有代码，但是….他应该检查你的所有代码。 这样的学习是双向的。 这会让他觉得自己是团队的一部分。
这是一个棘手的问题，不会有一个“正确”的答案，但这里有一些意见和build议：
所以即使我觉得这样做不合适，我应该使用他所核对的内容吗？
当然不是，恕我直言。 你需要先做一个评论。 否则，他如何相信你，如果你使用的代码是不令人满意的？
要求所有公众成员评论。 （他的代码没有被评论。）
这应该是一个简单的。 没有任何评论的借口。 如果您遵循编码惯例，请向他展示此约定。 如果没有，也许是时候写一个小的。 您也可以将其纳入代码评论。
我从你的想法中看到的一件事是问他他认为他能做什么，或者你可以做些什么来让你们更容易。 他认为他的代码是否令人满意？ 等等，你可能会惊讶于他要说的话。
听起来这个新人的问题可能在这个过程中被发现太晚了。
除了审查他正在编写的作品和编写的代码之外，还要强调预先分析和规划。 在给他任务时，让他在白板上勾画出问题的定义，algorithm和时间表。 和他讨论一下，解决你在这个阶段遇到的任何问题，而不是等到时间stream逝，破坏完成。
根据我的经验，越早发现问题，就越快修复。
你所做的事情非常好，你已经认识到你自己需要改进的地方。
我的过程是尽量保持新人的积极性。 目前我有一个同事，我可以在闲暇时间做一些小题大做的“好玩”的工作，以保持积极性。 在实际工作中，我让她开始自己的分支，告诉她去找黄金，并保证“她不能破坏任何东西”。 一旦完成，她会让我知道完成的任务，然后我将执行代码审查，提出build议或展示她实现任务的替代方法，这通常是一起完成的。
我认为把键盘从某个人身上移开是一个非常糟糕的主意，虽然他们可能会很慢，但是你需要明白，这可能会让人觉得有辱人格。
从我所说的最好的感受就是让他们热情洋溢地迎接挑战，这将激励和鼓励更好的实践。
如果你发现他们没有提供足够的结果，你应该确实要求他们更新他们的代码，并确保代码被充分logging（而不是像有时候那样过度）。
把他们当作你永远鼓励的朋友，他们会走很长的路。
我的build议是问他他是怎么想的。 如果他认为自己做得太棒了，而且是宇宙中最伟大的东西，那么你可能会遇到更大的问题。 另一方面，如果他认为自己刚刚过来，那么尝试向他展示一些绳索可能并不是那么糟糕。 我build议给他更小的任务，并回顾一下他写的部分内容，这样他就没有那么偏离了，这是他曾经到过的那个地方。
另一部分是你和新人之间有什么样的关系？ 你是他的老板，同事还是别的什么？ 我怀疑如果你跟他谈了几件事情，可能有助于理顺事情。 我记得在我的第一份工作中，必须有一个小小的手才能通过消防任务的初步审判。 如果可以的话，每天尝试几次，根据自己在哪里以及他在做什么进行登记。
很好的问题，以及一些很好的回应！
我想补充的另一个build议是：当你做配对编程时，不要太快纠正他的错误。 记下他们自己，但让他继续，看看他是否可以解决自己的错误/问题。 当然，如果他需要太长的时间，你还是要伸出援助之手（你得决定多久），但是一些最好的学习经验来自纠正自己的错误。
感谢您为成为良师益友所做的努力。 这是我的2美分。 我曾经有一位高级开发人员用估计来检查开发人员是否使用正确的方法（没有时间压力）。 如果开发人员估计10小时内可以在2小时内完成的事情，那么你肯定知道一些错误。
然后，他偶尔会在我的办公桌旁边（不是微小的pipe理）来检查是否有好的事情，如果我感到不安，可以提供一些新的提示或更好的想法。 我感觉他的方法增强了我对自己的信心，使我成为一个更好的程序员。 我肯定会说，这个“微妙的检查”偶尔dropbys比每周的代码审查更强大和敏捷，因为一个小程序员坐得越久，没有太多的线索越快，他失去了他/她的信心。 在开始时保持简单，将有助于新手适应得更快。
作为即将成为计算机工程师（和初级工程师），我可以同情新手。
对他来说最重要的事情之一就是他不会因为早早犯错而惹上麻烦（或被解雇）。 鼓励他去尝试，即使他不认为他的代码是完美的。
在我的第一份工作中，我的任务花费了比我想要的更多的时间，因为我担心我会错过一些事情，或犯一个简单的错误，使我看起来像一个白痴，所以我花了更多的时间检查，以确保我所做的一切都是正确的。
几乎所有需要说的话都说了很多好的build议。
我只想补充一件事：他可能没有意识到自己的工作范围 – 估计，写作testing，错误跟踪等等，实际上是他的一部分任务，完全是他的责任。 如果你清楚地明确地表明自己需要自我指导，那么也许是一个非对抗性的谈话，可能会清除一些对他的期望的混淆。
努力做正确的事情的满分。
我会让这个人做一段时间非常有限的，明确的事情。 例如，让他们在你已经定义的类中实现了一些方法，并且你已经实现了unit testing。
一旦他们可以接受一个非常有限的东西，将他们转移到另一种types的任务上。 过了一会儿，他们就可以做好5件事，然后再做10件事，等等。
我必须问 – 你在这个人的招聘过程中有什么参与？ 你采访了他们吗？ 你是否允许注册有关雇用技能水平的意见？
对于一个两人开发团队，我会避免直接招聘团队成员。 这样一个小团队没有足够的空间去支持他们需要的在职学习。
计算机科学学位实际上很less涉及真实世界的编程任务，如源代码控制，错误跟踪，项目（自我）pipe理，甚至超出基础的编程。 他第一份工作可能是一件可怕的事情。 有一件令人担忧的事情是他的打字速度很慢，这说明缺乏自信心编程（一个很大的担心，但是如果他有正确的想法就可以克服），或者因为他在考虑这笔钱而做了CS，能力是必需的（主要担心表示试用失败）。
鼓励他先从逻辑上在纸上devise解决scheme – 看看他的思维过程如何没有实际编码的压力，你看着。
配对编程时切勿接pipe键盘; 否则这是一个好主意。 也让他坐在你的节目上。
向他询问你正在使用的工具和他以前的经验。 如果没有，最好给他一些训练，直到他有信心。
恭喜你对辅导的态度。 一个简单的事实是，你问你是否做得对，如何做得更好，意味着你做得对！
我认为这个问题是，你可以在两种情况下：
1）他/她只需要时间和指导去了解游戏是什么，但是会到达那里
2）他/她不是队员，不在乎。
显然，如果你处于（2）的情况，辅导不会有帮助。 如果是这样的话，你最好的策略就是限制这个人可以做的伤害，并且把他/她从队伍中解救出来。 但是如果不给这个人一个机会，你就不会这么做，这就是你正在做的事情。
已经有很多好的build议。 假设你正在和一个你可以指导的人一起工作，我的两条一般build议是：
1）帮助人理解他/她的期望。 给这个人一些小任务，说出你要找的东西（代码重复…），并且一起看这些。 要鼓励，但要坚持规则：如果你们一致认为有一件事情要做，没有完成，不要让它下滑，这是不尊重团队的。 不要修复代码，如果事情没有按照约定完成，请将代码发回去解决。 这将有助于他/她走上正轨 – 如果反复出现同样的问题，抱歉，但是你的团队中有一个沉重的负担。
2）build立信任。 学院应该对理论有一个很好的理解，但是通常对团队工作，大型软件的准备不足。 让这个人了解，差的承诺会影响整个团队。 让他/她明白，提出问题是好事，每个人都会犯错误。 我发现结对编程很棒，因为它表明没有人是上帝（但不要接pipe键盘！）。 要求这个人评估他们做了些什么，他们在某个特征上遇到了什么问题，并告诉他们你对什么是好，哪些不好，哪些地方有了进步的评估。 同样为了鼓励问题，如果可以的话也去问问题，或者想一想你正在处理的问题。
这里提出了很多优秀的build议，可能很难将所有这些信息直接传递给您的员工。 你有没有考虑过把他介绍给StackOverflow并让他读这个问题及其答案？ 当然，你应该先和他谈谈，这样你们的批评才不至于成为一个痛苦的惊喜。
我看到这种方法的几个好处：
- 他可能会涉及到StackOverflow，这是一个很好的方式来提高你的编程风格和学习绳索
- 他可以从你的angular度看待事情
- 他可以亲眼看到所有的build议，知道我们之前都在那里
- 这将打开一个非常诚实和前期的雇主/雇员关系的大门
也许你应该为你的公司制定一个可接受的编码标准的“清单”。 例如，你可以包含这样的一些东西：
- 每种方法都有文档logging，并遵循C＃/ Java /标准。 你可以通过提供相关的链接来执行这些标准，所以他知道在哪里看。
- 每种方法都是清晰和高效的。 这有点主观，但是这是一个核对清单项目，当你检查他的代码时，给你讲话点数，这将帮助他看到他需要改进的地方。
- 每种方法都会引发适当的exception。 如果你在devise中定义自定义的exception（一般来说是一个好习惯），确保他正确地使用它们。
- 没有代码冗余。 确保将通用代码分解为辅助方法等
- 技术使用得当。 例如，如果你看到他为一个string写一个“substring”方法，他应该知道在string类中使用substring方法，而不是重新发明轮子。
关键是，通过一个清单/记分卡，它给了你一个更主观的审查他的代码的方式，并为他提供了宝贵的意见，如何改善。
而且我认为这会帮助你“把手放在键盘上”:)。
祝你好运。
- 不要随着时间对他施加压力。
- 尽可能分解任务 – 事实上把事情分解成你能想到的最小的步骤
- 不要指望他给出有用的时间估计
- 有代码审查。 查看代码并给出良好的反馈。
鼓励他，当你可以。
对你想要导师的荣誉。
从学校出来的孩子没有任何有用的小组发展技能，也从来不需要编写需要维护的代码。 这是一个很大的步骤，但应该在一个月或更短的时间内克服。
主要的问题是为他所要完成的工作设定期望值。 如果他知道他会对所有事情进行检查，并且与质量保持一致，那么他最终应该排在最后。
如果他不那么还有其他问题，你必须解决。
祝你好运
在这里有很多好点子，所以我只是添加一点。
我是代码审查的忠实粉丝，但是当你处理新手编码时，你在代码中发现的“问题”数量可能会很大。 我倾向于检查代码，然后与其他开发人员一起阅读笔记。 我非常小心地把真正的问题和“迂腐的废话”（我把它贴上标签，在这里没有评论，这是错误的命名风格，find一个更好的名字等等）分开。
也愿意做出单调的折衷。 公民身份是重要的，所以如果菜鸟增加了一个类名只是好的，但你可以考虑一个更好的考虑，让他们保持自己的名字，使他们觉得自己“拥有”了系统的一部分。
哦，如果你正在审查他的代码，让他也审查你的。 ;）
- 给他们个别的，明确的，一口大小的工作。
- 让他们知道为什么每个块是必要的。
- 开始他们两个块，所以他们可以select下一个工作。 当他们学会处理多任务时，给予他们更多的时间，给他们每个人的优先权和粗糙的期限。 确保他们有买入; 他们需要感觉每个截止date都是合理的。
- 就个人而言，我倾向于给所有新开发者一个“实用程序员”的副本。
每过一段时间，我都会努力工作，努力工作，而这是行不通的。 哪一个人会同意，但统计上，它发生了; 在某个时候，学习何时切断电源并寻找新的开发者。 我倾向于等待太久，这导致了所有参与者更多的压力。
我肯定会减less时间估计的要求。
对于那些手头没有经验的新手来说，没有一般的发展经验，也没有系统帮助他们进行任何合理的估计，这几乎是不可能的。 在这个“真实”的世界里，他需要训练和经验，甚至是明智的。
这在本质上是非常一般的，可以和其他人一起使用。
虽然这听起来很明显，但面对这个人（以一种很好的方式，但有足够的坦率的启发）。 首先，问他们是否希望提出意见和改进意见，如果他们不这样做，你就完成了。 如果他们这样做了，那么你是积极的一面，你知道你所看到的，让他们坦率地知道你所观察到的，并询问他们是否希望在这些领域的每个领域提供具体的意见。 总是让他们知道，每个人从一开始就开始，这个行业总是在学习 – 试图find一些积极的，他们可以很早与你分享 – 你会发现这将把重点放在“共享和沟通”，而不是独裁和专制的风格，你也学习的东西也！
请记住，开放沟通是真正的目标 ，反过来又会导致产品和性能质量状态的改善。 这是一个具有大量人格types的行业，这是具有挑战性的。
你提到了FogBugz。 如果你正在使用EBS，那么询问他的估计值应该在不太长的时间内计算出来。 我想把我的投票加到“给他一小块离散工作”的选项上。
我有一个开发人员真的很难跟上要求，避免增加“奖金”function。 我知道这不是一回事，但我认为解决scheme可能会有所帮助。 我们每两个小时聚会15分钟，回顾一下他做了什么，他做了什么，他下一步做什么，以及他计划如何做。 它工作得非常快，在几个星期之后，我们能够开始把时间间隔延长到四个小时，然后每天，最后在每个多天的任务之后。
我认为最主要的是，正如其他人所说，你知道双方都有问题，并且在这里寻求帮助来解决双方:-)
我会开始实施testing驱动开发。 然后，你可以给他一个要求列表，或者如果你感觉真的很好，一个testing列表，然后让他把它撕碎。
我也删除了“要求所有公众成员的意见”。 因为他可能试图在评论中思考一些聪明的东西，而不是真正的编码。 很快，你会开始对你的公共成员发表评论，说当代码做别的事情时。
我认为结对编程也往往是在这些情况下的优势。 你需要更多的同行（同级别的人）来做编程，因为你最终会给他编码方面的经验。 通过结对编程，双方都应该获得好处。
你如何分配新的开发人员任务？ 你是否期待他只是从你的迭代中抽出一些东西，然后去城里呢？ 如果是这样，暂时不这样做可能会有帮助。 挑出一个有趣的小任务 – 要么作为迭代中任务的一部分，要么作为迭代中的子任务。 为他提供他需要实现的每一条信息 – 包括将方法和（如果你正在使用）进行unit testing，以确保其工作。 确保所有的东西都写好了，然后和他见面，看看他需要做什么。
如果他有，可以每天回答问题。 不要在这个事情的最后期限上立即按他 – 只要跟踪他在这个任务上取得的进展。
完成后，检查他做了什么。 build议他需要做的改变。
一旦过去了，慢慢开始增加你给的任务的复杂性。 也许下一个任务将解决多个层次，或者将涉及添加更多的参与function – 您的具体环境将决定这一点，您的经验也将如此。
这里肯定有学习曲线。 每个人都会以不同的方式来解决这个问题，你的工作是（a）让他保持这样的曲线，并且（b）如果他能够跟上，就向上推荐。
这是我的观点请纠正我如果我错了作为首发，学生期望有一定水平的训练…这是因为他会听说他的朋友正在接受其他公司的训练，并且performance更好…..在这种情况下，你需要让他觉得网站是他唯一的指南….而且你需要帮助他一点，理解一些东西……因为尽快上大学有点难消化版本库工具，框架和其他东西…既然他现在没有接受过这方面的培训，而且你直接把他放在一个项目上，那么他就很难理解事情了…..给他一些时间，让他了解事情。 …直到他意识到自己有责任，那么我觉得事情会变得更顺畅……..
代码审查和配对编程（让他打字!!）绝对是一个好主意，是一个很好的时间来传授你喜欢的编码风格/语言特性，他可能不熟悉/改变他所有的键盘绑定。 你也应该利用这些机会去参观你的代码库，向他展示与他正在工作有关的有用的类或模式。
我还build议在指定新function/错误时，与他进行白板对话。 试着问他如何满足各种要求的问题，或者他是否认为有任何缺失的要求/非要求。 尽量让他尽可能多地提出devise，尽pipe你已经想到了一个好的devise。 通过这种方式，你可以评估他独立思考的能力，同时还提供devise指导，他会更加适应这个过程。
目前我的工作也有类似的问题。 我正在做以下
- 通过电子邮件将他链接到有用的在线video（例如Google干净的代码）。
- 同行审查他所做的一切。
- 我最近开始确定他正在评估方法和类，以及他们在开始编码之前的职责，帮助他思考他正在做什么，并确保每个方法和类只有一个责任。
- 为他提供书籍阅读（例如Code Complete坐在我的书架上）
- 提供补充而不是让他失望，在哪里我需要指出是怎么回事，是build设性的。 我们都很年轻，经历过一次
首先，他应该阅读正在使用的语言的完整教程和一本好的软件书，如“完成代码”。另一个重要的方面是，他必须知道工作是什么，他为什么要做这个工作，什么是那里的大图。 那么他必须给他一个印象，就是他可以提出任何问题，也可以自己去寻找。
