职场上有两种问题
一种是人际问题
一种是技术问题
技术问题要解决需要平心静气摆脱掉阶级意识互相说服
但文人相轻，工程师也相轻
要你的主管摆脱掉阶级意识本来就不容易
如果你确实比他强了，那他面子往哪摆
有些年轻工程师就是只会写Code
人际关系几乎是0分
掌握资源的人是主管，掌握资源的是老板
讲难听一点工程师再厉害都只是劳工的
是看老板脸色吃饭，很厉害的工程师也只是换间公司工作
要出去创业，接案也要看客户的嘴脸吃饭
除非你客户多到不行根本不缺客户
不然跟客户我不觉得跟公司上级相处有什么差异
差别只在于自己创业因为市场很大
这个客户不行，你可以再换个客户
成本很小，把这个客户扫地出门就好
但找工作成本和时间都大得多了
回过头来为什么强者A没办法让主管听他的
我就自己脑补一下我自己的经验
这种很厉害的人，通常都比较自傲，讲话也很直接
偏偏主管绝对是玻璃心的
你要像对待一尊玻璃神像一样对待你的主管
常常拿起来摔啊，撞啊，你觉得玻璃能不碎吗？
再脑补一下，即使你不自傲，让主管觉得你是个威胁
可能主管也会弄你会是妨碍你的路
装笨有时候也是一种艺术
大智若愚，你这么强有时候也要拍个马屁，请个饮料
装傻一下，就是因为你有缺点，有弱点，主管才会觉得你可信任
你马的code都写得飞快，算法超强，资料结构三十秒随意拆解
你觉得主管放你在身边会不会觉得你是种威胁？
这么厉害应该晚上回去多多写开源和教学
让市场看见，而不是去纠正主管，你纠正他越多，他给你的资源越少
资源的分配权力在上面
不是在下面
要有话语权你要先有舞台啊，把现在在舞台上的主管砲轰一顿
跟在看电影的时候在台下嘘演员意思一样，你就算是再厉害的演员
也要尊重现在正在台上的人，这样未来你才有舞台发挥
再来是彼得原理
台湾的技术部门主管随着公司不同，有的要实际处理Code和管理专案
有的不用，有的算是业务性质或者兼著其他部门的主管做
他不见得懂Code或者以前会，但上了管理职这些东西不熟了
或者技术演进，没跟上。
而这些不熟新技术的主管，开明点的会找员工帮自己加强或者自己看
又或者可以听进去下面的话，那不开明或者比较老古板的阶级至上
你阶级比较低还不听话，他当然想办法把你踢掉，人类某种程度跟很多动物很像
都还是有地盘的观念，跟狼一样，在狼群里面你只能听首领的
吃肉永远都是首领先吃，后面的再依序阶级吃
有时候阶级到了，就算你不是狼群里面最会抓猎物的
大家也是得听你的
难道张忠谋会是程式王？ 还是制程王？ 还是蚀刻王？
在台积电他这些能力都超弱了吧，管理也是世界第一？
为什么他是董事长，而你只是轮班星人？
如果你不想待在这狼群，想自力更生也可以
出去一只狼，很容易饿死，因为狼群可以做战略攻击
而一只狼只能单兵作战
狼群首领废物你要挑战狼群首领，很容易被其他狼一起杀掉
这跟职场一样
只能说先处理好人际关系
才能进入到核心的技术问题
主管不听就顺他意思就好，就跟客户不听专业意见
一意孤行，你就听客户就好
拿钱办事就是这样，钱拿到最重要
去上班就是去赚钱的，不是去比赛谁是程式之王
不能说这样的生态对整体环境是好事，但先找到你的舞台
你才有机会让别人看见你
大丈夫能屈能伸，在狭缝能生存，在宽广的地方也能大放异彩
才是真正的聪明人
※ 引述《imindflow (imindflow)》之铭言：
: 小的提供一个公司裹发生的实例给你参考
: 公司有个强者A，就是喜欢写程式没事就看一些open source那种，
: 喜欢和别人讨论技术问题，也喜欢帮别人解决问题，学习速度很快，
: 常常1个新东西交给他，他很快就会比你熟
: 而且更强的是，常常他的看技术的sense比大主管好
: 例如大主管做了一个技术决定，
: 强者A会很小心的提醒大主管可能会发生什么问题？
: 但大主管往往不会听，结果最后还真的每次都发生问题...
: 另一个"__者"B，写code比较脏一点，凡事交差就好，不太多话
: 大主管说什么，B都照做，然后错了，再跟大主管说错了
: 大主管会再下另一个指示，B会再去做
: 有时要做个3个循环，才会找到正确解答
: B就是属于乖乖听话当主管的棋子，没有自己的想法的人(或是装傻)
: 让你猜，谁最后变成部门主管?
: 答案是B，而且加薪5万升了副理，月薪15万左右
: (不过公司也快倒了..)
: 强者A呢？离职后不知去向
: 本人刚好也是热爱写程式的，当A走了之后，我也跟着走了
: 最后在另一间公司，跟一群开明的同事在一起，
: 没有什么上对下的关系，学到好多东西
: 所以建议你，跳吧!!
: ※ 引述《tommady (tommady)》之铭言：
: : 个位前辈好，
: : 不才小弟我前天与主管发生争执，
: : 是软件架构上的设计想法不同。
: : 文章可能有点长，
: : 如果前辈们不喜爱，
: : 还请见谅。
: : 小弟写后端的，有一个case分配刚好是
: : 主管写game server
: : 我写game logic
: : 由于是第一个游戏，
: : 所以没有任何前例或者范本或通用架构，
: : 现在写的一切就是未来的依循，
: : 然而在前期讨论都很顺利，
: : 意即 ，
: : game server就是包含除了实际游戏逻辑以外全部的部份，
: : 我只要写好游戏逻辑，例如牌类比大小，
: : 我只消管怎么比大小就好，
: : 其余的都由game server处理。
: : 这看起来很完美，
: : 但实际做出来的时候，
: : 我原本预想由我提供几个interface，
: : server只要呼叫这几个就能完成一局游戏，
: : 比如:
: : 1. start
: : 2. stop
: : 3. command handle
: : 争议点在command handle，
: : 我原本期待的是game server收到任何
: : client传来的命令，只需要by pass给这interface就好，
: : 这个interface会自行处理。
: : 但是主管坚持，他只提供client命令的读写 ，
: : 其余的游戏逻辑搞定。
: : 也就是他只管server client之间沟通的library。
: : 这样变成我的游戏逻辑得处理命令的接收，
: : 逻辑得fork一个thread去听有无命令进入，
: : 而不是定义该怎么处理命令，
: : 然而这样会让未来每款游戏都需要重复的处理命令。
: : 怎么想都觉得这样十分鬼异，
: : 我说，
: : 我想要的是只需要填肉，骨干可以通用的架构。
: : 主管回，
: : 你别管这么多，以后的人写不好写不顺，
: : 我会开除他，别管骨干通用。
: : 争论到最后，主管直接爆气讲，
: : 你别觉得自己写code很厉害，
: : 我说这样就是这样。
: : 当然，主管都讲到这份上了，
: : 我只能默默的说，
: : 只是想提醒这样架构会造成重复，
: : 以及通用性不足。
: : 然后就吞了。
: : 唉，小弟以前写bios的，单兵作业比较多，
: : 请问我该如何处理这种多人协同作业上的歧义呢？
: : 感谢。