邮件订阅，第一时间收到更新： https://liding.substack.com/ 。如果你在国内，这个link可能打不开，那么请使用这个link。
第一年还在摸索，第二年感觉有点迷茫，今年觉得终于慢慢按照我的节奏走了起来。
每年年底我司会有一个Annual Check-in Feedback session，和自己的manager 1 on 1 来沟通这一年的accomplishment。同时manager也会在这个1:1 之前找这一年来和我有过密切合作的同事给我评价（做的好的方面 和 需要成长的方面）。
所以这个这个Feedback session可以听到汇总的一些自己的优点和不足。
今天这篇我就来分享我今年收到的feedback。
说优缺点前，得先给多一点背景。我不能说的太细，毕竟做的project还是公司内部保密的，所以可能有点模糊，大家get到大意即可。
背景
在过去的几年里， 我在一个内部新产品孵化组做新产品，虽然我的title是 research scientist，但实际上很多的时间都是在做 software/research/infra/frontend engineer的职责。我十分的喜欢这个组，因为做的东西很前沿而且人都很赞。我们把这个组叫成「前沿组」吧。
我在「前沿组」花了80%以上的时间。在暑假和其他零零散散的20%时间里，我也在继续推进我的research agenda。今年暑假我做的是和 video understanding for accessibility的项目。去年和一个大学教授合作做出了一片不错的成果X，带了两个intern又在做成果Y和Z，同时又在和另外一个教授做成果V。
接下来就说我的优点吧，多少带有一些职场里的话术，各位将就着看。
相信读者里有比我senior很多的，也有和我属于差不多职业阶段的。如果你们有任何的建议，欢迎给我来信 podcast@dingzeyu.li
优点
我今年的主题是reduce the number of things that I work on. Be more focused。这个是在去年和之前和多人讨论咨询后，我觉得最适合我的一个计划，这个得到了manager的肯定。
I continue to make critical contribution. 我觉着大意就是我选的这个「前沿组」的确impact大 + 缺人，所以做的事情总算是重要的事情。比较空泛的一个开头吧。
Teammates value and appreciate my versatility — I help out wherever needed, even though sometimes outside of my comfort zone/expertise. 像我之前说的，过去的几年里，基本是各种各样的帽子都戴过了。组织哪里需要我，我就去哪里，很多时候我都得迅速的学一个新的framework/library，然后马上运用到我们的场景里。时间紧，任务重，不是每个团队里的researcher都愿意接这种活。我个人觉得，为了这个「前沿产品」成功，我不介意干多一些这种脏活累活，反正我对自己的学习能力也挺自信。这样子的versatility（多面性， 多能手）也是在「前沿组」目前的情况下的一个不得已的产物吧。
Effective communication, how I communicate, the timing of my communication etc. Not wait for too long before getting feedback. 毕竟我是非常hands on的一线IC，有时候对上面瞬息万变的roadmap没法实时了解，有时几天没有standup猛然发现咱组的plan都大变了，所以我现在会喜欢开始写code前确认这个是我们当前sprint的must do。然后有了个MVP就赶紧寻求feedback，在request code review之前先把功能方面的需求都address完。
Good sense of user facing features. Bridge between ML analysi and front end feature. 我感觉在另一个平行世界里，我应该会挺喜欢当Product manager（PM），我很在于用户体验，也很喜欢听取用户的feedback，在当中汲取出值得做的一些点
Find ways to move forward. 这个主要是关于 去年开始的 和几个现有产品组的对接。背景里介绍到了，今年我基本就在捣鼓「前沿组」和「研究」这两个方面，并没有很多时间做传统意义上的tech transfer。所以之前本来打算开始做的几个tech transfer都在今年有些停滞。主要是产品A和产品B的停滞。
产品A的话，刚好把我之前的一个intern return回来当fulltime了，我就在他入职前花了些时间和产品Ａ组沟通，确认和时间线和交货需求等等。在他入职后，确认了他的确很有兴趣来drive这个tech transfer，所以就平稳交接给他了。这一个经历，我manager十分的满意，因为既deliver promise，而且实现了 influence without hierarchy（因为我的前intern并不在我们组，纯靠我画饼，洗脑，客观说服来influence的他）。
产品B的话，去年deliver了一个大feature，但是他们有一堆follow up的小feature request 甲乙丙，我一直没有时间做，我也觉得那些不是特别的critical，换句话说，我没有被画饼成功。所以我捣鼓了半天修复了一些大feature的bug（由底层别人的library引起的bug）和把大feature提速。这个纯粹就是挤时间做的了，没啥特别的。
需要成长的几点
Be more explicit about that I can or cannot do. 沿着上面的产品B讲，我虽然修了别人引起的bug和提速了，但是并没有做甲乙丙，终于产品B组略有微词。回想我自己的回复，的确不是特别明确，我一直嘴上没有说不做，然而身体是一点都没在做，（因为我没有被convince甲乙丙有大意义）。这样子的言行不一致让产品B组有了误判，他们一直在期待我做的甲乙丙结果却等来了bug fix和speed up，好是好，只是unexpected。
类似的事情貌似在「前沿组」里也有一点点迹象，就是有时assign task到我头上，我也不拒绝也不热情，放在那里好几个星期/月，就stale了。
总结这第一个成长点，其实主要是我自己沟通还不够直接。很多时候我存在侥幸：“ 我之后会有闲时间把这个做了的”。然而现实是，时间不够用，因为我不相信这个饼，所以这种task的优先级都比较低，导致最终都在一拖再拖。
目前和manager讨论的方案：
先在接下来几个月，把欠下的甲乙丙都做一下，毕竟答应人好久了，还是得交差的，不能再拖了。
未来类似情况出现时，应该更加explicit的表达，比如说：This is an important task, but I don’t have enough bandwidth for the next XXX months/years. I won’t be able to work on this. Let’s work together to figure the best plan moving forwards.
至于是啥plan就看当下的境况了。比如说产品A和我前实习生的交接就十分漂亮。或者帮他们document需求和一些implementation/testing的requirements。总之不可以既不表态也不干活。两者必须得选其一。
Future plan for accessibility research
这个就是我的学术研究的计划，具体的估计各位也没啥兴趣，我就不写了，如果有兴趣欢迎告诉我，我可以写更多。
今天的重头戏是最后的下一点。
Polish in terms of design/frontend/eng.
这一点是最头疼的。也是这一年来我都隐隐有感觉到的，跟「前沿组」里的几个tech lead和同事聊的时候都有感觉，所以收到这个feedback并不诧异。大概的意思就是我写的code可能比较rough或者比较scrappy。
首先，什么是Scrappy？
我搜了一下，可能以下几个link有或多或少的谈到。
我其实自己在写这篇blog以前也没有很清晰的认识，读了上面的几个链接之后我觉得以这几点可以总结 我对于scrappiness的理解：
Progress over process.
I’m not an engineer and my skills are not infinite so I had to try to figure out how to build this. I talked to a lot of people about geospatial tools and maps and someone showed me this product called XXX. I was snooping around on that product and I came across an example where you would click on some part of a map and they would write what the population was in a box. That gave me an idea, so I looked at the code and I saw something that I could actually do. I needed to get a story into this box and I need to show how the story changes as you move. This became the seed for what would become Quill. And I didn’t get permission to do this.
上面两段是我从别人网站里截选出来的。第二段话其实一定程度上是我的scrappiness的写照。我不太会用某个library，但是我又不得不在短时间内学会并且完成任务，所以我在网上迅速学习找到example，然后搞出了个第一版本。
我是非常理解这个feedback的，毕竟我做了十多年的research，写过各种各样的research prototype的code，无需经过任何的peer code review，只要能够work，并且赶在paper deadline前把少数的实验快速准确的跑完，就够了。从本科到PhD，基本每一两年就得学一个对当时的我全新的编程语言和理念，C++ matlab python openscad javascript 物理建模软件自带的语言 等等。 为了能在当时那样的环境里thrive，我的成长模式就是，短平快的把现有项目所需的语言赶紧学会，然后把code写通，把个mvp搞起来。因为如果不能够这样的话，那我就没法快速验证我的research idea了。
你可能会问，为什么你不把一个语言学深点？首先一个自身出发的因素应该就是我对技术底层的本身并不是deeply passionate，我对于他们能够带来的应用更加感兴趣，所以一旦完成我的application之后，我就没有兴趣再去深深钻研了。于此相关的，在读博期间，时间紧任务重的时候，我当时想的是怎么能够快点validate我的研究想法，如果work的话，就赶紧设计实验 然后实现代码 做完这个项目之后，下一个项目很有可能也不再用一模一样的体系，于是给了我完美的借口不去深究。
这样自身加上外界的因素，让我现在习惯于目前scrappy的工作状态。
回到现在我的这个feedback，在「前沿组」里我还是在延续着我短平快的风格，速速就把任务所需的语言和理念学了个大概，然后马上咔咔咔的写出了个肯定可以work的版本。欠缺的是 1）code并不好maintain，打个比方，我可能是带着写C++的mentality在写typescript/react，虽然两者有些许共同，但是也有大量的不同，很多逻辑是不一样的，这样我写出来的code虽然能work，但是并不容易看懂/被maintain。2）没有写完整unit test的习惯，很多时候我会写一些helper function，但是总是带着想当然的状态，认为只要我自己的几个use case可以了就不把测试做完整。3）很多时候我完成的这个scrappy code的feature是时间很赶的，因为马上就要内部deadline了（也是为什么别人不愿意做的原因），所以在code review的时候别人可能会不情不愿的approve，因为如果要细致的让我把一个一个scrappy code都修改好的话，review的时间和iteration的精力消耗太大，所以teammate会不情不愿的approve，而我的这种code一旦进入codebase，就让有code洁癖的人就会不开心。
分析了这么多，其实我觉得一半的原因在我自己，另一半在我们项目目前冲冲冲的状态，要是我们有着更长的时间线，或许会有不一样的境遇。
那么下一步怎么做呢？
我没有很清晰的想法。目前我的思路是这样：
首先和teammate沟通，谢谢他们指出的我的不足，并询问他们有什么concrete的idea我能够改正的，尤其是在process层面，可以让我一步一步做，来提高的。
我以前可能要对于时间的要求估计不准确。意思就是以前我估计完成一个任务是按照我的“scrappy code”的时间估计的，所以deadline就压的很紧，但是实际上如果我要留时间给refactoring和其他improvement的话，时间很有可能得double甚至更多。短时间内看，这样是会减慢进度，但是长期的话，我check in的code更多人可以易懂易用，可以提升整个team的效率，所以我觉得这个tradeoff的值得的。
另外一个也是manager给我的一个思路，就是目前的「前沿组」就还是十分像startup一样的在往前冲，所以可能在这个组当中想要慢下来成长是比较难的。所以他的一个建议是，在这个「前沿组」外面寻求engineering polishment growth的机会。看看有没有其他的mentor可以帮助我成长
还有一个思路，是寻找一些和我的strength更加aligned的任务。这样我就不用别做别学了。这样或许是可以让我写出更加专业的code。
好了这篇分析写的比我想的要长太多了，谢谢各位读到最后。
对于我需要成长的几点，如果各位有建议，欢迎给我来信。我非常喜欢收到feedback和建议，以此来改进自己。podcast@dingzeyu.li