被 Manager 批评了，但是我觉得我做得对，怎么办

[Mikawa]

这周被老板喷了，有点难受，不知道是不是我做错了，发出来请老哥看一看

我是去年跳槽进的现在公司，进去不久 Manager 分了个活给我，让我做一块小东西（一个通用的技术需求），因为不算绩效，所以可以自己折腾。我在开工的时候拉了个会和组里其他人过了下设计，就开始做了。

那个活我当时打算拿 node 写个 CLI 就行，但是实际写完之后发现还有些可以做的，需要在 CLI 里加个命令，本地起个 UI ，类似 Prisma 那样，就开了个 nextjs 的应用，和 CLI 放在同一个仓库，把那个仓库改成了 monorepo ，后面因为循环引用，就把 cli 里的一块逻辑提出来了。

上面这些坑挖了不久，我就因为被其他原因 block ，暂停这个 CLI 的开发，最近打算继续做，就在周会上提了下。

我 Manger 刚好打算对另一个新成立的组输出些东西，就找我要了仓库，说看一下。实际是打算把我做的和他手下另一个做这块的人做的东西缝一下，提供给他们组。

分支是周四发的，周五晚上他在微信群里 @全体，说不要把代码写的过于复杂，过度包装，还用了个抽象的比喻，我也没多想，就没管，也没想是说谁。

结果第二天打开工作 im ，发现老板给我留言批评我，说我过度包装了，让我把 monorepo 合回去，并且说“他以为可以分分钟给出去，最后他自己写了，这些功能几个文件就搞定了 balabala”，最后说这也不是什么大事，让我不要担心之类的

我一直觉得我和老板脑回路对不上，平时他带了好几个组，所以不常会和他一起交流设计，但是一旦开始讨论，意见几乎必然相左。平时都是在设计的时候意见不一致，这次是实际发生的事情，一步一步有迹可循，所以我直接给他说了我为什么这么做

昨天晚上他看到我的消息，还是说我做的不对，s 说我是在乱叠包装、杀蚊子用大炮，他自己写就几个文件，别人还可以改 balabala

刚刚醒了看到他昨天晚上的消息，人有点麻，完全没办法沟通，去年跳槽就是希望去外企工作氛围能轻松一些，结果老板完全没办法沟通。

总之我把我为什么这么做再详细讲了下，并且给他抗议他不经过我，直接扒代码，扒不出来就说我过度包装的行为，让他后续有这种例子叫上我

补充下背景：

这个活交给我的时候是组里自己用的，不算绩效，做得出来就做，做不出来就算了

核心需求是让我解决项目里文案提审的时候需要人肉梳理的问题，我是拿国际化的方式把文案抽出来，写了个 diff patch 的把改动抽出来提审，修改好把改动应用到项目里，整个功能不至于几个文件就能搞定，而且迭代了一段时间加了些相关功能后，还是有一点代码量的。后面开 nextjs 的应用是发现有些别的功能可以做，需要提供 UI

我 Manager 的喷我的点是我搞 monorepo ，属于过度包装
我这次希望他能够明白我为什么这么做，所以和他解释了两遍。我是觉得如果要给其他组用也好，要整合也好，可以叫上我一起，而不是自己弄了发现问题把我批判一番，如果他能明白我为啥这么做，以后交流说不定会顺畅些

我有和 Manager 说我会把 monorepo 合回去，也没有在群里和他对线，都是私聊的。我是因为自己和他想法总是不一致，比较困扰

我意识到我最核心的问题是没有“拿钱办事”的观念…毕竟上一次跳槽也是因为遇到了自认为不合理的事，并且不可调和

我对 Manager 的理解一直是“大头兵遇到问题抛给他他来解决，其他时候纵向带队提升组里的技术，横向和其他岗位配合提升项目”，来新公司遇到微操的老板完全不知道咋配合了

（我还是想给自己开脱一下，这个活之前从来没人看过代码，拆 monorepo 之后对外暴露的还是个 CLI ，之前在组里讲的时候也说过要开个 nextjs 做 UI ）

[wunonglin]

不用太过自责。他只不过是遇到自己不会的领域了而已

[Procumbens]

个人意见：自己的项目想怎么来就怎么来，公司的项目往往是要跟别的组对接的，一般还是听 manager 的

