发布于 2026-01-06 0 阅读
0

辞掉我的第一份工作

辞掉我的第一份工作

这份工作

最近我辞掉了第一份工作,我觉得这是个好时机,可以回顾一下我近两年的网络和移动工程师生涯。我在硬技能和软技能方面都取得了长足的进步。
我希望我的经历能对其他人有所启发,帮助他们发现思维中的误区。

我做了两年的咨询开发人员,主要编程语言是 JavaScript,前端使用 React.js,后端使用 Node.js。
我主要在一个客户公司工作,对于像我这样寻求挑战的人来说,那里简直是天堂。我们开发了很多很棒的产品,但这篇文章我就不赘述了。

硬技能

学习编程相关的课程。

简洁的代码

为函数和变量命名清晰易懂可能是我们日常工作中遇到的最棘手的任务之一。编写小型应用程序时,这听起来很简单,但随着时间的推移或在某些函数中,这项工作就会变得非常繁琐。

在这个过程中,我学到的最重要的一点是:当你对某个名称犹豫不决时,不妨问问坐在你旁边的人。如果这个人看了一眼你的代码都看不懂,那其他人肯定也看不懂。你可以征求他们的意见,并从中吸取教训。下次别人读你的代码时,你就会确信自己已经选好了比最初设想的更好的名称。

评论并非一切

我们可以写十几条评论,但是拜托……谁来更新这些评论呢……我同意评论可以帮助实现某个功能,你可以描述步骤,方便自己和后面的人参考。这样,你就能和需要解决bug或其他问题的人分享你的思路,但这同时也意味着你要信任下一个人会更新你的评论以反映所做的更改。如果没有人更新,下一个人可能会非常困惑。

我完全赞成在复杂函数中添加注释,别误会我的意思,但修改函数时,你应该维护两个地方而不是一个。
我想表达的重点是,首先要确保所有函数都有清晰的名称,只有当名称清晰但函数名称不明确时,才应该开始添加注释。业务逻辑本身就比较复杂,而且不会经常变化,因此值得添加注释。

协同编程

我发现自己最享受的事情之一就是协同编程,但不是那种严格意义上的协同编程。我喜欢大家互相交流想法,比如甲说x,乙说y,然后一起尝试。这样可以了解其他人是如何调试程序和看待错误的。

在解决问题方面,每个人的思维方式都各不相同,即使是像解决问题这样看似合乎逻辑的事情,也有数百种解决方案。这意味着我们可以互相学习,找到更有效的解决方案。

另一个好处是,你会看到一些你平时不会接触到的代码库部分。我自己也注意到过这个问题:有些人不了解我编写的包含大量业务逻辑的代码,这导致他们在处理这些部分时感到沮丧。

软技能

知识评估

我刚开始的时候讲东西特别混乱,总是想当然地认为别人对我说的内容有一定的了解。这大概是最糟糕的假设之一了,我真不知道自己当时怎么会犯这种错误。科技领域有很多我完全不懂的东西,如果有人要给我讲解这些领域的高阶知识,我肯定也听不懂。

然而,这并非罕见的思维误区。我们常常需要做的最难的事情之一,就是把自己置于对话的第三人称视角。评估你正在进行的对话/指导,既要站在接受者的角度思考,也要站在旁观者的角度思考。

我认为这是我近期学到的最有价值的东西之一。它让我能够撰写更好的文档,更好地组织对问题的回答,以及更清晰地表达自己的想法。

严苛是自取其辱。

我一直对自己要求很高,但这往往会导致一些问题。我深刻体会到,这些期望都是自己强加的。你不应该因为别人比你优秀就把自己的期望强加给他们。
把自己强加给自己的期望强加给别人,会让人感到沮丧,甚至害怕提问。如果有人不喜欢问你问题,那就应该敲响警钟了。
我并不是说如果每个人都问你问题你就不应该采取行动,但这应该由你自己来判断。

技术远不止于从事技能型职业,它更关乎沟通和互相学习。与团队缺乏沟通会导致其他人也在处理同一个bug,而你却还在处理。与业务部门缺乏沟通则会导致功能不够完善,发布时往往需要大量修改。

敏捷工作

大学期间,我一直对敏捷开发及其带来的额外成本持怀疑态度。但现在我已经完全改变了这种看法,敏捷开发是一种非常棒的工作方法,能够确保客户得到他们想要的东西。

敏捷工作方式往往带有很强的个人风格,所以我简单介绍一下我们的工作方式。我们的迭代周期为两周,每两周会举行一次仪式日,内容包括向客户演示产品、回顾总结以及规划下一个迭代周期。我一直很喜欢这些仪式,因为产品演示是对整个团队的一种鼓励,而回顾总结则能让你倾诉那些让你感到压力和疲惫的事情。

我确实认为故事点数总体上并不是一个理想的衡量单位。我知道我们需要一种方法来告诉业务部门哪些功能具有什么价值,但是……如果我们仅仅根据复杂度来判断一个任务,就相当于在说“嘿,这个不复杂”或“嘿,这个很复杂”,这并不公平。团队新成员接手这样的任务可能会感到自卑。新成员本应参与到任务的评估过程中,但大多数新成员的意见都被其他人否决了。

舒适区

很多公司似乎都安于现状,他们虽然对新事物持开放态度,但却不愿主动推行。这需要仔细权衡利弊。我本人喜欢在某些方面有所改进的新事物,大多数时候,我已经对这些事物进行过评估,并判断它们是否具有潜力。

我们举个例子来说明。我非常看好 MobX,因为它性能出色。我当时想,既然新人可以先学习其他方面,为什么还要让他们担心性能问题呢?但事实证明,这是一个糟糕的决定,因为大家根本不知道如何高效地扩展 MobX。这或许是因为我在他们的第一个项目中参与得太少,但我想,这就是咨询工作的本质吧。

我发现,当你想要推出一些新东西时,它应该清晰明了。例如,我之前引入的 TypeScript(没错,是在它还没火起来之前)就非常成功。它不会强迫开发者改变思维方式,只是为开发者提供帮助。

这绝无贬低之意,而是为了说明决定哪些功能值得引入、哪些功能不值得引入有多么困难。
开发周期必须对客户保持一致,软件质量和代码质量都必须保持不变。

一般性学习

表现

并非所有人都关心这个问题,我知道这是一个经常被讨论的话题,但我真心相信,如果一些公司能够看到他们救助的那些手机/网络状况不佳国家的用户数量,他们一定会感到震惊。

我知道你需要一些数据指标来有效地告诉业务部门我们需要采取措施,但是如果用户因为网络连接速度慢而导致网站加载速度过慢(比如加载了几兆字节的JS文件),那么谷歌分析和其他分析工具就无法捕捉到这些用户。你需要真正参与到网站的访问中,这些工具才能正确地显示可靠的信息。

这个问题有解决办法,但我认为这种想法有问题,全球应用程序应该全球可访问。这并不适用于企业内部使用的应用程序。

结论

工作是一个学习的过程,作为一名开发人员,我在过去两年里取得了巨大的进步。我很珍惜这段经历,也很感激结识的人,现在我正在展望未来。

文章来源:https://dev.to/jovidecroock/quitting-my-first-job-1741