转载

终于学会承认自己做不到

要说 2016 年我在技术上的最大的收获，当属心态发生了转变。在此之前，我在技术上没有一个明确钻研方向，为了解决问题嘛，碰到什么问题就搞定什么问题，一时半会搞不定就绕过去，也能获得很好的结果。到头来却是，我成了一个「全栈」工程师，不知道我真实水平的人以为我能力很好，什么烫手山芋交给我都能得到超出预期的好结果。我自己却感觉到彷徨和困惑：几年之后，人们提起我的时候，想到的是一个干活很靠谱的全栈，还是一个别的什么？

我想要成为一个真正的技术专家，而不是一个顶着技术专家头衔的「全干工程师」。带着这样的理想，我加入了阿里云的云数据库团队，然而并没有什么平台是能承诺一定让你成为专家的，平台能够提供的是高难度的问题，高水平的同僚，剩下的一切都需要自己去证明，机会也要自己去争取。

仅仅懂得比别人多，是成不了专家的，最多就是成为咨询师。大老板跟我说，专家就是要能搞定别人搞不定的问题。为了能够搞定别人搞不定的问题，你要成为这个领域里的第一，开始是团队里的第一，后来是公司里的第一，最后是行业里的第一。

属于我的领域在哪里，我不知道。没关系，先从把工作做好开始。

后来因为对工作中一些效率上的工具不满意，自己在周末造了两个轮子，不曾想无意中解决了团队里说了很久却一直没能解决的问题，然后就这样获得了团队里的第一届「创新之星」，奖品是一台大疆无人机。

终于学会承认自己做不到

有些事情别人半年都搞不定，你两天就做出来了；有些事情你半年都搞不定，别人两天就做来了，我希望每个人都能做自己最擅长最喜欢的事情，把事情做精做深，真正发挥每个人的价值

什么是我最擅长的事情？我不知道。我不是 MySQL 专家，不是 Redis 专家，不熟悉 NGINX，不熟悉 Kafka，不熟悉任何一个基础设施或者中间件，不是任何一个数据库或者操作系统的老司机，甚至我做为 Java 工程师也不熟悉 JVM，更不知道 Servlet 是何方神圣，做为 Python 工程师也不熟悉 Python 解释器。但是我在需要的时候能魔改 Druid 连接池底层的 SQL 解析，能魔改 pip 打造出一个能从 Nexus 仓库上传、下载、安装 Python 模块的 mpip。

于是到头来我还是一个什么都拿不出手却什么都干的渣渣？回想着大老板跟我说的话，我似乎发现了问题的结症：我对自己的要求太多，以至于什么都想做最终什么都做不好。

于是我开始学着承认自己能力不足，学着承认自己搞不定。在过去，承认自己解决不了问题总是让我感到羞愧，如今却可以心安理得地承认自己搞不定，让同事找老司机看问题，然后自己跟着在一旁学习，而不是自己抱着代码默默排查个老半天。

心态转变之后，突然整个世界都变好了。

我虽然还不知道自己擅长什么，但是我至少知道了自己不擅长什么。走出舒适区就是要去做自己不擅长的事情，可是我连舒适区都没有，连擅长的领域都没有，还是先找到舒适区吧。

今年有大半年时间我没怎么写生产代码，而是在做一场旷日持久的线上变更，每周有两三天通宵达旦地工作，以至于我在做变更的那段时间里，都不怎么会写代码了。但是那段时间里，经常有同事找我讨论 Java 系统架构、HTTP API 的设计，这让我意识到，原来我在 Java 系统设计、微服务架构方面的经验，甚至于之前在菜鸟网络时见识的各种淘系中间件、各种内部轮子的设计，可以给同事们设计系统的时候做为参考，可以分享我之前掉过的坑、做过哪些事情避免掉进坑。

我突然发现，只需要动动嘴皮子给个方案，然后由别人坑哧吭哧去把系统实现出来，这种感觉真的很奇妙，但是有毒！这不就是我们说的 PPT 架构师吗！据说菊花厂的架构师就是这样，只出设计，不写代码。那段时间也曾经和同事开玩笑，说我已经写不动代码，干脆转型做 PPT 架构师，专门参与技术方案讨论就好了:joy:

后来，旷日持久的变更终于做完了，零故障，很棒，超出预期。因为做这个变更，在一些项目上欠下了债，之前是厚着脸皮一拖再拖，现在从变更里出来了，债得还。还债之路也并不平坦，老板让我开始介入一个重要的底层系统的工作。原本以为能够等到我把债还完才开始介入，没想到债才刚开始还，我就在一次讨论中贡献了一套技术方案，然后在这个系统里坑哧吭哧写了一个月才把这个方案给实现了，前几天刚刚交付测试。我从零开始给这个系统设计了一个全新的分布式架构，号称能解决之前老架构上解决不了的各种问题，还和同事一起在这套新架构上支持了一个全新的业务，老业务的迁移也在开始规划。

终于等到了一个机会，做出一个能够代表自己真实的工程能力的系统。原来，在这之前所做的一切工作，获得的一切认同，成为一个靠谱的全栈工程师也好，和同事通力协作零故障地完成超级大变更也好，都只是在为这个机会做准备，之前做的一切日常而琐碎的系统维护，也显得不是那么琐碎无聊。

当你不知道该做什么的时候，可以先把手上的事情做好。简单的事情做不好，就不会有机会去做不那么简单的事情。

事了拂衣去，深藏身与名。交付了一个牛逼闪闪的新架构，交付了一个新业务，本以为可以悄悄的退出来，继续还我的项目的债。但是天不从人愿，CAP 定理让人们中毒太深，提到分布式系统言必谈 Paxos 和 Raft，以至于我搞了一个和 Raft 毫无关系的系统，也被同事询问系统设计的理论基础。

对我来说设计一个分布式架构的应用，和设计一套微服务架构的应用，都是纯粹的软件工程，除了一个是系统内部通信完成状态转移，一个是系统之间通信完成业务请求之外，没什么本质区别。Storm 和 Kafka 之类的分布式系统，不也没有理论基础么。但是换个方向一想，我做的系统居然已经重要到需要理论来保证其正确性的地步了，如果我真能给出理论或者什么证明，是不是也就可以自称「略懂分布式」了？

一直没认真看分布式方面的书，终于吃了文化的亏，就趁着这个机会好好补课吧，或许分布式系统设计，可以成为我所擅长的领域。

原文 https://blog.jamespan.me/posts/finally-i-learn-to-admit-that-i-can-not-solve-it

正文到此结束