【作为软件工程师,引发的思考】

1.我还是不太了解

“你怎么会不知道BGP是什么?” “你从来没有听说过 Rust?” 我们大多数人都听过这类言论,而且可能听得太频繁了。我们中的许多人热爱软件的原因是因为我们是终身学习者,在软件中,无论你朝哪个方向看,知识的广阔视野都在向各个方向延伸,并与日俱增。这意味着你可以在自己的职业生涯中度过数十年,但与在看似相似的职位上度过数十年的人相比,仍然存在巨大的知识差距。你越早意识到这一点,你就能越早开始摆脱冒名顶替综合症,转而乐于向他人学习和教导他人。

2. 软件最难的部分是构建正确的东西

我知道这在这一点上是陈词滥调,但大多数软件工程师不相信这一点的原因是他们认为这贬低了他们的工作价值。我个人认为这是无稽之谈。相反,它凸显了我们工作环境的复杂性和非理性,这加剧了我们的挑战。你可以设计出世界上技术上最令人印象深刻的东西,然后却没有人愿意使用它。一直在发生。设计软件主要是一种倾听活动,我们通常必须既是软件工程师,又是通灵者,又是人类学家。投资这个设计过程,无论是通过专门的用户体验团队成员还是仅仅通过自我教育,都将带来巨大的回报。因为如何真正计算构建错误软件的成本?这不仅仅是损失了工程时间。

3.最好的软件工程师像设计师一样思考

优秀的软件工程师会深入思考其代码的用户体验。他们可能不会用这些术语来思考它,而是考虑它是否是外部 API、编程 API、用户界面、协议或任何其他接口;伟大的工程师会考虑谁将使用它、为什么使用它、如何使用它以及对这些用户来说重要的是什么。牢记用户的需求确实是良好用户体验的核心。

4. 最好的代码是没有代码,或者不需要维护的代码

我想说的就是“程序员会编码”。你问任何职业的人如何解决问题,他们都会在他们擅长的方面犯错误。这只是人性。大多数软件工程师在编写代码时总是会犯错误,尤其是当非技术解决方案不明显时。对于不需要维护的代码也是如此。当很多轮子已经存在时,工程团队很容易想要重新发明轮子。这是一个平衡的行为,有很多理由来发展你自己的,但要小心有毒的“不是这里发明的”综合症。

5. 软件是达到目的的手段

任何软件工程师的首要工作就是交付价值。很少有软件开发人员理解这一点,更不用说将其内化。真正内化这一点会导致解决问题的不同方式,以及查看工具的不同方式。如果您确实相信软件服从于结果,那么您将准备好真正找到“适合工作的工具”,而这可能根本不是软件。

6.有时你必须停止磨锯子,而开始切割粪便

有些人倾向于直接陷入问题并开始编写代码。其他人往往想要研究又研究,但却陷入分析瘫痪。在这种情况下,请为自己设定一个截止日期,然后开始探索解决方案。当您开始解决问题时,您将很快学到更多知识,这将引导您迭代出更好的解决方案。

7. 如果你不能很好地理解宇宙的可能性,你就无法设计出一个好的系统

这是我经常遇到的问题,因为我的责任让我在软件工程的日常工作中越来越远。跟上开发者生态系统的步伐是一项艰巨的工作,但了解什么是可能的至关重要。如果您不了解给定生态系统中什么是可能的以及什么是可用的,那么您将发现不可能为除了最简单的问题之外的所有问题设计合理的解决方案。总而言之,要警惕那些很长时间没有编写任何代码的系统设计者。

8. 每个系统最终都会很糟糕,克服它

Bjarne Stroustrup 有句话说:“只有两种语言:人们抱怨的语言和没人使用的语言”。这也可以扩展到大型系统。没有“正确”的架构,你永远无法偿还所有的技术债务,你永远无法设计出完美的界面,你的测试总是太慢。这并不是让事情变得更好的借口,而是一种为你提供视角的方法。少担心优雅和完美;相反,努力持续改进并创建一个让您的团队喜欢工作并可持续地创造价值的宜居系统。

9. 没有人问足够的“为什么”

抓住一切机会质疑“一直以来做事的方式”的假设和方法。有新的团队成员加入吗?注意他们困惑的地方以及他们提出的问题。有一个没有意义的新功能请求吗?确保您了解目标以及推动此功能需求的因素。如果你没有得到明确的答案,请继续问为什么,直到你明白为止。

10. 我们应该更关注避免 0.1x 程序员而不是寻找 10x 程序员

