湾区tech一点小小的经验

在湾区某厂摸爬滚打了多年，从走过的各种弯路中想吐槽一些东西以及分享一些能给公司提高生产效率的总结。

1. most code without review
所有的非production的代码都不应该被要求code review.这么说吧，一个task, 我自己搞不用review的效率=review + 各种扯皮的效率的5-10倍并且保证production bug free. 多年的经验告诉我code review已经不再是原来单纯的code review, comments更像是职场politics的一种naive的做秀。所有的code要上production只需要通过configuration即可。出了问题也可以直接找到负责人。

2. no doc before code
什么design之类的，在写出代码前都是浮云。所有的项目都应该是code driven并在写出code后给出完善的documentation. Eng与Eng之间不需要通过design来交流，否则只能说明是自身技术问题。eng 与non eng之间可以通过doc交流。所有的架构上的tradeoff 都应该在code出来后根据真实stats做选择，几乎所有的design review也基本都=浪费时间。除了一些精英组，大部分正常组都是用它来凸显visibility以及天秀，根据我多年的design经验没半点卵用，而且经常是design一套，我implementation 由于各种因素又是另外一套。后来回想也真是后悔，倘若没有design, 我的项目都基本能减少50%以上的时间。

3. every piece of code need complete documentation
用来补充1和2，每块逻辑块都应该能直接map到一段文档并通过NLP测试达到能够被一个正常成人IQ理解的程度。这么做也基本可以消除大部分程序员之间的communication. 同时每段documentation都应该能反map到源代码.

4. no cross team project
.1point3acres所有的跨组项目都是没有定义好的项目。每个组都应该有相应的组的boundary, 而不需要任何的collaboration. 如果有只能说明director级别的无能与懒惰把自己的task下放给了下层managements. 每个team都应该拧好自己的螺丝，每个director都应该告诉每个team拧哪些螺丝，而不是下放给mgr甚至TL来去浪费时间跨组扯皮。换句话说，每个team都应该相当于是一个API，外部给了input就能给出准确的output. 所以任何跨组的东西都是在adjust各组的I/O, 这是应该由各组manager之上，sr manager或是director来决定的。

5. no standup/1on1/etc
任何的进度汇报，与mgr的perf沟通也都等于浪费时间。进度的stats 应该都是auto track的比如Eng自己update进度在tool里。每周的1 on 1也基本都是无用，绩效都有专门的dashboard能够track, 每个人的contrib, progress应该都是在dashboard上一览无余，任何项目上的沟通blocker也只需要chat即可不需要任何无用的跟mgr这一级的扯皮。

6. mgr is just a record keeper
经理的职责只应该是回报各种dashboard 的进度给上层，以及上层的指令传达给下层的eng. mgr不需要也没有义务去管任何eng的perf 因为perf都在dashboard 以及各种stats里。同时eng的年度rate也应该都是automatic来定。一个算法就可以各种指标来给出unbiased rate.比如代码量，个人项目完成度，代码production稳定度与可靠性以及各种其它metrics之类的。一个有效率的公司的mgr只需要做一个踏实的record keeper以及指令传达。

7. bad revenue = bad leadership
任何公司的盈利亏损都跟程序员没半点关系，程序员的代码再好，你们那些director/ vp给的指令方向不对也白搭。所以在盈利不好的时候都应该尽量保留底层程序员，尽量先开除高级别的director 以及VP。且cutoff职责不属于VP。程序员的cutoff基本都应该根据perf来定，倘若公司实在没钱养不起应该直接申请破产和程序员共生死。


希望地里各级的包括码农，mgr或者director的能够从中获益并为各公司积极献策，使得我们的科技公司能够提前进入到下一个level并顺利躲过经济危机在美国尽快实现繁荣昌盛与富强。

那就是说lz只管自己写，提前不给计划也不写design doc（PM不知情），互相不review（peer不知情），perf也不让manager管，反正tradeoff也不提前想也没法管。最后大方面出了问题全是leadership背锅。那得是多么信任你了解你而且自己也没压力的老板才能做到。

你这个是把公司里面的每一个人当成机器去运行，事实上工程师，经理和高管都是人。就拿做决策来说，没有人可以保证所做的决策制定的方向都是正确的。至于工程师，大家平常也有不同的职业目标，工作方式，以及背景。你这样管理很多工程师会很难受，而且绩效考核不可能完全公式化。你如果这样搞就会有人利用这个规则做优化，事实上没有一套metrics是完美的，Meta就搞了很多类似的metrics弄的里面卷到飞起。总而言之，你管理的团队是由人组成的，千人千面，不是冰冷的机器。这就是为什么大家要强调team culture的原因

匿名用户 发表于 2022-08-21 20:10:43
那就是说lz只管自己写，提前不给计划也不写design doc（PM不知情），互相不review（peer不知情），perf也不让manager管，反正tradeoff也不提前想也没法管。最后大方面出

我觉得小作坊比如一些小startup可以这么玩，大厂这么玩就完了。

楼主有大才，希望能闯出一片天

这个...........实在是不知道怎么comment了

那是全组rockstart的节奏啊！现实就是一个org就几个rockstar，大多数人是能偷懒就偷懒...产品质量和进度就靠那些撑着

stand up是真的浪费时间，还会被目光短浅的组员abuse成个人talk show

daily stand up完全是counter productive，不仅是低效，还会更容易让人burn out，因为不是每天干的活都能转化成talk，这样就会给人无形的压力

匿名用户 发表于 2022-08-21 19:45:34
这个...........实在是不知道怎么comment了

没人让你review，你comment个啥🥴