Author Archive for: e_volancers

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

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

Continue reading

老是犯同种错误!初阶工程师如何对自己的程序码负责?

经常会看到工程师是用「自己的想像」完成工作,导致成品交出时与客户想法有落差,其实客户想要做的东西并不复杂也并非完全做不到,在呐喊「不可能完成」之前,要先回头检视一下客户想要的「规格」究竟是什么? 本篇来自五倍红宝石资深工程师 RUBY 大叔投稿,INSIDE 经编审刊出。 为了在工作上得以生存,大家都曾经做过哪些努力呢? 前阵子笔者才刚结束一个与外包厂商的合作,执行过程感触良多,每个人在职场上或多或少都有犯错过,但回头检视自己为何做不好,且力求改善的人并不多,很多时候不去做新的尝试,就不会找到新的方法。 今天跟大家聊聊初阶工程师如何提高自己的经验值以及工程师的当责之道是什么? 初阶工程师可能都碰过的问题 我想一定很多人都曾有过在工作上反复犯下同一种错误,或没理解到客户想法而做白工的经历,种种的恶性循环导致自己很疲惫,平常与同事们开会时,也会看到一些现象,如果你是初出茅庐的工程师,可以看看自己是否有这样的问题,如果你只是一般公司员工,这篇文章也有一些想法可以参考。 1. 总是让客户帮你检查错误 当我在面试新工程师时,都会请面试者针对自己写的代码(或作品)做出讲解,但很多面试者解释不出来,甚至没有想过自己为何这样做,只是应付面试基本需求。 作为一名工程师,必须训练自己站在更全观的角度思考自己经手的项目,在递交给客户之前反复确认,而非让客户扮演除错的角色。 有些人或许对自己交出的东西很放心,万一犯错了,如果后果不太严重就会轻忽它,记住,如果想提高自己的工作敏锐度,第一步必须先保持对所有事物的怀疑,包含自己写的代码。 2. 交的东西跟客户想象有落差 经常会看到工程师是用「自己的想像」完成工作,导致成品交出时与客户想法有落差,其实客户想要做的东西并不复杂也并非完全做不到,在呐喊「不可能完成」之前,要先回头检视一下客户想要的「规格」究竟是什么? 大部分人都只想把工作做完而非做好,更别说是花时间与客户做沟通,其实,只要一步步确认好客户要的需求「规格」,善用所学的程序技术测试项目,持续确认、持续验证,就有机会破解难题。 换句话说,想达成客户的需求并不用很高深的技巧而是要用正确的方式实现。 该如何持续累积自己的经验值? 这边想先说一下,现在很多人想投入工程师领域,因此坊间也开了蛮多三个月工程师速成这种课程,并不是说上这种课不好,而是当每三个月就多出上百名工程师的情况之下,个人经验值的累积就更为重要了! 无论你是透过哪一种方式当上工程师,以下这两点希望可以带来一点帮助。 1. 厘清核心与非核心工作是哪些 当接收到工作任务时,很多人会希望一步到位做完再呈现给客户看,除非是对客户的规格相当清楚有把握,否则可能会造成自己花费过多时间在错误的理解上,一开始可以先从最基本的需求「确认」做起,当完成一部分后先让客户验证,以达成迅速对焦及修正。 并非每项任务都要达到自己内心要求的标准才算及格,得认知到核心与非核心功能分别是哪些,再进一步做工作上的轻重比例分配,降低自己心理门槛及压力。 2. 学习难度别调太高,慢慢来比较快 每个人都想在工作岗位上尽早上手,为此,积极的工程师们也愿意多看一些书充实技术,这是非常好的事,不过,有时网络上推荐的书自己当下的状态不一定能看懂,或是作者书写方式跟自己理解事物的方式差异很大,造成难以吸收,网络上也有很多「经典」书籍是适合有经验(或想更进阶)的人去读,初期读的话很容易变成似懂非懂的状态,因此一个好的技术书,应是选择 「适合自己」的。 平常在工作时,也要让自己边做边学,毕竟很多状况没有实际做过就无法了解,逐步找出答案,才能累积对的经验值,就像减肥,也不是直接选择高强度方式就能瞬间瘦身,总是得配合自己的状态行进才能长远有效。 工程师的当责之道即是「职人精神」 所谓的「当责」是指为自己的承诺负责并完成落实,如同我一开始抛出的问句:「为了在工作上得以生存,大家都曾经做过哪些努力呢?」 很多年后,当你回头检视自己,你会成为怎样的工程师,这都可能取决于你的当责之道是什么。 我认为工程师的当责之道就是「职人精神」,就像专业咖啡师磨练自己的技术,专注完成一杯咖啡的态度,工程师也是如此,必须培养让自己在工作上成为职人的境界,进而圆满自己的人生价值。

