最近我为一个内核程序员的职位面试了十几个候选人。这些候选人都来自一些不错的大公司,这些公司在芯片或嵌入式操作系统领域十分有名。这些候选人大多声称自己在内核方面有着十年的在职工作经验。他们的简历看起来非常耀眼——各种相关的项目、术语和奖项…… 但他们几乎无人能够回答一个非常基础的问题: 当我们调用标准的 malloc 函数时,内核中会发生什么? 先别吃惊。当我要求其中一位候选人基于 glib 的哈希函数写一个简单的 LRU 缓存框架时,他先是表示从来没用过 glib——这正是我所预料的——于是我帮他打开了 glib 哈希 API 的页面,并向他详细讲解了这些 API;然后大约一个小时以后,他只写出几行凌乱的代码。 我不知道其它国家是否也有类似的情况,但在中国,或者更精确一些,在北京,这就是现状。那些在不错的大公司里工作了多年的“资深”程序员们无法在一些简单的、基本的问题上证明自己。 这到底是怎么回事 当我在这个问题上思索得越多,我就更加相信,这不仅有他们自身的原因,同时也归咎于他们所供职的这些公司。这些公司通常提供了一个稳定的代码堆,往往几年都不会有大更新。这些代码的专有技术把人们的技能框进一个定式,以致于他们只需要遵循现有的路径,而不需要发挥创意。如果你碰巧为这类代码工作,而且与世隔绝了很长一段时间,那么有一天你会发现你自己已经陷入一个可悲的位置——他们在团队或公司内称呼你为 “ 专家 ”,但不幸的是,你无法在市场上找到一份同等待遇的工作。 这就叫作 “ 专家陷阱 ”。日复一日,程序员们都渴望在团队或公司内成为一名专家;但是,当那一天真正到来时,我们却早已作茧自缚。我们在既有代码中钻得越深,我们自己就陷得越深。既有代码是如此稳定(如此宠大、如此好用),让我们渐渐地失去了从无到有独立编写完整项目的能力。更糟糕的是,如果我们的主要工作就是维护这些既有代码、很少开发新功能,那么过不了多久,无论研读了多少代码,我们都会发现自己不会写代码了——哪怕是一个像毕业大作业那样简单的任务。这就是程序员的困境: 我们以编码为生,但那些养活我们的大公司却在无形中磨灭了我们的生存技能。 如何打破这种困境? 对于个人: 首先, 打造你自己的私人项目。你需要不断地打磨自己的技艺。如果工作本身并不能帮助你做到这一点,就捡起那些你感兴趣的问题,然后用你的私人时间去攻克它。通过这个方法,你应该会学到新东西。如果把你的私人项目发布出去,比如在 GitHub 上,你说不定会认识一些人,帮助你大踏步地向前迈进。 不要在一个团队中停留超过两年。强迫你自己四处转转,哪怕在是同一家公司内,你会面对新的挑战和新的技术。试着每隔 18 个月就出去面试工作。你并不需要真的换工作,但是这能让你看到真实的市给予员工压力和挑战。实行轮岗制度,让“专家”们有机会拓展他们的技能。启动新项目,用战役来磨炼你的勇士。 对于团队和公司: 给予员工压力和挑战。实行轮岗制度,让“专家”们有机会拓展他们的技能。启动新项目,用战役来磨炼你的勇士。 周期性地举办***马拉松活动。这有助于营造一种崇尚创新和创作的企业文化,人们会受到同伴的激励——“擦,这个混蛋居然可以在 24 小时内写出这么漂亮的框架,我也得加把劲儿了!” 那么对于这种现象,微博上又有哪些互动呢?让我们一起来看下: 皮皮彭: 这是大公司的通病,不仅仅是针对做技术的,其他任何职位也是一样。公司大到了一定规模,很多事情就变得复杂了,不是那么纯粹了,很多人因此就会忘记了自己人生真正的目标和追求是什么,到底是要创造出好的产品,还是为了完成某个任务?个人内心保持追求,公司层面力求简化和纯粹,是最重要的。 非常同意文中的观点,在技术日新月异的IT行业,“专家”这个词其实是个危险信号,意味着你的知识距离老化不远了。IT工程师应该经常更换工作领域,了解多个领域的前沿问题,同时应该花一些时间在开源项目上。 这个叫体制化。和电影里说的道理一致。但也看你在公司的啥部门,如果在基础部门或参与开源,这可以避免。当然从公司看,这样人也需要。 为什么大公司是这样,那是只有大公司有能力和时间会把底层不变的技术形成框架,让开发人员针对每天都在变的需求进行开发。那些在大公司写内核底层的,是不会出现在人力市场的,早已都是大公司的管理人员了。 对此,各位程序员,你们又是持何种观点呢?本文作者主要描述了程序员在大公司所面临的问题,你们身处的环境如何呢?不妨和我们一起分享下吧。 英文原文:Programmer’s dilemma |
转载于:https://blog.51cto.com/hongyu0621/1279283