我的职业生涯和经验教训

我已经好几次被问到“我怎么能这么高效”。在这篇文章里，我会分享我的故事。

简介

对我个人而言，2020 年是我在 Twitter 和（开源）开发者社区中更加活跃的一年。虽然我并不出名，也没有很多粉丝，但它确实为我带来了一小群人，我现在把他们视为朋友。

去年，我构建并发布了几个小型开源库，以及一些大型项目，例如Testing -Playground和Updrafts.app。leaflet -geosearch 的下载量突破了 100 万次🤯，最近我又开始着手我的下一个项目rake.red。这一切都与我的日常工作息息相关，我的日常工作是开发一个 B2B 协作平台。

这并非全是小狗和月光，但我已经在关于2020 年的斗争的博客中谈论过这一点，所以这不是本文的主题。

提高生产力

现在已经发生过几次，有人问我一些问题，这些问题归结为我如何变得“如此高效”。

经验远不如我的开发者经常会问这个问题。这本身没什么问题，反而我相信这就是答案。当我看起来比你更高效，或者迭代速度比你更快时，这可能与我从事软件开发超过 15 年，并且近 10 年前就推出了我的第一个 SaaS 产品有关。（我想我得在 2021 年 9 月 17 日庆祝一下🎉）。这是你在社交媒体上看不到的故事。你会看到开发者发布他们的作品，但你往往看不到那些默默付出的时光，甚至那些年。

别误会我的意思。你不需要这15年就能赶上。Web开发领域变化太快，我五年前积累的大部分知识都已经过时了。但不妨把它比作运动员或一级方程式赛车手。我们很清楚，每一项纪录都会被打破。总有人会比现在的纪录保持者更快。但我们也知道，未经训练的你不可能打败运动员。

无论您仰慕的开发人员是谁，我相信他们都经过了多年的培训。

获得经验

我的经验大多来自于犯错和自我反省。我经常思考自己刚刚做的事情是否可以做得更好，或者更高效。我没有接受过计算机科学方面的教育，也从未参加过任何开发者课程或训练营。

我编写的第一段专业代码是为了自动化我自己的工作。我的职业生涯始于 CAD 操作员，我注意到了绘图中的规律和重复。AutoCAD 有一个 c#.net 接口，我用它把原本需要几天的手动操作减少到几分钟来观察和协助计算机绘图。

最终，我积累了丰富的 C# 使用经验，并用它解决了更多问题。不久之后，我们面临着荷兰新出台的涉及电缆和管道等地下基础设施的法律和义务。该法律的实施催生了对管道管理门户的需求，于是我决定构建它。我的第一个 SaaS 就此诞生，并获得了几家大公司的客户。

这款 SaaS 最终促使我决定转行，以软件开发为生。

升级

我经常遇到的一个相关问题是如何做得更好，如何学得更快，甚至如何享受学习。

我认为学习是一种手段，而非目的。我从未将学习视为目标。我不认为我能以那种方式学习。

相反，我构建了类似testing-playground.com这样的项目，因为我看到了需求。当我选择技术栈时，我可能会添加一两个听起来值得投资的东西来熟悉。对于testing-playground，我选择使用React，因为我熟悉它；我选择部署到Netlify，这样我就可以学习一些无服务器函数。我不会想着“哦，天哪，我要学习无服务器！太有趣了！ ”。我只是在解决testing-library没有repl的问题。学习无服务器，对我来说是一份不错的简历加分项。

看到最终产品上线，我当然很满足。甚至可能有点庆幸自己让它在 Netlify 上运行了。但“学习无服务器”从来都不是目标，也不是让我感到满足的原因。对我来说，用它解决问题才是满足感所在。

犯错

我从犯错和认识到错误中学到最多。自我反省至关重要，尤其是在你身边没有人能够或愿意指出你的错误的时候。如果你有同事，但没有人指出你的错误，这并不意味着你没有错误。说实话，我认为（在这个行业）没有人是没有错的。

这些年来，我犯了不少错误。我列举几个，以便我们都能从中吸取教训：

逐步迁移到新技术

这个问题并非非黑即白。我的意思是，我目前正在维护一个可以追溯到 2014 年的代码库（基于 NodeJS/MongoDB）。当时，我们还在使用 Node v0.10！这些年来，我们从 Blaze 迁移到了 React，从类组件迁移到了函数式组件，从 hocs 迁移到了 hooks，从 REST 迁移到了 GraphQL。在我作为唯一开发人员的几个月里，我还在那个代码库里实现了一些“绝妙的想法”。一部分是因为新技术看起来更好，一部分是因为我盲目追随最新潮流，还有一部分是因为我想尝试一些新的东西。

我真的很后悔。如果可以重来，我会跳过一些迁移，坚持现有的惯例。这也是我现在有更多业余项目的原因之一。如果我想尝试一些新东西，我会在业余项目中去做，而不是在谋生的项目中。

迁移本身并没有错。但由于时间紧迫，并非所有迁移都已完成。因此，一个代码库中会使用多种约定。这对可维护性不利。

代码复杂性

我过去犯的另一个错误与函数式编程有关。我说的不是 React 函数式组件，而是使用镜头、遍历、柯里化、point-free 函数和不可变性。简单来说，就是使用ramda.js和操作数据partial.lenses。它们都有各自的用途，但在某个时刻，我尝试将所有东西都变成 point-free 的，结果却产生了不必要的复杂代码。我吸取了教训，退了一步。我仍然会运用从函数式编程中学到的知识，但会稍微放松一些。我更注重可读性。

我认为这里最重要的教训是，代码越短并不总是越好。为了可读性而写。你未来的自己会感激你的。

追随潮流

我犯过两次这样的错误，并且（希望）不会再犯。

第一次是 MDG 宣布放弃对其视图层 Blaze 的支持。我很快就迁移到了 React，但由于我独自开发了这个项目，这浪费了宝贵的时间。我坚信，如果我坚持使用 Blaze，应用程序仍然会运行良好。我们可以用不同的方式利用这段时间，而不会造成任何严重影响。

第二次用的是 Hooks。我喜欢 Hooks！但我犯了一个错误，就是要求团队在接下来的几个 Sprint 中重构所有组件。这比预期花费的时间更多，而且由于这项技术对每个人来说都是全新的，所以犯了一些错误，并引入了新的 bug。

我不确定是否应该将 GraphQL 添加到这个列表中，但我还是加入了这个行列，而且我们平台目前使用 GraphQL 作为私有 API。我确实喜欢这项技术，但它确实让事情变得比严格要求的更复杂。事后看来，我认为 REST 对我们来说会是更好的选择。

最后的话

我从未在IT公司工作过。我目前是自由职业者，与非技术合作伙伴在一家合资公司工作。我的面试表现不佳，但我构建并维护了一些（Web）应用程序。

除非你真的从学习本身获得能量，否则我建议你停止追求知识。如果你需要为工作学习一些东西，那就在工作时间学习吧。这是工作的一部分！如果你想为自己学习一些东西，那就去创造一些东西。为你的问题创造一个解决方案，知识自然会随之而来。问题越难，你从中学到的就越多，当你完成它时，你的满足感也会越大。

相信自己，别让任何人阻碍你，也别觉得有义务在私人时间学习！自学是一种选择，而不是义务。