10 倍程序员是一个愚蠢的神话。认为某人可以在一天内完成另一位有能力、勤奋、经验相似的程序员在两周内可以完成的工作的想法是愚蠢的。我见过程序员编写了 10 倍的代码,然后你必须修复它 10 倍的次数。某人成为 10 倍程序员的唯一方法就是将他们与 0.1 倍程序员进行比较。有人浪费时间、不寻求反馈、不测试代码、不考虑边缘情况等等……我们应该更关心如何让 0.1 倍程序员离开我们的团队,而不是寻找神话般的 10 倍程序员。

11.高级工程师和初级工程师之间最大的区别之一是他们对事情应该如何发展形成了自己的看法

没有什么比高级工程师对他们的工具或如何构建软件没有意见更让我担心的了。我宁愿有人给我我强烈不同意的意见,也不愿他们完全没有意见。如果您正在使用您的工具,并且您在很多方面不喜欢或讨厌它们,那么您需要体验更多。您需要探索其他语言、库和范例。积极探索其他人如何使用与您不同的工具和技术来完成任务,没有什么比这更快地提高您的技能了。

12.人们并不真正想要创新

人们经常谈论创新,但他们通常寻找的是廉价的胜利和新奇的事物。如果你真正进行创新,并改变人们做事的方式,预计大多数都是负面反馈。如果你相信自己正在做的事情,并且知道它确实会改善事情,那么就做好长期战斗的准备。

13.您的数据是系统中最重要的部分

我见过很多系统,其中希望是数据完整性的主要机制。在这样的系统中,黄金路径之外发生的任何事情都会产生部分数据或脏数据。将来处理这些数据可能会成为一场噩梦。请记住,您的数据可能会比您的代码库更长久。花费精力保持秩序和清洁,从长远来看会得到很好的回报。

14.寻找技术鲨鱼

一直存在的旧技术是鲨鱼,而不是恐龙。他们能够很好地解决问题,从而在技术世界不断发生的快速变化中幸存下来。不要对这些技术下注,只有在有充分理由的情况下才更换它们。这些工具不会很华丽,也不会令人兴奋,但它们会完成工作,而无需很多不眠之夜。

15.不要把谦逊误认为无知

有很多软件工程师除非被要求,否则不会表达意见。永远不要仅仅因为某人没有当着你的面提出自己的观点,就认为他们没有什么可补充的。有时候,最吵闹的人是我们最不想听的人。与周围的人交谈,寻求他们的反馈和建议。你会很高兴你这么做了。

16.软件工程师应该定期写作

软件工程师应该定期写博客、写日记、写文档,以及做任何需要他们保持敏锐的书面沟通技巧的事情。写作可以帮助您思考问题,并帮助您与团队和未来的自己更有效地沟通这些问题。良好的书面沟通是任何软件工程师需要掌握的最重要的技能之一。

17. 尽可能保持流程精简

如今每个人都希望变得敏捷,但“敏捷”就是小块地构建事物、学习,然后迭代。如果有人试图强行塞入更多东西,那么他们可能正在出售一些东西。这并不是说人们不需要问责制或帮助来以这种方式工作,但是您有多少次听到来自您最喜欢的科技公司或大型开源项目的人吹嘘他们的 Scrum 流程有多么出色?保持精益流程,直到您知道您需要更多。相信您的团队,他们会交付。

18. 软件工程师和所有人一样,需要有主人翁感

如果你将某人与他们的工作成果分开,他们就会不太关心他们的工作。我认为这几乎是同义反复。这是跨职能团队运作良好以及 DevOps 如此受欢迎的主要原因。这并不全是交接和低效率,而是掌控从开始到结束的整个流程,并直接负责交付价值。让一群充满热情的人完全掌控设计、构建和交付一个软件(或任何真正的东西),神奇的事情就会发生。

19. 面试对于判断一个人的团队成员有多优秀几乎毫无价值

最好通过面试来了解某人是谁,以及他们对特定专业领域的兴趣程度。试图弄清楚他们将成为多么优秀的团队成员是徒劳的。相信我,一个人有多聪明或知识渊博也并不能很好地表明他们会成为一名优秀的团队成员。没有人会在面试中告诉你他们会变得不可靠、辱骂、浮夸或从不准时出席会议。人们可能会声称他们对这些事情有“信号”……“如果他们在第一次面试中询问请假,那么他们永远不会去那里!” 但这些都是废话。如果你使用这样的信号,你只是在猜测并拒绝优秀的候选人。

20. 始终努力构建更小的系统

有很多力量会推动您预先构建更大的系统。预算分配、无法决定应该削减哪些功能、渴望提供系统的“最佳版本”。所有这些事情都非常有力地推动我们建造过多的东西。你应该对抗这个。当你构建一个系统时,你会学到很多东西,最终你会迭代出一个比你最初设计的更好的系统。令人惊讶的是,这对大多数人来说是很难推销的。

原文点我查看

猜你喜欢

转载自blog.csdn.net/Cavin80/article/details/133930167