经验之谈

二十年老程序员的二十条心得:面试几乎没用,警惕很久没写过代码的“大牛”

务必警惕那些已经很久没写过代码、也没设计过系统的所谓“大牛”。 站在巨人的肩膀上当然更容易成功,所以我们才会希望行业前辈能给出一些有意义的建议。今天这些建议来自一位有二十年行业经验的软件工程师,他的总结在 Hacker News 上引发了大量的讨论,帖子多天来一直占据“热榜”第一。   Justin Etheredge 最初在各类小型和初创企业中担任软件工程师,之后进入了咨询行业并开始为大型企业服务。Justin Etheredge 表示过去二十年以来的经历塑造了他对于软件的理解,并产生出一些坚定的信念。他把这些信念整理成一份明确的清单,希望能为大家带来一点帮助与启发。   引起网友激烈讨论的二十条建议:   1. 我懂的并不多  “你怎么会不知道什么是 BGP?”“你难道没听说过 Rust?”   类似的问题可能每天都会出现在我们面前。没错,投身于软件行业的很多人之所以热爱这份工作,就是因为它敦促着我们终身学习。   在软件领域,无论我们朝哪个方向前进,都有着广阔的知识空间不断延伸而且每一天都有所变化。换句话说,这是一份能够承载我们度过几十年的职业生涯,而两位在类似岗位上分别工作了几十年的人之间也很可能存在巨大的知识差距。我们越早意识到这一点,就能越快摆脱“冒充者综合症”,成为一个乐于向他人学习、也乐于教导他人的积极分子。   2. 软件里最难的部分,是构建正确的东西 我知道这种话大家肯定听过无数遍了,但大多数软件工程师仍拒不承认,理由是这种说法似乎在贬低他们的工作成果。我个人觉得这样的心态大可不必,这类表达其实是在突出软件开发环境中的复杂性与非理性因素,而这些都会加剧我们面临的挑战。我们当然可以设计出在技术上最令人印象深刻的东西,但却没人愿意用——这类困境随时都会出现。   软件设计主要是一种聆听活动,开发者往往身兼软件工程师、通灵师乃至人类学家等多重角色。而我们对这种设计能力的每一点投资,无论是引入专业的用户体验师还是接受更进一步的自我教育,都能给开发成果带来巨大提升。毕竟与打磨设计能力相比,开发一款“没人用”的软件成本还是太高了、太高太高。   3. 顶尖软件工程师会像设计师那样思考 伟大的软件工程师会深入思考代码成果的用户体验。虽然使用的术语或者切入点不同,但无论是对于外部 API、编程 API、用户界面、协议还是其他接口,优秀的工程师都会考虑由谁来使用、为什么要使用、如何使用以及对用户来说哪些因素真正重要等。总之,牢记用户需求才是实现良好体验的核心所在。   4. 最好的代码就是没有代码,或者说不需要维护的代码  “程序员就是管编程的”,而且跟其他专业人士一样,我们也会在自己最擅长的方面犯错。这是人的本性,没办法。大多数软件工程师编写出的代码总是有点错误,而且往往无法用非技术方案来解决。   另外有一种很神奇的现象,越是有大量相当成熟的解决方案存在,工程团队就越是想“重新发明轮子”。想表达自我、加快专业成长当然是好事,但还请大家分清场合与需求,过度泛滥的发明欲望恐怕不利于编写出无需维护的代码。   5. 软件是达成目的的手段 任何一位软件工程师的主要工作都是交付价值。但我发现大部分软件开发者并不理解这一点,能够将这个理念内化进日常工作的开发者就更少了。但只要能够完成内化,我们解决问题的方式、看待工具的角度都会有所变化。如果您真心相信软件要服从于结果,那就一定能找到“真正适合工作的工具”,而这种工具也许压根就不是软件。   6. 有时候,你压根没时间磨刀 都说“磨刀不误砍柴工”,但刀磨久了反而让人心浮气躁、难以投入真正的工作。代码编写也是一样,研究多了容易让人陷入“分析瘫痪”。   一旦出现这种状况,请马上给自己设定一个截止日期,之后再探索解决方案。在着手解决问题时,我们很快就能找到思路与线索、引导自己一步步迭代向更好的产出。   7. 如果没法理解所有可能性,就设计不出优秀的系统 这也是我个人一直在努力解决的问题。我的职责变化导致自己距离常规软件工程任务越来越远,我发现跟上开发者生态的发展速度越来越难,有时候自己甚至不理解哪些趋势真正重要。总之,如果不能理解特定生态当中的那些可行性与可用选项,那么我们根本没办法为所有问题找到合理的解决方案。   总而言之,务必警惕那些已经很久没写过代码、也没设计过系统的所谓“大牛”。 8. 每套系统最终都很差劲,要勇于接受这一点 Bjarne

Continue reading

Categories

Please Like Us