阎浮提 · 2021年03月09日

后端新人成长手册(上篇):后端学习的正确姿势是什么?

内容预警:本文仅从技术方面讨论数字后端新人的成长建议,部分观点包含作者的主观感受,如有不同意见欢迎留言讨论!文章较长需要些时间,请保持耐心。

最近几年通过工作和本公众号了解和认识了很多初入后端的新人,期间既听到不少领导抱怨人难招、听到一线资深工程师抱怨新人难带,也听到很多初级工程师抱怨不知道如何提高,领导没耐心指导不到位等。小编也是从新人走过来的,大家的经历我很能感同身受。现实中优秀的新人往往是少数,但是希望大家在看过这篇文章理解领导的想法后也能渐渐做一个更好地成长为合格的后端工程师。

第一份工作中不懂的太多怎么办?

这是所有新人都会面对的第一个问题,也是很多人对第一份工作倍感压力的原因。你可能面临开会时别人汇报的项目进度如同天书;也可能对同事间谈笑风生的技术用语和技术问题毫无头绪;甚至可能直属领导交给你一项任务但你却连任务的内容都听不懂。这并不是某个人独有的问题,而是绝大多数后端新人都将面临的第一道门槛。根本原因在于绝大部分人在学校无法接触业界普遍的芯片设计流程,很多人在工作之前甚至不知道数字后端这个工种,遑论能够知道它的工作内容和所需要的知识。在这样的条件下开始第一份工作,很多人会感到十分焦虑。

image.png

我一直建议新入行的同学不要心急,更不要无端给自己增加压力。一般正规公司都不会指望刚入行的同事在短时间内上手工作,这也是我建议应届生优先选择大公司的原因之一。这个缓冲期一般都有几个月甚至半年之久,建议大家好好利用这段时间来打下基础。公司培训和文档丰富的要充分利用这个优势,公司没有资源的需要发挥主观能动性多查多看,把涉及后端的基础知识都要学习一遍,比如:数字芯片设计制造流程、数字后端的定位和工作内容、后端输入输出文件、EDA工具在每个大步骤中都在做什么、各类技术术语的含义等,遇到不懂的词语需要记录下来找时间统一提问或者自己找答案,争取在一两个月内至少能够看懂别人工作汇报的框架和部分术语。

image.png

大家可能注意到我这里并没有过多提到去向同事提问这一途径,原因在于在大多数公司资深工程师都会比较忙,少数可能对新人的问题甚至没有太多耐心,因此这部分资源应该在合适的时候才加以利用。比如遇到某些概念查阅了不少资料也很难理解甚至根本查不到,或者某些工具的用法和行为通过user guide的描述仍然不清楚,又或者是自己有一个具体的问题需要解决,有了一些思路但是想问问有没有更加高效的方法等等。本质上就是需要向他们请教一些书本上和网络上学不到的知识和经验,并且尽量让别人看到自己在提问背后是做了足够的功课而不是一个伸手党,这样不仅能够有效减少无耐心的回答,也能够让别人更乐于分享自己的知识。当然除此之外对别人讨论的话题积极倾听或者参与也是好习惯,但是初学的时候可能会面临内容难以理解的困境,相信积累一段时间之后会有所好转。接下来我们讲讲如何正确且高效地向别人提问。

image.png

如何高效地向别人提问?

正确提问是一个复杂的话题,github上甚至有人专门写了几万字的长篇文章专门论述这个话题。我们这里并不会方方面面地深入讨论,只是就后端本身而言给大家提出一些比较通用和有效的建议。我一直认为可以通过一个人提问的方式来判别提问者的态度水平,在这里并不是要贬低或者冒犯谁,而是很多人的提问方式很明显是想直接伸手要答案而从未尝试过自己思考和动手实践,长期在这种情况下学习和工作的人必然无法触及到问题和知识的核心,渐渐地就会与同龄人中善于思考和学习的人拉开差距。我们应该认识到工作中本质上没有谁对自己能否学会负有责任,也没谁有义务一定要培养或者辅导自己,大家都能心平气和地对自己倾囊相授自然是幸运,但现实是不少人仍持有‘教会徒弟饿死师傅’的思想,而且大部分人工作本身很忙,对不相干的人根本不想多花一点心思。正因为如此,正确提问才显得如此重要。

image.png

我把高效的提问分为几个部分:

1) 提问之前耐心做足功课

    这年头不论是线上还是现实,一个伸手党从来都是不受人待见的。伸手党最大的特点就是把便利留给自己,把麻烦留给别人,在解决问题的方法上尤其如此。假设一条timing path很难满足,我看过有人发出过类似的提问:【急急急!!哪位大神帮我看看这条path是怎么回事?】然后贴出一张不完整且不清晰的时序报告截图,再无其他描述。这种情况除非问题显而易见且容易回答,否则是不太可能得到别人的帮助的。

image.png

