我在Twitter上看到了一篇有趣的博文——你可以先看看。如果你懒得上Twitter看，看我转载这篇的就行了。
有一天我和我的朋友Simone一起喝咖啡，期间我们聊起一些工作上的事情。我们俩都管理着一些员工，为了说明给初级职员分派任务时出现的问题，她打了一个绝妙的比方。
这就像你让他们挂一幅画，但他们从来没有干过这样的活。你明白你要做什么——只要让他们这么做就行了。事实上，你认为有些东西不用解释，因为你觉得它们太简单了。所以，你让一些新手来为你工作时，你说，“把这幅画挂在那里，做完了告诉我”，很好理解，对不对？但他知道应该怎样钉钉子吗？实际上，有很多细节他不清楚，他需要学习才能把画挂好。另外，还有很多东西你容易忽略。
首先，是怎么做。他需要什么工具？你知道工具箱里有锤子和钉子。但他不知道，他认为他有合适的工具完成任务。于是他在办公桌上找到了一个订书机和胶带。
现在他有两种方法完成任务。他可以做很多小的胶带圈，这样它们可以固定在墙上，然后把它们钉在画的背面。这种方法看上去可能没事，但是只有画掉下来的时候你才知道他做错了。另一种方法是，他把一大条胶带缠在画上，并且把它用订书机牢牢钉在墙上。用这种方法的结果可能更糟，虽然和你的要求差不多——画挂好了，但是画面被遮住了。只要有足够的订书钉，画就能挂住。但是这样太难看了，而且也不是你想要的挂法。如果你不及时制止他，他可能会继续用这种方法挂画。
还有一种可能的情况，特别是对那种急性子的初级程序员来说。当你的老板来问你射钉枪的采购订单时，你才发现他这样做了。于是你叫来你的下属了解情况，发现他上周一直在google上搜索，阅读参考书，并向讨论组求助。他知道你想把画挂在墙上的钉子上，并且认为钉钉子的工具是高级气动射钉枪。如果他能接受你的意见，你得指出挂图和装修用的钉子是不一样的，并且告诉他工具箱里的锤子才是真正适合做这件事的工具。要是他还固执己见，就可能会有像下面这样的争吵了：
“为什么不能买射钉枪？”
“因为没有足够预算。”
“难道就没法做好一件事情吗？”
“你可以用锤子钉钉子。”
“可是我们不是应该更快更好地完成工作吗？难道我们用锤子的原因只是因为用习惯了它？眼光应该放远点。”
“我们没有足够的时间证明买射钉枪是对的。明白吗？”
最后双方不欢而散。
现在，你觉得你把工具的问题说得够清楚了。他也拿到了锤子和钉子，开始了他的工作。问题是，他还应该知道如何有效地使用它们。对你来说熟练使用锤子是轻而易举的事情。但是对以前从未见过锤子的人来说，它看上去似乎只有一种用法。事实上，你可以用锤柄末端。你还可以用爪形部分夹住钉子，然后把它钉进墙里，而不必在大力钉钉子时用手拿着钉子。
站在木工的角度来看，这似乎有点低级，但它反映了使用软件工具时的实际问题。一个软件往往提供很多参考文档，但范例和习惯用法却不多。你可以买一本一千多页的参考书，它告诉你用一个软件可以做些什么，却没有哪怕仅仅5页内容来说明在你的实际情况下你该怎么用它。就算你有一个实例，它们也不告诉你为什么要用这种方式运行。读完本文之后，你就不会再纠结钉钉子是用锤子还是射钉枪了。
我刚开始使用XML时就遇到了这种情况。我读过的帮助文档里这样说过，“用SAX解析器读取XML文件，不要用DOM解析器。DOM解析器运行速度很慢，并且占用内存过多”。后来我问过其他人，“为什么不行呢？难道DOM解析器执行效果很差吗？”
他说:“并非如此，但如果你只想获得作者和标题信息你何必加载一个10M的文件呢？”
“啊，是这样，我想把一个20K的文件内容发布为一个网页。”
“那你还是用DOM解析器吧。”
此外，还可能会出现数据交互问题。现在你的下属知道怎么钉钉子了，他做的第一件事情是在画框上钉一个钉子。
天哪！！！
“不不不，你没看到画框背后的绳子吗？你应该把钉子钉在墙上，然后把绳子挂上去。”
“哦，我不知道它有什么作用。不过你只钉一个钉子？多钉几个不是更安全吗？比方说钉6个。”
“用一个就足够了，钉子多了反而不好调整。”
“为什么要调整呢？”
“你得把画挂正吧。”
“哦？要挂正吗？”
唉，又没说清楚。
现在我们开始讨论更高层次的设计问题。画应该挂在哪里？应该挂多高？他没法决定。如上文所说，它没有你想得那么简单。
你明白画不能挂在门边，因为开门时会挡住它。它也不能挂在那边，因为你要把新书柜放在那。或许你的天花板有14英尺高，画只是用来让这个大房间显得不那么空荡。也有可能这是你和“猫王”的合影，有人坐在你办公桌前的时候你可以显摆显摆。如果它是一张老照片，你必须确保它不会受阳光直射。这些都是“业务规则”。虽然你挂画的方式大同小异，但你必须考虑它们。
也有些业务规则会影响你的决策。如果画比较贵重，你得想办法把它保护好，比方说把它挂在比较难够着的地方。如果它价值连城，你得用两英寸厚的玻璃来保证它的安全，周围还得装上警报系统。要是你打算用来挂画的那堵墙非常结实，你得用钻头才行。如果墙本身比较值钱，你还是暂时打消挂画的想法吧。
这些规则可能有些道理，但它们并非那么显而易见。一些在某种情况下正确的方案在其它情况下不一定是对的。你只能通过你在房间里挂画的经验来了解它们。另外，你还得考虑哪些规则可能改变。你确定要把画挂在这吗？这幅画会被移到别处吗？它会不会被换成另外一幅画？新的画和原来那幅还是一样大吗？
别指望新手会考虑这些。你可以适当指点他一下。你的任务是尽可能多地告诉他工作的细节。如果他聪明，好奇，他会提问，并了解这样做的来龙去脉。不过这需要时间。
如果你没有给他足够的信息，他会试着猜测。前面提到的急性子的程序员这时可能就不顾规则了。你告诉他把你的宠物狗照片挂起来，一周后他回来了，问你要不要再考虑考虑他关于石膏锯的建议。
“你为什么会想到石膏锯呢？”
“办公室的工具箱里只有木锯，不太适合锯石膏板。”
“什么？你认为只有你想锯石膏板吗？你可以在Home Depot上买一个锯子。”
“那么，好吧，我去买一把。”
“等等，你怎么会想到锯石膏板？”
“是这样，我不知道挂画最好的方式是什么，所以我上网找了讨论组里的画廊设计师。他们说，最好的方法是锯穿墙壁，做出一个框架。把画从后面放进去，这样能够保证玻璃的安全，因为你不必动它。而且这种方法比钉钉子更加美观。”
“...”
这个比喻可能有些不太切题，不过请相信我——它非常有参考价值。如果你的职业生涯中还没有遇到此类事情，你可以先看看它。
关键是，从细节技术层面到整体效果层面，有很多东西你必须知道。不能让一个新手随意猜测，不管他有多聪明。而且这和聪不聪明没关系，一切都要根据实际情况决定。可能你和他们一起工作太久了，你忘了你也有一段时间不知道这些。但是你必须详细地描述你的要求，方便他们提问。
仅仅是这样吗？
这让我想起了《帝国反击战》中我最喜欢的场景之一：Luke Skywalker遭受了失去亲人的打击，他一直在寻找自己隐秘的身世。后来他跟随绝地大师Yoda学习如何成为绝地武士。但是Luke想学的东西Yoda却没有教他。实际上，观众们认为，Luke似乎并不了解绝地武士应该是怎样的，毕竟除了和Ben Knobi一起学习的时间，他几乎没有任何这方面的经验。而他之前并不知道Kenobi是绝地武士，直到他亲眼目睹Kenobi在战斗中牺牲。
这是这个场景中令我印象最深的画面：
LUKE：师父，移动石头很难，它和我以前学的完全不一样。
YODA：不，没有什么不同。只是你认为它们不同罢了。你必须忘掉你所学的。
LUKE：（静静地集中精神）好吧，我试试看。
YODA：不，别老想着只“试试”。要么做，要么就别做。
而《帝国反击战》和上文挂画的例子有什么联系呢？
初级程序员们应该“忘掉”他们觉得自己已经知道的东西，然后重新学习他们需要的东西。
刚走出校园的程序员有两种类型：他们要么干劲十足，随时准备改变世界；要么他们胆小如鼠，不敢抓住机会或者尝试有风险的东西，生怕被炒鱿鱼。
第一种程序员，也是我非常担心的一种。他们自认为他们知道要做什么，并且在google和互联网上搜索他们需要的资料——他们会为了挂画把墙锯开。或者他们会因为射钉枪和你争吵，因为他们觉得那是对的：射钉枪钉钉子的效率更高。实际上他们错了，因为射钉枪没法控制钉钉子的力量（它会把钉子整个钉进墙里），并不适合挂画。
另外一种就比较不幸了，他们没法被用人单位接纳。因为他们缺乏工作的主动性，所以他们没法真正学到什么东西。他们只能做简单的拼写检查或是类似于行政助理的工作，甚至有可能一辈子都耗在HTML网页上。他们会抱怨，厌倦这份工作，最后跳槽到邮政行业，市场销售行业（也许更糟，做个推销员）。不管怎样，这对他们没有好处。
这不得不让我深思：初级程序员应该做些什么呢？如何让一个程序员从入门到精通？初级开发人员应该怎样避免向这两个极端发展呢？
结论就是：初级程序员们必须学会“问”。问了，就必定会有收获。
看看急性子的初级程序员的例子：如果他敢于发问，“老板，我从来没挂过画，我该怎么做？”，就不会有射钉枪、胶带、石膏锯这样的问题了。作为一个过来人，你应该知道他没有你那么经验丰富。
老手们没法了解新手们不会什么。但是帮助他们意识到“哪些不会”是非常重要的。这种关系就好比之前提到的绝地大师和绝地学徒之间的关系，也可以说是西斯领主和西斯学徒的关系，或者是千百年来人类历史上的各种师徒关系。
最关键的一点呢？
从某个角度来说，我们都是初级程序员。就算你有四十年各平台和嵌入式系统的C++开发经验，但涉及到关系数据库（或是Nosql，或是Java和JVM，或是C#和CLR）的时候，你就是一个初级程序员。再换句话说，关于原力和拯救宇宙（包括一个后来你才知道是你妹妹的漂亮女孩）的绝地武士，你依然是个新手。
现在你知道该怎么做了。
为你自己找一位老师（也许现在更准确的说法应该是“导师”），向他们学习或是提问是非常有用的。然后，反过来，让你的同事或是朋友中的初级程序员也这么做；他们不一定会接受你的帮助，但仔细想想，你在这个年纪的时候，不也希望有一位大师来教你吗？
你是想成为爱抱怨的Luke Skywalker还是想成为绝地武士Luke Skywalker呢？Luke失去了一只手之后才明白Yoda远远比他聪明，应该多请教他，而不是告诉他“你做错了”。
如果你不想让项目出错，还是老老实实承认自己不是无所不能吧。如果你想让你的项目更加出彩，不妨考虑一下我的建议。
原文链接：http://blogs.tedneward.com/2012/03/21/Unlearn+Young+Programmer.aspx
原文地址：http://blog.csdn.net/u012138153/article/details/46326755
