那些没体会过的风景|别把自己当个超人——给初级程序员的一点小小建议

我在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

    推荐阅读