[w2er]

楼主大早上的消消郁结，既然是老板，有没有对下属谩骂罚跪人格侮辱之类？有没有工资克扣之类？其他事不都是老板您都对嘛，这点事就跟老板硬刚，还来回刚，就你面子值钱，不需要给老板留点面子是吧。
另外建议尝试考虑下，
1,自己公司该不该，有没有权利复用自己公司的现有代码？
2,到底是简单明晰了后面使用和维护过程中有好处呢还是块块力求纷繁备全后面大家才更高效？
3,同一个要求，我们到底该花一天时间给出简单直接可接受版本，还是花十天时间给个尽可能多的展现了我更多能力的力求完美主义版本。不论是从公司角度还是个人角度，我该如何选。

[aulayli]

你跟老板计较什么？打工人要有觉悟，工作上老板做啥都是对的，不要反驳，不要顶撞，非要杠就只有六字真言了😂。

[kx5d62Jn1J9MjoXP]

抗议他不经过我，直接扒代码，扒不出来就说我过度包装的行为，让他后续有这种例子叫上我

如果你做的东西是很简单的但是你的代码会让人"扒不出来"，那问题可能在你

[ruidoBlanco]

第一，manager 做太多 micro management ，甚至插手代碼用哪個庫，是個不懂如何管人的 manager 。但是這是他的問題，不是你的問題。
第二，打工人不跟老闆計較，他說什麼都聽。拿吃屎的錢，幹吃屎的活。這鍋算你的。
第三，manager 是坨屎，得跑路。這鍋也算你的。但這跟第二條並不矛盾。

[cuebyte]

如果这是你一个人的项目，你想怎么做就怎么做了。可实际上这是要在公司内部用的，你就需要在每一步和相关责任人达成共识，不然这锅你就真甩不掉。

你开工的时候拉了人说是做 CLI ，但之后改成 monorepo 应该没有沟通好；你可能在早会上提了，但他们可能以为你就是加了点小功能，提升了一下 UI 。实际上一到手上发现居然成了大项目，自己还都不知道。原本以为把你和其他人做的东西整合一下就行了，结果发现小需求变成了大项目。类似于你女朋友出门买菜，结果刷了一辆车回来，惊不惊喜，意不意外？


你觉得沟通困难，是因为你没有沟通，而是事后给自己擦屁股。不信任感已经产生了且愈演愈烈，当然会越行越远。

[chuck1in]

楼主能说下详细需求吗？文案提审是啥意思？

[Mikawa]

@chuck1in 我们项目的文案在设计稿里是设计师和产品写的，但是上线前会给专门的组审核这些文案，他们会提出一些修改。因为迭代拉得比较长，所以人肉找出文案挺麻烦的

[chuck1in]

@Mikawa 相当于你要比对上一个版本的 prd 和这个版本的 prd ，然后把改动 diff 出来，整理以后给审核小组发过去。他们审核改动好以后，你再 merge 到现在的 prd 里面吗

[Mikawa]

@chuck1in 嗯嗯，差不多，我比较的是代码，因为实际开发的时候遇到的小改动一般不会体现在设计稿里

[chuck1in]

@Mikawa 如果要做一个成熟的工具出来感觉挺不好做的，能请教下怎么实现的吗？每次需求可能增加了很多新文案，这种你怎么统计？是专门标记某个 html 元素中的 text 来统计的吗？

[Mikawa]

@chuck1in 我让其他同事帮忙在文案上加上 i18next 的包裹，这样就能标记出文案了，标记的文案可以用 i18next-parser 这样现成的工具提取。

diff 那块我的思路是用 json patch 来描述项目里 i18n resource 从初始化开始每一个迭代的改动，把改动记录存在项目里，类似 git 那样，因为是改动，所以合分支的时候冲突也只会出现在记录 commit 列表的地方，解决的时候 CLI 提供个 gny 直接跑一下三路合并就好。如果要取巧的话，可以只在主干跑一次，这样就永远不会有冲突。

提出来的 diff patch 可以转换成一个 excel ，拖到在线文档里让审核组看一下，改完拉下来跑个 merge ，把改动记录下来，修改 resource ，这样就行了

[Helsing]