Continue reading

怎样成为一名更优秀的程序员?

有几个人在 React 大会上向我请教一个问题——如何成为一名更优秀的程序员。人们将我视为一名非常资深的程序员,因此值得听听我的建议。我觉得可以分享一下,自己多年来在编程方面的“思维模式”。 先简要自我介绍一下:我叫 James Long,今年 32 岁,有超过 10 年的丰富工作经验。不过,直到近几年,我才对自己的工作越来越有信心。即使现在,我还是不断怀疑自己。关键是这种感觉不会消失,所以试着忽略它,继续深究技术知识,继续积累经验。 我再次提醒一下,这些只是提高你技能的几点建议。最终,你需要弄清楚自己适合的方式是什么。 1. 找到能激励你的人,但不要崇拜他们 过去许多年,我仰慕过许多人,并且通过他们关注新技术。我相信他们是正确的,并且对他们所做的事情深入研究,因此学到很多。 这些人往往非常高效、才华横溢,并且能鼓舞人心。你要想尽办法找到他们,让他们激励和指导你。 不过,别崇拜他们。如果仅看 twitter 上的贴子,你会觉得他们遥不可及。但是,如果走近他们的真实工作中,你会发现自己与他们相比没什么不同。只不过在到处摸索尝试而已,我们都只是在进行试验。 最后,不要盲目地相信他们。如果你有不同意见,就请他们参与进来,并从观点碰撞的过程中汲取经验。 我的一些最有成效的对话就是这样发生的。曾经,我的 Emacs 配置一团糟。不知道为什么,我的 OCaml autocompletion 不能用了(它坏了一个多月)。我没有自动化的东西,有时必须在 shell 历史中寻找所需的命令。为修复问题,我一开始写 ugliest 代码。我将东西写成全局对象,直到最后才明白我到底做了什么。 最有经验的程序员一直在破解和钻研;最重要的是,你能完成任务,达成目标。 2. 不要贬低自己的工作 程序员小白往往认为他们的工作价值不大,因为他们是新手。或者你可能是一名有经验的程序员,但是在一个新领域工作,这会让你感到不爽。但在我看来,最好的想法往往来自于新程序员,他们可以看到现有技术的改进点,而思维固化的人却看不见。 不管怎样,你的工作都是值得的。最坏的情况是,即使你的想法没有成功,社区也可以从中了解到为什么这种方法行不通。 (给社区的一个提示:这要取决于我们是怎么做的,并让新人很容易融入进来。) 3. 不要因为害怕落伍而不停工作 每天都会有新技术问世,如果你一晚上不碰技术,可能就会感觉跟不上这个世界。这不是真的。事实上,如果经常放下手头工作,你会做得更好,因为你会有新想法。 我发现,当不工作的时候,我总会有新想法不断产生。 实际上,网络上每天发布的内容大多是“新瓶装旧酒”,真正具有革命性的技术每隔几年才会出现一次。关于这个问题,你可以看看这个视频—— Hammock Driven Development 。 4. 忽略 fluff 客观上说,你能取得更快进步的主要方法之一是忽略那些并不能提高技能的“fluff”。换句话说,要“聪明的利用时间”。一天的时间有限,你需要将时间花在钻研更深层次的事情上。随着时间的发展,你会发现自己有很大进步。 那什么是“fluff”?这取决于你自身的具体情况。但是,我可以给你一些我认为是“fluff” 的例子:语言语法、库 API 和配置构建工具。例如,学习一个新的 ES7 JS

Continue reading

Categories

Please Like Us