職場上有兩種問題
一種是人際問題
一種是技術問題
技術問題要解決需要平心靜氣擺脫掉階級意識互相說服
但文人相輕，工程師也相輕
要你的主管擺脫掉階級意識本來就不容易
如果你確實比他強了，那他面子往哪擺
有些年輕工程師就是只會寫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的，單兵作業比較多，
: : 請問我該如何處理這種多人協同作業上的歧義呢？
: : 感謝。