在一个团队里，写代码最好要和原项目架构和设计保持一致

你想把代码设计的更好可以理解，但是：

1. 你原来和大家对的方案是 CLI ，但是你做着做着就改方案了

2. 你改方案没有知会到你的 manager 和相关方，没有了解其他人的意见和对别人的影响

3. 感觉你的沟通有问题，你做的时候，遇到问题，就要找机会跟 manager 说出来，和大家讨论方案，而不是擅自改动实现方案

估计你的 manager 看到你的代码的时候也是有点无语，怎么写出来的东西跟之前说的有那么多差异

[dandycheung]

在公司里做的事情，可以交付都是一个重要衡量指标。如果你在给自己挖坑之前，把项目做到了一个可以让人拿来就用的状态，那么，你既可以后续不定期维护迭代，也可以在任意时刻让有需要的人有的用。如果在当时就把这个工作里程碑同步给你的 manager ，那么应该可以避免这次的尴尬和委屈。总之，对工作成果有自发性的高要求，这种工作态度值得肯定和保持，不过工作方式还可改进。其实是个小事，不用过多挂怀。

[mrz3333]

多磕头，少说话。虽然我做不到！

[devliu1]

站在他的角度也没有错，涉及组与组之间的合作，复杂度高可能对方组里没办法改，还是要多 sync up 一下

“外企”+“微信群”这个组合就很有意思

[lasuar]

实现之前先讨论方案是否受到领导认可，最好不要有的自己的绝对技术思维，因为这不是你的个人项目。

[yougg]

老板给你钱，你还要教老板做事？
你是什么顶级行业咨询师吗？

[urnoob]

op 目前不明白
任何项目首先是交付
其次代码简单比复杂更难，何况就是个工具。人人能改，不容易改错才是工具。
外企比较开放，不会和国内互联网企业相互斗的那么厉害。碰到调整和裁员，移交的就移交 不会因为你特意做的复杂而留在你自己手里。
反而在移交后还要支持人家，对方首先要找的就是你上司。

[Mikawa]

我有个问题，monorepo 难道不是对 CLI 的横向拓展吗，为什么会有这么多人认为这是改变了项目结构呢

[air00dd]

@ruidoBlanco #6 manager 应该是搞心机对老板画饼、撒谎了，甩锅给 op 。老板应该不知道 op 的是个人项目，以为是公司项目。

[yuanmomo]

个人看法，你自己说的还是有很多活可以做的。我不知道当你在开始做这个优化的时候，你有没有主动沟通。

个人的工作方式，一旦自己做的东西，跟 leader 之前想的哪怕有一点点不一样，都会及时的跟他说清楚，然后再开始做。这个是沟通能力中最基本的一点。自己是干活的，要随时让 leader 知道干活的进度。

其次，你说你的意见不一致，这个不能说你 100%都错，你 leader 都是 100%对。我曾经跟你一样的做事情的态度，但是后面随着工作年限增加，自己也慢慢带项目，就开始懂一些了，才开始意识到其实之前大多数跟 leader 意见相左的时候都是自己的问题，自己没能从更高的角度去看带一个问题。这个最终在我自己带项目，带团队的时候，遇到跟年轻的自己差不多的时候，体现的淋漓尽致。那个时候，经常听到领导说：不用做得这么麻烦，你就简单加个 xxx 就行，这个项目要是真的做到那样的级别，一定会重构，而且肯定不止你们几个了。然而，事实证明，那些项目，后来全死了。

[air00dd]

“不算绩效，所以可以自己折腾”：是不是 op 已经被 manager PUA 了？就算不算绩效，还是要按公司要求做的，自己折腾太自由还是要 op 自己背锅的，本来受雇就是为公司做事，并不存在真正意义上自己折腾的空间。

[air00dd]

manager 为了自己的业绩，肯定后来对这个项目过度吹捧让其他不明真相的人有过度期望。op 和 manager 谈话的时候应该带录音笔，以免频繁被暗算、被他甩锅。manager 和老板肯定谈过什么 op 不知道的东西。

[fnmgzbv2]

首先，打工就系听领导的，领导需求就是对的，你可以推介一下自己的，不行就要放弃了。自己觉得好的，可以提升自己的就自己私底下完成作为以后的资源。

