Re: [請益] 當主管要求資深RD撰寫自己經驗的文件
額 這種要求還是第一次聽到
如果是畫畫UML圖
講一下各系統的關聯 讓新接手的同事能快速上手
這個是滿正常的
有底子的人看圖再自己追code就夠了
可是要寫到為什麼選這技術
為什麼用這演算法
這個講不完耶 要講可以講很深
不懂主管要你做這個的用意
要嘛就準備個報告 分享給全team的人
有問題直接問 這樣比較好吧
有些東西是靠經驗的
我覺得這裡有資安風險 或是這裡可能是流量瓶頸
就會多做些保護措施
只可意會不可言傳
如果用講的就能懂 那幹嘛還要資深RD
要分享當然能分享啊
問題是學得人功力不夠
也聽不懂為什麼這樣做 那等有興趣的人自己來問不是比較好
至少他知道這裡是有竅門的 這時候的分享才有價值
不然你叫一個資深架構師 分享大流量網站設計經驗
結果底下都是新手 根本不知道這個東西厲害在哪
還不如寫個簡單的文件讓大家看得懂就好
所以這題是要看情況
如果同事都是高手 就寫詳細一點
如果新手居多 就寫些需要注意的點就好
--
※ PTT 留言評論
1
好奇是真的遇過這樣的事情,還是純粹自己想像. 想了一下大概有幾種狀況 1. 如果是公司文化或新的大頭希望公司能加強文件,那就乖乖配合 確實有公司會要求文件寫得很完整. 2. 公司即將資遣你,所以希望先把你的東西挖出來18
原文恕刪, 用職場生存的角度來看,我個人建議是「寫,但場面要搞大」 如果要寫,就好好作,讓它變成一場內部訓練,記得開課發信邀請要cc高層主管 這件事下下策就是賣命寫然後只有寄給開口要求的主管,幫他抬轎 如果真的很忙只能隨便寫,那就做個樣子,寄給大家時補一句10
????? leetcode那點東西要刷10年? 你哪來的自信覺得自己是什麼絕世高手? 我以為要稱高手,最少最少也要在GitHub開宗立派耶? : 10年下來,2
自己花時間得到的經驗, 不論把文件寫得多詳細, 別人都不太可能 不花相近的時間學成。 完成一份詳細的文件後, 因為又重新思考了一次,爆
首Po請問當主管要求資深RD撰寫自己經驗的文件, 請問員工該如何運對呢? 我隨便舉個例子 已寫C++語言程式為例 有個10年資歷的A員工,2
現在我是即將要畢業的學生,未來應該也是到豬屎打工 不過我想來說一下對於「分享」的感想 由於本身不是正統IC LAB的學生,所以面試題目、知識大多都是看google的 Google了很多相關的東西,其實發現一般來講台灣人比較少討論這方面的知識 連FPGA一些使用技巧也大多都是中國論壇的討論
28
Re: [請益] 發現同事反組譯自己程式碼怎辦我還是補充一下我待的不是資訊業,我們程式都各寫各的,各自負責互不相干, 沒有強制一定要簽入版控,休假會有代理人,但不是他,離職當然程式是公司的, 但是現在沒有,也沒有跡象要被FIRE,主管應該也不會叫他做這種事。 我寫的這東西主管知道,而且已經上線穩定運作一年多了,屬於Service,有釋出API給 內部使用,所謂技術價值是指可以影響公司的競爭力,而不是一般人隨便弄弄就有辦10
Re: [請益] 當主管要求員工留下獨門經驗的技術文件其實寫這種文件 受惠最大的還是自己啦 為什麼不寫? 尤其是當你面試下家公司的時候 過去做過哪些project7
[閒聊] 有沒有被主管 同事...整過?如題, 邀請大家分享故事, 讓大家知道彼此不孤單? 簡單分享: 向類似主管的同事問問題,3
Re: [請益]高流量網站和資料結構高流量應用 你沒定義好需求根本無法討論怎麼設計 1. 資料一致性要求? 持久性要求? 如果一定要用到交易,基本上一致性和持久性就一定要, 就直接用掉 CAP 定理的 Consistency,算是最常見的瓶頸 2. 如果是寫 log 系統,這種 QPS 要破萬比網站容易多了,也很常見