當主管要求資深RD撰寫自己經驗的文件 - 工程師

同意啊 系統廠風格程式會動就好，然後就變成量產

然後要clean code不能放註解

open source給大家點評下 新人或外包取代的可能

同意，要好好幹就要讓它有價值

做事情還有要幹不幹的？公司過太爽？老闆太混？

不是個人想搞大就能大場面，倒是人事來看內部培訓

if any question是錯誤文法喔

非常正確，不只是做給別人看，同時也是建立工作成就
感。

搞大也要能屁的出來啊，現實是會屁的早都變主管了X
D

以台廠風格越級不一定好就是 抬轎能跟著起飛也沒有
不好

如果是公司明確給你的任務再寫，不然手上任務項目都
做不完了

也可能剛來不久準備屁一發起飛XD

原po說的沒錯 你寫那麼多就是幫主管抬轎 但升遷加薪
沒你的份，甚至讓他的人把你心血嘴砲一波 一起上位

這篇做法很棒，建立自己專業權威，辦的好也給主管
面子。

花花轎子人抬人，完全不想抬別人的人也不會有人想
抬你。但是抬別人要抬的有技巧，讓其他人有一天也
願意抬你

推這篇心法 懂的都懂

推一個

這篇真高手 完全正確作法 若真是厲害根本不怕人學

分享技術是建立地位與人脈的好機會 好好利用就對了
下面也有人說了 很多公司分享技術是常態

若在自己公司能有這機會當領頭者 其實很棒

不要怕投桃 投桃才會有人報李

這篇才是真相，code review?會動就痛哭流涕了

公事如果要求合理當然不能選擇，但是重點是做到什麼
地步。例如說明程式邏輯上為什麼會動跟怎麼樣的概念

去做全盤的規劃是兩回事，可以說是招式跟心法的差異
，兩個都是可以應付老闆，但前者偏向單純地公布勞動
成果，後面偏向個人融會貫通的經驗。畢竟公司只是買
你當下的勞務，不是整個人的人生經驗都充公吧？招式
或心法能不能教取決於自己的核心利益，如果每個同事
人都很好很願意公開分享，抱著大家一起進步的觀念毫
不保留也是可以。但是以原本的例子來說，看起來不像
是這樣。這個時候就要自己懂得“分階段出貨”。比如
先起頭寫大綱刺探老闆的需求，從最不痛不癢的格式跟
scope搞起，一方面看看到底真正的需求在哪裡，是不
是真的跟自己想的一樣技術要脫光光還是還是只是老闆
或某個單位轉達的需求，這都會嚴重影響交付成果。另
外也有判斷需要真正理解這些文件的單位到底是哪些，
只需要重點照顧到這些單位的需求，其他寫太多根本沒
人看，只要弄到需求單位沒意見的程度就好，一般的主
管誰管你這麼多？另外就是會不會影響到自己的loadin
g能不能丟出去，能丟給別人維護的、當然優先教，當
然也是以這些部分優先。說實在，文件最重要也是唯一
的關鍵點就在於誰要看、誰該看這份文件。scope跟aud
ience沒定義出來一切都是枉然。

製造業很多code你明明知道不該這樣寫，但是量產最大
，今天要汽車明天能下水後天要能飛

code review完難道要處長去找廠長抱怨產線愛亂玩？

寫一寫方便人家讀而已 真的不用整天幻想有什麼獨門
技術
軟體改變太快了

原PO他無法開班授課啦 Y

正解，推

這篇很懂辦公室政治，推
最沒價值的真的就是被別人拿去私用而沒建立起個人品
牌

推方法

同意