更好的提问方式是:我在做xxx工艺的项目中,在xxx工具中的xxx阶段跑出来的timing在xx corner下有这样一条path,clock cycle是xxx,clock skew是xxx(如果已经做了CTS),uncertainty加了xxx,CRPR是xxx,data有xxx级且没发现delay异常的地方,data line物理距离xxx,setup/hold有xxx的violation,原因看起来像是xxx导致的,尝试了xxx方法但是无效,请帮我看看我分析的原因对不对以及有什么其他办法可以解决。首先让别人充分了解你的问题,同时也向别人展示你的分析过程,相信会有更多的人愿意帮助你,而且很多高手也确实喜欢解决一些比较困难或者罕见的问题。如果上述问题中的很多概念和术语你还不了解,那么请继续加强基础知识和概念的学习。

顺便提一下,光在网络上发一些【跪求xxx!!!】【急急急!!!】等标题的问题并不能帮你更快更好地得到帮助,你需要用实际行动赢得你想要的答案。

2) 问题背景描述清晰准确

    很多人在提问的时候会忽略非常多的基础背景和细节,并理所当然地认为别人应该了解,因此导致对问题的描述非常抽象。比如直接甩过来一张LVS比不过的哭脸截图,提问是什么问题导致的LVS失败。恕我直言,这种情况对方不骂人已经算是有修养了。

image.png

首先这种问题本身并不适合远程提问,因为它和设计环境以及设计数据的完善程度息息相关,能出错的地方实在是太多了。尽管如此,对于这样的问题提问者仍然可以做到这样的叙述:我用xx工具正常做完PR,有多少drc和short,分别是xxx导致的应该不影响LVS,写出数据过程没有遇到错误,PR工具中检查LVS有/没有发现问题,但现在使用xx版本的Calibre/ICV跑LVS比不过,看到report里面报出xx net可能有open/short,或者某些instance/net不匹配,但是PR工具中检查不出来,我应该从哪里入手分析?再配合你report中的截图或者文本,这样的提问更有可能让别人帮助你或者给你提供思路。

3) 提出让别人容易回答的问题

    理论上来说,答案越复杂的问题有人帮助你的概率越低。那么最简单的办法就是提出一个问题只需要让别人回答是或者不是,而实际中绝大多数问题都可以转换成‘是/不是’的问题,前提是提问者做了足够的功课。有时可能一个‘是/不是’的问题不能完美解决回答你的疑惑,但是多个‘是/不是’的问题也要比一个需要长篇大论回答的问题让人更容易回答。

image.png

4) 有条件的情况下配图解说

    我曾参加不止一个会议看到双方针对同一个问题为了让对方搞明白自己表达的内容而反复陈述半个小时甚至更久,而有人只需要简单的在图上画一画就会在几分钟内让所有人明白对方想要表达什么,这就是图像的力量。人类对图形图像的理解速度远超声音和文本,因此在条件允许的情况下请尽量增加图示来辅助沟通,不仅能让沟通更加高效,也更有利于从别人那里获取答案。试想如果对方第一眼看你的问题就不明白你在说什么,他又有多大概率会回答你的问题呢?

5) 说出你的见解

    大部分人都很想知道提问者的分析和结论,尤其是提问者做过的实验和结果,因为这可以在一定程度上帮助对方过滤掉很多无用信息,同时也向别人展示了提问者自己的态度和努力。提问者的看法很可能并不是问题的根源,但也比一些流于表面的观察现象和不动脑子的伸手党要好的多。因此,遇到问题之后请务必花心思分析和研究,有想法的话可以做实验验证并得出结果,这都是学习和积累的宝贵方法。

最后,如果对照上面的思路你发现对完善自己的问题还没有任何帮助,那么请从第一步开始:耐心做足功课。因为这种情况的本质还是基础知识的缺乏。你需要了解你当前步骤到底在做什么,它和以前的哪些步骤有什么依赖关系,工具扮演的角色和基本的行为是什么,工程师需要设置哪些输入又要检查哪些输出等等。有了更多的基础知识,才有可能对问题的原因有更多的见解,解决问题的方法和手段也可以慢慢得到积累。

来源:https://mp.weixin.qq.com/s/4VK0koCY7KousCgfOUQe8w

推荐阅读


如果大家有任何后端技术与职业发展方面的问题,抑或关于数字后端感兴趣的技术话题想要了解和探讨,欢迎关注我的知乎专栏: 数字IC后端设计工程师修炼之路
同时欢迎关注微信公众号:数字后端芯讲堂,一起探讨技术,共同提升!
本极术专栏也会同步更新芯片设计后端的技术干货,也请关注数字IC后端设计工程师修炼之路
推荐阅读
关注数
3825
内容数
46
本专栏致力于将数字芯片后端设计的技术,经验和技巧介绍给想入门或提高的你。一方面从基础知识方面的讲解使初学者少走弯路,另一方面用实际工作中的经验技巧方便从业者提高和交流。
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息