[wangkun025]

你和 manager 的沟通太差了

[ruoxie]

及其厌恶过度封装，提前封装的行为。借着 Dont' Repeat Yourself 的名义，拿公司项目练手，封装一些一个两个月之后自己都不知道是什么玩意的代码，残害别人。

[Otho]

你没摸准你的 manager 的脉，其实就是还没有相互信任，这个是要通过长期密切的沟通建立起来的。刚开始就要多沟通，即使在小的事儿也要沟通，慢慢的他熟悉你了，你也熟悉他了，后面就会好很多。以前经常有人提起向上管理，因为你的 manager 不可能完全了解你在做什么，多沟通，就是一定要让你的 manager 知道你是怎么想的怎么做的，来来回回一段时间后，相互熟悉了就好了。
这件事不必往心里去，以后多沟通。

[ZeroDu]

听领导的。这让我想起了有人在公司把 namespace ，package 这种用上自己的名字，网络昵称

[zhenghuiy]

第三方视角：OP 的出发点很好，感觉会是个自驱+有学习力的工程师，但执行方面有一些问题 —— 一个基本原则，在团队里的事，任何事以及任何时候都需要沟通好预期、同步好进展。也许你觉得它只是一个不那么重要的小事，但一件对方预期一天搞定小事跟你花费了好几天并且搞成大事，相差太远。

比较好的做法是：先尝试理解对方的预期，知道对方有个预设的方案，然后你要么先按照这个方案做出来交差，然后自己私下尝试用更多时间去做你认为更优的解决方案；要么在对方提出需求时你就跟对方沟通清楚，同步自己想尝试下用 xx 方案。

沟通，沟通，沟通，重要的事情说三遍。

[chunqiuyiyu]

不好好沟通，由着你自己的想法搞，我就想问一下你如果是管理者，手下人依着自己的想法各行其是，工作还怎么开展？

[NoOneNoBody]

你都悟到一些东西了，就不再重复了
补一个点：
“一个通用的技术需求”，这个确实不能太“自我”，不能写一个逻辑只有自己懂的东西
通用模块或程序，是不限人都可能调用的，因应自己的工作还可能有增减的需求，需要简单清晰
不然每个人想修改都要找你，且不论你是否三头六臂，在公司立场看也是低效率的

[xuanbg]

有一说一，monorepo 这玩意迟早得凉。

[jameskongawork]

“因为不算绩效，所以可以自己折腾。” 然后又 “实际是打算把我做的和他手下另一个做这块的人做的东西缝一下，提供给他们组。“ 然后又”@全体，说不要把代码写的过于复杂，过度包装“

这行为多少有点 PUA,需求变的比脸快

[Daming]

工作是为了什么，赚钱啊。想通这点就行了。
个人发展下班后自行提高。

[jameskongawork]

@jameskongawork 不过破这个局很简单，他要怎么做你就怎么做，他说的话要有邮件或者聊天。出了问题直接截图拍他脸就好。不用走心

[scys]

工作罢了，老板想怎么样就怎么样，轮不到你来说。
当时，你可以说明为什么想要这么做，如果他不同意，决定权在他。
就算你是已经做得，也没必要争，决定权在他。

[seki]

从时间线来看，你和别人过完了设计之后，就没有按照设计来完成，这之中也没有和别人再提起是吧
有时候有些问题是没有标准答案的，既然是老板的要求，那就按老板说的做吧
你这老板已经比较贴心了，会私聊和你说别想太多，虽然没有体察你内心的真正想法
建议约一个 1:1 和老板友善交流一下，总结一下以后用怎样的形式和他沟通，避免内耗

[zzwood]

优化逐渐逐渐做，你上来就想给人一个豪华汽车，你造了精美的车体，做了超智能的系统，也配了超好的轮胎，结果你发动机还没接好，你本来想给客户一个超好的体验，结果都跑不起来，反而客户失去了兴趣。你得一点一点把优化喂给他，他每次都看到有优化进步，他每次都有好的体验。一步一步来，不要上来就搞大的。不是有那么几句话，“先得有了，再谈优化”，“不要一口吃个胖子”，“胃口要吊才能满足”

[stillsilly]

做事不由东，累死也无功

[qzxs]

Zoom?