- 博客(1394)
- 收藏
- 关注
RSS订阅原创 大佬们都在修炼的内功-结构化思维
—先画出顶层架构图，明确几个大模块：数据输入、预处理、核心运算、输出缓存。每个大模块再往下细分：预处理里包含数据对齐、格式转换、有效性检查。这样一层层拆下来，原本模糊的需求就变成了清晰的模块树。最常见的场景：老板丢过来一份规格书，说要实现一个复杂的数据处理模块。新手的第一反应往往是打开代码编辑器就开始写，结果写到一半发现逻辑对不上。这些问题不在纸上画清楚，代码写出来就是一锅粥。结构化思维的第一步是"自顶向下"拆解。接口定义:看似简单却最容易出事。找到模块之间的边界和依赖关系。但拆解不是机械分工，关键是。
2025-11-24 09:03:56
79
原创 为什么芯片工程师压力这么大？
这不是时间管理的问题，而是一个无解的资源分配难题。人的精力是有限的，24小时就那么多，扣掉睡觉吃饭通勤，能用来战斗的时间本来就不够。想把手上的项目做好，就得全神贯注投入进去，哪有心思去琢磨新技术？项目在跑，流片在等，客户在催。这时候最需要的是稳定输出——用熟悉的工具链、用验证过的IP核、用已经掌握的设计方法论。越焦虑效率越低，效率越低越没时间学习，越没时间学习就越焦虑。芯片工程师注定要活在这种分裂里，一边靠旧技能吃饭，一边被新技术追杀。既要保证现有工作质量，又要持续学习升级，这本身就是一个不可能三角。
2025-11-23 07:59:28
181
原创 你的身边缺的是那种真正愿意把话说透的同事
不是泛泛地说”这个设计有问题”，而是指出”这里的时钟域交叉没处理好”。不是敷衍地说”辛苦了”，而是具体地说”你昨天那版优化让功耗降了15%，这个思路很对”。不是空洞地说”我们多交流”，而是直接约好”每周二下午三点，固定沟通半小时”。他从不在大群里说”大家有事就说”，但他知道每个模块负责人的风格。你问他意见，他说”都可以”，最后出问题了又说”我当时就觉得不对”。那些”有空再聊”“改天约饭”的话，听着客气，实际上就是信号衰减的开始。很多人以为沟通就是”保持开放”“友好回应”，结果表面上很热心，实际上。
2025-11-22 08:44:01
99
原创 那些被奉为圭臬的芯片”行业惯例”
每个项目的约束都不一样——工艺节点、功耗预算、时间窗口、团队能力——这些变量一变,最优解就变了。照搬上一个项目的做法,或者照搬其他公司的流程就像拿着别人的钥匙开自己家的门。不是凭空造轮子,而是知道什么时候该用现成的轮子,什么时候必须自己造。看到一个设计方案,不是先问”大家都这么做吗”,而是问”他们知道规矩的边界在哪里,知道什么时候该打破常规,什么时候该发明新规矩。十年前合理的设计理念,放到现在3nm工艺上,可能就是个笑话。当”这是规定”成为唯一理由,当”以前都这样”变成挡箭牌,你就离平庸不远了。
2025-11-21 08:34:26
207
原创 研发流程为什么总是推不动?因为你在“逼“人改变
今天推个新的版本管理规范,明天上个验证流程工具,后天又要统一代码风格。每次都是雷声大雨点小,最后不了了之。管理层一脸无奈:"这帮人怎么这么抗拒改变?他推新流程从来不开全员大会宣布,而是先找几个意见领袖聊天:"咱们现在这个流程确实有点乱,你觉得问题在哪?这次是某个据说在互联网很火的敏捷开发方法,PPT做得特别精美,领导讲得慷慨激昂。执行三天,回到原点。——是那种"你们听好了,从今天起必须这么做"的傲慢,是那种完全无视现状的一刀切,是那种把大家当执行机器的冷漠。人们不是抗拒改变本身,人们抗拒的是被改变。
2025-11-20 08:32:29
135
原创 研发流程为什么总是推不动?因为你在“逼“人改变
今天推个新的版本管理规范,明天上个验证流程工具,后天又要统一代码风格。每次都是雷声大雨点小,最后不了了之。管理层一脸无奈:"这帮人怎么这么抗拒改变?他推新流程从来不开全员大会宣布,而是先找几个意见领袖聊天:"咱们现在这个流程确实有点乱,你觉得问题在哪?这次是某个据说在互联网很火的敏捷开发方法,PPT做得特别精美,领导讲得慷慨激昂。执行三天,回到原点。——是那种"你们听好了,从今天起必须这么做"的傲慢,是那种完全无视现状的一刀切,是那种把大家当执行机器的冷漠。人们不是抗拒改变本身,人们抗拒的是被改变。
2025-11-20 08:32:29
106
原创 研发流程为什么总是推不动?因为你在“逼“人改变
今天推个新的版本管理规范,明天上个验证流程工具,后天又要统一代码风格。每次都是雷声大雨点小,最后不了了之。管理层一脸无奈:"这帮人怎么这么抗拒改变?他推新流程从来不开全员大会宣布,而是先找几个意见领袖聊天:"咱们现在这个流程确实有点乱,你觉得问题在哪?这次是某个据说在互联网很火的敏捷开发方法,PPT做得特别精美,领导讲得慷慨激昂。执行三天,回到原点。——是那种"你们听好了,从今天起必须这么做"的傲慢,是那种完全无视现状的一刀切,是那种把大家当执行机器的冷漠。人们不是抗拒改变本身,人们抗拒的是被改变。
2025-11-20 08:32:29
147
原创 研发流程为什么总是推不动?因为你在“逼“人改变
今天推个新的版本管理规范,明天上个验证流程工具,后天又要统一代码风格。每次都是雷声大雨点小,最后不了了之。管理层一脸无奈:"这帮人怎么这么抗拒改变?他推新流程从来不开全员大会宣布,而是先找几个意见领袖聊天:"咱们现在这个流程确实有点乱,你觉得问题在哪?这次是某个据说在互联网很火的敏捷开发方法,PPT做得特别精美,领导讲得慷慨激昂。执行三天,回到原点。——是那种"你们听好了,从今天起必须这么做"的傲慢,是那种完全无视现状的一刀切,是那种把大家当执行机器的冷漠。人们不是抗拒改变本身,人们抗拒的是被改变。
2025-11-20 08:32:29
79
原创 研发流程为什么总是推不动?因为你在“逼“人改变
今天推个新的版本管理规范,明天上个验证流程工具,后天又要统一代码风格。每次都是雷声大雨点小,最后不了了之。管理层一脸无奈:"这帮人怎么这么抗拒改变?他推新流程从来不开全员大会宣布,而是先找几个意见领袖聊天:"咱们现在这个流程确实有点乱,你觉得问题在哪?这次是某个据说在互联网很火的敏捷开发方法,PPT做得特别精美,领导讲得慷慨激昂。执行三天,回到原点。——是那种"你们听好了,从今天起必须这么做"的傲慢,是那种完全无视现状的一刀切,是那种把大家当执行机器的冷漠。人们不是抗拒改变本身,人们抗拒的是被改变。
2025-11-20 08:32:29
54
原创 为什么你的团队里,总有人“不好用“?
还有个团队,里面有个"话痨",开会特别爱讲,写代码反而一般。把一个人放错位置,不仅浪费了他的才华,还拖累了整个项目。写代码要快,文档要好,沟通要强,还得能抗压。问题是,很多管理者看到这种偏科,第一反应不是"怎么用他的长处",而是"怎么补他的短处"。,有人代码写得溜但不爱说话,有人PPT格式做得漂亮但逻辑一般,有人特别能钻研但就是慢。——不是把每个人都打磨成标准件,而是搭建一个系统,让不同形状的零件都能找到自己的卡槽。那些抱怨"手下没人"的管理者,真该想想:不是你没人,是你不会用人。
2025-11-18 07:13:09
393
原创 为什么你的团队里,总有人“不好用“?
还有个团队,里面有个"话痨",开会特别爱讲,写代码反而一般。把一个人放错位置,不仅浪费了他的才华,还拖累了整个项目。写代码要快,文档要好,沟通要强,还得能抗压。问题是,很多管理者看到这种偏科,第一反应不是"怎么用他的长处",而是"怎么补他的短处"。,有人代码写得溜但不爱说话,有人PPT格式做得漂亮但逻辑一般,有人特别能钻研但就是慢。——不是把每个人都打磨成标准件,而是搭建一个系统,让不同形状的零件都能找到自己的卡槽。那些抱怨"手下没人"的管理者,真该想想:不是你没人,是你不会用人。
2025-11-18 07:13:09
231
原创 为什么你的团队里,总有人“不好用“?
还有个团队,里面有个"话痨",开会特别爱讲,写代码反而一般。把一个人放错位置,不仅浪费了他的才华,还拖累了整个项目。写代码要快,文档要好,沟通要强,还得能抗压。问题是,很多管理者看到这种偏科,第一反应不是"怎么用他的长处",而是"怎么补他的短处"。,有人代码写得溜但不爱说话,有人PPT格式做得漂亮但逻辑一般,有人特别能钻研但就是慢。——不是把每个人都打磨成标准件,而是搭建一个系统,让不同形状的零件都能找到自己的卡槽。那些抱怨"手下没人"的管理者,真该想想:不是你没人,是你不会用人。
2025-11-18 07:13:09
234
原创 为什么你的团队里,总有人“不好用“?
还有个团队,里面有个"话痨",开会特别爱讲,写代码反而一般。把一个人放错位置,不仅浪费了他的才华,还拖累了整个项目。写代码要快,文档要好,沟通要强,还得能抗压。问题是,很多管理者看到这种偏科,第一反应不是"怎么用他的长处",而是"怎么补他的短处"。,有人代码写得溜但不爱说话,有人PPT格式做得漂亮但逻辑一般,有人特别能钻研但就是慢。——不是把每个人都打磨成标准件,而是搭建一个系统,让不同形状的零件都能找到自己的卡槽。那些抱怨"手下没人"的管理者,真该想想:不是你没人,是你不会用人。
2025-11-18 07:13:09
357
原创 为什么你的团队里,总有人“不好用“?
还有个团队,里面有个"话痨",开会特别爱讲,写代码反而一般。把一个人放错位置,不仅浪费了他的才华,还拖累了整个项目。写代码要快,文档要好,沟通要强,还得能抗压。问题是,很多管理者看到这种偏科,第一反应不是"怎么用他的长处",而是"怎么补他的短处"。,有人代码写得溜但不爱说话,有人PPT格式做得漂亮但逻辑一般,有人特别能钻研但就是慢。——不是把每个人都打磨成标准件,而是搭建一个系统,让不同形状的零件都能找到自己的卡槽。那些抱怨"手下没人"的管理者,真该想想:不是你没人,是你不会用人。
2025-11-18 07:13:09
168
原创 为什么你的团队里,总有人“不好用“?
还有个团队,里面有个"话痨",开会特别爱讲,写代码反而一般。把一个人放错位置,不仅浪费了他的才华,还拖累了整个项目。写代码要快,文档要好,沟通要强,还得能抗压。问题是,很多管理者看到这种偏科,第一反应不是"怎么用他的长处",而是"怎么补他的短处"。,有人代码写得溜但不爱说话,有人PPT格式做得漂亮但逻辑一般,有人特别能钻研但就是慢。——不是把每个人都打磨成标准件,而是搭建一个系统,让不同形状的零件都能找到自己的卡槽。那些抱怨"手下没人"的管理者,真该想想:不是你没人,是你不会用人。
2025-11-18 07:13:09
77
原创 内耗才是最大的熵增
纠结要不要跳槽,每天刷招聘网站三小时,工作敷衍了事,最后哪儿都去不成。明明该专注一个方向,却什么都想做,结果什么都做不好。团队小一点,层级少一点,流程简单一点。见过太多工程师,技术能力没问题,就是内耗太严重。如果一半能量用来内耗,一半用来做事,那还能往前走。至于个人内耗,最有效的办法是先做再说。搞清楚什么最重要,把80%的能量投进去,其他的差不多就得了。这些情绪像寄生虫,不断消耗能量,制造混乱,让人原地打转。少开点没用的会,少纠结点无意义的选择,少在乎点别人的眼光。做芯片设计,最怕的不是技术难题,是内耗。
2025-11-17 08:22:32
241
原创 芯片团队里合理的”PUA”
他有个习惯，每次review设计，总能挑出一堆问题，而且经常会说”这个方案能用，但配不上你的能力”。这时候他的lead过来，看了看，说了句话：“以你的水平，不应该止步于此。他看见你昨天为了一个bug调试到凌晨，看见你为了理解一个架构啃了一周的论文，看见你身上那束还在燃烧的光。但这个”逼”，必须是带着爱的，必须是建立在真实看见的基础上的。没有人觉得被冒犯，因为大家都知道他是真的看见了你的潜力，而且他自己就是这么对待自己的。他不会让你做他自己都做不到的事，他推动你的方式，就是他推动自己的方式。
2025-11-16 06:43:25
303
原创 简历上写”能吃苦耐劳”,HR看了都想笑
勤奋好学、吃苦耐劳、责任心强”——这几个词就像万能钥匙,套在谁身上都不违和。问题是,HR看简历时内心OS是:“废话,谁会写自己懒惰、怕吃苦、没责任心?
2025-11-15 08:37:06
143
原创 为什么你的好意建议,总是换来别人的沉默?
组会,老张又开始了他的"热心指导"。对着小李的芯片设计方案,张口就来:"这个时序约束怎么设的?"话音未落,小李脸色就变了,整个人像被按了静音键。这场景,做芯片的人太熟悉了。代码review时、方案评审时、debug时,出在那句没说出口的潜台词上。"为什么不考虑那个方案?明明是想帮忙,怎么就成了"找茬"?好心提个建议,气氛瞬间降到冰点。
2025-11-14 07:58:10
199
原创 你的团队里,别再养“超级英雄“了
给某个人最多的资源,最难的项目,最高的奖金。更讽刺的是,那些被捧成英雄的人,压力大得要命。所有人都指望他解决问题,他不敢说不会,不敢说累,不敢休息。见过一个项目,技术核心离职,留下一堆没人看得懂的代码。因为知识是分散的,经验是共享的,任何一个人离开,都不会让项目陷入瘫痪。那些真正走得远的团队,从来不是靠一个英雄力挽狂澜,而是靠一群人并肩作战。遇到问题,不是等某个人来救场,而是大家一起讨论,各自贡献自己的专长。老张累趴了,项目还是延期了,因为关键节点全压在一个人身上。一个靠谱的团队,不应该有不可替代的人。
2025-11-13 13:23:55
181
原创 你的团队里,别再养“超级英雄“了
给某个人最多的资源,最难的项目,最高的奖金。更讽刺的是,那些被捧成英雄的人,压力大得要命。所有人都指望他解决问题,他不敢说不会,不敢说累,不敢休息。见过一个项目,技术核心离职,留下一堆没人看得懂的代码。因为知识是分散的,经验是共享的,任何一个人离开,都不会让项目陷入瘫痪。那些真正走得远的团队,从来不是靠一个英雄力挽狂澜,而是靠一群人并肩作战。遇到问题,不是等某个人来救场,而是大家一起讨论,各自贡献自己的专长。老张累趴了,项目还是延期了,因为关键节点全压在一个人身上。一个靠谱的团队,不应该有不可替代的人。
2025-11-13 13:23:55
336
原创 你的团队里,别再养“超级英雄“了
给某个人最多的资源,最难的项目,最高的奖金。更讽刺的是,那些被捧成英雄的人,压力大得要命。所有人都指望他解决问题,他不敢说不会,不敢说累,不敢休息。见过一个项目,技术核心离职,留下一堆没人看得懂的代码。因为知识是分散的,经验是共享的,任何一个人离开,都不会让项目陷入瘫痪。那些真正走得远的团队,从来不是靠一个英雄力挽狂澜,而是靠一群人并肩作战。遇到问题,不是等某个人来救场,而是大家一起讨论,各自贡献自己的专长。老张累趴了,项目还是延期了,因为关键节点全压在一个人身上。一个靠谱的团队,不应该有不可替代的人。
2025-11-13 13:23:55
284
原创 你的团队里,别再养“超级英雄“了
给某个人最多的资源,最难的项目,最高的奖金。更讽刺的是,那些被捧成英雄的人,压力大得要命。所有人都指望他解决问题,他不敢说不会,不敢说累,不敢休息。见过一个项目,技术核心离职,留下一堆没人看得懂的代码。因为知识是分散的,经验是共享的,任何一个人离开,都不会让项目陷入瘫痪。那些真正走得远的团队,从来不是靠一个英雄力挽狂澜,而是靠一群人并肩作战。遇到问题,不是等某个人来救场,而是大家一起讨论,各自贡献自己的专长。老张累趴了,项目还是延期了,因为关键节点全压在一个人身上。一个靠谱的团队,不应该有不可替代的人。
2025-11-13 13:23:55
278
原创 你的团队里,别再养“超级英雄“了
给某个人最多的资源,最难的项目,最高的奖金。更讽刺的是,那些被捧成英雄的人,压力大得要命。所有人都指望他解决问题,他不敢说不会,不敢说累,不敢休息。见过一个项目,技术核心离职,留下一堆没人看得懂的代码。因为知识是分散的,经验是共享的,任何一个人离开,都不会让项目陷入瘫痪。那些真正走得远的团队,从来不是靠一个英雄力挽狂澜,而是靠一群人并肩作战。遇到问题,不是等某个人来救场,而是大家一起讨论,各自贡献自己的专长。老张累趴了,项目还是延期了,因为关键节点全压在一个人身上。一个靠谱的团队,不应该有不可替代的人。
2025-11-13 13:23:55
403
原创 你的团队里,别再养“超级英雄“了
给某个人最多的资源,最难的项目,最高的奖金。更讽刺的是,那些被捧成英雄的人,压力大得要命。所有人都指望他解决问题,他不敢说不会,不敢说累,不敢休息。见过一个项目,技术核心离职,留下一堆没人看得懂的代码。因为知识是分散的,经验是共享的,任何一个人离开,都不会让项目陷入瘫痪。那些真正走得远的团队,从来不是靠一个英雄力挽狂澜,而是靠一群人并肩作战。遇到问题,不是等某个人来救场,而是大家一起讨论,各自贡献自己的专长。老张累趴了,项目还是延期了,因为关键节点全压在一个人身上。一个靠谱的团队,不应该有不可替代的人。
2025-11-13 13:23:55
151
原创 你的团队里,别再养“超级英雄“了
给某个人最多的资源,最难的项目,最高的奖金。更讽刺的是,那些被捧成英雄的人,压力大得要命。所有人都指望他解决问题,他不敢说不会,不敢说累,不敢休息。见过一个项目,技术核心离职,留下一堆没人看得懂的代码。因为知识是分散的,经验是共享的,任何一个人离开,都不会让项目陷入瘫痪。那些真正走得远的团队,从来不是靠一个英雄力挽狂澜,而是靠一群人并肩作战。遇到问题,不是等某个人来救场,而是大家一起讨论,各自贡献自己的专长。老张累趴了,项目还是延期了,因为关键节点全压在一个人身上。一个靠谱的团队,不应该有不可替代的人。
2025-11-13 13:23:55
223
原创 你的团队里,别再养“超级英雄“了
给某个人最多的资源,最难的项目,最高的奖金。更讽刺的是,那些被捧成英雄的人,压力大得要命。所有人都指望他解决问题,他不敢说不会,不敢说累,不敢休息。见过一个项目,技术核心离职,留下一堆没人看得懂的代码。因为知识是分散的,经验是共享的,任何一个人离开,都不会让项目陷入瘫痪。那些真正走得远的团队,从来不是靠一个英雄力挽狂澜,而是靠一群人并肩作战。遇到问题,不是等某个人来救场,而是大家一起讨论,各自贡献自己的专长。老张累趴了,项目还是延期了,因为关键节点全压在一个人身上。一个靠谱的团队,不应该有不可替代的人。
2025-11-13 13:23:55
348
原创 你的团队里,别再养“超级英雄“了
给某个人最多的资源,最难的项目,最高的奖金。更讽刺的是,那些被捧成英雄的人,压力大得要命。所有人都指望他解决问题,他不敢说不会,不敢说累,不敢休息。见过一个项目,技术核心离职,留下一堆没人看得懂的代码。因为知识是分散的,经验是共享的,任何一个人离开,都不会让项目陷入瘫痪。那些真正走得远的团队,从来不是靠一个英雄力挽狂澜,而是靠一群人并肩作战。遇到问题,不是等某个人来救场,而是大家一起讨论,各自贡献自己的专长。老张累趴了,项目还是延期了,因为关键节点全压在一个人身上。一个靠谱的团队,不应该有不可替代的人。
2025-11-13 13:23:55
114
原创 芯片项目延期?因为你把资源给错了人
但很多团队的流程都是祖传的,没人敢动。结果就是明明可以同时干的事情非要排队,关键路径被人为拉长。每个环节都可能delay,但只有关键路径上的delay才会直接推迟tape-out时间。,计算资源应该优先给关键路径的仿真验证,供应商沟通要重点跟进关键路径的IP交付。前端综合等着RTL代码冻结,后端布局等着网表交付,验证等着环境搭建完成——这个问题问清楚了,资源往哪投、会议找谁开、风险怎么控,全都有答案了。非关键路径上的任务有时间buffer,晚个一两周不影响大局。识别出关键路径后,第一件事不是加人,是。
2025-11-12 16:57:18
280
原创 项目成了,但团队其实还能做得更好
前端和后端之间,明明可以提前对接接口规范,结果拖到后期才发现对不上,浪费了一周时间返工。验证和软件之间,明明可以同步推进,结果验证环境搭好了,软件团队还没准备好测试用例。如果每次项目成功了,领导都是一通夸,团队会以为自己已经很厉害了,就不会再想着提升。还有技术深度的问题。如果团队只是完成任务,而不是提升能力,那这个项目再成功,对团队的价值也有限。如果团队的能力不持续提升,今天的成功,可能就是明天的瓶颈。然后最重要的,是告诉团队:我们做得不错,但还能更好。搞不清楚这个问题的团队,赢得了项目,但输掉了成长。
2025-11-10 08:17:40
246
原创 芯片工程师是微观世界的火箭科学家
从粗一点到细一点再到超级细,芯片里的结构越来越小,物理规律开始在这个尺度上”不讲理”了。芯片能用,就是成功”入轨”。这就像火箭要飞得越来越高,环境越来越极端,每一个物理现象都在挑战工程师的控制能力。少算一个数,漏掉一个检查,忘记拧紧一颗螺丝,结果就是几亿美元在你眼前炸成烟花。这些小到看不见的开关每秒要开关几十亿次,在指甲盖大小的硅片上制造出惊人的热量。芯片工程师要在头发丝万分之一的精度上驾驭这一切,难度不比把火箭送上火星低。尺度不同,但本质一样——都是在用人类的智慧,去驾驭一场精密设计的爆炸。
2025-11-08 18:20:25
154
原创 放手,也是芯片团队leader的顶级能力
做综合的同事,对工具的脾气比你摸得透。你要做的,是建立一套让信息透明流动的机制,让相关的人都有渠道了解到这些信息，而不是让所有决策都经过你这个"中央处理器"。先问工程师的判断,而不是直接丢一套方案过去。leader每次都抢着给方案,久而久之就懒得动脑了——反正你会告诉我怎么做。说到底,芯片研发拼的是团队的整体算力,不是leader一个人的主频。那些真正厉害的项目,往往不是管出来的,而是给足空间长出来的。技术出身的管理者,往往有个执念:我不盯着,项目就得出问题。很多做芯片研发的管理者,每天忙得像个陀螺。
2025-11-08 09:48:34
272
原创 00后让管理者破防了
以前管人是道数学题。要么学着把管理变成一种艺术——理解他们在想什么、在意什么、需要什么,然后用他们能接受的方式去沟通、去推进。一个做数字前端的00后工程师,你让他优化时序,他可能先问:"为什么要这么做?一个架构师如果只是听命令画图,设计出来的东西大概率是平庸的。更让人崩溃的是,00后对"权威"这个概念近乎免疫。00后不是来破坏规则的,他们只是在用自己的方式,倒逼整个职场变得更人性化一点。那套"我是领导你听我的"的管理逻辑,在00后面前彻底失灵了。管理的本质,应该是激发人的主动性,而不是压制人的独立思考。
2025-11-07 07:39:26
351
原创 辞职不是因为不爱工作，而是懒得再说话了
验证工程师要跟设计对testcase,后端要跟前端确认时钟树,项目组要跟市场部撕需求。但当一个人发现,说了等于没说,推了也推不动,一个做数字前端的工程师，在周会上提出优化方案,被项目经理一句"现在没时间折腾"打发了。第三次,他就不说了。加班起码看得见产出,沟通无效就是纯粹的精神内耗。慢慢地,人就不想说了。那些混日子的,本来就不care事情怎么推进,自然也无所谓说不说。那些离职的人,带走的不只是技术经验,还有对这个组织彻底的失望。健康的团队,应该是说了就能被听见,提了就能被讨论,不想说,不代表不在乎。
2025-11-06 12:23:09
247
原创 没人管你难不难过,大家只关心这颗芯片什么时候能tape out
醒醒吧,连亲爹亲妈有时候都懒得哄你情绪,更别说那些和你抢资源、争绩效的同事了。当你不再期待别人照顾自己的情绪时,反而会活得更轻松。没有,也是正常的职场生态。客户催进度的时候,没人在乎你昨晚加班到凌晨三点,他们只想知道ES样片什么时候能出来。每个人都有自己的KPI要完成,自己的项目要推进。公司付钱买你的专业能力和时间,不是雇你来寻求心理安慰的。做好手头的活,按时拿到工资,这才是最实在的关系。当然,这不是说要把自己变成冷血机器。你的芯片还没做出来,别人的板子也在等着联调。管理情绪是自己的责任,不是别人的义务。
2025-11-05 08:01:46
261
原创 一颗芯片失败了，没人能独善其身
太多技术很牛的工程师，偏偏在协作上栽跟头。更常见的是跨组开会时各说各话，前端觉得后端不懂设计意图，后端抱怨前端给的约束根本没法实现。后端说这个floorplan有问题，多半不是故意为难，而是看到了congestion的风险。芯片设计本来就没有唯一正解，不同trade-off之间的选择，本身就需要团队反复讨论。芯片团队里什么人都有：有人喜欢激进的架构创新，有人坚持稳妥的方案。说到底，芯片研发拼到最后，拼的不只是个人技术有多深，还有团队协作的效率。学会协作，不是为了当老好人，而是为了让自己在这个行业走得更远。
2025-11-04 07:53:29
188
原创 想让员工改变?别批评,先夸他
只是新来的leader在代码review时说了一句:"你这个算法思路挺巧妙,要是能再优化一下时间复杂度就完美了。"就这么一句话,小李整个人就活过来了。小李最近像变了个人。以前交付代码总是拖拖拉拉,现在主动加班优化代码,还自己搞了个性能分析工具。同事们都好奇,这人吃什么药了?芯片公司最常见的管理风格:挑错。代码review挑bug,方案评审挑漏洞,周报会上挑进度。眼睛永远盯着那百分之二十的问题,对百分之八十做得好的地方视而不见。比一百次批评都管用。
2025-11-03 12:14:23
140
原创 认真做人，诚实做事，追求结果，享受过程
debug找到问题的瞬间，设计通过验证的时刻，芯片第一次跑起来的那一刻——这些小确幸是真实存在的。那些确实会影响芯片质量的环节，再累也得啃下来。该做的做到位，不该纠结的就放过自己。芯片不会因为你的焦虑变得更好，反而可能因为你的过度紧张出更多问题。时序约束该写清楚就写清楚，验证该跑的case就跑完，设计文档该更新就更新——如果你每天都觉得痛苦，每个任务都是煎熬，那要么是方向错了，要么是心态崩了。至于你中间用了什么方法，走了多少弯路，代码写得优不优雅，其实没人在乎。芯片研发行业的诚实不是软弱，是一种效率。
2025-11-02 09:55:26
241
原创 越偏科越值钱
testbench里的随机约束写得像艺术品，一晚上跑出的场景比别人手动写一个月还多。一个成了公司验证方法学的制定者，那些精妙的constraint solving策略让后来者受益无穷。找到你在验证链条上真正擅长的点——可能是激励设计、可能是工具开发、可能是形式验证、可能是性能分析——然后疯狂放大它。他搭的自动化流程，让验证工程师从重复劳动里解放出来。芯片流片一次几百万，项目组要的不是验证全才，要的是在关键环节能顶住的尖刀。这个行业不缺什么都会一点的人，缺的是能在关键时刻力挽狂澜的偏才。
2025-11-01 07:04:00
193
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人