千万不要被 Leader 的鬼话影响

[zzhbbdbbd]

千万不要被 Leader 的鬼话影响 刚出来工作不久，感触很深的一件事情，很多时候对于一件事情的解决方法有很多种，当你突然想到一种很好的解决方法的时候，Leader 突然拿出一个烂方法说这个好，总是在朝自己灌输一系列他的想法，但是通常这个阶段的自己没有太大的说服力，再有力的理由也会打半折，你知道，代码这东西，只要能解决问题，他能扯 100 种理由来说他的观点，最后将你的方案丢掉，理由就是他觉得，他的方案更好，最后代码是越写越糟糕。

这样的团队不能提升自己，反而在走倒退的路，我觉得团队低于我的期望了，有时候真的想把公司的产品当作自己的产品来做，但是后来发现真的很难。

[ly4572615]

我不一样，我碰见的都是些好久不在一线的“领导”碰见影响业务的问题，带着一堆人靠开会连猜带蒙去解决问题，我们这里也没有 Leader 一说，都是自己处理解决自己的问题

[lixiangzaizheli]

不知道我这个 leader 的鬼话如何

[lixiangzaizheli]

https://imgchr.com/i/mSwmSf

[zzhbbdbbd]

@ly4572615 这样太好了，我们是一个部门有一个 Leader，这个 Leader 是技术，方案，拍板的，有的时候，Leader 真的就是整个团队的短板，什么都是他说了算

[also24]

转述一下我在之前的帖子里的态度
https://www.v2ex.com/t/546096


我做组员的时候，我会详细说明这么做的理由，以及主管的方案的问题，然后由主管告诉我最终结果：
“那就改掉吧” 或者 “别 BB，按我说的做”

我做主管的时候，了解一下组员想这样做的原因，陈述一下自己的想法，然后给出最终方案：
“那就改掉吧” 或者 “别 BB，按我说的做”


总而言之：
组员只要确保自己讲清楚理由，主管只需要确保收集足够的信息。
至于决策？你以为 “主管” 两个字是什么意思？

[also24]

之所以这么做，主要是因为：
当主管干涉你的方案时，主管要对他作出的决策负责


当然，如果你遇到了一个，干涉你方案还不为这个决策负责的主管，那确实是个糟糕的情况。

[betulac]

领导不是应该只关心你什么时候干完吗

[liangkang1436]

@also24 说的清清楚楚明明白白，令人信服！

[zzhbbdbbd]

@also24 看你这么一说，我觉得挺有道理的，但是有的时候他的决策虽然不会引发业务上的问题，这意味着他并不需要负责，因为没出问题，但是，代码却很难看，整个团队的代码水平是被限制住了

[zjsxwc]

碰到的技术领导水平和经验都比我高，code review 时是学习的时候，

碰到产品出身的领导确实有楼主这些问题，但是他们是老大他们说了算，不用多想造做就行，留下聊天证据，出问题不是我背锅就行。

[scofieldpeng]

给你一个小 tip 吧：觉得有更好的办法，带上你的理由给更好的方案。如果 leader 不认同，反驳你并且不执行，没关系。如果出事的时候，因为老方案的原因，并且领导愿意承担责任，跟你没啥关系。不愿意，你至少认清了这个 leader 可以说是不负责的 leader 了。
还是那句话，拿钱办事，要么忍要么滚。
最后，这就是为什么我家里有一个高可用集群的原因之一。如果环境给不了你想要的，那就自己主动创造一个适合你的环境。

[zzhbbdbbd]

@zjsxwc 是技术出身的，每次 code review 就是在把他那些糟糕的观念灌输给我，接受不了，拗不过，常常只有妥协

[zzhbbdbbd]

@scofieldpeng 谢谢，可能我对公司有所误解，我一直以为团队是能够帮助我提升的，发现缺了“好的团队”这个形容词

[virus94]

@zzhbbdbbd +1 部门里就所谓的 leader 最散漫,思想落后,大大小小的事都要插一嘴,跟村头的长舌妇似的.
可怕的是,公司居然可以一直容忍这种人存在.

[zzhbbdbbd]

@virus94 有的时候我挺理解他要考虑很多，其实有的时候他确实对他的烂 idea 很固执，很惊奇产品还可以活，现在项目里都是各种 patch，全局滥用，有的时候安慰自己这不是自己的项目。leader 真的是团队的短板啊，code review 的时候照做就行了

[scofieldpeng]

@zzhbbdbbd #13 好的公司是能在一定程度上帮助你成长，但是不要认为公司能帮你很多，最根本的还是靠你自己。

[also24]

代码难看这个事儿，因为没有具体接触，我不太好猜测具体情况。

有时我也会刻意要求组员写某些 “冗余” 的代码，乍一看有些过度解耦的嫌疑。
这种情况有时是因为我这边和产品 /业务交流的会更多，会预测到一些后期需求，不太复杂的预先准备工作，就在前期顺手做了。

这个只能说有利有弊，短期来看会增长工期，长期来看也有预测不准的风险在里面。
但是还是那句话，这部分责任，我会来承担，短期工期我来争取，长期风险我尽量降低。


另，如果我遇到有人写了有风险的代码，又不听我的意见的情况，时间充裕的情况下我不会太强求，而是会构造一个对应的特殊 Case 要求他处理，他就明白我的意思了。

[zzhbbdbbd]

@also24 赞同这种情况，但是在两种方案都可以解决问题的情况下，并且我的方案更能适应多种场景，他会以没有这种场景来反驳，然后采用他的烂点子。上面的你会出一个 case，他出不出来，也没必要出，拍板就行了...

[also24]

@zzhbbdbbd #15
“代码好看” 是要付出很大的成本的，老项目丑一些是常态。

代码不是艺术品，重心最后其实还是在业务需求方面。
有预见到风险的时候，及时告知就好了，个中权衡，让具体负责的人来做。

除非 leader 是无理取闹，否则还是以负责人说的为准吧。


组员：我觉得这样写，在高并发场景下，如果有两个请求连续操作 xxx，会出现问题。
组长：你想太多了，我们这个系统没多少人用，真出了问题那部分数据也不重要，别管啦。

组员：我觉得我们应该把 xx 拆分出去，方便下个项目复用
组长：你妹的这个项目工期还有 3 天了，你给下个项目省时间有个鬼用，别管啦。

[zzhbbdbbd]

@also24 可能我觉得代码是艺术品...